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.
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.”
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.”
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. ”
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.
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
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
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.”
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.