Programming is an interesting profession. It’s not just an engineering exercise, where you’re building the most logical, structured, and well-designed application according to some set of industry best practices; rather, there’s a great deal of creativity that goes into it – an artistic quality, if you will. Instead of solving a particular problem the same way for every project, you must creatively adapt your thinking and communication to meet the expectations of each project’s stakeholders. Programming is not well understood like other professions. You know what lawyers, accountants, and doctors do. Their workflows and processes are well known since their professions are mature and a good portion of the population has interacted with them directly or indirectly. Programming, on the other hand, is different. To many people, a website or software solution magically just “appears” after a programmer spends time at his or her computer. Enter Robert C. Martin’s The Clean Coder.
The Clean Coder helps demonstrate how programmers can conduct themselves as professionals, removing that black-box quality and holding themselves to standards as other professionals do so they garner the same respect from their peers and can help others do more with technology.
I’ll talk about some of the lessons that really resonate with me:
In the forward, Matthew Heusser relays a story about how his colleague, Joe, considers “estimates” from the technical team and “estimates” from the legal team with completely different mindsets. In short, Joe considered legal estimates to be final, whereas technical estimates were negotiable. Why weren’t estimates from the two teams treated equally? In my career, I’ve seen the same thing many times, largely stemming from three reasons. First is the assumed “magic” that non-technical people think programmers wield. Throughout the book, Martin explains how to remove the veil of mystery regarding said magic. Second is that I’ve run across others that compared us with their profession and made some assumptions, such as, though a harsher example, we’re being lazy or noncommittal. Here, the author discusses how to address such assumptions when confronted with them. Third, and the most important part that we can influence, is the tech person’s mindset and approach to work. From the text, the programmer learns how to craft their own mindset and workflows to handle these. In essence, we can’t make things perfect, but we control a lot of parameters to make things better.
The first three chapters cover the conduct that a software developer professional should exhibit. A recurring theme within all three chapters is that software developers should take responsibility for what they say and do. Martin gracefully simplified this down to: how/why to say “no” and how/why to say “yes.” For example, if a developer agrees to a timeline, then they should make the timeline. If there are risks or unknowns on something you’re defining a timeline for, don’t agree to it, but rather just agree to what you can commit to if possible. The key is to not let yourself get bullied into agreeing to something you know you can’t meet with confidence. Others will build their own schedules and commitments around what you say, and there may be serious repercussions and loss of face if you fail to deliver. If you’re not as accurate as possible, you’ll erode the trust you have with your colleagues.
Along with controlling and defining your commitments, you need to take responsibility for your work output. Specifically, being a professional means that you certify and guarantee that your work output functions. For example, accountants ensure that their accounts balance when they finish closing out the books monthly, quarterly, and year’s end. If they left discrepancies, they would soon find themselves out of work. However, developers seem to be able to deliver questionable code or features that just plain don’t work, again and again. I understand why: development is hard. There are a lot of moving pieces and people in a software development project; as a result, there are a lot of rules that get balanced when you go in and change something. None of that takes away from the fact that developers lose trust of their peers when they fail to deliver working solutions for the tasks assigned to them. They’ll probably remember the failure (their label, not yours) instead of the nuanced “whys” that caused that failure.
Luckily, software developers have tools available to them to prevent this from happening, but only if the tools are actually put to use. Martin’s philosophy around testing is something with which I completely agree. The only way you can truly know that what you’ve added or changed doesn’t break everything else on a project – regardless of size – is to test it and have a structured, scalable approach to testing. Manual testing takes time, sometimes A LOT of time, and you leave a lot to chance that way. Hence automation. When automated, a test can be written once and then just be executed. It makes it trivial to repeatedly ensure that your code matches all the criteria it needs to meet. (Note: I wouldn’t recommend this approach across the board, particularly if an MVP, pilot system, or feature with a lot of changing specifications is being created, which is quite common with my startup customers. For something mature, scalable, and maintainable in a financially feasible manner, it’s required.)
Martin’s discussion of “expected criteria” is another area that is really important for developers to understand and put to use. Ultimately, a customer or stakeholder will have to accept the software that a developer builds. When is the software done? What do clients judge the system’s success by? What aspects of the software do they value, and how do they prioritize what they value? To address this, I've always operated from the mindset of: the software is done when the customer tells me it's done. Part of that determination is working with the customer to define the acceptance criteria, though that can be difficult if the customer is non-technical or busy. Even high-level criteria are helpful, such as "Search for a product, and buy it” or “Load fast.” That’s fine so long as the stakeholders are open to iterations later to arrive at what they truly want. Conversely, the criteria could be very specific. Ideally, the developer helps the customer put more definition on their acceptance criteria throughout the process. The more quantitative, the better. The developer is finished with the work when they deploy or deliver the software or functionality that meets all the acceptance criteria. In conclusion, it’s not so important how the acceptance tests are written even though there are best practices; what is important is that you and the client know what is “done” and agree to it.
The book is chock-full of other applicable advice as well, from numerically-driven ways to handle estimates to suggestions for interacting with colleagues. All of the recommendations align to the goal of helping developers comport themselves as professionals so they’ll be treated as such by other professionals. It’s very important because our work is nebulous and our profession is new. I highly recommend this book to anyone who wants to be a professional software developer for the long-term or works a lot with them.
Buy new:
$35.34$35.34
Buy new:
$35.34$35.34
FREE delivery Tuesday, May 7
