The Muratori-Martin debate: Clean Code, yay or nay?

What's Clean Code to you, programmers? To some, it's the Holy Grail of programming, a state to strive for at all costs. To others, it's a pain in the butt and an impediment to getting shit done.

Many others, like myself, I suspect, fall in between these two polar extremes - Clean Code is a good-to-have, but should be sacrificed when needs must. Because all programmers have to work within the contexts and envoironments they are given, and not every one has the luxury of making demands. Code exists to add business value, period. Nobody pays programmers to write beautiful, clean code for the sake of it, or take as long as they like writing said beautiful, clean code.

Do you have a moment to talk
about our Lord and Savior
Clean Code?

That's not to say that code shouldn't be beautiful and clean; far from it, but it shouldn't be the primary or overriding goal, at least not in the business context. It certainly shouldn't be treated like some sort of religion.

If you're given the choice of speed of delivery, performance, or Clean Code? what do you choose? If you say "all of the above", chances are you'll get none of the above.

Casey's take

One Casey Muratori falls squarely into the anti Clean Code camp. He recently took to YouTube to rant about Clean Code and how it's ruinous to his profession - that of a games developer.

In the video, he goes through the principles of Clean Code, such as (paraphrased):

1. Use Polymorphism instead of If blocks or Switch statements.
2. Hide the internals of a class.
3. Keep functions small.
4. Functions should do only one thing.
5. Don't repeat yourself.

And then he proceeds to eviscerate most of them by example, showing how much Clean Code slows the program down. Also, how breaking those rules could actually improve the code. I have to say, that was educational. And a real eye-opening live example of what I always like to say - there are no blanket solutions. One programmer's Clean Code is another's garbage.

Casey Muratori vs Uncle Bob

Cue the Clean Code fanboy outrage!

And what bigger Clean Code fanboy than "Uncle Bob" Robert C Martin himself, the author of Clean Code (which I regrettably haven't had the pleasure of reading yet)? I was alerted to the debate that had sprung up on GitHub after doing a Google search, and immediately forked that branch so I could catch up at my own leisure.

Crossing swords.

In it, Martin took on Muratori in a vigorous debate, filled with examples and counter-examples, and one amusing aside about GitHub's interface speed.

At the end of it, Muratori had this to say:

So if I had to restate the summary, I would say:

• We both agree that complete hiding of implementation details can be useful, and that people should know how to do it.
• We disagree on how often they should be hidden; you think the answer is "most of the time", I think the answer is "only in specific circumstances"
• We disagree on how important the computer is. I think we need to think about the computer most of the time, whereas you do not.

In Martin's closing statement...

In my work I don't care about nanoseconds. I almost never care about microseconds. I sometimes care about milliseconds. Therefore I make the software engineering tradeoff towards programmer convenience, and long term readability and maintainability. This means that I don't want to think about the hardware. I don't want to know about Ln caches, or pipelining, or SIMD, or even how many cores there are in my processor. I want all that abstracted away from me, and I am willing to spend billions of computer cycles to attain that abstraction and separation. My concern is programmer cycles not machine cycles.

... and this.

I tip my hat, however, to your valid concern that myopically focussing on programmer cycles and utterly ignoring computer cycles can lead to horrifically inefficient systems. None of us want that; just as none of us want to work in a world where we focus solely on computer cycles to the detriment of programmer productivity.

I marvel at how classy and professional this exchange was. I've known people to get outright nasty about their geek credentials, and I've worked for code purists who constantly derided my code for not being clean enough. This debate showed me that people are capable of not making things personal where their work is concerned. That said, Robert C Martin does have a reputation to uphold, and he's probably not dumb enough to tarnish his own legacy with a public hissy fit.

Some will differ as to who won the debate. I don't think there was necessarily a winner in the classic sense - both acknowledged each other's viewpoints but retained their own opinions. If there was a winner, it was probably everyone who was privileged to witness this.

My takeaway from all this...

I hold Robert C Martin in high regard. How could I not? The man's accomplished more than I ever will, in my own industry, at my own game. And reading his work, there's this sense that I will never live up to his standards.

But here's the thing - do I want to? Should I even want to? Uncle Bob and I work in the same industry, yes, but we also work on vastly different things and with vastly different things at stake. It's like comparing a skateboard to a bicycle... not that I would ever seriously compare myself to Uncle Bob, or him to a bicycle.

Clean Code has its place. But as with most things, we should not accord it more importance than it deserves.

Cleanliness is next to Godliness!
T___T

Reference Review: The Clean Coder: A Code of Conduct for Professional Programmers

The Clean Coder: A Code of Conduct for Professional Programmers is a book I first picked up when I was working in a startup. My then-employer had a shelf full of these, and I spent what I call "decompression time" browsing through the chapters. Years later, I have decided to get off my ass and write a review.

This book was written by Robert C. Martin, a character of no small fame in the software industry. At the time of publication, he had over 40 years in the industry.

The Premise

This book is a collection of Robert C. Martin's opinions on what it takes to be a professional programmer. While there are times I consider some of his views extreme, to his credit, he makes no bones about the fact that all this is a matter of opinion.

You will likely not agree with everything I say here. After all, this is deeply personal stuff. In fact, you may violently disagree with some of my attitudes and principles. That's OK - they are not intended to be absolute truths for anyone other than me. What they are is one man's approach to being a professional coder.

I am not at a hundred percent agreement on his opinions, far from it. However, I have had so many people try to give me tech career advice (which I franky never asked for) even though they -don't know shit- are woefully underqualified to do so. Reading opinions from someone who is obviously qualified, for a change, feels like a breath of fresh air.

The Aesthetics

The cover used for this book is something like some kind of exploding star. Not really being into space photography, all I can really say is "eh, it's kinda pretty", and move on.

What's more interesting visually, however, are the little cartoons at the start of each chapter. They range from slightly lame to wickedly funny.

The Experience

Martin's writing style is certainly lively and dramatic, and very often, he does come off as more than a little self-righteous. Ultimately, though, this adds to the experience. To say I was both entertained and educated, would be an understatement.

Martin drops gems liberally, from his war stories to advice on scope negotiation, time management and design practices. There were times when I had to stop reading and conduct a Google search on the terms he was using.

Due to his vast experience, however, there were times where he simply lost me, especially when he was talking about tape decks and transistors. Robert C. Martin is a programmer from a very different era and sometimes it is easy to forget that.

The Interface

There are little snippets of humor, especially where the author has sprinkled footnotes. For the most part, content is neatly organized into coherent groups.

What I Liked

The Foreword to this book, contributed by Matthew Heusser, is great. It grabs you and really sets the tone for the rest to come.

The footnotes are really precious.

I resonated deeply with Martin's advice on owning one's career, taking responsibility for your professional growth and practicing one's craft. These were my dearly-held opinions long before I ever picked up this book.

The war stories in the book. In the course of reading the author's opinions on what it takes to be a professional, it is tempting to dismiss him as a pompous jackass. However, his war stories do not paint him as a hero. In fact, for the better part of them, these stories detail all the mistakes he made, both in technical terms and in terms of attitude.

This bit is something I have been ruminating on for a while, and Martin puts it nicely.

Perhaps we didn't get into programming to work with people. Tough luck for us. Programming is all about working with people. We need to work with our business, and we need to work with each other.

Martin's little summarization of various IDEs at the later part of the book, was charming.

Generally, there are some really thought-provoking parts in the book where the author illustrates just why a programmer going it solo is a terrible idea. It brught to mind all the times I've had to do it during my career, and how blissfully unaware I was at how unprofessional all this was. This gave me a very different, sometimes disturbing, perspective.

What I Didn't

Martin's very extreme take on professionalism.

What would happen if you allowed a bug to slip through a module and it cost your company $10,000? The nonprofessional would shrug his shoulders, say "stuff happens", and start writing the next module. The professional would write his company a check for $10,000!

This strikes me as unrealistic. What if your code is responsible for the loss of a life? Are you supposed to commit seppuku? What if your code is responsible for the loss of ten lives? Commit seppuku ten times? There's a certain point where that logic breaks down.

This bit. It's a common occurring theme in the book.

And indeed, doesn't it make sense that the first responsibility, and first goal, of an aspiring professional is to use his or her powers for good?

Martin makes this big song and dance about using our "powers" for good. I have my reservations, not because I want to do evil, but because I think assigning any sort of moral value to code is pure folly. Code is just code. Code is about solving problems. Whether that problem is about aiding orphans in Africa or getting past the security in a bank, is irrelevant as far as code is concerned. (The law, however, is another story)

However, and I mean this with great sincerity and respect, Robert C. Martin has done more in his career than I likely ever will. He is probably writing from that viewpoint. His code will affect far greater things than mine will.

Conclusion

This is not a bible, and should not be treated as such. It is, however, a good source of advice for those who find themselves at a loss as to how to proceed in their career, how to handle pressure and how to navigate the various intricacies of human communication.

After a re-reading of this text, I find myself strongly motivated to read the rest of his work.

My Rating

8.5 / 10

Time to get clean,
T___T

Three Great Virtues (Part 3/3)

Hubris is probably the most misunderstood of all the programmer virtues. But you're in luck - I'm Teochew, and if anyone understands arrogance, it's us.

The Virtue of the Great Programmer - Hubris

Developer ego is more commonplace than you'd expect. Any developer with some experience under his belt is going to be rather opinionated about how things should be done. Programming is about bending the will of a machine to our own, and making it churn out the results we want. It is about creating usable objects out of virtually nothing. It is about dealing in languages many people are too intimidated by to even attempt. And getting paid for it. Why wouldn't we be arrogant? Consider the quote below from Robert C Martin, in his book The Clean Coder.

"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance."

Robert C Martin seems to be a bit of an extremist in his views, and more than a little verbose. But in this case, he hit home for me right there.

But... but, but.

Why be modest when
you're that good?

In order for hubris to be a virtue, it has to work for you. It has to help you in your development. It has to drive you.

It has to spur you on to create products that people can only praise. Any code attributed to your name has to achieve great things. That arrogance manifests itself as pride in your work.

It has to inspire you to go boldly where no one has gone before. "A hundred programmers have failed? Well, I'll be the hundred and first." "Better men have tried and failed? Bitch, there ain't no better man." In fact, I believe that it is this same audacity to try something different, something unthinkable, that separates great programmers like Bill Gates (daring to succeed despite dropping out of university? The sheer gall.) and Linus "I'm always right" Torvalds from the rest.

How not to be Arrogant

Some forms of arrogance manifest as a belief that one has already learned all that is worth learning, and there is no need to keep exploring. That's arrogant, sure... it's also foolish. Dangerously so. Technology is constantly evolving. As I type this, a few million hackers around the world have figured out newer and more insidious ways to breach web security. New frameworks are threatening to render the ones you use obsolete. New features in your favorite programming language are causing older features to be deprecated. Going down this path is a sure route to ruin. There's a place for arrogance. Not so for complacency.

Refusal to listen to feedback is another dangerous manifestation of arrogance. Sure, not all feedback is created equal. If, for example, you haven't written a line of code your entire misbegotten life and have the audacity to comment on my professionalism, be prepared to be very firmly put in your place. On the other hand, working too close to the product can lead to blind spots, and sometimes - just sometimes - fresh perspectives are helpful even if they are from laypeople. There's also a tendency for a developer's ego to lead to defensiveness - such as refusing to concede an argument or admit that someone else knows more than you do. That is insecurity. If you're confident enough in your own abilities and value, you don't ever need to travel that rocky road.

Then there's the Not Invented Here syndrome. The pragmatic developer understands that there is no shame in collaboration or leveraging off someone else's work. "Real devs code from scratch"? What kind of egoistical rubbish is that? No matter what you do, you're leveraging off the work of Ada Lovelace, mother of the modern computer. Want to be a "real dev"? Go re-invent algorithms!

So...

Are you an adequate, good or great programmer?

This is, as you may have suspected, just my opinion. There are many ways to interpret the words of Larry Wall. In fact, I have no real business telling anyone how to achieve greatness in programming - after all, I'm just about adequate myself, on some days anyway. Like many people, I have my moments. Some days I feel like I'm Neo from the Matrix, and some days I wonder why I'm even employed.

But in general, yes, most developers fall around the "adequate - good" axis, with only the top echelons making it into the "great" category. Still, "adequate" is a good goal, and "good" is a respectable one.

Be virtuous!

Too impatient to sign off properly, too lazy to care.
T___T