How to Significantly Improve Your Engineering Team Productivity & Happiness
The important lessons that we can learn from “Clean Code”, A book by Robert C. Martin
We are — software engineers, known to be a group of nerds and introverts, but you need to know that in almost every software engineering activity is a social activity, we communicate ideas with people around the world who may not have any common language with but code that easy to read — Clean Code.
Now, the questions are which kind of code can be communicated well? Which kind of code doesn’t make us as reviewers always curse that code? Which kind of code if we abandoned it for just 2 months, it still can be the code that we can understand?
Yes, All of those questions can be answered if we implement “Clean Code” in our codebase. I think Implementing “clean code” practices appropriately will double productivity in the long run (at a bare minimum) and significantly improve the morale (both productivity and happiness)of the engineering team.
Just like the book that Robert C. Martin created….
I highly recommend this book to every member of the engineering team. This book is really mind-blowing. I have summarized some points about how this book can really help you improve your engineering team productivity and also increase happiness.
Lets we start with:
Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
You will meet this quote at the beginning of the book. Yes, you are. Looks like Robert C. Martin reminds us about our professionalism.
IMO, at least there are three things that I can summarize from this book to improve your engineering teams productivity
“If it isn’t tested, it’s broken”
Yes, you are right! you meet this quote on memes. But this is absolutely true. You need to write lots of tests, especially unit tests, if you don’t, you will regret it. It will ruin the production system, and also can be a high cost in the future.
“If it isn’t tested, it’s broken”. Regularly, you need to repeat this sentence to your engineers. You will prove the quote true again and again unless you build a culture of testing. Write a lot of tests, especially unit tests. Think very hard about integration tests and make sure you have a sufficient number in place to cover your core business functionality. Remember, if there’s no test coverage for a piece of code you’ll likely break it in the future without realizing it until your customers find the bug. Such a nightmare I think.
Repeat “if it isn’t tested, it’s broken” to your engineering team over and over again until it becomes an unconscious message in your engineer's mind. Practice what you teach, whether you are still newly being a software engineer that just graduated from school.
Choose Meaningful Names
Always use short and precise names for variables, classes, and functions.
There are two hard problems in Computer Science: cache invalidation and naming things.
Maybe some of us are familiar with this quote. It presents day-to-day life on an engineering team. This is so true. If you and your team aren’t good at naming things in your code, it will become an unmaintainable nightmare and you won’t get anything done. You’ll lose your best developers and your company will soon go out of business.
Seriously, guys. We can’t communicate well with other engineers if we use bad variable names like x, y, or res and they most certainly don’t let them name classes things like SomethingFoobar. Make sure your names are short and precise, but when in conflict favor precision. Strongly optimize developer efficiency and make it easy to find files via “find by name” IDE shortcuts. Enforce good naming stringently with code reviews.
Classes and functions should be small
What does “small” mean for functions and classes? No more than 4 lines of code for functions, and no more than 100 lines of code for classes. Yes, you read that correctly, 4 lines and 100 lines. It seems somewhat arbitrary and small and you’ve probably never written code like that in your life. However, 4-line codes in a function force you to think hard and pick a lot of really good names for sub-functions that make your code self-documenting.
Additionally, they mean you can’t use nested IF statements that force you to do mental gymnastics to understand all the code paths. With small classes and functions, you can make every engineer happy to read your code, there is no time to scroll up and down again and again just to see the small changes.
In the end, let me wrap it all, make yourself sure to remember and apply these three “clean code” principles to dramatically improve your team’s productivity:
- “If it isn’t tested, it’s broken”
Write lots of tests, especially unit tests, or you’ll regret it. - Choose meaningful names
Use short and precise names for variables, classes, and functions. - Classes and functions should be small
Functions should be no more than 4 lines and classes no more than 100 lines. They should also do one and only one thing inside it.
Yes, I hope your team is like in the left door, not the right ones. Reviewing codes is an exhausting job, let we help our team members to understand what we write.
Actually, I’m still reading the book right now, in order to remember what I have read, I write it on my Medium. I will update it if there is something new that I get from the “Clean Code” Book by Robert C. Martin. I hope it can help you guys improve your engineering team performance.
Reference:
