Blog » Book: The Clean Coder by Robert C. Martin
Book: The Clean Coder by Robert C. Martin
Yes, the "r" is no mistake - this is a book on what it means to be a professional programmer, someone who has a programming job and takes it seriously.
The book teaches you to take pride in what you're doing, to stick to good practices (especially under pressure) because that's the ethical thing to do, to not cave in and "just try to do it faster", but at the same time to take responsibility for what you're committing to. It reminds you that requirements are not set in stone, that the client might not know really well what they want and it's your duty to help them figure that out.
It also gives good advice on several subjects both technical and soft, like estimation, TDD and different kinds of testing, mode of work, and time management. The author shares many war stories from his 40-year-long software engineering experience, talking about how to avoid his mistakes.
Some of it is very opinionated (it's Uncle Bob, what'd you expect) and I didn't agree with everything, but some things rang very true for me and actually were painful to read. I had to look at the areas where I'm not behaving like a responsible professional; overlooking broken windows, not managing my time properly, concentrating on broken requirements instead of the overall goal.
On the other hand, it was nice to see some confirmation about things that I'm just discovering for myself now, like the effectiveness of pair programming or that one person shouldn't juggle several projects.
I highly recommend the book to all professional programmers.
Some of my takeaways:
- you can commit only to something you know that you can deliver (for instance, you cannot commit to fixing a bug if you haven't investigated it yet)
- programming in isolation can (perhaps) make you personally more effective, but it almost always makes the team less effective
- similarly, the state of "flow" is, by the author's account, overrated - it's pleasant, and you work very fast, but you lose the wider view
- I learned about human-readable acceptance tests that are supposed to help business communicate with development - I'd like to see them in action
- "teams are harder to build than projects" - so you shouldn't form a team around a specific project, you should built a well-jelled team that can tackle many projects, even at once
- even if you were invited, you absolutely should excuse yourself from meetings where you waste your time