Programmers write a lot of code. Some of it good, some bad, the rest just plain fugly. There’s code to provide functionality, code to prove a point, code to research a bug, code for fun; well, code for every occassion. So let’s examine the production occassion.
We’re employed to implement a feature and there’s a lot of code that needs to be written. But before we settle into implementation, we need to locate where it will belong. Like my cats kneading their sleeping spot, we refactor our bed of code to setup our work area. Then we settle into the business of production code. Red green refactor commit repeat.
Now when implementing “serious” code, we sometimes forget that QuickAndDirty code is just another tool in our box in order to get the job done. Faced with a lengthy workflow, there’s nothing wrong with plugging in un-cohesive, tightly coupled structs/procedures [ =:-o ] to get your thoughts down and documented. Of course, as with any tool, you need to use it correctly in order to get happy mileage out of it.
But just because you’re doing serious production code [and pair programming] don’t be too self conscious about the code you write. Be bold and get dirty. Write quick code to make it compile and flow. Just as red green refactor mantra is applied to tests; the same can be applied to production code.
The major advantage is that you don’t have to keep a hundred threads tied up in your head all at once while you journey through a workflow or a concept. Along each step of the way, there will be discoveries and unanswered questions about what [not] to do [particularly for UI based work]. These distractions can add up quickly and before you know it, you’re coding down a path that when you finish, it takes a while before you find that trail again.
Oh and by the way, don’t leave your tools lying around for others to trip on…
note: production code here is used to distinguish between purely test and deployed code, although i regard test code as production code in my environment.