Return of the Real Programmer

By Brian Hurt | Published: April 3, 2009

So, when Robert started talking about his April Fools joke post, I immediately thought of the classic essay “Real Programmers Don’t Use Pascal”. It was a take off of a book that was a seven day wonder at the time, entitled “Real Men Don’t Eat Quiche”, which was a funny-once sort of book.

Parts of the “Real Programmers” article didn’t age well- most of the languages discussed (Pascal, Fortran, Cobol, Assembler) are, by and large, irrelevant and unknown to most professional programmers today. Most programmers today don’t know flow-charts, and don’t hang out at beaches doing anything, because most beaches don’t have wireless.

I would, however, argue that the Real Programmer is alive and well- indeed, he (and it is almost always a he) is even more prevalent today than he was in 83. Aspects of being a real programmer have changed, but the core attitude and nature of the Real Programmer remains. Indeed, in many ways the modern Real Programmer is worse than the original. The original breed still remains, mainly doing C++ these days. Meanwhile, a new breed of Real Programmer has arisen, and found a home in languages like Ruby. Some of the aspects changed, but the attitude DNA remains the same.

By the way, the date as I write this is April 3rd, and I’m being deadly serious.

So what are the defining attributes of a Real Programmer?

First, and foremost, Real Programmers are about the testosterone. If your average Cobol/Java drone thinks programming should be (needlessly) dull and boring, your average Real Programmer thinks programming should be (needlessly) difficult and dangerous. The purpose of programming, to the Real Programmer, is to prove how clever and/or manly they are.

Now, there is a little bit of Real Programmer in all programmers- you can’t get good at programmer without getting a kick out of solving a hard problem just to solve a hard problem. But for most of us, we grow out of that being our primary motivation- and that’s where the Real Programmer is different. The Real Programmer is the classic “thirteen going on thirty” programmer. If there are two ways to solve a problem- the hard, difficult, and dangerous way, and the simple, easy, and safe way, the Real Programmer will choose the former. After all, what good is a solution if you can’t brag about it?

This is the core attitude of Real Programmers, from which all other attitudes can be derived. It this attitude, more so than anything, which distinguishes a Real Programmer. It is possible to be coding primarily in Assembler, Fortran, and C++ and not be a Real Programmer- and it is equally possible to know no other language than PHP or Basic and be a Real Programmer. The difference isn’t in the tools or languages used, but rather in the attitude taken.

As an example of the “derived” attitudes, Real Programmers don’t maintain code- there are no bragging rights in maintaining code. Only in new code do bragging rights hide. This includes rewriting code- but only if the new version of the code is somehow better (or at least was written faster) than the old version. This is how the Real Programmer fixes bugs- they throw out the old code and rewrite it, only now the code isn’t old and crufty and broken (new and crufty and broken, maybe…).

Real Programmers don’t make mistakes. Or, at least, don’t admit that they make mistakes. To admit to making a mistake is to admit to being something less than God’s gift to programming, which undermines the primary motivation. Only wimps and incompetents make mistakes. Trying to sell a new technology (such as static typing) on the grounds that it catches many mistakes the programmer makes is just an affront to the manhood of the Real Programmer- and thus will inevitably be dismissed.

The one exception to this is when, by accepting that you might, theoretically, have the potential to one day make some sort of minor error, you get to brag about what you did to avoid that (extremely unlikely) eventuality. This is where Unit Tests come in. See, the great thing about unit tests is that they’re code, generally new code. And when you change some piece of the “core” code, you get to rewrite (from scratch) a whole bunch of unit tests!. And then you get to brag about how many unit tests you have, and have written recently. It’s all about the bragging rights, remember.

Since Real Programmers don’t make mistakes, anything done by the language to prevent mistakes is pointless, and simply serves to thwart the intentions of the Real Programmer- the uppity computer thinks it better than him, see? How is the Real Programmer supposed to display his cleverness with the damned compiler henpecking him at every point? If you write, and constantly rewrite, a whole huge bunch of unit tests, and then brag about your unit test suite, but still don’t like static typing, you may be a Real Programmer (with apologies to Jeff Foxworthy).

This is a concept that, when taken to it’s logical conclusion, drives you to program in assembler. Not all Real Programmers take this logic to the extreme- this is the primary difference between the “Old Guard” Real Programmers, and the “New Wave” Real Programmers. The New Wave of real programmers don’t mind not having pointer arithmetic, or not having manual memory management, two things the Old Guard can’t imagine living without. But that’s just because the New Wave has grown up with languages where that was just standard. Try to sell a Real Programmer a new programming style or language feature, based on trading a small amount of power (mainly the ability to screw up) in order to gain a large amount of protection from mistakes will simply be met with hostility.

Real Programmers don’t document, because you can’t brag about documenting. You wrote a real nice introduction to how the order flow system works? Hah! I rewrote the whole billing system. From scratch. With one hand tied behind my back. I almost didn’t make it out of the server room alive!

Real programmers don’t trust that fancy book-learning stuff. This is one way where the New Wave of Real Programmers is even worse than the Old Guard. The Old Guard at least new basic data structures and algorithms, and could do things like sort an array (though they did have a tendency to write super-tuned hand-optimized assembly language implementations of bubble sort). The New Wave is not capable even of that. Their knowledge of algorithms and data structures is limited to the API of the Vector/List/Array class of their favorite language(s), including the call to the sort() routine.

I will say this sort of ignorance is (or has become) very common place among programmers. In interviews, my favorite first question is “write a routine to sort a linked list- any algorithm is fine- bubble sort, merge sort, whatever.” This shows me two things, that a. you can in fact write code, and b. you have some knowledge of basic data structures and algorithms. One of these days I hope to be involved in an interview where I need to come up with a second question that isn’t designed just to make the interviewee feel somewhat better after completely blowing the first question.

Ignorance may be common, but the Real Programmer takes it to another level. Now only are the ignorant of the basics, they wear their ignorance as a badge of pride. Not only do they now know anything, you are suspect if you demonstrate any theoretical knowledge, or opine that such knowledge might be useful. Once again, the issue comes down to bragging rights- which of these two scenarios gives one the most bragging rights: struggling with this complex, thorny problem for months (barely making it out of the machine room alive), or recognizing that the problem is a partial differential equation, and simply looking up the solution? Bingo.

And so on.

There is one last topic I want to touch on before signing off, because I know it’ll come up in the comments. I have fairly recently opined that programming shouldn’t be boring. This can be taken, basically correctly, as a rant against the “Cobol/Java Drones”. But this does not mean that I was encouraging people to be Real Programmers.

The opposite of the Drone isn’t the Real Programmer, in fact the two breeds of programmers have a lot in common- an ignorance of theory, not thinking about what they are doing and how they are doing it, an emphasis on code even at the cost of maintainability, resisting change, and so on. A Drone is basically just a testosterone-deficient Real Programmer. Neither one really thinks.

And if you’re about to write a flame (in the comments below, or on the comments section of reddit or digg, or on your own blog) all about how wrong I am, how you are in fact God’s gift to programming, and if I knew anything at all I wouldn’t be espousing such stupid questions, perhaps you should stop and think…

Related posts:

  1. The Programmer is Dead; Long Live the Developer!
  2. REAL ID: Told You So
This entry was posted in Classic, Programming Language Punditry, Software Business. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://barrkel.blogspot.com/ Barry Kelly

    Writing a mergesort for a linked list on the fly is easily done in 10 non-pressure minutes on one’s own (I just did it because of your suggestion, as an exercise in recursion vs iteration with mutable nodes), but doing the same thing while someone is watching you, and you’re in a strange place, etc., is a whole other ball game.

    Or to put it another way, I wouldn’t be surprised if what you’re seeing is nerves etc. rather than lack of knowledge / skills. Then again, I haven’t been in your shoes, so I don’t know the details…

  • brianstewey

    As I was reading your article and agreeing wholeheartedly with your ideas about the self perception of “real programmers”, I was thinking that you must have conceived this idea through your experiences with other programmers. But then I read the part about your first interview question been – “my favourite first question is “write a routine to sort a linked list- any algorithm is fine- bubble sort, merge sort, whatever.” and then it struck me how you knew so much about “real programmers”, you were writing about yourself.

  • UnrealProgrammer

    I tend to agree with the previous comments. I have been a successful programmer for 12 years. I have a degree in computer science from a major university. Your question is favors someone who just got out of CS class rather than a real world programmer. I certainly know the principles behind all of the sorts and linked lists, but it’s easy to be rattled by a barrage of academic questions in an interview situation. Quick – what’s the difference between a Hashtable and a Hashmap in Java?

  • Brian

    Several comments:

    brianstewey: Actually, I got this question from an interview I took many years ago. Guess what? I aced it. Banged out a merge sort in ~10 minutes, in C, no problem. And Barry Kelly, that was with people watching me.

    By the way, I’d be ecstatic as an interviewer, if the candidate blinked at me, and whipped out in thirty seconds:

    sort :: Ord a => List a -> List a
sort [] = []
sort (x : xs) = (sort [y | y <- xs, y < x]) ++ [x] ++ (sort [y | y <- xs, y >= x ])

    UnrealProgrammer: Without googling the answer, and without having done serious Java programming in years, I believe one is synchronized and the other isn’t. 60/40 that Hashmap is the unsynchronized one. Googling: Yep. There are a couple of other behavioral differences (how the implementation behaves if you’re updating the table while iterating over it, which is a bad idea IMHO in general, and whether you can store nulls or not, another bad idea IMHO). But I got it right, including that Hashmap is the unsynchronized one.

  • http://barrkel.blogspot.com/ Barry Kelly

    Give yourself a pat on the back, Brian.

    Some people don’t enjoy performing in front of an audience so much. That shouldn’t condemn them, but it sounds dangerously like you enjoy doing so.

  • http://barrkel.blogspot.com/ Barry Kelly

    Actually, now that I’ve thought about your response for a few minutes, it sounds like you’re trying to hire yourself. I’ve fallen into that trap myself before. I believe it’s a hallmark of poor and/or inexperienced interviewers. You’d probably be better off discussing some open-ended problem, and look to be surprised by some creativity.

    In other words, look for people who are better than you in some areas. Complement your weaknesses.

  • Brian

    Barry Kelly: actually, I hate performing before an audience. Guess what? It’s a job skill (or more specifically, a getting the job skill).

    As for what questions to ask during the interview, this question is just intended to see if you can write code. Is there some form of programming of which I am unaware of that does not involve writing code? That doesn’t amount to being an architecture astronaut?

    If I were trying to just hire myself, the question would be phrased “write a tail-recursive O(N log N) merge sort on lazy lists in Ocaml, please”…

  • http://barrkel.blogspot.com/ Barry Kelly

    IMO, the task of writing fiddly code during the hiring process is best left to a technical problem-solving exercise, most likely over email, with a couple of problems and a few hours to come back with the solutions. Something that more closely resembles actual work conditions. Even being alone in a room with a work laptop for 30 minutes would likely be better.

    “Getting the job skill” of performing before an audience – being good at this seems to imply doing lots of job interviews. I don’t know about you, but I seem to have job interviews at a rate of about three per decade. Maybe I’m not aiming high enough, but I’ve never been rejected from a job once the interview process started, and I’ve been fairly happy with the jobs I’ve had.

    All I’m saying is that asking people fiddly questions on the spot can give misleading results if they’re nervous. I know I’ve stammered a little on a couple of really stupid little things through overthinking when on a phone interview, when I would never even have to think about them when doing work.

  • http://www.smokejumperit.com Robert Fischer

    @Barry Kelly

    If it takes you a couple of hours to write a sort algorithm, you’re already out of my job pool.

  • brianstewey

    Reading the comments and your replys I am now certain that this blog entry is about the author whether the author is aware of this or not. Why is that? Because in an interview you got asked to write a linked list and what did you do?

    “Actually, I got this question from an interview I took many years ago. Guess what? I aced it. Banged out a merge sort in ~10 minutes, in C, no problem. And Barry Kelly, that was with people watching me.”

    Now going back to you blog post.
    “First, and foremost, Real Programmers are about the testosterone. If your average Cobol/Java drone thinks programming should be (needlessly) dull and boring, your average Real Programmer thinks programming should be (needlessly) difficult and dangerous. The purpose of programming, to the Real Programmer, is to prove how clever and/or manly they are.”

    So not only did you “ace it and bang it out” in a fiendishly quick time you also did it in C.

    And this comment also seemed to stick out.
    “If I were trying to just hire myself, the question would be phrased “write a tail-recursive O(N log N) merge sort on lazy lists in Ocaml, please”…”

    Most impressive once more, I don’t know if i could even google the answer to that one. But I guess I am not a real programmer, but on reflection I don’t think I want to be.

  • http://barrkel.blogspot.com/ Barry Kelly

    @Robert – I think you’re taking things out of context now :)

    I can write a simple linked-list mergesort in 10 minutes without a problem, as I indicated in my first comment. A couple of hours for a technical question offline (e.g. over phone) isn’t unreasonable either, but I would prefer to set a more involved, less cookie-cutter problem, like a programming competition question, as I indicated in my comment on Brian’s later post.

  • http://barrkel.blogspot.com/ Barry Kelly

    Oops – I meant “(e.g. over email)”, not “(e.g. over phone)”.

  • Chris

    It’s sort of ironic, given the (well written) post, that in the comments you end up arguing over bragging rights about who was able to write a merge sort, from scratch, under time pressure – the hardest way possible, right? You barely made it out of the interview room alive!

  • http://ww.google.nl n0xie

    If you want to learn about Real Programmers, I strongly urge you to read this:
    http://www.cs.utah.edu/~elb/folklore/mel.html

    Real Programmers(TM) isn’t about bragging rights. It’s about being in control of the computer, not the other way around.

    Just like this blog isn’t about Real Programmers, just about a guy who wants to show the world how good he is at taking interviews.

  • bitterchick

    Coding in front of people? I love it. I’ve had a few clients who were either programmers or ex-programmers themselves. When I code, it’s like performance art. I’m not talking about interviews here. I mean, when I’m on the job, people can’t help from stopping what they’re doing just to watch me code. I guess it’s kind of mesmerizing. Like watching a fire burn. Real programmers: we write our own parsers, use our own languages, at least some of the time. If you limit yourself to other people’s languages, then it’s like living in a box. I wrote my first parser when I was 14. It was my second program. Nothing brilliant. Really just a simple macro language. Back then, I just thought that was normal. I mean, back then a computer would normally come with some kind of Basic interpreter built-in, which was great for learning, but also somewhat limited. Now I use llvm. Yeah, I may be old guard, but some of us can learn new tricks. Chix can be geekstas too.

  • Lacie

    I enjoyed reading this blog. It was really funny. The funny thing is that you are at least twice as dogmatic as the people you are complaining about, but I guess that is to be expected given your experience with Ocam. Like most people I have met that advocate functional programming you seem more that just a little bit bitter that the rest of the world is not interested in your skills or your dogma. See you are what I like to call a “Real Engineer.” The Real Engineer thinks that things like being able to to write a merge sort of the top of your head are important job skills. The Real Engineer likes to program on the bare algorithm. So they travel from one obscure language to another reimplementing functionality that already exists in any mainstream language. They do it for exactly the same reason that Real Programmers use inline assembly– because it is fun. And just like Real Programmers they generally do not have a job where they get to do the type of programming that they like, but just like the real programmer they do it anyway and the rest of us get to fix the bugs in their crappy unnecessary algorithm reimplementations.

  • Pingback: links for 2009-04-08 « pabloidz

  • pady

    I am with Brian that it will be nice to have a smart ( real ) programmer as your co-worker. And I used to interview like this a few years back. But what I have realized is that it depends on what the job needs. Most programming jobs do not need the depth – we would like to have the breadth of knowledge. Knowing that there is an API or open source that will do the sort is a good beginning ( i am surprised how many programmers do not even google !!! ). So if you have worked in multiple languages, know about the algorithms ( not all the details ), have a general idea of how they work, maybe can calculate the complexities and have the right attitude ( excited about the problem ), I will consider you. So my questions have changed in the past few years – i start from scratch – basic language fundamentals, then checkout some advanced concepts. What is “advanced” is based on your needs. I assume writing a search algo parsing a terabyte within a sec will definitely need questions like Brian’s. But if you are writing a help desk desktop app to be used internally, your requirements might not be the same.

    The big question I have is “is a real programmer attitude” good for your team or not ? Unless your team is full of “real programmers” ? In which case, we will end up with code with no documentation and I know the cost of that – rewrite :)).

  • Pingback: del.icio.us bookmarks for April 6th, 2009 through April 20th, 2009 < Subject Code

  • Michael Bacarella

    Firstly I’d like to say, Brian, you are missed. :(

    I just could not resist commenting on this part of your article:
    write a routine to sort a linked list- any algorithm is fine- bubble sort, merge sort, whatever.

    I think what we’re trying to do when we conduct interview is separate programmers who connect widgets to databases all day from programmers that have experience solving unique problems. In my experience if someone can solve one kind of unique problem they can usually make a good stab at solving most of them, so we may as well make it as easy as possible to identify the second kind.

    Here’s what I’ve come up with. Get ready.

    1. Here’s a binary string of 1s and 0s, such as 11001. What decimal number does this represent? Accept big or little endian answers (bonus if they ask which endian I want or grumble about other kinds of bit-coding). I’ve interviewed people who claim to be Math majors giving up on this. Most people get this one, and there has never been someone who missed this one who gets the next two.

    2. Here’s an instance of a hash table. It maps unique keys to unique values. Write code to invert the hash table so that values now map to keys. e.g. {1: ‘a’, 2: ‘b’, 3: ‘c’} -> {‘a’:1, ‘b’:2, ‘c’:3} Use any language. Take as much time as you want. Programmers claiming 10 years of experience blow this. Some people fill the whiteboard up with code and still fail. Some people demand to know why I’d ask such a useless question and get flustered.

    3. I describe a situation where we’re sticking a lot of data into a hash table and the program has asymptotic behavior. That is, it takes a minute to store a million entries but an hour to store ten million entries and days go by before it gets to a hundred million. What’s going on? I guide them through confirming we’re not swapping, what kind of data we’re populating, why we’re doing this at all, and so on towards some kind of hash function worst-case distribution on our data.

    That last one is more about the journey than the answer (although it’s great if they know the answer immediately). I’ll answer every question they ask along the way and see if they can use an analytical process to steer towards the answer, rather than voodoo programming which is how most people fail (“maybe if we stuck it into an Oracle database instead?”). If they suggest a better way to solve the problem instead of worrying about the hash function that’s fine too.

    Everyone who answers all three successfully was someone we did not regret hiring.

  • http://www.smokejumperit.com Robert Fischer

    @Michael

    With #2, are you looking for an in-place answer, or can I clone the hash table, clear the original, and insert the inverted pairings? The in-place answer is somewhat trickier…

  • Pingback: On Interview Questions and Sort Routines

  • http://www.loup-vaillant.fr Loup Vaillant

    Briansteway: of course the author is talking about himself as well:

    “Now, there is a little bit of Real Programmer in all programmers- you can’t get good at programmer without getting a kick out of solving a hard problem just to solve a hard problem.”

    I, too recognize myself a bit in this. My latest project, for instance, has some bits of Real Macho Programming. Less than 350 lines long, and already has some parts I don’t fully understand! I would kill the author if I wasn’t him. Needless to say, substantial rewrite is pending.

    I am proud, however, to brag about the fact that my code would probably rank high in Ocaml golf contests. :-)

  • Categories