Code Simplicity

Everything you want to accomplish with a piece of software depends on only two things: Understanding Executing on that understanding When I say everything you want to accomplish, I mean everything.

Over the past few years, we have been so focused on worrying about the future of our own profession that most of us have failed to notice the most important thing that’s about to happen: Everybody will be able to write software.

As I write this, it’s the start of 2026 and many people are in a crisis about what their job is.

In the field of software engineering, we often talk about using or building a “platform.”

I’ve been working for over 20 years in the field of “developer experience,” where we help developers be more effective, efficient, and happy, by improving tools, systems, and processes.

Sometimes, I have to explain software development to people who are not software developers.

About a year ago, a Twitter user tagged me and some other programming authors in a thread where they described the barriers to accessing computer programming books in their country.

There are often discussions at software companies about whether they should or shouldn’t have a “monorepo,” meaning “a single, version-controlled repository for all code at the company.”

One of the most important properties about any software system is the ability to understand what it is going to do without having to run it.

Many years ago, I wrote a blog post explaining what was wrong with computers, and essentially saying the problem was complexity.

There’s a point that I’ve been making to engineers recently that I realized would be valuable if shared more widely.

One question that people ask me all the time is, “How do I become a programmer?”

There are three key factors to being or becoming a great programmer: awareness, understanding, and responsibility.

Hey everybody.

It is very easy to think of software development as being an entirely technical activity, where humans don’t really matter and everything is about the computer.

Sometimes people have a very hard time debugging.

There’s a point that I made in the book but which I have had to point out to people a few times since then, and so I wanted to emphasize it a bit more.

Often, people who work on engineering productivity either come into conflict with the developers they are attempting to help, or spend a long time working on some project that ends up not mattering because nobody actually cares about it.

Almost as long as I have been working to make the lives of software engineers better, people have been asking me how to measure developer productivity.

There is a key rule that I personally operate by when I’m doing incremental development and design, which I call “two is too many.”

Here’s an obvious statement that has some subtle consequences: Only an individual programmer can resolve code complexity.

Today there was an interesting discussion between Kent Beck, Martin Fowler, and David Heinemeier Hansson on the nature and use of Test-Driven Development (TDD), where one writes tests first and then writes code.

In general, when technology attempts to solve problems of matter, energy, space, or time, it is successful.

When I talk to developers about code complexity, they often say that they want to write simple code, but deadline pressure or underlying issues mean that they just don’t have the time or knowledge necessary to both complete the task and refine it to simpl…

When solving a problem in a codebase, you’re not done when the symptoms stop.

Much like we gain knowledge about the behavior of the physical universe via the scientific method, we gain knowledge about the behavior of our software via a system of assertion, observation, and experimentation called “testing.”

In the world of software, it is the job of software developers to solve the problems of users.

One thing we know about software design is that the future is important.

In June, I released a second revision of Code Simplicity.

I don’t often dive deep into the philosophical underpinnings of Code Simplicity, but I’ve been realizing more and more that there are a few philosophical principles behind the writings that would be valuable to share.

What if every software developer could gain the knowledge of long experience without having to go through the pain of repeated failure?

Here are some clues that tell you that your code may be too complex: You have to add “hacks” to make things keep working.

Your program is not important to me.

Growing and maintaining an open-source community depends essentially on three things: Getting people interested in contributing Removing the barriers to entering the project and contributing Retaining contributors so that they keep contributing If you can…

Many people think that the readability of code has to do with the letters and symbols used.

How many times have you used a piece of software that was full of incredibly convoluted features, strange decisions, and unusable interfaces?

One of the major goals that I have with researching software design is the hope that we can take people who are “bad programmers” or mediocre programmers and, with some simple education and only a little experience, bring them into being good programmers…

In the context of The Equation of Software Design, it is now possible to reduce the primary principles of software design into just two statements: It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of Implementation.

So today I was playing around with a little equation that may in fact explain nearly all of the principles of software design.

So, there’s a lot of talk on the Internet about privacy.

A long time ago, I wrote an essay called “Why Computers Suck” (it was given the title “Computers” and “What’s Wrong With Computers” in two later revisions, and the original title never saw the light of day).