Code Simplicity

Code Simplicity

Before You Begin….

by Max Kanat-Alexander
Published on January 17, 2011

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 or great programmers. I want to know–what are the fundamental things you have to teach somebody to make them into a great programmer? What if somebody’s been programming for years and hasn’t gotten any better–how can you help them? What are they missing? So I’ve written quite a bit about that, particularly in some of my recent articles.

However, before somebody can even start on the path of becoming a better software developer, one thing has to be true:

In order to become an excellent programmer, you must first want to become an excellent programmer. No amount of training will turn somebody who does not want to be excellent into an excellent programmer.

If you are a person who is passionate about software development–or even just somebody who likes being good at their job–it may be hard to understand the viewpoint of somebody who simply doesn’t want to get any better. Keep Reading

Software Design, In Two Sentences

by Max Kanat-Alexander
Published on May 13, 2010

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:

  1. It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of Implementation.
  2. The Effort of Maintenance is proportional to the complexity of the system.

And that is pretty much it. If all you knew about software design were those two principles and the purpose of software, you could evolve every other general principle of software development.

-Max

The Equation of Software Design

by Max Kanat-Alexander
Published on January 6, 2010

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

Privacy, Simplified

by Max Kanat-Alexander
Published on December 29, 2009

So, there’s a lot of talk on the Internet about privacy. Some people say that privacy is only desired by those who have something to hide. Some people insist that privacy is a human right that should never be violated without consent.

There’s only one problem with this whole debate: what is privacy, and why would anybody want it? This is rarely defined–most people just seem to assume that “everybody knows” that privacy is, so why would it have to be explained?

Well, I’m not a big fan of “everybody knows.” And in fact, it turns out that privacy actually means two different things, which many people use interchangeably without specifying what they’re actually talking about. So to help clear up some of the debate online, and to hopefully shed some light on how it can all be resolved, here are some clear definitions and discussions of what privacy is, and why people would want it.

Privacy of Space

The first type of privacy is “privacy of space”. Keep Reading

Why Programmers Suck

by Max Kanat-Alexander
Published on December 1, 2009

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). The article was fairly long, but it basically came down to the idea that computers suck because programmers create crazy complicated stuff that nobody else can understand, and complexity builds on complexity until every aspect of a program becomes unmanageable.

What I didn’t know at the time was why programmers did this. It was obvious that they did do it, but why would the software development industry produce so many crazy, complex masses of unreadable code? Why did it keep happening, even when developers should have learned their lesson after their first bad experience? What was it that made programmers not just make bad code, but keep on making bad code?

Well, this was a mystery, but I didn’t worry too much about it at first. Just the revelation that “bad programs are caused entirely by bad programmers”, as simple and obvious as it may seem, was enough to fuel an entire investigation and study into the field of programming, one which had some pretty good results (that’s mostly what I’ve written about on this blog, and it’s also the subject of a book that’s in development). The problem had been defined (bad programmers who create complexity), it seemingly had a solution (describe laws of software design that would prevent this), and that was enough for me.

But it still baffled me that the world’s universities, technical schools, and training programs could turn out such terrible programmers, even with all of the decades of advancement in software development techniques. Sure, a lot of the principles of software design hadn’t been codified, but a lot of good advice was floating around, a lot of it very common. Even if people hadn’t gone to school, didn’t they read any of this advice?

Well, the truth was beyond my imagination, and it took almost five years of working on the Bugzilla Project with a vast number of separate contributors until one day I suddenly realized an appalling fact:

The vast majority (90% or more) of programmers have absolutely no idea what they are doing.

Keep Reading

The Singular Secret of the Rockstar Programmer

by Max Kanat-Alexander
Published on November 10, 2009

Before all the laws of software, before the purpose of software, before the science of software design itself, there is a singular fact that determines the success or failure of a software developer. This fact makes the difference between the senior engineer who can seem to pick up new languages in a day and the junior developer who struggles for ten years just to get a paycheck, programming other people’s designs and never improving enough to get a promotion. It differentiates the poor programmers from the good ones, the good programmers from the great ones, and the great ones from the “rockstar” programmers who have founded whole multi-billion dollar empires on their skill.

It’s not anything complicated, and it’s not something that’s hard to know. It’s not something that you can only do if you’re born with a special talent or a “magical ability to program well.” There is nothing about the nature of the individual that determines whether or not they will become an excellent programmer or a poor one.

There is only one, singular fact:

The better you understand what you are doing, the better you will do it.

Keep Reading

The Engineer Attitude

by Max Kanat-Alexander
Published on August 20, 2009

The attitude that every engineer should have, in every field of engineering, is:

I can solve this problem the right way.

Keep Reading

How We Figured Out What Sucked

by Max Kanat-Alexander
Published on August 18, 2009

So, after my last post, a few people asked, “Okay, but how do you figure out what sucks?”

Keep Reading

The Secret of Success: Suck Less

by Max Kanat-Alexander
Published on August 11, 2009

When I started working on Bugzilla in 2004, it was a difficult time for the whole project. There were tremendous problems with the code, we hadn’t gotten a major release out in two years, and a lot of the main developers had left to go do paid work.

But eventually, thanks to a bunch of new members in the Bugzilla community, we released Bugzilla 2.18. Hooray! Bells rang, birds sang, and there was much rejoicing.

However, in the space between Bugzilla 2.16 (which was before my time) and Bugzilla 2.18 (which was the first release that I helped get out), something very strange happened–we developed serious competition. All of the sudden there were a bunch of new bug-tracking systems, some of them open-source and some of them not, that people were actually using.

At first it wasn’t too worrisome. Bugzilla was pretty dominant in its field, and it’s hard to lose that kind of position. But as time went on, there was more and more competition, and some people were predicting doom and gloom for Bugzilla. We were a tiny group of completely unpaid volunteers, and some of these competing products were being made by companies whose marketing and development resources absolutely dwarfed us.

And yet, with every release, our download numbers kept going up. And always significantly–30-50% more than the previous release, every time.

And then we hit Bugzilla 3.0, and our download numbers nearly doubled. And they’ve kept going up with every release from there. Nowadays we get over 10 times the number of downloads per release that we did in 2004.

So how did we pull this off? Well, as far as I can tell:

All you have to do to succeed in software is to consistently suck less with every release.

Keep Reading

“Consistency” Does Not Mean “Uniformity”

by Max Kanat-Alexander
Published on May 14, 2009

In a user interface, similar things should look the same. But different things should look different.

Why do over 75% of Facebook’s users think that the new Facebook UI is bad? Because it makes different things look similar to each other. Nobody can tell if they’re updating their status or writing on somebody else’s wall, because even though the text is slightly different in the box depending on what you’re doing, the box itself looks the same. The new Chat UI (introduced a few days ago) makes idle users look basically identical to active users, except for a tiny icon difference. (It’s also important that different things are different enough, not just a little different, because people often won’t notice little differences.)

This is an easy pitfall for developers to fall into because developers love consistency. Everything should be based on a single framework, in the backend of an application. But that doesn’t mean that everything has to be displayed the same in the UI.

This fact–that different things should look different–is actually true with code, too, but people rarely think about it, because developers are actually pretty good about it. For example, accessing a value of an object should look different than calling a method on it, and in most programs, it does. For example, in Bugzilla’s code, accessing a value on an object looks like $object->value whereas calling a method on the object looks like $object->method(). It’s not all that different, but the () at the end is enough difference for the average programmer to notice “Oh, that’s a method call that does something–it’s not just accessing a value in the object.”

All in all, consistency is really important in both the backend and the frontend of an application. But that doesn’t mean that every single thing should look exactly the same–if we took that to extremes, we’d just have a solid white page, and that doesn’t seem all that usable (frontend) or readable (backend), does it?

Previous 1 2 3 4 5 6 … 9 Next
  • Home
  • Contact
  • About
  • Book: Understanding Software
  • Book: Code Simplicity

Max Kanat-Alexander Follow

mkanat
Retweet on Twitter Max Kanat-Alexander Retweeted
January 10, 2023

@__mharrison__ I did.

I would've read Kanat-Alexander's "Code Simplicity" sooner.

I truly think it may be the most crucial code learning resource there is.

I'm thankful for all other books. They give information/knowledge about usage of tools. Code Simplicity, however, teaches wisdom.

Reply on Twitter 1612846495056945152 Retweet on Twitter 1612846495056945152 1 Like on Twitter 1612846495056945152 21 Twitter 1612846495056945152
Retweet on Twitter Max Kanat-Alexander Retweeted
December 9, 2022

@mkanat just ended reading "Code Simplicity", great ready: simple and easy to understand, just as code is meant to be! 👌🏼

Reply on Twitter 1601103831101685761 Retweet on Twitter 1601103831101685761 1 Like on Twitter 1601103831101685761 1 Twitter 1601103831101685761
December 7, 2022

Sometimes you have to choose whether to be “nice,” or actually say “no” to doing the wrong thing. Keep in mind, it is not actually kind to deliver bad products to all your users, just so you can be “nice” to one person.

Reply on Twitter 1600448041848229888 Retweet on Twitter 1600448041848229888 Like on Twitter 1600448041848229888 4 Twitter 1600448041848229888
November 15, 2022

It's always important to understand your users and the problems they actually have.

In developer tools, it's easy to assume you already know the problems, because you're a developer. But often, it's surprising to discover what developers' actual pain points and requirements are.

Reply on Twitter 1592626294474559488 Retweet on Twitter 1592626294474559488 Like on Twitter 1592626294474559488 11 Twitter 1592626294474559488
Retweet on Twitter Max Kanat-Alexander Retweeted
November 15, 2022

How does LinkedIn approach developer productivity?

In this week's issue, @mkanat shared his learnings from spending ~20 years in this field, and how LinkedIn approaches this area.

Subscribers can read the full issue here: https://newsletter.pragmaticengineer.com/p/linkedin-engineering-efficiency

Reply on Twitter 1592567547718553600 Retweet on Twitter 1592567547718553600 11 Like on Twitter 1592567547718553600 107 Twitter 1592567547718553600
  • Home
  • Contact
  • About
  • Book: Understanding Software
  • Book: Code Simplicity