There are many ways to describe the difference between two types of developers: Junior vs Senior Developers, New vs Experienced Developers, Good vs Bad Developers. I’ve never been comfortable with any of these because its always too easy to find exceptions that prove the rule. I’ve worked with junior developers who really understand what it takes to be a successful well rounded programmer, and with senior developers who have years of experience yet lack a few important skills to really allow them to be successful.

Naming is hard

A further problem is trying to talk about and label developers without it seeming like a value judgement. There are plenty of fantastic technical people who could code the most amazing algorithm quickly and efficiently, but are simply not capable of being effective mentors to their teammates. Likewise there are people who excel at constructive actionable code review feedback, nurture those around them and inspire them to do better, but hit their technical ceiling early when things start to get complicated. Both of these types of people can be awesome developers and team members, and when paired with a great manager who knows how to play to their strength, can really round out a team.

Developer

So how then do we talk about developer proficiency? I would like to see us move away from adjectives in front of “Developer” and instead try to redefine the term. I think to truly develop an application someone should be able to function across different areas of the lifecycle of that application. They should be able to reason about the broader motivations at play, and know when to come to a compromise on technical purity when a business need demands it, and vice versa. A developer learns that great results come from teams of people working together effectively, and that team harmony trumps individual concerns always. Let terms like “junior” and “senior” refer only to responsibility and time served, but not to knowledge or ability. In a team of developers authority can come organically based off nothing more than a reputation and trust that is formed over a series of interactions.

Coder

So what then about the others? The people who strive only for purity of code and are happiest when someone else is making the decisions? I’ve always liked the term “Coder” as it sends a clear message about the priorities of the person. Is this meeting about the code? If not, then they’re probably not going to be engaged. If that is telegraphed up front by someones position in the team, then harmony actually increases. The coders are building the lego pieces, and even putting them together to form the final outcome, but they’re happiest following the instruction booklet. They aren’t interested in questioning if the outcome will fit the need, or even be useful, pretty or solve a problem. They simply follow the objective thinking that is inherent in the job, and leave the rest to others.

Pick your poison

So which one am I? Which one are you? I think one of the benefits of using different terms is that I can be both. I’m a Senior Developer in terms of approach and thinking, and where I am now I’m also a Senior Coder, because I know the codebase very well and can get things done very quickly and efficiently. I’m changing role soon though, and I’d probably identify as a Junior Coder there for a while. I’ll still be applying the Senior Developer thinking where appropriate, but learning a new codebase and perhaps even making some “rookie” mistakes like coding standards violations etc.

On every project I think everyone could identify themselves as a different spot on the two axes, and I think that position would change over time. Additionally its fun to spend a bit of time as one or the other, writing a small console application in the most productive yet ill-designed way, can be a lot of fun and a bit of a break sometimes. It doesn’t make you a bad developer, in fact one could argue its one of the qualities of a good developer that makes you aware that sometimes that is an option, and the right path to take.