On making sense of everything you know, and don’t, as a software developer
Being a software developer is about more than just knowing how to crunch long lines code. Sure, that is one aspect of it, and a very important one at that, but there’s a lot more that you need to know in order to be truly effective.
I’ve always found it somewhat challenging to make sense of what I need to learn in order to polish my skills as a developer and how to constantly fill in the gaps in my knowledge. The software landscape is constantly evolving and the list of things I need to learn only grows and longer and longer. The tricky bit is that when you’re just starting out, you don’t really know what you don’t know.
There are hundreds of programming languages out there and a ton of different frameworks. There are different programming paradigms you could focus on. Further still, each industry that you choose to work in usually requires some specialized knowledge, specific to the business. This, coupled with all the “on the job” skills you need, suggests that there are a lot of things that you need to keep track of.
I find this especially important since it also raises the question of how a software developer chooses to define themselves. Do you consider yourself exclusively as a Java Developer? Or are you a seasoned web developer who just happens to have some expertise in Python? Or do you just find working on Big Data applications absolutely fascinating, no matter what the role?
Over time, I’ve found it helpful to think of my knowledge base as aligned along five key verticals:
- Programming Fundamentals
- Technical Depth
- Technical Domain Knowledge
- System Knowledge
- Business Knowledge
Most developers are familiar with the first few, but allow me to elaborate.
Programming Fundamentals
All developers are expected to have a basic understanding of fundamental programming concepts. This obviously includes simple ideas related to programming such as variables, functions, loops etc. But developers are also expected to have a solid understanding of data structures and algorithm design, as well as different programming paradigms like Object Oriented Design, Functional Programming, Iterative Programming and so on.
Most formal introductory programming courses tend to heavily emphasize on this as well, and for good reason. Having a good understanding of these concepts is ultimately what sets the stage for everything else that you do as a programmer. Especially early on, when you’re just learning how to code, it is a good idea to solidify these concepts as much as possible.
Your fundamentals also encompass your ability to write good code. It is important to learn the best practices when it comes to writing clean, maintainable code. Although each language has it’s own set of best practices, there are a handful of principles that you should learn to make sure you’re always writing code that is up to the mark, no matter the environment.
Technical Depth
Obviously, simply knowing what a for loop is isn’t going to get you very far as a software developer. The next step, typically, is to take all the knowledge you have learned and apply it in the context of a few programming languages.
I usually like to argue that it is more important to learn how to adapt to different programming environments and quickly pick up new frameworks than become really good at any single one of them. Most popular languages are similar enough that you could start being productive in a relatively short amount of time with a little bit of practice.
But I’m also aware that although most programming languages are similar at a fundamental level, each has its own quirks that warrants special attention beyond a certain point. JavaScript is a classic example. You could start writing functional JavaScript with a little bit of knowledge and even be good at it within a couple of weeks. However, it often takes months, or even years, to master some of the most advanced concepts the language has to offer. And this is exactly where the depth of your technical knowledge comes into play. And it is this expertise that a lot of employers value.
Unfortunately, being really good at something is also a double edged sword. Though being an expert at any one language makes you more desirable in that domain, it also makes you less likely to experiment with something you are not familiar with. It becomes easy to fall into the trap of utilizing the single piece of technology for everything that you do.
For the longest time, I considered myself exclusively a Rails developer. I had spent months mastering the ins and outs of the framework to the point where using any other tool for building a website seemed absurd. It also made me less likely to consider jobs that required knowledge about anything other than what I knew.
Technical Domain Knowledge
This is loosely related to the previous point, but instead encompasses the general area of software you are working with. For example, someone working as a web developer would likely need to have some understanding of how the web works. A basic understanding of the HTTP protocol, REST APIs and databases, for example, will likely go a long way.
Most modern web frameworks abstract this away and do a lot of the heavy lifting for you. But having a fundamental knowledge of what’s happening under the hood still makes you a more versatile developer. You could change the language you are working with and move to something with a completely unfamiliar syntax. Or maybe the framework that you’ve been used to working with is now obsolete and needs to be swapped out for something new. None of that will change how the internet fundamentally works. And so having that knowledge already gives you a leg up. It gives you a better starting point from which you can begin filling in the gaps in your knowledge.
This is true for any field of software development. Mobile development, desktop development, data science applications, embedded systems, graphics engineering etc. are all intricate sub domains within software development, each with its own unique set of technical challenges. It can often take a person years of experience before they can fully grasp all the complexities and nitty-grities associated with it.
System Knowledge
Each codebase is different, and has a personality of its own. Any company that has been around for a while, likely has a codebase that has evolved with over time as well. It has been worked on by lots and lots of developers. For companies that have been around longer, there may be some legacy code that is still being maintained. Alternatively, there may be tons of dead code floating around the codebase degrading its overall quality. Data abstractions that were created to solve a use case years ago may no longer make sense. Oftentimes, there’s also a lot of infrastructure around the code itself that you need to be familiar with.
In any case, understanding the system that you’re dealing with, in and of itself requires some work. This is also crucial since having a limited understanding of what you’re working with is going to either slow you down or degrade the code quality even further. Neither of these are desirable outcomes.
Unfortunately, this is usually not something you can simply learn by yourself. The only way to understand the different parts of the code are to work with them over time, and gradually build up your understanding. This is where the supervision of senior members of the team is essential — who can ensure that your code still meets the standards and doesn’t inadvertently break something.
Business Knowledge
Lastly, it is also important to understand the core business of the product that you’re working on. This definitely varies from one industry to the next. As a developer, it is likely not expected of you unless you’re in a handful of industries. Certain industries, like finance for example, or AdTech, or HealthTech, are notoriously complicated and require some specialized non technical knowledge.
But even in other industries, I’d argue that having business knowledge can only be a positive thing. Not only does this make you more aware, it also allows you to write better code. Part of your job as a developer is to capture relationships that exist in the outside world and communicate them using code. Having a better understanding of these relationships thus helps you make better design decisions.
Ultimately, there is no getting around the fact that software development is vast, and complex. There is never a shortage of things to learn or ideas to explore, and you’re never quite done. The only way to get better is to stay curious, be aware of your own blindspots, and keep working towards eliminating them. Cheers! :-)