Code Simplicity

One question that people ask me all the time is, “How do I become a programmer?” Or, “How do I learn to program?” There are a lot of possible answers to this, depending on the person and how you want to go about it. I figured that since people ask me this so often, I had better finally write an article about it.

Find the Best Way

One rule that has served me well when I’ve been learning to program, no matter the method I was using, was to always ask, “What’s the best way to accomplish this?” or “What’s the right way to accomplish this?” That is, in programming there are many different routes you can take to accomplish your task. But usually, only one of those is the recommended way, either in terms of the most modern way to do it in your programming language, or the best practices that the community of programmers have agreed on based on experience. Usually, you can find out this information by reading the documentation of the programming language you’re learning, or searching online for a best practice via Google or Stack Overflow. If you can’t find the answers, ask the question on a forum, mailing list, or Stack Overflow. I still do all of this, to this day, when I’m given a task where I have to learn something that I don’t know about.

The advantage here is that you don’t just learn to program, but you learn to be a good programmer. Also, it forces you to really dive deep and understand the tools and languages that you’re using. If you do this continuously as you go, you eventually develop a good, deep understanding of the systems you’re working with, while maintaining enough practicality to keep yourself interested. (That is, you are only diving this deep on the things you’re actually doing something with—not random theoretical stuff that you’re never going to use. That can be interesting too, but it’s not an educational system that you can use forever to really learn to program.)

Of course, you have to make sure that you really understand everything you are reading when you do this. That might mean diving down into more documentation, and then even more documentation, until you understand all the words and symbols being used. That’s okay! That’s a big part of what makes this system work—that you gain a true, deep understanding of the symbols and concepts you’re working with.

Now look, to be clear, when you’re first learning to program and you’re given a challenging task, it’s okay to just try to get it done any old way you can. You’re learning the basics, not the best practices. This piece of advice is for once you get over the hump of learning the basics of how to get anything done at all. For a project that you’re doing purely to learn something, the most important part is that you learn the thing you’re setting out to learn. But once you’ve got that in hand, delve deeper into it and try to see if you’ve done things the best possible way.

Okay, now that said, let’s talk about the different methods that people actually go through to learn to program. Continue reading →

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: Continue reading →

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: Continue reading →

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. How do we tell where there are productivity problems? How do we know if a team is doing worse or better over time? How does a manager explain to senior managers how productive the developers are? And so on and so on.

In general, I tended to focus on focus on code simplicity first, and put a lower priority on measuring every single thing that developers do. Almost all software problems can be traced back to some failure to apply software engineering principles and practices. So even without measurements, if you simply get good software engineering practices applied across a company, most productivity problems and development issues disappear.

Now, that said, there is tremendous value in measuring things. It helps you pinpoint areas of difficulty, allows you to reward those whose productivity improves, justifies spending more time on developer productivity work where that is necessary, and has many other advantages.

But programming is not like other professions. You can’t measure it like you would measure some manufacturing process, where you could just count the number of correctly-made items rolling off the assembly line.

So how would you measure the production of a programmer? Continue reading →

Here’s an obvious statement that has some subtle consequences:

Only an individual programmer can resolve code complexity.

That is, resolving code complexity requires the attention of an individual person on that code. They can certainly use appropriate tools to make the task easier, but ultimately it’s the application of human intelligence, attention, and work that simplifies code.

So what? Why does this matter? Well, to be clearer:

Resolving code complexity usually requires detailed work at the level of the individual contributor.

If a manager just says “simplify the code!” and leaves it at that, usually nothing happens, because (a) they’re not being specific enough, (b) they don’t necessarily have the knowledge required about each individual piece of code in order to be that specific, and (c) part of understanding the problem is actually going through the process of solving it, and the manager isn’t the person writing the solution.

The higher a manager’s level in the company, the more true this is. When a CTO, Vice President, or Engineering Director gives an instruction like “improve code quality” but doesn’t get much more specific than that, what tends to happen is that a lot of motion occurs in the company but the codebase doesn’t significantly improve.

It’s very tempting, if you’re a software engineering manager, to propose broad, sweeping solutions to problems that affect large areas. The problem with that approach to code complexity is that the problem is usually composed of many different small projects that require detailed work from individual programmers. So, if you try to handle everything with the same broad solution, that solution won’t fit most of the situations that need to be handled. Your attempt at a broad solution will actually backfire, with software engineers feeling like they did a lot of work but didn’t actually produce a maintainable, simple codebase. (This is a common pattern in software management, and it contributes to the mistaken belief that code complexity is inevitable and nothing can be done about it.)

So what can you do as a manager, if you have a complex codebase and want to resolve it? Continue reading →