Simple code is the best code
🎁 Special edition: Insights from the LinkedIn Engineering community!
Typo (sponsored)
This week's newsletter is sponsored by Typo. I recently tried their latest platform version and I really like the way they approach to improving engineering productivity.
Typo AI is the only software engineering intelligence platform that brings together development analytics, AI code reviews & developer surveys to deliver software faster, better, and more predictably.
For continuous improvement of your dev teams, I highly recommend checking them out.
They offer a 14-day free trial & 20% off (lifetime offer) for Engineering Leadership readers. Use this coupon code at the checkout page: EL20.
Let’s get back to this week’s thought.
Intro
One of the best things I like to see as an engineering leader is: A simple solution to a complex problem. Anytime I see that, it really makes my day.
But how do we actually know what is a simple solution? How can we define simple?
This is what I like to say:
It's hard to define what simple looks like, but you just know it when you see it!
And it’s very true because simplicity has many different ingredients and can be defined in so many different ways.
The more experience you have in a certain field, the easier you spot simplicity because you can match it to certain practices that you find to be great and have worked well in your case.
But let’s take a step back and define why exactly simple code and overall simplicity is the way to go in the engineering industry.
The more complex a solution is, the more 💰costly it is for the business
With every line of code we create, someone needs to maintain it and the more complex the code is, the harder is going to be for people to understand it.
Therefore it will cost more to the business to ensure that it works correctly or to add additional functionalities.
I have made many mistakes in my career thinking that complexity is a good thing.
I did it both as an engineer and a manager as well, but now simplifying is my personal philosophy. I strongly believe in it not only professionally, but also personally.
Anything I put my mind into, I ask myself:
What would be the simplest solution for this?
If you wish to read about my mistakes and why simplifying as much as possible is the way to go in detail, you can read this article: Simplifying as much as possible is the way to go in the engineering industry (paid article).
Let’s get into why simplicity is not as easy as it seems.
Simplicity is hard
If you can make it simple, you truly understand it.
When we look at some of the most used products in the world → they are very simple to use. The companies behind them didn’t just make them simple on the first try.
It’s been years of continuous adjustments and making things better, so they came to the result that we know today.
The same is true with simple code. You need to really know what you are doing to make it as simple as possible. Plus your empathy needs to be on a very high level.
Empathy is what helps you write code in a way that others with zero context can easily understand it.
You can read more about why empathy is such a superpower here: Empathy is a superpower in the engineering industry (paid article).
So, how do we define simple code?
I have asked the LinkedIn Engineering community for their definition of simple code
There has been a LOT of really great answers and I am sharing some of them with you.
There are a lot of tips and insights here that I highly recommend you either note down somewhere or bookmark this article.
“Code is simple when it’s easy enough for anyone to read. Just like simple English.”
— Mike Thornton“It's simple if even the most inexperienced person in the team can look at in and understand it.”
— John Crickett“Simple code = I don't run git blame against it.”
— Neo Kim“I measure it with cyclomatic complexity-reduce the nested conditions. Makes it easy to test as well.”
— Taha Hussain“Simple code is code that is easy to read. I'd say readable code has good variable names and a good structure. And yes, over the years you can just see and tell which code is simple and which is complex.”
— Kamran Ahmad“One way to think about it is that simple code is easy to understand. It minimizes unnecessary complexity, avoids overly clever solutions, and clearly communicates its intent. It’s code that others (and your future self) can quickly pick up and maintain without scratching their heads.
Focus on writing code that’s readable and concise, but not at the expense of clarity. A simple approach often involves breaking down complex logic into smaller, well-named functions or using descriptive variable names”
— Ayman Anaam“Simple code == Everyone in the team (and even outsdie the team) understands it”
— Francisco Manuel Soto Ramírez“It's about the team's preferences rather than one's individual preferences.
Team > Me”
— Petar Ivanov“Simple code is often the most powerful. Anyone who deals with a lot of coding knows how frustrating bugs from complex code can be.”
— Sidwyn Koh“Simplicity is complex. It needs thinking to make things simple. Keeping things simple shows a person's experience.”
— Diwakar Singh“If I could pick the 3 most important guidelines those would be:
- separation of concerns
- stateless over stateful
- inversion of control”
— Djordje Mladenovic“Simple code:
1. Readable (for humans, not just to compilers)
2. Meaningful naming conventions
3. Separation of concerns
4. Provision for scale
5. Documentation / Comments”
— Dharan Rajan“I used to work on one project for 2-3 years before switching to another. And for me a simple code - it is the code I can easily understand after 1 year I wrote that.”
— Alina Kulish“On a technical level, it can be measured using a McCabe method.
However, on a human level, it is a different measurement. My go to indicator is how easy it is for the author to share the details with others so that it is not owned by the author anymore.
Some concrete metric could be an effort to resolve a defect by author vs non-author. Effort to add a change request by author vs non-author.”
“Simple code reads like a story. clear, easy to follow, and with no hidden surprises.
If someone new to the project can jump in and understand it without asking for a walkthrough, you’ve nailed simplicity.”
— Saurav Rawat“Simple code is intuitive and easy to maintain. It reduces cognitive load and allows others to understand and enhance it effortlessly. Simplicity is an art, and achieving it can be the true mark of expertise!”
— Ram Verma“If I can add functionality or change functionality without having to refactor the whole thing due to an inappropriate abstraction, it's simple.”
— Krystian Cybulski“Not every complex problem can be solved in a simple way. But there is an over-complicated solution for every simple issue.
Complex != Complicate”
— Martin Spickermann“Code is simple when it prevents all possible misuses and misunderstandings, while at the same time minimising the amount of knowledge needed to use it correctly.
Needless to say, simplicity takes a lot of effort.”“Simple code, to me, doesn’t mean limiting functionality; rather, it embodies clarity, maintainability, and focus—qualities that make scaling, debugging, and iterating far more efficient.”
Last words
Thanks to the great LinkedIn Engineering community for all the great insights on this very important topic!
I regularly feature insights from the comments on my LinkedIn posts, so definitely make sure to follow me on LinkedIn for a chance to get featured the next time.
Let’s end this article with this important thought:
A lot of people can write complex code, but the ones who write simple code are the real experts.
Stay tuned till Wednesday, there is a great article lined up for paid subscribers, if you are not already a paid subscriber, consider joining!
We are not over yet. 2 things.
How Fractional CTOs make huge impact on 30% time
Together with
, we are hosting a free event in collaboration with Maven.We will talk about:
1. What is a Fractional CTO and how do you become one?
2. What are the key skills needed to thrive in the role?
3. Tips on how you can learn and practice the key skills needed.
The 30 min event is going to be on November, 5th (17.30 CET).
If you’re an engineer or engineering leader, interested in potentially becoming a Fractional CTO, this would be a great event for you!
I will be speaking at Infoshare Katowice
I will be hosting a workshop and having a presentation on November, 26 in Katowice, Poland. If you’ll be attending, it would be great meeting you there!
If you don’t have a ticket yet, you can get it with 10% off with code: ISK24-OJSTERSEK10
Looking forward to meeting you there!
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn or Twitter.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
Clever code is probably the worst code you could write.
Clear, readable code is probably the hardest code to write.
Great article Gregor!
I think we get paid to make complex things simple