Ljubljana, Slovenia

Premature optimization

In my many years as a software developer, this is one phrase which I have heard over and over:

"Don't optimize your software prematurely."

I have no idea where the phrase came from. I know that most software is shit because people don't know any better. And generalities like this encourage people to write bad software. I will try to list a few things that I think make up a good developer culture.

Invest in people, not hardware

Developers should be encouraged to think about possible bottlenecks before they happen. Generally, this is called planning, or in some extreme cases, premonition. As long as people are paying attention to detail, the problems will be obvious before they happen.

The thing which I see too often is that a lot of managers throw faster SSD's, more ram, faster and more CPU cores at the problems which shouldn't exist in the first place. This encourages a culture of programmers which think every problem is solvable by more hardware. You wouldn't believe how much running costs we have saved by correctly writing the software in the first place, and then additionally only tweaking the few bottlenecks that were found after the fact, mostly caused by feature creep.

Share your failures

If you make mistakes, learn from them. Define what you did wrong. Admit to your problems and share your failures. If anything, a developer should be comfortable admitting his failures, rather than hiding them. To quote the old adage "The first step to fixing a problem is admitting you have one." and regarding sharing your problems: "Those who cannot remember the past are condemned to repeat it."

Admitting problems shows integrity, which in turn increases trust. Nobody is perfect, it is only how you handle failure that defines you as a person. I'd take the programmer who admits his failures and works on them any day of the week, because I will trust them to say what is and what isn't going well. Sharing the problems with other developers means other people can also learn from their failures.

Specialize

Don't be the guy who knows and does the little bit of everything. While this is fine for individuals and small teams, being specialized is better than being generally good at everything. That's my theory at least.

An expert for SQL only has one problem domain the whole day. Writing SQL queries, preforming DBA tasks. His problem domain becomes his life, he knows how to set indexes and create database structures and squeeze the last bit of performance out of the SQL services.

Now imagine that SQL guy having to work with JavaScript as well. Write some JavaScript, work on some SQL, write more JavaScript. The attention to detail falls by the wayside soon enough, and time is lost in the context switching between the two problem domains.

A specialized developer will solve problems in his own problem domain by a factor faster and better than other developers. I have seen this many times over in projects over the last 10 years, small and large. Specialized programmers however will choke if they have to work on projects that require many skill sets from them. There are not many exceptions to this rule.

Ask for help

You don't need to do everything yourself. Delegate. Figure out what needs doing and what is important. Inevitably there are people around you who are better than you at something. Communicate.

This section could be called team work, but I find it important to get the message to your head that you are an individual. Your skills are your own, and other people have other skills that might be better than yours. You don't need to know and do everything, and don't be afraid to ask for help when you need it. You can search and talk about things outside your company and connect with the local developer community.

In conclusion...

Out of context managers use the phrase "don't optimize prematurely" as another way to say "write code quickly". In practice, performance goals have to be kept in mind, with a balance between design and optimization.

You will inevitably work with some bad programmers or contractors. The "shining light" at the end of this tunnel however is, that the better you are at your craft, the better people you have around you. I've seen good programmers rise out of very unconventional places.

"Cream always rises to the top"

- Tit Petric

While I have you here...

It would be great if you buy one of my books:

I promise you'll learn a lot more if you buy one. Buying a copy supports me writing more about similar topics. Say thank you and buy my books.

Feel free to send me an email if you want to book my time for consultancy/freelance services. I'm great at APIs, Go, Docker, VueJS and scaling services, among many other things.