Being a Senior Developer is much more than just a job title. It’s also much more than just years of experience. But what is it that makes the difference?
I’ve been thinking about this difference for quite some time - and there have been some recent comments in the blogosphere that have prompted me to put pen to paper, err, keyboard to screen.
One blog entry that resonated with me is the (admitted brief) set of comments made on myShoggoth in his entry Senior Developer vs. Junior Vol. I.
In my thinking, there are a few absolutely vital characteristics that are required for someone to be a real Senior Developer. Three of these are given here.
Wide Vocabulary
It is well understood in the field of linguistics that, unless you have a word to express the concept it is difficult to think about the concept.
For example, in ancient Greek there are four distinct words that get translated into the english word Love: Agapa (divine), Philia (friendship), Storge (family) and Eros (sexual).
It has been suggested that the lack of distinction between these concepts is a significant source of personal problems for native English speakers as the single word used for different concepts leads to confusion.
The way that a developer thinks about solving problems is similarly limited by the different languages (or paradigms) known to that developer. As the cliche goes, If the only tool you have is a hammer, pretty soon, everything looks like a nail.
A true Senior Developer will have a wide vocabulary of concepts, sourced from many different environments.
Proactively Lazy
Most people are lazy - they put things off until tomorrow that could be done today. This is true of most developers as well.
However, by the time most people reach adulthood, they’ve learnt that there are many things that could be left until tomorrow, but which are really much better done today.
The same is true of software development - putting a bit more effort in today can save you a whole heap of time in the long run.
New ideas like “test first development” and “automated testing”; old ideas like “documentation” or “specifications”.
These are all things often skipped or dismissed by less experienced developers as unimportant or a burden.
Unfortunately, doing this tends to make life harder in the long run - a false economy.
A senior developer understands the real tradeoff between a little work now and a lot of work later.
Scope of Repair
Most bugs in software have a simple fix - once you’ve found where the bug is. Often, the thing that takes the most time is the process of locating exactly where the bug comes from, tracking it down to the exact line of code.
Once you have the bug isolated, how do you fix it?
Many developers will throw in additional code to make the issue go away, and move onto the next item in their to do list.
A Senior Developer, on the other hand, will look to see how to ensure the bug never comes up again. This involves some refactoring, some additional testing, and often takes a little bit longer. It’s also not uncommon to locate and fix some previously unknown bugs at the same time. The result of this extra work is code that is manifestly better.
I’ve seen many very capable developers - people worthy of the title Senior Developer - who triage a bug by adding internal tests (often with Assert Statements) to track the bug back from the point where it is visible to the original cause. They don’t remove that scaffolding after fixing the bug - they leave it in place to identify other bugs earlier.
A Senior developer doesn’t work to just remove the external symptoms of a bug, but to remove the underlying problem that gave rise to the bug in the first place.
Comments
blog comments powered by Disqus