7 Software Engineering Articles Every Developer Should Read

November 20, 2020 · 5 min read
two girls sitting on a couch, typing on macBooks, looking concentrated
Photo by Mimi Thian on Unsplash

There are myriads of articles online about software engineering.

You encounter dozens of them every day, and every time you decide to either read that article or not.

Many articles focus on technical details, and those are important if you need to implement something specific.

But like any profession, software developers do a much better job when they get the basics right.

Here are 7 articles you should read, if you're a developer. Each one contains ideas that helped me become a better software engineer, even if I don't 100% agree with everything.

What I tell all new programmers

Advice from a developer and programming instructor, that he learned his students need to hear.

“Programming is really hard. No matter how good you get at programming, the only thing which slows you down is your ability to learn & solve problems. This seems to become more true as you get better at it. This is a fantastic trait - you will never be bored programming. If you are, you're doing it wrong and you should abstract over the set of code you're rewriting.”

Evolutionary Design

You've certainly heard about agile software development. All agile principles are worth understanding, but Evolutionary Design is a centerpiece. It reduces your risk on every software development project.

It has much in common with Lean management and means that you start with a very simple but whole product and add more value from there.

“Evolutionary Design is both a management and technical practice: it influences how we organize people, plan work, develop and release. I said at the beginning of this blog that it is agile’s most valuable practice. It helps us manage collaboration and integration risk by guiding us to produce a primitive whole. It tests that we are collaborating successfully by asking us to integrate early and often. It helps us discover what our users need.”

Where is the complexity? - Coding the Architecture

In software engineering, you are modeling the complexity of the real world. Actual processes, interactions, data, and constraints. Therefore, your software necessarily has a certain complexity that you can't reduce anymore unless you remove functionality.

The most important question here is where and how you model this complexity in your code. Most "shiny new technologies" only offer novel ways of hiding this complexity for you.

“One of the dangers that software architects face is that their background can determine how they perceive complexity and how they deal with it. It is very common to push complexity out of the area they know and into another because it initially appears to be reduced. In reality it is still there but is now residing in part of the system that is less well understood. ”

Write Dumb Code

The best code is no code. The second-best code is code that doesn't surprise you and is easy to understand. Always add the least amount of complexity to your projects, including libraries, tools, databases, and infrastructure.

  • “We should not seek to build software. Software is the currency that we pay to solve problems, which is our actual goal. We should endeavor to build as little software as possible to solve our problems.”
  • “We should use technologies that are as simple as possible, so that as many people as possible can use and extend them without needing to understand our advanced techniques. We should use advanced techniques only when we are not smart enough to figure out how to use more common techniques.”

In the same regard, you should read the “Boring Technology” presentation. Choose boring and proven technology when possible, to minimize the amount of unknown unknowns.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint Exupéry

A Detailed Explanation of The KISS Principle in Software

This article is a beautiful explanation of “Keep It Simple Stupid”. This should be your mantra when developing any system (apart from building a working version as early as possible).

“Keep in mind though: if you try to understand the business you’re working for, you will have more chances to find simpler solutions. Try to speak with domain experts (people having the knowledge of the business itself) as much as you can, always refresh your knowledge and avoid being overconfident in it.”


If you're ever thinking of adding anything to your project or not, the answer is probably “you ain't gonna need it”. This principle supplements the two previous ones.

“The first argument for yagni is that while we may now think we need this presumptive feature, it's likely that we will be wrong. After all the context of agile methods is an acceptance that we welcome changing requirements. A plan-driven requirements guru might counter argue that this is because we didn't do a good-enough job of our requirements analysis, we should have put more time and effort into it. I counter that by pointing out how difficult and costly it is to figure out your needs in advance, but even if you can, you can still be blind-sided when the Gondor Navy wipes out the pirates, thus undermining the entire business model.”

“Simplicity – the art of maximizing the amount of work not done – is essential.” – Agile Manifesto

Guiding Principles of Lean Development | Planview

Even when you're not the one setting the requirements for your project, I hope you have some way to express your thoughts and give feedback. Developers knowing about Lean development principles benefit every project.

“It might seem self-evident; every team wants to build quality into their work. But unless this is part of a disciplined practice, it’s far easier said than done. In trying to ensure quality, many teams actually create waste – through excessive testing, for example, or an excessive logging of defects. In recent decades, many Lean development teams have found success by applying the following Lean development tools to build quality into their work. In Lean development, quality is everyone’s job, not just that of the quality analyst.”

Read High-Value Articles

Time is our most important asset. Once used for something, it's gone forever.

Some articles, blogs, and authors have much higher value-for-time ratios than others. You can learn insights from people with decades of experience from home, at no cost.

“You must learn from the mistakes of others. You can’t possibly live long enough to make them all yourself.”

If you want more high-value articles, take a look at Nerdful Mind. There I share the best articles about mindfulness, psychology, and software engineering every Sunday.