Last month, I picked up a copy of Robert C. Martin’s “The Clean Coder”. The Clean Coder is a handbook to help software engineers navigate the workplace. It includes advice on dealing with conflicts, avoiding burnout, time management, teamwork, and more.
I read “Clean Code” and watched some Clean Coders videos a while back, so I was excited to see what Uncle Bob had to say about actually being a software engineer. While much of the book was very helpful, there were many sections that I found misguided at best, and problematic at worst.
From the very beginning of the book, I got the sense that I was not truly in the target audience. You may think that’s fine; after all, not everyone can be in the target audience for every book. But I am a professional software engineer, the target audience claimed by The Clean Coder, and yet much of the content was aimed away from me.
In one section, Uncle Bob includes an anecdote written by John Blanco in order to illustrate a point. The story begins by setting up the life of a typical software engineer.
When you hit your teenage years you decide you want to be a software developer. During your high school years, you learn how to write software using object-oriented principles. When you graduate to college, you apply all the principles you’ve learned to areas such as artificial intelligence or 3D graphics.
The expectation that you learn software development in high school in order to explore higher level concepts in college rubbed me the wrong way. I personally didn’t learn to code until college, and I have friends and coworkers who started later than that.
There is a pervasive belief in the software industry that in order to be a good programmer, you had to start when you were a kid. A recent Hacker News thread on an article about Howard University’s CS program involved a fair number of people commenting that people who started their CS education in college “probably aren’t SV [Silicon Valley] material”.
I experienced it firsthand in college, when I changed my major to Computer Science as a sophomore. Often, students around me loudly proclaimed how bored they were with the intro level CS courses, because they covered the material at age 13–14. They feigned surprise when they found out that, at age 19, I had never written a line of code before. Once, a student told me that he felt bad for people like me who had to work so hard in the intro classes “just to learn what everyone else already knew.”
Luckily for me, I believed that you could get a job with only 4 years of CS experience. (Guess what? You can!) Because I have already started my career as a software engineer, reading that passage didn’t dissuade me from pursuing anything. But I imagine a college freshman or sophomore reading that and feeling that judgement once again. I imagine that for some people, reading that belief in a widely regarded tech book could be the last straw, making them think that they are not cut out for a career in software just because they didn’t learn to code in high school.
Later on in the same story, Blanco makes a point about dealing with clients and 3rd parties at the same time:
In client terms, a “3rd party” is akin to Angelina Jolie. Despite the promise that you’ll be able to have an enlightening conversation over a nice meal and hopefully hook up afterwards … sorry, it ain’t happenin’. You’re just gonna have to fantasize about it while you take care of business yourself.
Surely there are other metaphors concerning expectation vs. reality that are slightly more universal than, “It’s just like masturbating while thinking of Angelina Jolie!” The overly sexual metaphor is pretty distracting from the original topic. While it didn’t prevent me from understanding the concept, it underscores the fact that this advice is not really for all software engineers, it’s for a specific type of software engineer, namely those that consider hooking up with Angelina Jolie to be the ultimate experience.
I read it as, “If you’re not into sex with hot women, you can deal with it and transpose this metaphor onto whatever it is you think is fun, I guess.” But based on the general tone-deafness of the piece, I have no reason to assume that it was meant to include LGBT women, or anyone else other than straight cis males. The whole thing felt like the programming advice equivalent of a GoDaddy or WinDev ad.
I understand that these excerpts were not written by Uncle Bob himself, but including them in the book is a strong endorsement. It perpetuates the archetype of a software engineer as a precocious boy who programmed throughout high school and grew up to be a hacker who jerks off thinking about Angelina Jolie.
There are many more subtle examples, as well. At multiple points throughout the book, Uncle Bob calls on his childhood experiences and explains how formative they were to his identity as a programmer.
Of course, I had other kinds of mentors too. There was the kindly neighbor who worked at Teletype who brought me home a box of 30 telephone relays to play with. Let me tell you, give a lad some relays and a electric train transformer and he can conquer the world!
There was the kindly neighbor who was a ham operator who showed me how to use a multimeter (which I promptly broke). There was the office supply store owner who allowed me to come in and “play” with his very expensive programmable calculator. There was the Digital Equipment Corporation sales office that allowed me to come in and “play” with their PDP-8 and PDP-10.
My problem here is not with his personal experiences, it is with the fact that he presents these experiences as standard. After describing the mentors above, he mentions one other mentor, a senior programmer who helped keep him from getting fired from his first job and showed him the ropes, then ends the list with, “But, frankly, that’s about it.”
It struck me as very tone-deaf for a person who was lucky enough to have a community that exposed him to technology and taught him skills, to describe those experiences as “about it”. What does that say to the young adult reading this who realizes that nobody ever sat them down and taught them technology skills? There are people who didn’t have kindly neighbors that worked at tech companies. There are people that no store owner automatically trusted enough to let them “play” with the expensive equipment. What about the people who struggled with their first experience in the industry and didn’t have someone to save them before they got fired? There are many people who weren’t given the opportunity to explore technology as children the way he was, and many people who didn’t receive the help as a young adult that he was given. He casually brushes off the experiences as helpful but not THAT helpful.
Does that make those people less suitable for a career in software? Of course not, but I would hate for a single person to read that and come to that conclusion. Acknowledging that his experiences were extremely helpful, and that he was lucky to have them would go a long way against discouraging readers who weren’t as fortunate.
Another problem I had with the book is that it makes the author seem out of touch with the current state of software engineering. That’s a little worrisome, given that the book was published fairly recently, in 2011.
In one instance, Uncle Bob explains the importance of documentation and reading code:
Have you ever used a third-party framework? Often the third party will send you a nicely formatted manual written by tech writers. The typical manual employs 27 eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one explaining how to configure, deploy, manipulate, and otherwise use that framework. At the back, in the appendix, there’s often an ugly little section that contains all the code examples.
Where’s the first place you go in that manual? If you are a programmer, you go to the code examples.
Often the third-party will send me WHAT? I don’t know of any software engineers for whom this is a realistic scenario. I’ve never been mailed a book with color photographs by a framework I found on Github or Cocoapods. I’ve never been mailed documentation by anyone in my entire life!
Does this prevent me from understanding his point, that the code examples are more helpful than high level explanations of what the code does? Of course not. Does it make me question if his advice will truly apply to me in my daily work? Absolutely.
This is not to say that the advice of older engineers is useless, or to poke fun at the fact that the previous generation has not kept up with the newest and trendiest technologies. Many of his anecdotes about working for Teradyne in the 70s are very interesting, and provide a great picture of what it must have been like to program on tapes, without version control and all the other niceties of modern programming. But for a book written in 2011 to include a scenario that is at least 10 years too old as though it is still relevant is bizarre.
It’s like the song Bug A Boo by Destiny’s Child. It’s a great song; I loved it as a kid and will always love it. The message is still as real as the day the song dropped, but I do chuckle every time they mention pagers, MCI, AOL emails, etc.
A few days ago, I read a blog post from Uncle Bob’s site, titled “Manhandled” . It confirmed my suspicion that he is, indeed, out of touch. The first part of the post describes how he was listening to an astronomy podcast where the guest (a female scientist) described the rampant sexual harassment of women in science. He is shocked and appalled, then has a sobering thought: “Could this be happening in the software community as well?”
He proceeds to do some research, and is horrified to find that, yes, women in software are harassed, too! The rest of the article delves into the exact results of his research, and a theory that the declining numbers of women in computer science since the 80s may be, in part, due to said harassment.
The post was written in January 2016. When I saw the title, I thought it was going to be Uncle Bob finally sharing his thoughts on one of the biggest issues in our industry. I was not expecting an “Uncle Bob just now finds out about sexism and harassment” post. I’m really disappointed that someone that influential in the software community somehow managed to ignore the plight of women in software for so long. It is disheartening to imagine that someone who speaks at conferences and writes books on the industry somehow managed to be so disconnected from it.
Despite the issues, The Clean Coder is a book that has a lot of useful advice. I would just urge anyone reading it to take it with a grain of salt, as it is not nearly as universal as you might think. This is also not a hit piece on Uncle Bob. I’ve read his books and watched some of his videos on Clean Coders, and found them very helpful. But I think that once he steps across the line from teaching purely technical skills to the complicated world of personal career development, his work falls severely short.