The Clean Coder

I recently finished reading The Clean Coder as since my company got the book. I read it on a recommendation from one of the tech leads and I found the book suprisingly easy to read. Since I had a physical copy I kept it near my home desk and just read it whenever I was wasting time. Turns out I previously wasted a lot of time. I basically finished the book in a week. Here I’ll write down some key points that I learned from the book. Most of this book is on the meta of being a Software Engineer and more specifically how to be a professional software engineer working at a company.

Chapter 1 - was on professionalism. The key takeaway is that you are a Software Professional and you should put in hours to improve yourself. To keep up to date with changes in the software industry and that no one is responsible for your career besides yourself. It’s up to you to keep up with learnings, to find a mentor etc. It’s great if your employer trains you and sends you to conferences etc. but you shouldn’t expect your employer to be responsible for your professional growth.

Chapter 2 ~ 3 - was mostly about commitments and communcations. My key takeaway that I learned was There is no try. Whenever you tell someone else that you’ll try - it means that you’ll do. I think that’s actually the most important point in this book. Don’t tell your PM / manager that you’ll try to do something unless you’re certain that you can complete it.

Chapter 4 - his thoughts on coding and the flow is interesting. He thinks the flow is bad. I personally think the flow is good. I guess I conflict with his beliefs. I agree with pretty mcuh everything he said with working crazy hours and stuff though.

Chapter 5 - he’s big on TDD. I’m already sold on TDD so this chapter was a bit redundant. He is quite extreme in his beliefs in tdd. A key point was that if you follow tdd or do pair programming on hard problems. Why don’t you always pair program? I do think that pair programming is more efficient and faster in the long run. I often ask people to pair after I’ve spent some time on the problem alone and then pairing usually magically solves the problem. I’m curious on what the author wuold say on implementing tdd in hard to do aspects. How do you write a test that replicates master/slave db replication issues?

Chapter 6 - code katas. I think code katas are weird. I’ve read about them. It just feels weird. /shrug

Chapter 7 ~ 8 - Testing. Hmmm. No real thoughts since most of my experience is working in startups with no QA team. lol.

Chapter 9 - most interesting thing from this chapter for me was… quick and dirty is never quick and dirty. You should avoid quick and dirty like the plague… because it always comes back to bite you in the ass.

Chapter 10 - interesting way of giving estimates. You should give the most likely estimate along with the worse case scenario.

Chapter 11 - on pressure and stuff. I actually already forgot this part. /shrug

Chapter 12 ~ 13 - Teamwork and stuff. Nothing of note for me.

Chapter 14 ~ mentoring, apprenticeship and craftsmanship. This was a really ineresting chapter for me because I do think that Software Engineering is very much a craft. When I graduated from the University of Waterloo I was really sucky. I had all the basics and stuff… but I was still missing so much. It was quite amazing that I worked at a startup with really good mentors. And I got to meet a freak of nature which opened my eyes to the limits of ability. It’s kind of like… the guy who broke the sub 4 minute mile. I met this amazing person who showed me what was possible. Which motivated me. Since then I’ve found amazing people who were better than me to learn from. I also really liked the authors categorization of Master / Journeyman / Apprentice etc. It’s kinda disappointing that I’m still only an advanced Journeyman despite the fact that I’ve been programming for 10 years.

Overall Thoughts - I think that this book was really good. Personally the part on communication / estimation was the area of most learnings for me. There is no try. I already a big believer in tdd. I can see why the tech lead recommended this book and I highly recommend this book as well.

You can get the book here