First Principles — Issue #47

The Minimalist Engineer

When I first started writing software I was writing Minecraft plugins.

I was doing it for fun, which meant just hammering away at my keyboard for hours, often with no regard for design or performance. I just wanted to see the code work.

My friend, who was also working on Minecraft plugins, showed me some code he was working on that allowed users to drive Minecraft "boats"on land on his server. For every player in a boat on the server – if they were holding the "w" key to go forward then the server would inch the boat forward in that direction at a logarithmic rate. Just like a car.

When he showed me the code, he had all the "Boats" on the server stored in a hash map, every "tick" the server iterates through the hash map, then would accelerate the necessary boats forward using and if statement and some math.

I suggested making a custom "boat" object with an "accelerate" and "decelerate" function to clean up the code.

We did. Then when the plugin went live? It was much slower.

I was learning about Object-oriented programming at the time and was confused. How could this be worse? Isn't this supposed to be what good code looks like? I felt like I was missing something.

Turns out – It's not always so simple.

Simplicity, or Abstraction?

Simplicity is the goal we strive for as engineers. Simple designs. Simple code.

In the modern age of software this often means reaching for packages. Finding that one package on the web that has a doTheThingIWant() function. It's like it was made for us.

In many cases this is harmless. Abstraction can save us a ton of head space and make for a much smaller code base. The problem comes when you use libraries in the wrong places.

In the story about Minecraft – abstraction ended up costing us. That's because we used it in the wrong place. We put it on the hot path.

Creating objects is expensive.

Minecraft plugins have a "tick" that runs every 50ms. This is how video games work. They are basically an infinite loop that update the game over and over to create the illusion of continuity.

There were a ton of boats on the server. Creating objects for each boat in the hot path added about 5ms of delay. In most cases this isn't an issue, but when you increase the "lag" of each loop on the video game from 50ms to 55ms? That's a 10% increase. You feel it. Back to a hash map it was.

This was an early taste of "the cost of abstraction" that I got early in my career.

Objects made the code simpler, but at what cost?

There is a difference between striving for simplicity, and unnecessary abstraction.

You Probably Don't Need It

If are ever justifying something to yourself – You don't need it.

This applies to clothing, cars, and code.

If you are cleaning out your house and decide to keep the salad spinner because you might spin one salad a year? You don't need it. I'm sorry, but you can toss your one salad a year in a bowl.

The same applies to software engineering. If you are adding a new micro service because one day you might have 10,000 customers and right now you only have 10?

Don't do it. Save it for when the need is undeniable.

Similar to how keeping a salad spinner floating around the kitchen cabinets adds clutter and occupies headspace?
Unnecessary code and infrastructure adds complexity and occupies your time.

The irony is that by anticipating 10,000 customers with micro-services you can add complexity that slows you down so much that it's impossible to ever get there. So much for scalability.

If you are ever asking "Do I need this?" The answer is no. You don't.

The Mantra of The Minimalist

Question Everything

Do you really need to import that library?
Do you really need to add that feature for launch?
Do you really need to create a separate service for that?

Questioning everything is the foundation of minimalism.

It's how a minimalist operates. Always question what is and consider what could not be.

Iterate

This isn't your only shot you get. It is just the first try of many.

Make decisions. Move fast. Commit. and iterate.

Do you really need that or can it happen in the next iteration? The ability to ask questions, make decisions, and execute fast will always be more beneficial in the long run.

Think about driving your car down the highway. You make minor adjustments every few seconds to stay straight in the lane. These are iterations. If you had to get it perfect from the start, line your car up with the lane, and go forward? You would end up hitting the wall after driving far enough.

Iteration not only lets you make progress faster. It helps you make better progress faster. It lets you constantly evaluate if you are on course and correct yourself.

Trim the Fat

Over time things get bloated.

Old code doesn't make sense, old designs are holding back progress, old features could be dropped because new ones do the same thing.

It is equally important to question what you are adding as it is to question what you have.

Ask "do I really need this?" when adding new code and when evaluating current code. The constant "trimming the fat" process will save more time than it costs in the long run.

Without constant maintenance, up keep, and trimming? the universe trends towards disorder.

So will your code.

______________________________________

Thank you for reading this week's newsletter.
I appreciate all of you who read to the end.

How I can help you:

​Book A Coaching Call ☎️​
​Free Course 📚​
​Email Me​ 💌​

Until next week 👋