Junior software developers are busy taking over the industry, but while they’re at it there’s another type of developer that’s rising hot on their heels. These engineers are the inevitable next step in the journey of the professional developer. They are intermediate engineers.
Most smaller organizations don’t have a standard classification for developers who have too much experience to be a junior, but don’t have senior-level chops. These individuals don’t usually have a distinct title outside of ‘[Insert Flavor] Developer’, and they are characterized by the rapid growth of both their responsibilities and skill set.
James Hickey describes this stage as developer puberty, and I think the description is apt. He says that these individuals are identified by ‘[A] mental urge or “pull” to believe that they actually know everything they need to know’. I agree with this description. Developers who are in this phase in their growth have somewhat of a benign arrogance, believing they’ve got it figured out, much like a teenager who believes her parents have it all wrong. Like teenagers, intermediate developers might not have the perspective needed to understand their naivety, or the dangerous nature of their newfound dogmas.
While it might seem as though I’m casting a negative light on these intermediate developers, please don’t misunderstand. Like the accelerated growth teenagers go through, the journey through intermediate developer territory is usually a very positive one, with the end result being many hard-earned skills, more competence, and a well-tempered perspective. This article will help you identify if you’re currently in this phase as a developer, and also give you my take on the pitfalls that come with it.
While these topics don’t encompass all of the potential pitfalls intermediate developers may experience, they are the ones that I’ve recognized in myself and others who were intermediates at the time of observation. Also note that it’s possible to suffer from some of these pitfalls, and yet not be an intermediate. None of us are perfect engineers, and there’s always room to improve.
Overconfidence, arrogance, and Dunning-Kruger
The phenomenon of developer puberty shares some similarities with the Dunning-Kruger effect, with the only difference being that it seems to be a bit more delayed for software developers. This is due to the overwhelming nature of learning to be a software developer. Until beginners have a grasp on the basics, they don’t have the enough perspective to feel confident. Yet, the effect is very similar once a junior engineer progresses to the intermediate level. This tendency to always “know the right answer” can be dangerous for engineers at any level, but is most common in intermediate engineers.
This trait most often manifests as a strong dogma related to a particular tool or architecture, which then turns into a “Hammer -> Nails” sort of situation. Examples of this:
- The belief that OOP is the only way to write software, and everything else is inferior.
- The belief that functional programming is the only way to write software, and everything else is inferior.
- Having a strong preference for a specific framework, to the point of actively bashing or subverting the principles of another that solves a similar problem.
- Having strong views on matters of code quality, such as the superiority of tabs over spaces (or vice versa).
- Equating messy code with technical debt, and subsequently refactoring at any opportunity.
- Blaming all problems faced on someone else’s use of an inferior methodology or tool.
- Believing in self-documenting code.
- Believing in documenting everything.
While most of these points represent healthy values, when taken to the extreme they become significantly less so.
Technical excellence over all else
While holding technical competence over all else is a hallmark of a good hacker, a professional programmer has to balance additional values, namely communication skills. As an intermediate developer it’s easy to get caught up in the idea that raw programming skill, code cleanliness, reducing technical debt, etc., are the most important aspects of what they do. While developers should never undervalue these skills, it’s important to realize that they share equal importance with other soft-skills and non-programming concepts. These are primarily communication skills, the ability to identify and execute on business value, and critical thinking that enables making good compromises.
Falling for this type of pitfall can result in a disdain for processes or other team members who contribute to the project in ways other than raw lines of code. It also drives a disregard for very important non-technical processes that projects/companies need to succeed. These can be anything from not understanding the importance of documentation for systems and projects, to ignoring useful processes like Scrum, TDD, or writing tech specs.
The “We are doing everything wrong” syndrome
Monica Lent describes this particular pitfall as “technical FOMO”, in other words the situation where a developer is convinced that the tools chosen for the current project are not the right ones. This is a product of what I would generally consider a good practice: keeping up with technical news and developments. Most of the time this is the result of reading hackernews or other tech news aggregators religiously, being exposed to companies who are walking the bleeding edge of new technology, and thus feeling as if the “old” tools being used for a particular project are not the right ones.
This belief is something that definitely fades over time. Of course, there’s always the outlying naysayer who will prove the exception to the rule, but for the most part experience tempers the urge to adopt the bleeding edge solution as the best solution.
While again, I don’t claim to have all of the answers, these are bits of advice I think applies to programmers in this stage of their development
Actively work on being humble
While you should always advocate for ideas you think have merit, and never accept an answer as ‘right’ based on authority alone, any developer will benefit from actively trying to be more humble in their day-to-day. This might take the form of practicing active listening, where you focus only on listening to what someone else is saying, without planning your response while they talk. Additionally, you could chose a tool or methodology that you don’t like or understand, and build a small feature or side-project while adhering to the principles of that tool/methodology. You could go a step farther and attempt to regularly throw out a tool or method that you prefer, if it doesn’t have a well-defined and well-understood advantage over similar solutions.
It does take work, but adopting the perspective that you don’t always have the full picture or the absolute best way to approach a problem will lead to a very healthy outlook later on.
Force new perspectives
The best way to challenge the ideas that you hold to be truths is to force yourself to take on new perspectives. This can be accomplished by using tools or frameworks you wouldn’t otherwise, pair programming with developers who are more skilled than you in a certain area, and by teaching others something you think you know well.
Pairing will force you to empathize with the way another developer approaches problems, and will undoubtedly lead to the insight that there’s never just one solution. Pair programming also has the benefit of just being a great way to work through challenges and improve the quality of your code overall. If you haven’t already, I’d definitely recommend trying it.
Teaching others about something you believe you have a good understanding of will show you just how little you actually know about that thing. This is true for pretty much any topic, not just in programming. Interestingly, teaching is one of the best ways to to learn something yourself, and it can be a very powerful tool for challenging unhealthy dogmas and self-assuredness.
A lot of what I’ve written here might seem to indicate that a high level of self-doubt is the only way to improve. That’s not entirely true. Confidence is an important tool at your disposal, and it’s a key part of communicating and collaborating well. Put another way, the best approach might be to always have a healthy amount of doubt, both for your own ideas and the ideas of others, but you should never let that doubt get in the way of questioning and reevaluating a problem, tool, or solution.
To put it confusingly: always doubt, but don’t doubt your doubting.
Don’t ever stop learning
Finding quality mentors. Taking part in large/open source projects. Exiting your comfort zone and challenging yourself by taking on features at the edge of your ability. These are the ways you can continually improve your craft and ensure that you are always progressing. This field is not generally kind to those whose skills are left to stagnate, and there’s always a new development that could be beneficial to your career. Stay on top of technologies as they change, be curious, and always work towards learning new things.
This article was largely inspired and influenced by the ones I’ve linked below. If you’re interested, they’re all great reads and well worth the time.
- Signs that you’re a bad programmer
A classic article (partly satirical) on identifying your skill set along a wide spectrum.
- Becoming An Intermediate Developer
The inspiration for this article, and part of a good series on the journey of professional software developers.
- The Software Engineering Job Ladder
A breakdown of common internal structures for determining the level and trajectory of a professional developer in a mid-large company.
- 7 absolute truths I unlearned as junior developer
Highlights the fact that we’re always learning in this profession, and we need to be continually reflective of things we hold to be “truths”.
- You Need Better Senior Software Developers
Explores the qualities companies should be looking for when hiring senior software developers.
Thanks for reading.