Review: The Clean Coder

TL;DR - If you care about software development at all, read this book now!
This book is a condensation and distillation of more than 40 years of industry experience. It is an amazing read. The book expresses the concept of professionalism in the clear, simple (not simplistic,) unapologetic style that Bob uses in all his writing. At a short 204 pages, you can read it in a weekend (like I did.)

Having been involved in Agile (XP, XPish, ScrumBut) projects for several years and recently in the software craftsmanship movement, many of the concepts in the book were familiar.

The chapters on Saying Yes, Saying No and Estimation really spoke to me. I have had many experiences where I have agreed to "try." Now I see the danger of that statement clearly. I have also had experiences where I have stayed firm on my estimates and been encouraged to feel as though I was not a committed team player. I now have additional tools to help me combat that feeling and take professional actions despite pressure (from management or the team) to do otherwise.

For me, the most powerful section of the whole book is the commitments section of the Chapter 10 - Estimates. "Professionals don't make commitments unless they know they can achieve them. It's really as simple as that." Wow. I have reread that section several times.

Comments

Post a Comment

Popular posts from this blog

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc
Read more

Episode 019 - Sustaining Communities

There are many benefits to having communities of practice, so long as the community continues to exist. In this episode, special guests Jon Turner and Neil Sorensen discuss what they've learned over their many years attending and facilitating the Utah Software Craftsmanship group ( http://utahsc.org/ ). Listen here:  https://crafting-code-podcast.github.io/episodes/019-sustaining-communities.html
Read more