Five principles that improved my software engineering skills

Mentoring younger developers is a very rewarding experience. It challenges your your pre-established ways of thinking, and it forces you to re-evaluate your long held principles. For example, a simple question like “Why does it matter to DRY out your code?” is remarkably hard to answer.

In the last couple of years, I was asked to provide tips and guidance on how to become a better software engineer. Sadly, I rarely gave a satisfying answer. It is hard to come up with a good advice on the spot.

This article is an attempt to systematically prepare and share a set of principles that helped me to become a better engineer. Obviously, there are as many learning styles as there are people, but these are what work for me.

I identified five principles that are the fundamentals of my learning style.

1. Start with a real problem, not with solutions

I am sure that there are people out there who can simply learn just for the sake of intellectual curiosity. But that is not how it works for me. I need to have a real reason for learning something.

For example, learning the actor model because my friend told me it’s an interesting approach for structuring programs won’t really keep my attention too long. I might learn the basics, but I will soon hop on to the next thing that grabs my curiosity.

Instead of learning a technology, an establish pattern or way of thinking, I find it much easier to learn as I was on a mission to fix something. For example, if I notice that I create lots of concurrency related bugs in my code, I go on a mission to figure out a way to improve this process and I explore the actor model as one of the possible solutions.

Starting with a problem that directly affects a human helps me in three ways.

1. I have a strong motivation for learning, which keeps my focus in place.

2. I don’t keep learning every small, potentially insignificant detail. For example, the mathematical model behind the actor model is perhaps interesting, but ultimately it doesn’t bring me closer to anything in real in my life.

3. When I find a solution, a real human being’s life gets better. This boosts my happiness levels, and inspires me to push on, even if it gets too hard.

2. Focus on the 80 percent, explore the 20 percent

Perfection is useless. I try to focus on the core 80 percent of the problem.

1. When learning, I learn the core of the idea. I’ll learn the rest when I really need it.

2. I strive to be an engineer that is not a just a “bug fixer”. Fixing bugs is an important skill to have, but first, I want to be a confident creator who can create things from scratch.

3. There are no problems out of my league

I observed two detrimental patterns in my life:

1. The “I’m an not smart enough to know that many things” pattern, where I would freeze when the problem was outside of my domain.

2. The “I’m am too good to learn about those insignificant details” pattern, where a I would refuse to tackle some issues because I thought that I am too good for them. For example, fixing a CSS bug is not worthy of my time, even if all of our customers are suffering to use our product.

Both issues are related to my inertia as a software engineer. I like to ask myself the question “Is this really that hard (easy) that I can’t push through it with just a bit of extra effort?”.

I are not less or more capable than anyone else. We are all humans.

There are no hard programming languages, each of them can be learned in a matter of weeks. Human interaction issues are also just a type of issue. Everything can be learned quite easily. Whining about an issue won’t really help anyone.

Many times, even 20 percent of the full knowledge from some other area can allow me to do things 10x faster, just because I don’t need to hand over the problem.

4. Always keep improving your basics

It’s a sad thing when a software engineer doesn’t know how to use grep to find a pattern recursively in a directory. Or when you don’t know how to follow TDD principles. Or when you struggle with the shortcuts in your editor of choice.

The basics are basics for a reason. Once I learned them, they improved every single day of my life.

I dedicate at least a portion of my time every week to keep the basics in good condition. If I have struggled with awk last week, for example, I make sure to read up a bit of from the manual page by the end of the week.

5. Read a shit-ton of code

Finally, the thing that improved my skills the most was reading other people’s work. Reading the source code Kubernetes taught me how to write proper Go code. Reading Rails’ source code, thought me Ruby. Reading my colleagues work got me up to speed in any area of our product.

The most beautiful thing about open source isn’t that it is free. It isn’t even the community. It’s the ability the download the source code, take a deep dive, and simply enjoy a relaxing Sunday evening.