Code Simplicity: The Fundamentals of Software is Now Free

Published on

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. I’ve been made distantly aware of these problems before—there are many countries in the world where the cost of a book in USD could be a person’s entire weekly salary.

I didn’t write any of my books to make money—I wrote them to get a message out and to help people. I usually think that people are more likely to actually read a book if they pay for it, and the point was to get people to read the book, because that was the only way I was going to change the software industry for the better. The book does still sell copies (which is unusual for a computing book, since it’s been ten years since its release) but the money it makes is not important to me—it’s getting people to read the book that’s important to me.

Once I realized that there was a huge population of the planet that was entirely barred from reading the book legally if they had to pay for it at all, I worked with my editors at O’Reilly to see if we could make the book completely free.

It turns out that for complex reasons beyond their control, they can’t make the book free on Amazon or in the O’Reilly store. But they can give me the distribution rights to the book, take the cover off, and let me distribute it for free!

So here you go, you can now download Code Simplicity: The Fundamentals of Software for free! I hope that this gets more people to read and understand the fundamental laws of software design, and that it helps make the world of software development a better place.

What is a Monorepo, Really?

Published on

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.” Very often, people base this decision on the fact that this is how Google stores its code.

I have now worked in developer productivity organizations at a company with a very advanced monorepo (Google) and a company with a very advanced multi-repo system (LinkedIn), and I have to tell you: most of the valuable properties that people associate with a monorepo have nothing to do with how many source control repositories you have. In fact, what people (and Google) consider a monorepo is actually multiple different concepts:

  1. Atomic commits across different projects. (And thus an atomic “head” commit that moves forward atomically for all code.)
  2. A universal directory hierarchy and a single view of all source code.
  3. The single place where you go to check out or commit code. (Including all tools that read or write stuff.)
  4. (Sometimes) The smallest unit of check out, commit, and dependency is a file.
  5. (Usually) No concept of a project, only concepts of directories and files.
  6. (Sometimes) The One Version Rule: There may only be one version of any dependency in the repository at any one time.
  7. The ability to require library maintainers to solve the problems they cause.

I’ll talk about these in more detail, including some of their upsides and downsides. Keep Reading

Reasoning and Choice

Published on

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. This concept is usually referred to as the ability to “reason about the system.” Basically, you want to make statements about the structures, actions, and results of the system without having to see them in action first.

To understand why this is important, imagine a system with a hundred different pieces. To keep this simple, let’s pretend it’s an actual physical system, and not a computer. Let’s say that we have an automated plant that produces cars, with 100 steps from raw materials to finished car. Each of these parts makes some change to the input materials to produce an output product. There are various ways we could configure this system and each of its pieces: Keep Reading

The Definition of Simplicity

Published on

Many years ago, I wrote a blog post explaining what was wrong with computers, and essentially saying the problem was complexity. Several years after that, I published Code Simplicity, which was essentially a thesis describing how and why simplicity was the most important quality of software.

Many years after that, I was sitting in a room of some of the world’s most experienced software engineers, coming up with guidelines and principles around which we wanted to structure software development, and after questioning the room, I came to a terrible realization: nobody had ever defined what “simplicity” was for software.

I thought, perhaps naively, that this was simply a known fact—that when I said “simplicity,” everybody just knew what I meant. To some degree, honestly, this was true. When you say the word “simplicity,” people at least get some idea. But I noticed that people would apply it in many different ways, some of them very much not what I intended. I would see people point at a function or file and say, “Look, it has fewer lines of code now, thus it is simpler!” Or say, “Look, this system uses such-and-such design pattern, thus it is now simpler!” Or worse, “This system is now completely generic and follows all of the things that ‘everybody knows’ you’re supposed to do with software, so that’s simple, right?”

So, I went on a search to try to find some sort of valid definition for simplicity. Eventually, I had to come up with it. I actually came up with this several years ago now, and I’ve been meaning to write a blog post about it, but simply haven’t done so. So what is the answer to this great mystery? For software, what is simplicity? Keep Reading

Fires vs. Strategy

Published on

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

When you do engineering work, there are different types of tasks that get given to you. Some tasks are emergencies or short-term work. We sometimes call this “putting out fires,” especially when the work relates to handling something that is urgently broken or immediately needed without delay.

Other tasks are strategic in nature. You have collected information about what is needed and/or wanted from your users, you’ve designed a solution, and you’re working toward it methodically and intelligently.

It is important to understand when you are doing which type of work, and to think about them differently. Keep Reading

How to be a Great Programmer: Awareness, Understanding, and Responsibility

Published on

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

I’ve talked a lot about the subject of understanding. Heck, I even named my most recent book Understanding Software. In particular, I’ve pointed out many times that the better you understand something, the better you will do it.

However, there are two other factors that go along with understanding to make somebody into an excellent software developer. In brief, if you aren’t aware of a problem, there’s no understanding to be had. And if you don’t take action to solve the problem (which starts with taking responsibility for it) then you can’t do anything about it.

There’s a lot to know about each of these points, though, and they are key points when one looks at how to become a better software developer. So I want to go into each one in more depth with you, here. Keep Reading

Understanding Software

Published on

Hey everybody. I’ve published a new book! It’s called Understanding Software.

The book contains all of the content that I’ve written on software development and working in teams since the publication of Code Simplicity, plus some entirely new content that’s never been published anywhere. In fact, it contains one of my favorite essays that I ever wrote from back in 2008 but never published before. So there’s that for you. All the content has been put into a beautiful layout, then curated and organized for maximum readability.

It’s something I’m actually really happy with, and I’m looking forward to hearing what you have to say about it, too.

From the Publisher

Understanding Software covers many areas of programming, from how to write simple code to profound insights into programming, and then how to suck less at what you do! You’ll discover the problems with software complexity, the root of its causes, and how to use simplicity to create great software. You’ll examine debugging like you’ve never done before, and how to get a handle on being happy while working in teams.

Max brings a selection of carefully crafted essays, thoughts, and advice about working and succeeding in the software industry, from his legendary blog Code Simplicity. Max has crafted forty-three essays which have the power to help you avoid complexity and embrace simplicity, so you can be a happier and more successful developer.

Max’s technical knowledge, insight, and kindness, has earned him a status as a code guru, and his ideas will inspire you and help refresh your approach to the challenges of being a developer.

What you will learn

  • See how to bring simplicity and success to your programming world
  • Clues to complexity – and how to build excellent software
  • Simplicity and software design
  • Principles for programmers
  • The secrets of rockstar programmers
  • Max’s views and interpretation of the Software industry
  • Why Programmers suck and how to suck less as a programmer
  • Software design in two sentences
  • What is a bug? Go deep into debugging

You can get it on Amazon, direct from the publisher, or in any other place where programming books are sold.

-Max

Kindness and Code

Published on

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. However, the opposite is actually true.

Software engineering is fundamentally a human discipline.

Many of the mistakes made over the years in trying to fix software development have been made by focusing purely on the technical aspects of the system without thinking about the fact that it is human beings who write the code. When you see somebody who cares about optimization more than readability of code, when you see somebody who won’t write a comment but will spend all day tweaking their shell scripts to be fewer lines, when you have somebody who can’t communicate but worships small binaries, you’re seeing various symptoms of this problem.

In reality, software systems are written by people. They are read by people, modified by people, understood or not by people. They represent the mind of the developers that wrote them. They are the closest thing to a raw representation of thought that we have on Earth. They are not themselves human, alive, intelligent, emotional, evil, or good. It’s people that have those qualities. Software is used entirely and only to serve people. They are the product of people, and they are usually the product of a group of those people who had to work together, communicate, understand each other, and collaborate effectively. As such, there’s an important point to be made about working with a group of software engineers:

There is no value to being cruel to other people in the development community.

It doesn’t help to be rude to the people that you work with. It doesn’t help to angrily tell them that they are wrong and that they shouldn’t be doing what they are doing. It does help to make sure that the laws of software design are applied, and that people follow a good path in terms of making systems that can be easily read, understood, and maintained. It doesn’t require that you be cruel to do this, though. Sometimes you do have to tell people that they haven’t done the right thing. But you can just be matter of fact about it—you don’t have to get up in their face or attack them personally for it.

For example, let’s say somebody has written a bad piece of code. You have two ways you could comment on this: Keep Reading

The Fundamental Philosophy of Debugging

Published on

Sometimes people have a very hard time debugging. Mostly, these are people who believe that in order to debug a system, you have to think about it instead of looking at it.

Let me give you an example of what I mean. Let’s say you have a web server that is silently failing to serve pages to users 5% of the time. What is your reaction to this question: “Why?”

Do you immediately try to come up with some answer? Do you start guessing? If so, you are doing the wrong thing.

The right answer to that question is: “I don’t know.”

So this gives us the first step to successful debugging: Keep Reading

1 2 3 … 9