Junior vs Senior Developers: What's the Difference, Anyway?

It may sound like a loaded and obvious question, but is it really?

I overheard some of the developers in my shop discussing this very question. One of my senior developers engaged two of the junior developers on his team about something unrelated. One of the junior devs eventually piped up about the question of junior versus senior developers as the original conversation wound down.

The senior dev, who happens to be one of the best and brightest coders I have ever had the pleasure to work with, spent the next thirty minutes trying to lay out, in his opinion, what the differences were.

As the conversation progressed with the usual answers, the junior developer who had originally posed the question (another bright spark in my company) attempted to break the question down further into what I thought were two very interesting, probing, and useful sub-questions:

1. How can I, as a junior developer and as objectively as possible, determine when I have become a "senior developer"?

2. How do you, as a senior developer, gauge junior developers' progress and know when a junior developer has crossed the threshhold into senior developer territory?

Question 1

I found the first question extremely interesting. As the discussion went on just around the corner in the office, I tried to think back to when I was just starting out in the software development world and what I thought as I grew as a developer throughout the years.

Surely time is a factor every developer considers as part of his/her graduating into higher levels of seniority. Matching those years against various job postings (some consider "senior" to mean having at least 5-7 years' worth of experience whereas others consider it to mean at least 10-15 years'), it quickly becomes apparent that there is no real "standard" as far as professional time spent goes.

Having been on the hiring side of matters, I can also attest to the fact that some developers consider themselves senior after just a few years, whereas others consider themselves just "intermediate" after 7-10. This is to say nothing of the actual, demonstrated knowledge.  Ego can also be a funny thing. This "impedance mismatch" can cause friction when opinions vary with respect to "time served".

What about the number of technologies or language learned? There is a school of thought that mastering just one or two languages makes for a senior developer as he/she has the experience and knowledge to know how to tackle problems presented in that language. However, another job might value more highly the ability to work with various similar technologies and the ability to tackle more generalized problems with different technologies.

Again, the obvious stares us in the face: It all depends on what the job is asking you to do. In that respect, there is little or no help in terms of internally gauging whether you have ventured into "senior developer" territory.

After much pondering and hearing the back-and-forth across the office, I concluded that the internal gauge for the first question is rather personal. If I were to posit one possible metric--however informal it may be--it would be the level of comfort and confidence you, as a junior developer, have when a senior technical member of your team/company asks you to do something new.

Question 2

There are doubtlessly countless metrics that exist to address this question. Frankly, I have yet to see any that serve as any sort of silver bullet or golden ruler by which all senior developers can be definitively measured.

Yes, there are certainly tests and exams that can be written to help gauge the level of skill of a developer. These tests cannot be ignored, there is no question.

To make matters more interesting, sometimes the people determining what a "senior developer" is not someone who is necessarily intimately familiar with the technology or language being requested. For example, in a small shop, the VP of Technology may be a master Java developer with lots of experience delivering Java-based enterprise applications. However, that same person may be tasked with hiring a senior iOS developer. In the vacuum of other senior iOS developers, someone has to take up the reins.

However, I digress a little. The real question here is gauging the progress of junior developers who with whom you are charged.

With several possible metrics, most seemed difficult (though not impossible) to properly convey to junior personnel. Again, if asked to post one possible metric, I would have to go with something along the lines of the developer's ability to generate an estimate for a task or series of tasks (however large) and to be able to confidently complete the tasks within a reasonable margin of the estimated time (don't get me started on task estimation) and with a minimum of assistance.

In other words, if you are still making the same or similar mistakes as to when you first started out in the development world, you most certainly are not moving into senior developer territory.

Conclusion

This article does not pretend to answer the questions raised by my astute junior developer. Rather, it serves to initiate a discussion on what metrics might reasonably be applied to each question--a starting point, if you will.

What do you think? What are some useful metrics for both sides of the fence to apply? We don't all have the luxury of full-fledged HR departments, but perhaps there is something we can all learn.

Leave some comments and let's keep the conversation going.