Clean coder — the personal side of being a developer

There are two types of developers in this world:

The first ones have been coding for a while and are being comfortable with their own achievements. They finish their work on time, find the best solutions under pressure, always have a great idea that works perfect and love their job like no one other. Oh, and their people skills are out of this world. They're practically amazing.

The second type is….oh wait, let’s go back to the first type. Right, they don't exist…

Because being a software developer means constantly learning and making mistakes, being under pressure for most of the time, sometimes being awkward while socializing and thinking how you know everything and nothing at all in the same day.

But don’t worry, this doesn’t mean you can not be a professional

As a matter of fact, I happen to know a lot of software developers that are exactly as the first type described earlier. This doesn’t mean they don’t struggle, fail or don’t have their own doubts. They do, but they have learned how to react to stressful situations, how to constantly grow, both technically and emotionally and most importantly, how to behave professionally.

All this growth asked for years of continuous learning and experiencing, but if you are here because you wish for the same, I have some good news for you. You can start with this:

The Clean Coder: A Code of Conduct for Professional Programmers

by Robert C. Martin

I was at the beginning of my journey when I happened to get this book in my hands. And oh, boy, it opened my eyes in so many ways.

Let’s start with the author. Every developer ever knows him as Uncle Bob. Uncle Bob has been a programmer since forever (somewhere in high school he built his first 18-bit binary calculator and he was born in ’52, you do the math), he knew all the old programming languages we don’t want to hear about and he debugged production code on paper. He’s one of the dinosaurs of our world.

He is also known for being a supporter of the software craftsmanship, one of the creators of agile development and the biggest fan of test-driven software development. And he’s funny as hell.

This book reflects Uncle Bob’s personal thoughts on what it means to be a professional software developer. His long life experience, skills, and achievements should make anyone consider reading this book. At least once.

Now, let me tell you how this book helped my skills and how it can help yours too:

1.Learn how to say NO

Business people will always ask for more requirements and they usually have no idea about the actual implementation and all the impediments. You have to be very precise when you answer a question like: ‘How long will this task take?”, “Is it possible to finish it until…?”. Do not say YES just for the sake of it. Saying a YES like that can easily affect the implementation process, estimations, and can make people go for a run just to be sure they meet the deadlines. Being a professional means being very sure when you provide estimations, and rather say an honest NO than an “I’ll try” which will probably create stressful situations and the developed product can be affected.

2. Understand the problem

Ensure the customer needs are met. Don’t ignore your guts when you feel there is more to the problem than what it seems. Ask, ask and ask again. And after you finish asking make sure you have all the answers.

3. Code clean, please, I am begging you

You are not the only one who reads your code. Although is a pretty logical statement, we tend to forget that once we start coding. Coding is a story, is literature, and needs to be easily understood by other developers.

4. Practice, read, practice!

Your job is, on average, 40 hours per week. But if you really want your profession to be meaningful, you need to practice some extra time. And that extra time is not an hour, two, but even 20 more per week. Take the time to study other languages, technologies, good practices, algorithms, etc. Always be a step ahead.

5. Don’t write code if you can not concentrate

Writing code while being distracted or tired is just a waste of time. And money. And other stuff. Find instead, a way to remove your distractions and settle your mind. If you are tired, don’t spend the night at the office! Go home, have a shower and rest. Try it again when you feel capable and good things will follow.

6. Debugging is coding also. I am serious

Debugging time is as expensive for the business as coding is. If you want to spend less time debugging you need to find proper techniques to do that. Please reduce your debugging time to zero.

7. Is actually 6

You can achieve very good debugging time by following the practice of Test Driven Development (TDD). That means you write the tests first and then the code. No, is not crazy and it’s possible. Just a little bit of practice and it will be your favorite technique ever.

8. Estimates are not hopes

Always measure your progress towards the goal. Estimate the best, nominal and worst case. Be as honest about those three dates as me saying I love pizza, which is very honest. Present the numbers to the team and stakeholders and always keep them updated.

9. Courage

Fix bad code when you see it. I know your first reaction will be “I don’t wanna touch that, it’s ugly”, but we need to fix bad code until it’s not too late. We will be responsible for the code, we may as well deliver good quality. In software development, this is also called “The boy scouts rule".

10. Tests are not important, are THE most important

You may think you save time by not writing tests, but just so you know, you are making yourself or your company actually lose money. And I am talking a looooot of money, some numbers we cannot comprehend. If bugs are being caught in the early stages of a project, it’s less expensive to fix them. Writing good tests is a long term investment and it helps you get all the results that you/ your company needs.

11. Time management is life management. You don’t wanna fail at that

Learn the best strategies on how to plan meetings, your tasks and your time. You can start by following the agile manifesto. Manage your time so you can take advantage of what Uncle Bob calls FOCUS MANA. Writing your code when your focus is high and doing other less productive things when it’s not.

12. There are so much more things you can learn from this book

For Uncle Bob being a software professional means a lot of things and we are very lucky if he managed to sum up all of them in this book. For him it means taking responsibility for your work, collaboration, settling arguments and communicating with your team, means pair programming and taking breaks when needed, means discipline, sleep, and a great will to do your best.

I hope I got you interested in finding all the other gems that this book has to offer, covering multiple situations and exemplifying all the mentioned principles as dialogues between the good/bad developer and the people behind all the corporate professional life. I highly recommend you to read it in full and when you’re ready for implementation, you can jump right into Clean code, one of the books of the series which is going to be the topic of my next article. If you want another intro to that book as well as other cool techy articles, be sure to check us at Blue-harvest.