I Just Want To Write Code!
That is something I hear from a lot of developers; they aren’t interested in any of the other activities involved with delivering a software project. They dont want to speak to people, gather requirements, design architecture, attend planning meetings, write documentation, fix bugs, monitor production services etc. I totally get this, I feel the same way to some extent. Those of us that fell in love with coding by sitting in our bedrooms until the early hours writing hundreds of lines of code will probably get it. You fall in love with coding. No one falls in love with planning meetings (if you do then you need to see a doctor!).
The above attitude is obviously not conducive to having a successful team of engineers with a breadth of experience, nor would it do your career any good if you adopted it. But that is not what I want to discuss here. Rather I have noticed an amusing paradox to the above attitude, that is the more code you write, the less code you can write in future.
If your organisation works anything like mine then for every line of code that you write there will be a future cost or liability associated with it. Imagine if you’re so wrapped up in the code for a specific project that you voluntarily spend your entire weekend working on it, getting some of the high-importance low-urgency items off the backlog. Maybe you completed that bit of hairy refactoring work on the core objects that we’d been putting off for months? Brilliant, fantastic! That will make our lives much easier! 🙂
Or will it…
Now you have changed all that code the following things will probably happen:
- You’ll have to explain and document the changes for the test team so your changes can be put into production
- Assuming your changes alter the way in which the app behaves in production, even slightly, then you’ll have to explain and document the changes for the support team so they can still effectively support it.
- Assuming you’re using Scrum or similar, you will have to demo your changes to the whole team.
- Maybe your changes affect other applications that use those objects in some way. You may have to refactor those apps too (and here we’re into recursion of all the other points!), or at the very least explain and document the changes for other teams so they understand how to modify their app to accommodate your changes.
- You will have to explain (and possibly document) the changes for the rest of the developers on your project so they understand what you have done, why you’ve done it and how it may affect them.
- You will become the de facto technical authority on these changes so if anyone works in this area in future they will come to you asking for advice.
- Any future projects building on the foundations you have created may well pick you out as a design authority, dragging you into early project discussions around feasibility and architecture.
- Your proactive stance on pushing the team forward may well push you into a de facto technical lead role meaning more and more people will be coming to you for advice, mentoring, code reviews etc.
Not all of the above will apply to every commit you ever make but the principle holds that the more code you write, the more of these other tasks will crop up on your TODO list, which is not what you wanted is it? You just wanted to write code!
So next time you’re on an all-night coding binge, have a think about the horrid work you are queuing up for yourself!
Trilemma Technology 
They dont want to speak to people – TRUE
They dont want to gather requirements – TRUE
They dont want to design architecture – I like this bit. But I am strange
They dont want to attend planning meetings – TRUE
They dont want to write documentation – VERY TRUE
They dont want to fix bugs – I like the challenges associated with this bit
They dont want to monitor production services etc. – TRUE
In the main, all we want to do it write code. We hope we can write it right first time, but you do have to slow down a bit. It’s unfortunate that quite a lot of time spent coding is lost through other things, but that’s the nature of the beast.
I haven’t hit the paradox you mention yet, and I hope I never have to. Hopefully I, or someone, can find a way of avoiding that!
I guess it depends how you work as a developer. A developer that is prone to massive coding binges will probably see the amount of time they have for coding fluctuate. They start of producing loads and loads of good code then get bogged down with everything else, to the point where their code writing tails off. Once they’ve battled through everything else they can start on another coding binge and the cycle starts again.
If the above is true then I would also wager that one could avoid this situation by trying to maintain a steady state, keeping a balance of coding vs other tasks. It’s down to individual preference of working style in the end.
It’s really odd that in the good old days when there was no project manager to manage the projects and the developers were left on their own, the success rate was much higher than now.
I don’t think the problem lies in the project manager, I think the problem lies in the current quality of the developers (much lower than before), as well as their ego.
I have seen the egotistical traits you refer to in your article in some people. However the majority of the developers I work with at the moment fully embrace testing in its many forms. Our conundrum is not so much ‘Do we need to test?’ or ‘are developers offended by testing?’ but more what kinds of testing and what level of testing are appropriate for a given project.
You refer more than once to a utopian past where things were better than today. Do you have anything to support your claims? I would be very interested to read something that attempted to measure and record the ‘quality’ of developers (whatever that means) over time.