What really separates Senior Developers from Junior Developers

I’ve posted previously why I don’t like the term ‘junior developer’ as it usually just means you are saying a developer is younger than you, and is often used to be demeaning for no good reason.

<digression> There are times when being demeaning is arguably the right thing to do, but it generally isn’t a good thing to do.  It should usually be reserved for when dealing with senior management, though I don’t recommend you practice it unless you really know what you are doing.  Being demeaning to people who don’t have an opportunity to be better just makes you a dick.  And not a good kind of dick, just a dick.</digression>

I think there are basically two things that actually make it reasonable to call someone a ‘Senior’ developer:

  1. A Senior developer is someone who can learn a system without any documentation in a ‘reasonable’ amount of time.  What counts as reasonable here is, like much in life, largely contextual.  In the last decade, there have been numerous times in which I was asked to learn System X which currently does Y and needed to do Z.  On approximately zero of those cases, I’ve had any significant amount of assistance, either from documentation or current developers, to learn what System X was, what Y currently does, or what Z is.
    1. Keeping names out of it, the best example came from a particular large organization.  The current developer who would have been the best resource to learn X,Y and Z from was working 60 hours a week on a very important release, the previous release of which had been a disaster.  He was swamped, to say the least.  He was very intelligent, and happened to be one of the people I interviewed with to get the job.  When I asked him what Y was (I knew enough to know what X was) and how it worked, he looked at me and said (only slightly paraphrasing), “I don’t have time to tell you.  We hired you because you seemed vaguely intelligent.  Fucking figure it out.  Please.”
    2. He turned out to be one of the best developers I ever worked with, and though I had maybe 30 seconds of being pissed off at his initial response, it quickly dissipated.  He really did not have time to work with me.  He really did expect/hope I could just fucking figure it out.  That really is why he recommended that I should be hired.
    3. Being able to ‘fucking figure stuff out’ is a largely non-teachable skill.  You have it or you don’t, for the most part.  Younger developers show this ability directly, which is why a ‘junior’ developer is often more valuable than a ‘senior’ developer.
    4. As a side note, if you are in management and you find these younger developers with these skills, it is imperative that you protect and foster them.  I don’t think I can emphasize that enough.  These are resources that are more valuable to you than just about any other.
  2. A Senior developer is able to be self-directed.
    1. A regular reader of this blog will know that I’m kind of a prick (“what do you mean kind of?”…I heard that).  Part of that ‘skillset’ involves being able to take charge and tell people (including especially senior management) when they are wrong.  This does generally take some experience, or a complete lack of tact, or both.
    2. If you can talk the talk and walk the walk, senior management actually doesn’t mind this, but it can be ‘scary’ if you’ve never done it before.  Looking a senior manager in the eye and telling them they don’t know what they are talking about is risky.

I reserve the right to add to this list, but, to be honest, those are the two things that really make the difference. 

One of the the things that should be noted about this is that the ability to write really good code is sort of besides the point.  Obviously, it isn’t entirely besides the point.  But, you can be a good developer in the sense of following all the shit that ‘Craftsmen’ say you should follow, and yet not be a senior developer, no matter how long you’ve been slinging it.

posted on Monday, April 30, 2012 7:41 PM Print
# re: What really separates Senior Developers from Junior Developers
4/30/2012 8:32 PM
I think there should be an addition to this list.

A senior developer knows how to build systems which you can troubleshoot from your blackberry/iPhone (in other words build systems which fail gracefully).

Let me give you an example: I work in the finance industry and one of the most common requirement is to load data files from various prime brokers. I expect any decent developer to build a system which does the task. But a senior developer will build a system which will throw a precise exception

1. When FTP is not available, the exception detail will include FTP server and the login.

2. When the particular file is missing, exception detail will include FTP server, login, full path to the file which system is looking for.

3. When you receive an empty file. Once again, full FTP/File details.

4. Most of these data files are in CSV format. System will complain if the number of columns in the file does not match expected columns. System should complain even if it is only using first 3 columns in 10 column file. If the expected file has 11 columns, something has changed in target system and system should inform you about that.

5. If a file is good but certain line items are faulty, system will send a summary message listing down all the invalid lines.

6. If file format checks out, doing sanity checks on data to make sure it's correct from business POV. These sanity checks are added as you encounter failures in file load process.

As I like to say, 'Be strict in what you accept and what you send.'

I have seen good junior developers who can code but they don't design systems which are fault tolerant.
# re: What really separates Senior Developers from Junior Developers
Derik Whittaker
5/1/2012 11:38 AM

Change 'Kind Of' to 'Mostly' please :)
# re: What really separates Senior Developers from Junior Developers
5/1/2012 10:18 PM

I'm not sure I would include that for at least two related reasons.

I think the level of exception handling that you mention is not something beyond any decent developer. In fact, I think a developer that is tied to operational support would probably be able to pick up and even define the sorts of things you list.

The second reason is more philosophical. FTP is perhaps not a good area, if only because it is largely a 'solved' problem, but in general, I don't know that having detailed error handling is necessarily necessary, as I don't believe exceptions should be handled that way.

Part of it depends on how the 'fault tolerance' is built. It is easy to over-architect such a system, where you try to imagine every type of possible failure in advance.

OTOH, the way you describe it, it could very well be grown organically, 'as you encounter failures' as you say.

But, YMMV.

Thanks for your feedback.

Post Comment

Title *
Name *
Comment *  
Please add 2 and 7 and type the answer here: