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. I have been intimately involved in designing key aspects of the developer experience at Google and LinkedIn, have been very involved with the research community in this space, and I’m constantly in touch with developer experience leaders at every major tech company. I’d like to spell out for you the ...| Code Simplicity
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. I have been intimately involved in designing key aspects of the developer experience at Google and LinkedIn, have been very involved with the research community in this space, and I’m constantly in touch with developer experience leaders at every major tech company. I’d like to spell out for you the ...| Code Simplicity
Sometimes, I have to explain software development to people who are not software developers. Over the years, I have come up with an analogy that explains what software development is like and its processes. I have successfully used it to explain software development to a 9-year-old kid, including advanced concepts like cybersecurity and so forth. I figure others might benefit from it, so here it is: Imagine that you live in a world without computers. You are the owner of a custom car factory,...| Code Simplicity
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 l...| Code Simplicity
I have now worked in developer productivity organizations at a company with a very advanced mono-repo (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 mono-repo have nothing to do with how many source control repositories you have. In fact, what people (and Google) consider a mono-repo is actually multiple different concepts.... The post What is a Monorepo, Really? appeared first on C...| Code Simplicity
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 ...| Code Simplicity
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 developme...| Code Simplicity
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 wha...| 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 accom...| Code Simplicity
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’...| Code Simplicity
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 cur...| Code Simplicity
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...| Code Simplicity
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 t...| Code Simplicity
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. When you clean up code, you are always doing it in the service of the product. Refactoring is essentially an organizational process (not the definition of “organizational” meaning “having to do with a business” but the definition meaning “having to do with putting things in order”). That is, you’re putting in order so that you ...| Code Simplicity
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. This comes about because the problem that you see that a development team has is not necessarily the problem that they know exists. For example, you could come into the team and see that they have hopelessly complex code and so they can’t write good tests o...| Code Simplicity
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 d...| Code Simplicity
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.” It’s how I implement the “be only as generic as you need to be” rule from the Three Flaws of Software Design. Essentially, I know exactly how generic my code needs to be by noticing that I’m tempted to cut and paste some code, and then instead of cutting and pasting it, designing a generic solution that meets just those two specific needs. I do this...| Code Simplicity
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...| Code Simplicity
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. Each participant in the conversation had different personal preferences for how they write code, which makes sense. However, from each participant’s personal preference you could extract an identical principle: “I need to observe something before I can make a decision.” Kent oft...| Code Simplicity
In general, when technology attempts to solve problems of matter, energy, space, or time, it is successful. When it attempts to solve human problems of the mind, communication, ability, etc. it fails or backfires dangerously. For example, the Internet handled a great problem of space—it allowed us to communicate with anybody in the world, instantly. However, it did not make us better communicators. In fact, it took many poor communicators and gave them a massive platform on which they could...| Code Simplicity
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 simplicity. Well, it’s certainly true that putting time pressure on developers tends to lead to them writing complex code. However, deadlines don’t have to lead to complexity. Instead of saying “This deadline prevents me from writing simpl...| Code Simplicity
When solving a problem in a codebase, you’re not done when the symptoms stop. You’re done when the problem has disappeared and will never come back. It’s very easy to stop solving a problem when it no longer has any visible symptoms. You’ve fixed the bug, nobody is complaining, and there seem to be other pressing issues. So why continue to do work on it? It’s fine for now, right? No. Remember that what we care about the most in software is the future. The way that software companies...| Code Simplicity
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.” There are many things one could desire to know about a software system. It seems that most often we want to know if it actually behaves like we intended it to behave. That is, we wrote some code with a particular intention in mind, does it actually do that when w...| Code Simplicity
In the world of software, it is the job of software developers to solve the problems of users. Users present a problem, and the developers solve it. Whenever these roles are reversed, trouble ensues. If you ever want to see a bloated, useless, complex piece of software, find one where the developers implemented every solution that any user ever suggested. It’s true that the users are the people who know what the problem is, and that sometimes, they have novel ideals for solutions. But the p...| Code Simplicity
One thing we know about software design is that the future is important. However, we also know that the future is very hard to predict. I think that I have come up with a way to explain exactly how hard it is to predict the future of software. The most basic version of this theory is: The accuracy of future predictions decreases relative to the complexity of the system and the distance into the future you are trying to predict. As your system becomes more and more complex, you can predict sma...| Code Simplicity
In June, I released a second revision of Code Simplicity. Some of you probably already know, but I thought that I should let everybody else know, too. The most important change is that book gets into the laws and rules of software design much more quickly now. It starts with a completely re-written Preface that tells the story of how I developed the principles in Code Simplicity, and why you might be interested in them. Then it gets into a much shorter Chapter 1 that distills everything from ...| 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. Also, some of these philosophies haven’t been fully formed until I sat with the work for a long time, applied it in a lot of situations, and talked about it with many people. This one–a theory that I have developed over time about how software can be thought of and worke...| Code Simplicity
What if every software developer could gain the knowledge of long experience without having to go through the pain of repeated failure? What if, instead of being a continuous chaos of complexity and argument, the process of software development could be a sane, orderly progression that was well-understood by every single programmer involved? What if all programmers and their managers shared a common ground for discussing software development decisions–a common ground that was based on facts...| Code Simplicity
Here are some clues that tell you that your code may be too complex: You have to add “hacks” to make things keep working. Other developers keep asking you how some part of the code works. Other developers keep mis-using your code, and causing bugs. Reading a line of code takes longer than an instant for an experienced developer. You feel scared to modify this part of the code. Management seriously considers hiring more than one developer to work on a single class or file. It’s hard to f...| Code Simplicity
Your program is not important to me. I don’t care about its user interface. I don’t care what its name is. I don’t care that you made it, or what version it is. The only thing I care about is that your program helps me accomplish my purpose. That’s a truly remarkable feat, and if your program does it, you should be proud. There’s no need to make your program take up more of my attention just because you think it’s important. Now of course, your program important to you! When you w...| Code Simplicity
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 get people interested, then have them actually contribute, and then have them stick around, you have a community. Otherwise, you don’t. If you are just starting a project or need to improve the community of an existing project, you should ...| Code Simplicity
Many people think that the readability of code has to do with the letters and symbols used. They believe it is the adding, removing, or changing of those symbols that makes code more readable. In some sense, they’re right. However, the underlying principle is: Readability of code depends primarily on how space is occupied by letters and symbols. What does that mean? Well, it means two things: Code should have the proper amount of white space around it. Not too much, not too little. There sh...| Code Simplicity
How many times have you used a piece of software that was full of incredibly convoluted features, strange decisions, and unusable interfaces? Have you ever wanted to physically or verbally abuse a computer because it just wouldn’t do things right, or you couldn’t figure out how to make it function properly? And how often have you thought, “How could any programmer think this was a sane idea?” Well if you’ve ever experienced any of those things, your next thought might have been some...| Code Simplicity
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...| Code Simplicity
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. 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 principl...| Code Simplicity
So today I was playing around with a little equation that may in fact explain nearly all of the principles of software design. I don’t know that it’s actually mathematically solvable in terms of numbers, but it does demonstrate the factors present in software development decisions and how they relate to each other. Before I go into the equation, though, I have to define the factors that are present when a designer is deciding whether or not to implement something, or how to implement it: ...| Code Simplicity
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 ...| Code Simplicity
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...| Code Simplicity
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 pro...| Code Simplicity
The attitude that every engineer should have, in every field of engineering, is: I can solve this problem the right way. Whatever the problem is, there’s always a right way to solve it. The right way can be known, and it can be implemented. The only valid reason ever to not implement something the right way is lack of resources. However, you should always consider that the right way does exist, you are able to solve the problem the right way, and that given enough resources, you would solve...| Code Simplicity
So, after my last post, a few people asked, “Okay, but how do you figure out what sucks?” Well, some of it’s really obvious. You press a button and the program takes 10 minutes to respond. That sucks pretty bad. You get 100 complaints a week about the UI of a particular page–okay, so that sucks. Usually there are one or two HUGE things that really suck, and they’re really obvious–those are the things to focus on first, even if they require a tremendous amount of work. For example,...| Code Simplicity
