I try to be better tomorrow than I am today. I am constantly thinking about what my strengths are and what I’m weak at. It is impossible to be good at everything though. That means needing to be selective with how I spend my time on improving. What will give me the most value for my time?

This thought process is more than for just personal growth too. Knowing what different skillsets are available and being able to identify them in others is critical when hiring developers. One of my teams and I made the mistake of hiring a great developer… who was great at things we were not doing. Not all developers are good at the same things. Not all teams need their developers to be good at the same things.

The most obvious developer skillset is programming ability. A developer’s job is to write code so a great developer should write great code. Unfortunately it isn’t as easy as that. There’s a lot of nuance in being able to determine programming ability.

Programming is really just a way to communicate with a computer. This is emphasized by the fact that developers write code in programming languages. Using the analogy of a language: it is one thing to know English. It is another thing to be able to write poetry in English. Or fiction novels. Or non-fiction meant for the general public. Or scientific papers. Knowing a language is one thing. Being able to use it well depends on a person’s expertise with the language in a certain context.

Continuing the analogy of writing in English, the skillset of an author and an editor is different. There is a ton of overlap in needing to understand good grammar, sentence structure, etc. But the mindset is different. For developers, there is a huge difference between writing code from scratch or iterating on an existing system. Unless a developer is a founder of a project, odds are that developer has expertise in iterating on existing systems.

Most of my early career was like this. Creating projects from scratch was something I rarely did my first few years after college. My jobs already had an existing product. That serves as a foundation for what decisions can be made. An existing system already has working functionality and the effort in not breaking that functionality creates restrictions on what can be done. My skillset was in evaluating what those restrictions were and what I could do within those restrictions. An editor doesn’t make the decision of changing a murder mystery into a romance novel. That’s something the author has already decided.

Even a horrible foundation is still a foundation. It still reduces the number of choices a developer has to choose from. That makes it easier to decide on what to do. The path may be unpleasant for a horrible foundation, but the decision to take that path is relatively simple to make.

Creating a project from scratch means the possibilities are literally endless. There’s nothing you can’t choose to do. A developer could choose to fall back on how they did things previously, but often times that is not the best way to go about things. How they did things previously was based on the restrictions they had at the time. Without any of those restrictions, they now have better options. The trick is being able to actually make a good decision with an infinite number of possibilities. It is a completely different skill than working with an existing software system.

There is also the ability to debug code. You may think this goes hand in hand with writing it, but the thought process is completely different. When writing code, the developer is the driver. They know what they need to build and they know how to build it. They are making every choice. X is going to be built in the front end. Y is built on the back end. Z goes in ElasticSearch.

When debugging, things are less clear. Users don’t know how a system is built and they don’t care. They expect things to work. When something doesn’t work, they say that it doesn’t work. Yet finding the exact spot in the code where the issue occurs could range anywhere from minutes to weeks.

Let’s say the search feature on a website is broken. User enters in something and nothing happens. All the user knows is that nothing happens when they hit search. This is where the developer starts investigating.

• Are there errors in the browser console?
• If so are they because the server returned bad data?
• If the server returned bad data, is that because the server code is broken or the front end code didn’t send the right parameters?
• If the developer can narrow the problem to being on the server, then they have to start investigating where on the server.
• Is it the code?
• Is it the datastore?
• Is it networking between the code and the datastore?
• If it is in the code, is it with the code written by the developer or is it with code in a third party library used by the developer?

Those are just the questions if a developer can actually reproduce the issue. Sometimes the issue can be related to location. Developers often use CDNs to deliver code and images to the browser. CDNs store copies of these assets in various locations in the world. This allows web pages to load faster because someone in Asia doesn’t have to wait for images to be delivered from the US. But that also opens the possibility of the CDN failing in Asia and so only those in Asia would see a bug. The developers in the US would be frustrated because they wouldn’t see the problem that users are complaining about. It’s like hearing someone complain about your smell when you don’t think you smell. Frustrating.

There are other frustrating examples of bugs like this, but the point is that debugging is a different skillset than writing code. It is more investigation/detective work than it is building something. The type of creativity needed is going to be different.

Going back to writing code itself, being able to write fast code and being able to write code that other developers can read are two very different things. One requires a greater amount of mathematical ability. The other requires organizational skills. While it would be nice to only work with developers who are exceptional at both, reality isn’t always nice.

Different software will benefit from developers who lean one way or the other. The nice thing about software though is that you can gain most of the benefits of having an “super awesome god” developer by having multiple developers with a range of skills. A developer with great organizational skills can set the foundation for the system as a whole while the developer who writes really fast code can focus on the algorithms that get plugged in.

While it would be ideal for every developer to be good at everything, time is a finite resource. Developers are going to tend to lean in certain directions. That’s a good thing too. Software is a field where you only need one specialist in an area who can increase an entire team’s competency in that area. For developers that means it isn’t always necessary to work on things that they are weak at. It makes sense to focus on continuing to develop one’s strengths.

For hiring managers and interviewers, it also means there isn’t a template used when hiring developers. They should think about what the current strengths and weaknesses of the existing team are and look for someone who can fill those gaps.