The shared goal of most developers is to become better at the techniques they use. Being better means being more efficient, which results in greater work motivation and fulfilment. For a developer, that usually means jumping from junior to proficient and from proficient to senior.
In this article, I’ve listed some tips on how to improve yourself to become a better developer.
While I was preparing to write this article, I stumbled upon many different articles on how to become a senior developer. One of the most common (and in my opinion incorrect) approaches, evolves around compiling a list of technologies you should learn. The idea is that once you reach the bottom of the list, you are done – you are ready to become a senior software engineer.
As a developer, I can fully understand why this idea is compelling. We tend to have a very high capacity in learning and a high interest in what we do. So the prospect of learning a new framework, tool or programming language is already something very appealing. Of course, learning new styles and techniques is part of being a developer; but this should be a prerequisite or requirement, not a goal.
Personally, I'm a fan of the KISS principle. I don't have much confidence in great frameworks or tools. History has shown us that bigger and better tools allow us to make bigger and more complex software – but that software usually isn’t better than the software made without them. So, although it may seem logical to focus on investing time and resources into learning tools and programs, from my experience – I would say this is not the case.
→ The only reliable thing to do for better software results is to invest in the people who are creating it.
Frequently asked questions like "Which programming language is the best?" can actually be approached analytically. For example: if there was a best programming language, everyone would be using it. Therefore, it would make sense that because there is more than one popular language in use – there is no universal best programming language.
The most frequent approach is using our rational mindset and subjective evaluation to try to understand which programming language presents which trade-off. How we evaluate these compromises determines how good a programming language is. However, a lot of times we simply don't have enough data to be able to make an empirical judgment and we need to resort to the rational model of reasoning about certain things, which can be a very thorny place to be.
Image: Nesa Makers
We can approach it with an emotional mindset and evaluate our own affiliations with the certain programming language, because human reasoning – fundamentally – is very flawed, especially when our emotional side kicks in. Be careful. Rationalism can very quickly turn into "religious dogma." Whenever you have a choice – try not to involve feelings about the code. It’s weird to get emotional about something so objective.
→ Be candid and question things objectively!
Programming is not About the Code
Just because the different disciplines share the common denominator that developers write code, it doesn't mean that they have the same challenges and constraints. If you are a game developer, you should probably know a great deal about linear algebra, and as a web developer you don't need to know any of that, but instead, you need to understand the business domain and a lot about user behaviour. Furthermore, embedded device developers should know about CPU cycles, memory management and similar elements.
→ Programming is just a tool and a medium to express the essential part: our ideas.
Generally speaking: as a developer, you can work at IT companies – which are focused on the technology development, or at production oriented companies – which are using the existing technologies to assemble them into a product, in order to solve particular customer problems. The cost of constraints and challenges between them are different and what is required from you as a developer differs as well.
You should be aware of these differences and to not understand them can lead to a lack of work satisfaction. Some developers working for production companies sometimes find themselves unhappy, as they feel they don’t satisfy their work expectations. These developers frequently swap the companies they work for, not knowing the real reason for their dissatisfaction and not realising that those companies are not playgrounds for them to work with deep tech. That’s why it's essential to know what kind of developer you are and for which type of company you want to work for.
Making Good Decisions
If you are asking the question whether it is better to rebuild something from scratch or to salvage it, the only answer you can expect is: neither!
Image: Kobu Agency
Both approaches may turn into extremely miserable experiences. What you should do instead, is to maintain your professional integrity and defend the objective before it happens. In practice, that means defining the maximum tolerable debt level and make sure you don't exceed that. This is mainly done by making good decisions in our day to day work and by compounding effects of small improvements and regressions. Be aware that big refactoring almost never works.
Human Thinking > Algorithmic Thinking
We are humans, we are solving problems for humans, and the only proper way of doing that is by thinking like a human. In a way, there is no alternative to that. If programming were deterministic, it would be a paradox in itself. We would then be able to automate it, and as a result – programming roles would not be needed anymore.
Better humans beat better tools – every time.
Technical competency is required, but not sufficient. What lies beyond technical skill is what will make the difference.
Always think about constraints. If you are making web applications, and at the same time thinking "Should I do some language level optimisation on my code?" The answer would be "no”! Because the constraint of your program is I/O, and the constraint of your team is developer resources. You are trading very valuable developer resources for the less useful type of work.
Be obsessed with the flow.
Solve real problems.
Don't have feelings about the code.