Professor Beekums Blog


Follow Professor Beekums
follow professor beekums on twitter add the professor beekums rss feed

Follow Up On "What Makes A Senior Software Developer"

A few readers asked me to do a follow up with the responses people sent in for what they thought made a developer a senior developer. I compiled all the emails I received with the comments on Hacker News.

Many folks had their own version of the checklist with different items on their respective lists. I found one to be very interesting though. I was sent a link to a post on this exact topic by Frontside.

At first glance it just seemed like a more complicated checklist. Yet there is one key differentiation: they accept that a senior developer does not need to complete every item on their tracks. There are options a developer can take that best fit their own preferences for how they want to grow in their career.

I’m a little skeptical of the approach because of how complex it seems at first. My worry is that a developer could spend an inordinate of time trying to understand the triangles. As with the checklist, they could spend more time focused on the attributes in each triangle instead of focusing on the work in front of them.

Still, the idea is different enough from a regular checklist that I’m really intrigued. If anyone else has tried it, I would love to hear how it went!

Another interesting concept suggested was that software developers should be licensed. The idea is it is impossible to have a consistent standard for what makes a senior developer without having a… standard for the profession.

It makes sense and it is an idea worth discussing. A lot of caution needs to be taken with this approach though. Who gets to decide what goes into the standard? A vote among all software developers? Who gets considered to be a software developer? Should it be a body of experts? How do you define who an expert actually is?

More importantly, any standard would need to account for the fact that there are very many different kinds of software developers. Working for NASA is going to be very different from working on a mobile tower defense game. Working on a social network will be very different than building software for medical devices. Working for a startup with no customers will be different than working for a company with thousands of customers. Technical debt is less of a concern if you don’t have product-market fit.

Professional licenses is a fun thing to discuss, but a great deal of caution needs to be made if it ever gets put into practice.

Many interpreted my post to advocate for developers who work independently and don’t need to ask for help. I actually disagree with this. A senior developer should be capable of doing work independently, but software development is a team effort. They should know when they should ask for help, but be able to function without it if necessary.

People sent me two great ideas that go hand in hand with this:
The number of problems a developer sees helps them create mental abstractions that they can use on similar problems. The more abstractions they have, the more problems they can solve quickly and with a high level of quality. These developers will also have a better sense of how difficult a problem may be and where their own expertise may be lacking. This is when it is best to ask for help.
Asking for help is an admission that you could learn more about something. That is a healthy behavior to have at any level of experience. The best developer I know (hint: it isn’t me) is constantly asking others for advice. Software development is a large field and it is impossible for everyone to learn everything. There will always be something that a developer will need help with.

One great quote on Hacker News in response to this: Once problems are complex enough there isn’t much that can be done as a solo ninja.

The last and most important response I received was the need to actually have quantifiable metrics. They didn’t appreciate my quick dismissal of the idea. Just because judging a programmer by the lines of code they write is ridiculous does not mean all quantifiable metrics are ridiculous.

This topic deserves a blog post on its own. For now I can sum up my opposition to the idea with the following statement: Once you tie quantifiable metrics to raises and promotions, you remove the incentive for a developer to maximize value for the business. You replace it with the incentive to meet your metrics. I have not met or heard of anyone who has actually had success creating metrics that correlate to maximizing business value.

UPDATE 2017-01-22: You can read the post on quantitative metrics here.

share on twitter share on linked in share on reddit share on facebook
Hi there! I hope you enjoyed this post.

I keep this blog around for posterity, but have since moved on. An explanation can be found here

I still write though and if you'd like to read my more recent work, feel free to subscribe to my substack.