Top 3: laws of development, overengineering and 2,138 technical questions

Happy New Year my friends!

​​In 2022 I decided to make a change to the newsletter.

In the last couple of months, I've realized that I'm always drawn to create systems, no matter what I do. So I decided to learn how to do it in tech and grow into the role of an architect.

This decision makes a difference in what I read and study every day. I'm reading less and less about web development and more about development and tech in general. That's what important for me.

And I want to focus on the important and share with you only the important. So here’s what will change to the newsletter:

I'll be sharing with you the top three articles I read each week with my notes instead of just sharing 5 links.

Topics: development, technology, web development [sometimes], self-development [sometimes], tweet of the week [sometimes].

Newsletter becomes more focused, deeper and personal. I’m sure you will enjoy it!

Before we start I have a question for you, how to name it?

"3-2-1" does not reflect what I write about, and I need a new proper name for it. The draft nam is "Top 3," but if you respond with something better, I'll change it to your name 🤝

Alright, let’s start!

1. Hacker Laws​

TL;DR: Useful laws, principles and mental models used in development.

What caught my attention:

• Brooks' Law – if a project doesn't meet a deadline, adding more people will delay it even more.

• Hyrum's Law – with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Example: You’re building an API. Every request can throw an error with a code and an error message. And your documentation says "check error type by error code”. Clear message.

What part of users do you think will check the error type by the error message?

I think it's a significant one so that in one day, changing the error message will bring down a lot of user applications and overload your helpdesk. That’s what this law is about.

• The law of triviality - people will spend more time on trivial and cosmetic tasks than on serious and significant ones.

The law works because many of us are afraid of losing our social status and will do anything to make sure that doesn't happen.

Example: Zoom conference. People discuss a very complex problem. How many will make a valuable contribution to the discussion of the problem?

I think less than 10%.

Because without expertise or preparation, it is difficult to give an opinion that can be easily argued without getting screwed.

But people still want to make valuable contributions. So when a new conference in Zoom gathers, but this time to discuss a trivial problem, 80% of people will actively participate in it, because now it's much easier to ground their opinion and therefore contribute too.

2. Overengineering can kill your product​

TL;DR: Why overengineering is evil, how it can kill your product and what to do about it.

I used to suffer from it myself. Sometimes I still do, when I believe that I can foresee the future and know how the market and the product will evolve.

Sometimes I’m right, more often I’m wrong. The problem is that this often always adds complexity to the project, which eventually leads to:

1. Reduced speed of development
2. Increased cost of development
3. Increased time for onboarding new people.

Generally, a business either loses or gains less. So de facto, when the idea of “optimizing for the future” comes up, I reject it. The exception is a big chance of that future, backed up by data.

3. DevOps Exercises​

TL;DR: 2138 questions related to technology, DevOps, and SRE.

For those who are preparing for job interviews or are hungry for new knowledge.

If you're enjoying the newsletter, share it with a friend or two. Here's one quick way you can do it in 5 seconds:

​Share with Twitter, WhatsApp, Facebook, LinkedIn or copy & paste this link: https://nickbulljs.com/3-2-1​

That's all for this week, take care and have a great one 🎅

– Nick