«    »

To Code or Not To Code

To code or not to code, that is the question for senior software developers when they are presented with the opportunity to move into an architect, project manager or team lead position. Rob Walling recently wrote an excellent article titled Why Good Developers Are Promoted Into Unhappiness describing his unsatisfying experiences as a manager and the problems that result from promoting star developers into non-development roles. Rob's article inspired me to contribute my own thoughts on this subject.

I have been thinking about this general topic for a while, as reflected in two of my recent articles titled How Much Do You Code? and Are You Doing Enough Coding?. These articles have focused more on the amount of coding one does as a software developer, and point out that the more senior the developer, the less coding they tend to do. Rob's article, however, focuses on the separate (but related) issue of senior developers moving into non-development roles. I think there are three major forces pushing developers in this direction:

  1. Promotion from management. The top performers within a team are often the most likely to be promoted to lead the team, even if they and the corporation are better off if they remain developers. This is especially a problem in hierarchical organizations with no technical career path.
  2. Desire to fix problems. As Rob pointed out, you may feel obliged to take on a leadership role in order to help your team or save your project. A contributing factor is the oft-mistaken belief that the new role will not take all of your time and that you will still have time to code.
  3. Desire for new challenges. If you are feeling stale in your current role then advancing into a more senior position is often the most obvious choice. It is not, however, always the best choice.

The correct answer to whether to continue to code or not depends entirely on you and your motivations. I recommend choosing the role that is most rewarding to you on a daily basis, and not choose a role based solely on its seniority, prestige, or salary level. Many developers end up unhappy in non-coding positions because they allowed external forces to push them away from coding. Unfortunately, it can be difficult to determine how much you will enjoy a role until you try it. And once you try a non-coding role, it can be difficult to move back to coding. This is when learning from the experiences of others can help. So here are some of mine.

I personally love coding – the act of creation, as Rob pointed out – and always have since I was young. I did my first coding as a kid on a Vic-20. So becoming a software developer was the obvious career for me. Early in my career I was offered and accepted the opportunity to become a team lead of a small team. I found that I could spend a little less than half my time coding. The other time was spent on administrative or project management activities. The exact percentage varied from week to week: there were some weeks with almost no coding, and other weeks with more. Even when I was involved with the code, a portion of this time was spent doing reviews and mentoring junior developers. The team size varied from three to seven subordinates. As the team grew, the less time I had to code. After a few years and the successful release of a new piece of software, I knew it was time for a change, partly to take on new challenges, and partly to do more coding.

I joined the architecture team within the same company and became involved in a project to build a new application framework. I was coding again full time together with some excellent experienced developers. Those were good times. Within six months, I was offered the architect team lead position, which I accepted partly because it had very limited administrative duties, so I was still able to devote a majority of my time to coding. I did become involved with some non-coding duties, such as a training initiative regarding the use of automated unit testing and mentoring, but I did not mind because I found both activities rewarding, though not without their frustrations. After a few years it was again time to move on.

I switched companies, joining CGI. I was going to be a development lead on a project, but CGI failed to win the bid. Instead, I joined a development project as a regular developer. I had no non-coding responsibilities, and the project was in the construction phase, so I got to do some of the most intensive coding of my career – probably 95% of my time. But like most development projects, it soon ended, and I moved onto a maintenance team as a senior developer. This was my first time in a pure maintenance role, and I discovered that there is definitely less time spent coding due to other responsibilities such as monitoring the operational production system and managing the process by which software changes were released into production. However, I found the role to be an incredible learning experience – check out some of my articles I have written as a result.

A few years later I was offered another team lead position. By this point in my career, however, I knew that I needed to code at least a certain percentage of my time. The offered position was for a fairly large team with many administrative duties, which I knew would offer no time at all for coding, so I turned the position down. Instead, my role in my existing team has gradually transformed into an architect role, partly out of a desire to fix problems, and partly out of a desire for new challenges. This has led to a reduction in the amount of coding I do. I still get to do some, and I am mostly enjoying the challenges associated with the new role. But I am being careful to avoid moving any higher up as an architect. As an application architect in my existing role, I am still fairly close to the code. I know other application architects who are no longer involved with code, and once you become an enterprise architect that is guaranteed.

There is nothing intrinsically wrong with becoming an architect, team lead, or manager, but there is nothing intrinsically right about it either. The choice of whether to code or not is best based on your motivations. What do you want to do?

If you find this article helpful, please make a donation.

Related Posts

  • No related posts

4 Comments on “To Code or Not To Code”

  1. Great post, Basil. In my current role I find myself writing code less and less, though I do enjoy the new opportunities that I have to help define the technical direction of my company.

    When I do start to get the “itch” for some hands-on work, I’ll take some personal time to work on side projects to keep my skills sharp. Recently, I’ve written and released a couple Rails plugins (caches_constants / validates_url) to scratch that itch. The concept of the caches_constants plugin should be featured in the upcoming Advanced Rails Recipes book.

  2. Leon Mergen says:

    The Peter Principle: “In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence.”

  3. Pauline Daniel says:

    Great post! I’ve also found that i “need” to code and don’t enjoy having a primarily administrative role

  4. SSK says:

    I’m reading this after 2 years, it is still lively and fresh and makes me feel bad for switch and it is too late now to go back on that road… but will share this to my team members.

«    »