Building technical self-reliance

There is no clear boundary between a “junior” and “senior” developer. One apparent difference however is the level of self-reliance developers display when solving technical problems.

By self-reliance, I mean the ability to solve technical problems without asking for help. This means being able to come up with original, elegant solutions to meet complex requirements. It means being able to dig into the implementation of a library to help explain unexpected behaviour. It means being able to foresee potential problems and advantages of a given approach to a problem before implementation.

Junior developers often have a strong desire to just “get things done”. To make the software meet the requirements they’ve been set and not worry too much about the details of the underlying implementation. This feels good in the short-term because there’s instant feedback. You write the code, see the result you want and then go home for the day. When there are problems, there’s little desire to slow down and understand what the software is doing. If you’ve ever stared incredulously at a junior developer attempting to debug a program by, for example, deleting random lines or changing the order of the code to see what happens then you’ve seen this first-hand.

A common trait amongst junior developers in this situation is to immediately seek the help of a senior developer. If a function doesn’t work as documented or the code from a blog post doesn’t seem to do what the author says it does then the next step is often to get a more experienced developer involved. This robs the junior the developer of an opportunity to practice their techncial problem-solving skills, of building their self-reliance.

When you make the choice to start a career as a developer, you’ll be much more valuable to people you work for if you see it as a long-term commitment. If all you want to do is build a prototype for a web application then it makes no sense to spend three months focusing on learning about relational databases. If on the other hand you believe you’re going to be doing this job for more than a decade, then it absolutely makes sense for you to spend three months to a year focusing on cryptography, operating systems or any number of other technical topics relevant to your day-job. By focusing on the long-term, you give yourself permission to slow down and really understand what your code does, rather than knowing just enough to make the software do what you want it to do today.

The first step to becoming more self-reliant is to make the decision to do so. This means accepting that you’re responsible for solving technical problems and it’s in your interest to learn how to do so without asking others for help. You have to make the decision to become the type of developer that other developers go to for help.

You’ll need a general knowledge of the software that the software you write works alongside. As a web developer you probably won’t need to implement an operating system kernel, a cryptographic block-cipher or a key-value store. You will however be working with these tools. On a long enough timeline, something will go wrong with software you build that will require knowledge of these other components to fix.

“General technical knowledge” is difficult to build at the start. It feels like you’re collecting a list of subjects to feel bad about not knowing in enough detail. Later on you’ll start to see concepts and techniques being re-used in various places, and this helps to a degree. You’ll also get better at learning new things and develop a higher tolerance for complexity.

You’ll need to be familiar with the documentation for the languages, libraries and frameworks you use in your day-job. This is where you go to help explain what your software is doing right now and come up with ways to put existing libraries to use to solve new problems. Documentation is often the first thing a more self-reliant developer will consult when trying to solve a problem.

You shouldn’t be afraid to consult technical documentation such as specs, RFC’s, language references and other “primary sources” of knowledge. These documents seem scary, but remember you’re in it for the long-term. It doesn’t matter if you only understood only 5% of the HTTP RFC because you’re going to read it twenty times eventually.

You need to be ready to dive into the code of any software that your software uses. Documentation can be wrong or imprecise. The only way to know what library code is actually doing is to open it up and read it.

Many developers have an aversion to reading code. A noble goal of software is to be easily reusable. It should define an interface, and as long as your code that uses it meets that interface, you shouldn’t have to care how the reusable code is implemented. In practice it’s almost never this simple. Mysterious bugs can usually be explained by reading the code that actually gets run.

Reading code is much more difficult than writing it. The code you’re reading is filled with the idioms, knowledge (or lack thereof) and techniques of some other developer. It’s also almost never the product of one coding session. The code you find on a project more than a few months old will be the work of multiple developers of different skill levels with different requirements to meet. You’ll only truly realise what it’s like to read your own code in this way when you come back to your own code two or three years later.

The skill you want to build is that of reading code and swiftly building a mental model of how it works. You do this by reading lot’s of code and slowly building a mental model of how it works. In time you’ll build the knowledge and reading comprehension ability to speed up the process.

You need to truly believe that with a combination of the above and enough time, there really isn’t any technical problem you’re not able to solve on your own.

You should absolutely debate approaches to solving a problem and have your code peer-reviewed. But before approaching a more experienced developer with a problem you’re having, ask yourself, have you really done all you can to solve the problem on your own? Have you read relevant documentation, specs and code? Have you looked around for other implementations of the thing you’re trying to build? Have you read up on topics you need to understand the context in which your code is running?

Start building your self-reliance by deciding that you’re going to solve problems on your own. You’ll probably be subtly wrong in numerous ways, but that’s fine. It’s far better to come up with a sub-optimal solution on your own and iterate than it is to have a perfect solution handed to you by someone else.