Lessons learnt from Clean Coder

Previously I talked about Clean Code, I want to focus this entry on how Clean Coder:A Code of Conduct for Professional Programmers (Robert C. Martin) made me evolve professionally. This book focuses on the professional aspect of a developer: the interactions with the rest of the team, the responsibilities of the roles, etc. I don’t know how to keep things short so let’s start with it!

How to manage estimations and its importance. Now you always have to work as a team, and in order to manage projects you need some time of estimation, and its the responsibility of the programmer to be as accurate as possible (and to research and train the technique).

How to interact with other roles in the Software Industry. Skills like managing expectations with the stakeholders, getting the best out of your QA, understanding the differences between a development manager and a developer manager, etc. A professional programmer is not only a good coder but an amazing team player. So take so time to learn everyone’s role!

The professional also carries the responsibility of saying no when the situation requires so. Everyone can say yes to anything and then deliver a shitty result, but you have to raise your hand when a situation will undermine your craftsmanship and end with a compromise in the Quality. Things like repeatedly doing overtime will end with some buggy and unmaintainable code, so saying no when there is no plan be, or the plan is to stay in that situation for longer than it should, it’s your responsibility.

Managing your time and schedule is also a really important skill everyone should learn. Uncle Bob talks about Pomodoro and other techniques, and it was the first time I realised about these amazing approaches. This has been a subject I’ve been working on for so long that you can see some of my latest results here.

He also made a controversial statement which I share. The Zone, even if you feel productive while staying on it, should be avoided and only used when the situation requires to. Entering that mind state will make you drop some of the best practices and induce you to decisions really hard to tackle and fix. That’s why he recommends not to listen to music while programming (making it harder to enter The Zone), and activities like pair programming or taking breaks from time to time (Pomodoro).

As said during the Clean Code summary, he considers Unit test as one of the main sources for code quality. If something doesn’t show how it works in a test, then you can trust its code.

A good professional is responsible for his art, so you have to allocate some time to train and improve your craft. Part of that time should be given by the employer, but you have to invest some of yours to stay always on top of your game.

He also recommends techniques like code katas to interiorize new languages, frameworks and tools; as they allow the practitioner to focus on the changes (as the problem is already known and mastered). He encourages as well to warm up with a coding kata before starting the working day, helping with all the bugs and failures that get introduced while you’re still getting into the programming mindset.

Personally, I found this book even more interesting than his Clean Code brother. This was the first time I start thinking about the surroundings of my career and how to become a better professional dealing with them, instead of just focusing on improving the code itself. A highly recommended read!