Eric S. Raymond, I have a bone to pick with you


Tonight at the Philadelphia Java User’s Group meeting I had a chance to hear Eric S. Raymond, aka ESR, speak.  Eric’s an interesting guy to say the least who frequently has opinions that many consider incendiary.  Tonight was no exception.  This was the first time I’ve ever met the man in person so going in I didn’t really have any expectations (aside from what I know of him generally I mean).  What I got was a lot of interesting anecdotes, a few thought-provoking comments and a lot of opinions on various things.  It’s always great to hear someone who clearly has so much experience and knowledge talk and I’m very glad I had the opportunity to attend.

Honestly, I found myself agreeing with most of what he said.  I believe Eric and I have a lot in common, a lot of thought processes that are, to a large degree, the same.  I can tell for sure that he’s got a similar “old-school” mentality and a set of experiences similar to my own (although there’s certainly significant differences).  Some of what he said, like his comments on architecting systems in layers (vis a vis, design a low-level set of APIs, then build a command line on top of it, then a GUI if and when it’s needed, he gave The GIMP as a great example) strongly echoes my own feelings based on a lot of experience, so I was absolutely receptive to that.  Some of it, such as his feelings at Python, I was a little more ambivalent about, although it makes me want to dive into a few things that I otherwise may not have (Haskell for example, something I DEFINITELY want to look into).

One thing he said though I disagreed with quite a bit.  He was talking about coding standards.  Now, on the surface, he didn’t say something that was totally against my own thoughts on the subject.  He basically was saying that coding standards are nice, but aren’t THAT important, and even if you have standards you shouldn’t be overly anal about them.

I basically agree with this.  I think I put a little more importance than he does in standards generally, and I CAN admittedly get anal about it sometimes, but the idea of generally not going to that extreme I do agree with.  I’ve always said I’m less concerned with everyone on my team following the same set of standards religiously than I am with each developer being self-consistent.  Nothing annoys me more… nay, nothing PISSES ME OFF AND GETS ME INTO A MURDEROUS RAGE more, than a developer who can’t decide how many frigging tabs they’re going to use between two different methods, can’t decide if they like their braces on the end of a line or alone on the next line or can’t decide whether they’re going to write comments on not, can’t indent consistently or name variables in a meaningful way, and so on.

However, on the other hand, he was too soft on the idea of coding standards for my tastes.  This bothers me because I think he’s missing a key point in the whole discussion, which is that developers who write code that doesn’t adhere to SOME set of standards, whether a codified set of standards or their own internalized standards, not only write aesthetically unpleasing code that is difficult to read (really the less important aspect of standards) but also, in my experience, they write crappy code (“crappy” as in more buggy and more difficult to maintain).

In a nutshell: if you don’t have the attention to detail and self-respect for your work to write clean-looking code then you aren’t going to write clean-WORKING code either.

It’s a systemic problem, something I’ve witnessed far too much of.  Supposedly “professional” developers who can’t be bothered to format their own code well and who don’t write their code in a consistent manner also write code that has more bugs, sometimes paralyzingly difficult-to-find subtle bugs, and code that is much harder to maintain and extend.  They tend not to comment worth a damn and they usually do little in the way of planning and thinking about architecture before just starting to mindlessly hack away.  It’s a detriment to an organization for sure, no matter if it SEEMS like they produce well because they always hit deadlines.  Hitting deadlines is well and good, sure, but doing so at the cost of cutting corners and writing code that is brittle (meaning it can’t be extended without breaking something) and will need to be replaced a year down the road serves no one well.

Writing clean code that is formatted in a consistent fashion, commented well, obviously architecting the code in a reasonable fashion, these are things true professional developers do as a matter of course.  In fact, they don’t know how to NOT do it!  Even when they’re writing a one-off “quick hack” program, they still do it.  Part of it is just experience of course- the experience of knowing that the one-off hack projects have a tendency to become frequently-used mission-critical applications without ever intending them to be… this is something newer developers usually don’t realize (through no real fault of their own perhaps).  Better the program is written well to begin with, just in case.  Most GOOD developers don’t even have a true set of standards they adhere to, usually, nothing codified in any real way… they simply have a very naturally consistent style that they rarely break from.  It’s as natural as writing any code and it’s just an expected part of the job, or at least it should be.

You know, being a good developer isn’t about algorithms or Big-O notation or patterns or architecture or syntax, at least not for the most part.  It’s about logical thought.  It’s about that exercise most of us had to do in school where the teacher makes you give them every step to make a peanut butter and jelly sandwich… inevitably you miss steps that in retrospect are incredibly obvious.  Guess what?  YOU WERE PROGRAMMING BACK THEN!

And I bet, if you could remember the experience, you could clearly see that some people just “got it” and some didn’t.  The ability to break complex things down into manageable parts and then describe them logically is the core of programming, just like it was during that school exercise.  Way too many developers nowadays seem to fail the basic “thought test”, and I haven’t yet determined if its something you can learn or not.

Logic is, at its most basic level, simple, elegant and clean.  Your code should be a reflection of that, in form as well as function.  It should be a reflection of the ordered mind and thought patterns that produced it.  But you also have to write it with the realization that others will have to deal with it too, others that will likely have a mind that works a bit differently than yours… and you’ll have to deal with it too, and it’ll inevitably be after the point you’ve forgotten writing it!  Writing code with good habits in the first place will make all of that so much easier.  In fact, I’d say it can make a developer who fails the “thought test” at least passable.

And sure, there are exceptions to all of this… there are top-notch programmers who generate code that looks pretty bad… but it works, and works well.  There are developers who know every last technical detail, have an amazing grasp of computer science concepts and can throw together highly complex code without much effort.  Hey, those guys are amazing to me too.

But I sure don’t want to maintain their code!

My headline here was obviously meant to be a bit sensationalist to get visitors… hey, I’m not immune to such vanity!  I actually suspect Eric would agree with most of what I’m saying here, and certainly I didn’t come away thinking we had a huge difference of opinion on the subject of coding standards.  Like I said though, for me, it’s about something a bit more than what I thought he expressed at tonight’s talk.

I’ll try and summarize it thusly: TAKE PRIDE IN WHAT YOU DO!  Maybe that’s really the key to it all.  My dad, and I bet yours too, often said “if it’s not worth doing right then it’s not worth doing at all”, and that’s an adage I believe in strongly, and it applies to writing code as much as anything else.  We all have time pressures, deadlines to meet and most of us have more work heaped on us than we would in an ideal world.  It’s certainly not EASY to be diligent and do things the right way instead of just the expedient way.

But really, that’s what separates the true professionals from the pretenders.

Treat your code like the artistic creation it, in fact, is, but strive to make it more like an engineering discipline.  Combining those two schools of thought properly will lead you to a good place!

Leave a Reply

Your email address will not be published. Required fields are marked *