Building quality software isn’t as easy as hiring great engineers and getting out of their way.
An engineering manager also needs to on-board software developers to these principles, keep the team together, and deal with leadership and clients when they want their software yesterday.
Uncle Bob has the advantage of having been on every side of this many times, and making every mistake possible along the way. Fanni Karolina Tóth interviews him on the Level-up Engineering podcast about how an engineering manager can stay true to the clean code principles, and lead a team that builds quality software.
This blog post covers:
I got a simple way to put it from Michael Feathers: “Clean code looks like it was written by someone who cares.” There's a bunch of low-level technical details, but the goal of clean code is to encourage programmers to care, and to have pride in their workmanship.
The underlying theme is that if you want to go fast, meet schedules, and keep your customers and your managers happy, keep your code as clean as possible. Nothing will make you work faster than keeping your workspace clean.
You can measure the size of methods or functions. A large part of the Clean Code book is focused around this idea. It’s simple: take your functions and make them as small as possible.
Once you go above five or six lines of code, they start to get too large. Many programmers find the idea of tiny functions disturbing. It’s new to them, and they worry that it will overwhelm them.
But it won’t overwhelm you, because you need to name them, and it’s an eye-opening experience. You have to come up with names for tiny concepts. They tend to get long names, because the concepts are so precise, so they require several words to describe.
So the functions take on names that are almost sentences. When you mix them with “if” statements and “while” statements, you start to form full sentences. Then your code starts to read almost like a natural language.
So, keep your functions as small as possible, and name them well.
The primary consequence is slow down. Everything goes slower if the code is dirty, and everyone knows this.
Bad code is usually written to go fast. This is the fundamental contradiction that drives most programmers.
They do the thing that slows them down in order to go fast. Then they make an excuse about it, “It'll slow me down in the long term, but it speeds me up in the short-term.”
This is incorrect. Every software engineer has written bad code in the morning, gone to lunch, and come back wondering what idiot was hammering on the keyboard in the morning.
Here’s an analogue: if you do a bad job of washing the dishes, it feels fast. It'll take you longer to wash the dishes, because you're not thinking and putting the effort in. You're just watching TV while doing the dishes.
This is the same problem when you want to lose weight.
If you control the amount and the contents of your food with discipline and organization, you will lose weight. It'll feel like a lot of work, but you'll get there. If you aren't disciplined, you'll never lose weight.
Measure quality indicators, for example, bug discovery rates. If bug discovery rates are high, something's wrong on the development side.
Take a look at the source code control system. How many modules are being thrashed? How many of those modules are getting attacked by more than one person? These are indicators that something is going wrong.
There are different metrics you can use. They’re indirect, but they're useful.
The best metric is to look at the morale and attitude of the programmers.
Make sure your team knows you trust them. When programmers give you an estimate, a promise or a lack of a promise, you need to understand that, and make your decisions according to that. If you trust your programmers, you'll have a better time and so will they.
You need to understand your manager deals with real issues, and you have to be on their side to solve their problems. You shouldn’t give in to arbitrary schedules, and promise the impossible. Instead, you need to communicate to your manager that you understand the issues, and you're doing your best to solve them.
One of the most important things a developer can say to a manager is the word no. You must be able to look your manager in the eye with all the empathy and sympathy you can muster, and say, “The answer is no.” You will save a lot of money if you say no at the right time.
Never promise to do something you know you can't do. They will believe you, bet a lot on your ability to do it, and you will let them down.
As an engineering manager, make it clear you expect high quality. Say, “We expect programmers to do the best job they can. If you do that, you will progress as fast as possible.”
And the programmers should say, “We understand, and we’ll do the best job we can, because we know that’s the only way to meet our deadlines.”
If I'm a manager, I make it a condition of their employment.
But let's look at this from another angle.
You are the captain of a ship in wartime. The survival of the crew depends on every member of the crew being as disciplined and well-practiced as possible. The ship will not survive if even one team member lets down the ship.
This is the message.
It’s the same with the COVID-19 situation. We're all supposed to be sheltering in place, and one person can wreck it. We're being told it's a team effort, and everybody needs to be on board.
For most people, this works; for some, it doesn't. The great thing about running your developer team is that if you have a member who doesn’t listen, you can have them go somewhere else.
In my experience, you can’t convince people. What you can do is demonstrate. Some people see the demonstration and decide, “I need to do this,” while others won’t.
If you spend a few years being undisciplined, you realize there has to be something better than that. If you try being disciplined for a year, you'll find it works out better.
You often wind up in a team where some want to write clean code, while others don't care. In that situation, there will be a divorce because the two sides cannot co-exist. Either the team will break into two, or one side starts leaving the other one by one.
A good engineering manager can see this division in the team. Then maybe you can divide the team and give one half tasks where they’re not going to do harm, and keep the other part of the team focused on the project.
Growth is a problem in the software industry, because there are too few people with experience to mentor the new engineers. The number of people in our industry doubles every five years. This means half the programmers in the world have less than five years of experience.
One of the engineering managers’ top priorities is sharing knowledge. The best way to do that is pair programming between experienced and junior software engineers. This means sitting at the same terminal, the same keyboard, and writing code together.
If you have 5 experienced engineers and 20 junior engineers, get those juniors sitting next to an experienced person for one hour each day. The seniors can take on their own tasks, but also have them help the junior engineers with their tasks. Doing this makes the new engineers understand why and how decisions are made on a daily basis.
Alternatively, you could learn by making the mistakes, but it's costly. If a senior is sitting next to you, you don't have to make the mistakes.
I just recently learned how to fly an airplane, and I had an experienced pilot next to me all the time. This way I didn’t have to make the mistakes, which have serious consequences in an airplane. That person made sure that I learned safely and quickly.
It’s the same when writing code.
The mistakes young programmers make can cost the company tons of money. A senior engineer sitting next to them for some time each day can stop that. It rapidly gets the junior programmers aware of the deficit in experience and hungry for more knowledge.
First of all, you don’t sacrifice anything by writing clean code.
If you're a technical leader, you don’t tell your bosses anything about your developer team writing good code with tests and taking time to refactor. Asking your manager if it's okay to do this is like asking your manager if it's okay to wash your hands after using the bathroom.
It's not their business.
Never offer the choice to a leader or a client between building software right or doing it badly in less time. It's the wrong choice, because you won't get it done sooner. The fastest way means the best way.
If I’m in the active development and have some code that needs refactoring, I just refactor it. A big mess doesn’t happen because a few people didn't refactor; it happens when everybody drops the ball. Dealing with that is different.
If you make a big mess, the only right way is to communicate it straightforwardly.
If the customer comes to you saying, “It takes you too long to do anything. How can we go faster?” then look the customer in the eye and say, “We screwed up, and it's going to take time to fix it. We won’t start a project to clean up the code. That would fail, we have no way to estimate it. Instead, from now on, every time we touch the code, we're going to spend some time cleaning it, and it’ll get gradually better.”
You adopt a new rule to check every module so it’s a bit cleaner than when you checked it out. The client may or may not notice the time you spend on it. But over a year or two, the code is going to get better, your estimates will shrink, and you’ll be faster.
It takes time; the mess didn’t happen instantly either, but you can clean it up.
The hard way. I've made every possible mistake, and it took decades.
It took me a long time to understand what mattered, what the principles were, and how to organize and articulate them. I knew 20 years ago that I wanted to write a book about it, but I didn't have the courage.
Finally, I just looked at myself in the mirror and said, you need to write this book. You may not be the best person to write it, but it has to be written. The Clean Code was released 12 years ago.
When I wrote it, I focused on the technical stuff, and ignored all the personal stuff. But I knew I had to talk about the personal side as well, so I wrote another book called The Clean Coder. That book is about my failures and my experiences as a programmer through the decades.
I explain things like how I was fired before, and how you write code when you’ve just had a fight with your significant other.
The software industry lacks the focus for professionalism. There's no universal standard or software engineering ethics. There's no set of disciplines that we all adhere to.
Doctors have a set of disciplines that they profess. They have an oath, a set of ethics. Software development needs that, and maybe now we’re beginning to accumulate those disciplines and ethics.
It’s necessary, because our society depends on software for its existence. This wasn’t true 30 years ago, but it’s true today. Just look around, and count the number of processors around you running code written by 22-year-olds at 3 AM.
Then count the activities of daily life that involve software. You cannot drive a car, microwave popcorn, make a phone call, watch TV, wash the dishes, buy or sell anything. You can barely sleep.
There's nothing in daily life that isn’t controlled by software. Software engineers are sitting in the middle of everything happening in society. We're in the position where we can kill people, and we’ve done it too.
We're going to have to deal with this soon.
The programmers who manipulated software to hit pollution standards on the testing rig for Volkswagen in California went to jail. I agree with that; they built software that cheated.
Your boss can tell you to do something, but you can always say no. Those developers should have said, “No, I'm not going to write code that lies and puts people at risk.”
At some point, we need to organize like the doctors did in the 1800s. They looked around and saw people claiming to be doctors who lacked the knowledge, the discipline and the experience. They organized, and created a licensing organization for becoming a doctor.
Something similar needs to happen in software development in the next two decades.
I'm in the middle of writing another book, called Clean Craftsmanship.
It’ll be a discussion of the disciplines of writing good code, but not the ethics. It'll be about the technical activities that help us write clean code. I'll be talking about test-driven development, refactoring, continuous integration and so on.
The book after that will be the book about the ethics of software development. I’ll call it something along the line of Clean Programming Oath. It’s another year or two in the future.
Of course, I'm always working on videos. We've put out around 60 videos over the last 10 years now, and I'm always working on articles, papers and talks.
He’s been a programmer for over 50 years starting in the ‘60s as a teenager, and has stayed with the industry since. He has worked on telecommunications projects, computational geometry and graphical user interfaces among many other things on many different platforms.
He became a consultant in 1992, and has been self-employed ever since. He’s run different software companies over the years, he’s written tons of books and articles, and he’s loved every minute of it.
Uncle Bob returned in episode 59 of the Level-up Engineering podcast to discuss software engineering ethics.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.