Stories about Software


Write Once, Confuse Everywhere

Not too long ago, someone asked me to take a look at a relatively simple application designed with the notion of having some future flexibility in mind. I poked around a bit to see what was where and found a reasonably simple and straightforward application. Like any, it had its warts, but there were no serious surprises–no whiplash-inducing double-takes or WTFs. One thing that I did notice, however, was that there were a bunch of classes that inherited from GUI components and had no implementations at all. So instead of using a TextBox, you might use a “DoNothingTextBox” with class definition DoNothingTextBox : TextBox and no implementation. (It was not actually called “DoNothingTextBox”–that’s just for illustration purposes.)

ConfusedI puzzled over the purpose of these things for a while until I inspected a few more and saw one with some code in it. I saw the purpose then immediately: hooks for future functionality. So if, for example, it were later decided at some point that all TextBoxes should disallow typing of non-alphanumeric characters, the behavior could be implemented in one place and work everywhere.

On the one hand, this does seem like a clever bit of future-proofing. If experience tells you that a common need will be to make every instance of X do Y, then it stands to reason you should make it easy and minimally invasive to touch every X. On the other hand, you’re quite possibly running afoul of YAGNI and definitely running afoul of the Open/Closed Principle by creating classes that you may never use with the specific intention of modifying them later. Also to consider is that this creates a weird flipping of what’s commonly expected with inheritance; rather than creating a derived class to extend existing functionality when needed, you speculatively create an ancestor for that purpose.

Is this a problem? Well, let’s think about how we would actually achieve this “change everything.” With the normal pattern of abstracting common functionality into a base class for reuse, the mechanism for the reuse is derived classes deferring to parent’s centralized implementation. For instance:

Notice that since all birds reproduce by laying eggs, that functionality has been abstracted into a base class where it can be used everywhere and need not be duplicated. If necessary, it can be extended as in the case of Ostrich, or even overridden (which Ostrich could do by omitting the base class call), but the default is what Parrot does: simply use the common Reproduce() method. The bird classes have a default behavior that they can extend or opt out of, assuming that the base class is defined and established at the time that another bird class extends it.

Aha! This is an interesting distinction. The most common scenario for inheritance schemes is one where (1) the base class is defined first or (2) some duplicated piece of functionality across inheritors is moved up into a base class because it’s identical. In either case, the common functionality predates the inheritance relationship. Birds lay eggs, and part of deciding to be a bird (in the sense of writing a class that derives from Bird) is that default egg-laying behavior.

But let’s go back to our speculative text boxes. What does that look like?

Now let’s say that time goes by and the developers all diligently stick to the architectural ‘pattern’ of using DoNothingTextBox everywhere. Life is good. But one day, some project management stakeholder tells one of the developers more on the UI side of things that all of the text boxes in the application should be green. The developer ponders that for a bit and then says, “I know!”

“Done and done.” He builds, observes that all text boxes are now green, checks in his changes, and takes off for the day to celebrate a job well done. Meanwhile, a handful of other developers on the team are updating to the latest version of the code to get an unrelated change they need. Each of them pulls in the latest, develops for a bit, launches the app to check out their changes, and, “what the… why is this text box green–how did I manage that?” Their troubleshooting progression probably starts with rolling back various changes. Then it winds its way into the version history of CSS files and styling mechanisms; stumbles into looking at the ASP markup and functionality of the various collaborators and controls on the web control/page; and, only after a great deal of frustration, cursing, and hair-tearing, winds up in the dusty, old, forgotten, formerly-empty DoNothing class.

I submit that the problem here is a subtle but profound one. As I’ve mentioned before, inheritance, by its nature, extends and sometimes modifies existing functionality. But this framework for building out and expanding software relies upon the fact that base classes are inherently more fixed and stable than child inheritors and that the relationship between child classes and base classes is well-defined and fixed at the time of inheritance/extension. To put it more concretely, OO developers will intuitively understand a how to use a “base” bird that lays eggs–they won’t intuitively understand how to use a “base” bird that does nothing and then later, spontaneously turns every bird on earth green. Changes to a base class are violent and confusing when they alter the behavior of inheritors while leaving the inheritors untouched.

So I’d encourage you to be extremely careful with using speculative inheritance structures. The instinct to create designs where potential sweeping changes can be implemented easily is an excellent one, but not all responses to that instinct are equally beneficial. Making a one line code change is certainly quick and creates a minimum of code upheaval for the moment, but once all of the time, effort, and hacking around during troubleshooting by other developers is factored in, the return isn’t quite so good anymore. Preserve that instinct, but channel it into better design decisions. It’s just as important to consider how broadly confusing or unintuitive a change will be as it is to consider how many lines of code it takes and how many files need to be touched.


Getting Started with Raspberry Pi

What and Why?

(If you’re here because you googled for a RPi tutorial, I’d suggest skipping to the next section)

I’ve recently throttled back on being all .NET all the time, mainly because I’m trying to spend more time working on my home automation. Toward that end, I recently picked up a Raspberry Pi. Since the organization’s home page neglects to include an elevator pitch as to what it actually is, I’ll summarize by saying that the Raspberry Pi (or RPi, for short) is a fully functional computer that’s about the size of a credit card and contains a good cross section of the device I/O that you might want, including audio, HDMI, USB, and ethernet. Oh, and they’re $35.

I’d imagine that most of you reading have either heard of this or, if you haven’t, you’re thinking of half a dozen uses now that you’ve read my description. But if you aren’t, here are a few uses you might find attractive: tiny media PC, small robot controller, car OBD troubleshooter device, Roomba brainwasher (I totally want to do this and use it to chase my cats around). One could also use it, as I plan to, for home automation.

My purpose here with my first RPi is going to be relatively simple — I’m going to offload the home automation controlling functionality of my home’s server onto it. The server I’m currently using is a repurposed dinosaur that I took with me to college (P2, 400 MHz processor, and tricked out to the max in slots with a whopping 3 128 MB sticks of RAM). It chugs along with an old Fedora installation, running a web server, SVN, a few databases, samba, and a few other goodies, as well as being hooked up to my big external drive where media is stored and eventually whisked into the cloud via Crash Plan. Add to this the fact that there’s a firecracker module plugged into its serial port to make the jump from my software to the electrical, and this is a pretty busy old machine that may not be long for this world. So I’d like gradually to parcel out its functionality to a handful of other machines to minimize my exposure to an extremely annoying failure, and the RPi is perfect, spec-wise and form-factor-wise, for the home automation web server.

Before Getting Started

So your Pi arrived in the mail, it has no installed OS, no instructions, and you’re not really sure what to do. No worries. I was like you, and I fumbled through it cobbling together a variety of guides and tutorials, and here, centralized in one place, is how I did it. This is the dead simple, option-free way to get something going with your RPi. All you’re going to get from this tutorial is an OS and web server on the device, but you’re not going to have to pick

RaspberryPiFirst off, prerequisites. To get started, here’s what you need:

  1. The RPi, obviously (pictured)
  2. A formatted Mini SD card that will act as the hard drive (pictured), or optionally a MicroSD card with a mini adapter. Either way, it needs at least 2 GB of space
  3. A micro-USB electronic device charger (i.e. an “anything but Apple” cell phone charger) to power the Pi.
  4. A desktop, Windows computer with either an onboard or connected SD card reader/writer
  5. An internet connection
  6. (Optional) HDMI to DVI adapter if you plan to spend a significant amount of time with your RPi plugged into a monitor.

You can probably make it happen without most of these things, but this is what I was working with when I did it, so if you have a Mac or want a different Linux distro on your RPi, this isn’t the tutorial for you.

Linux on the Pi

Here are the steps that I followed:

  1. First, download the zipped OS, “Raspbian Wheezy” for the RPi at this link, which will actually trigger the download. If that becomes defunct or you want to find it on your own, you can go to the RPi download site.
  2. Now that you have the OS, you need a means of putting it on the SD card. For that, you’ll need the Win32 Image writer (link triggers actual download of zip) or find the download yourself at their site.
  3. Plug your SD card into your SD reader/writer.
  4. Extract the contents of both of the zip files that you downloaded and launch the disk manager utility with administrator rights. If it takes a long time to load, there’s probably a driver issue with your SD card — that happened to me, but the fix was very specific to my hardware and is thus beyond the scope of this tutorial.
  5. Choose the Wheezy-Raspbian img file and the drive in which your SD card is mounted on your computer (below). For me the only option was the drive with the SD card, but make sure you double check that it’s the right one — I don’t want to be responsible for your frying some drive you need with a Linux install.WinDiskManager
  6. When you’re sure you’re not blowing anything you need away, click “Write,” and then click “OK” when warned.
  7. The write process will take a while, with specifics depending on your hardware. For me it took about 10 minutes. At the end, a “Write Successful” dialog will appear.
  8. Pop the SD card out of the computer and put it into the RPi.
  9. Plug your RPi’s HDMI into a TV (or monitor with the adapter) and plug a USB keyboard and mouse into the RPi.
  10. Now plug the RPi into power and let it boot up. It should look like a normal Linux boot sequence:
  11. Once it boots up, you’ll be shown some initial configuration options. I enabled SSH and expanded the root partition to use my entire 8 Gig SD card. Your mileage may vary here, but I bought the SD card just for the Pi and I have no interest in leaving the Pi plugged into my bedroom TV on a permanent basis, preferring to remote in.
  12. I also enabled booting into desktop, though I may later get rid of that option since the Pi will be headless. From there I selected “Finish” and rebooted. This took a while since it resized the root partition on reboot.
  13. Once it booted, it booted to a cute little desktop with the RPi logo in the background and you can configure it like any other Linux distro.
  14. One early thing to note is that the default user/pass is pi/raspberry — this will help if you drop into a console tty. (i.e. you hit ctrl-alt-f4)
  15. On the desktop, I noted that wheezy ships with WPA-supplicant for wifi config, which is handy if you have a wifi USB dongle, though I did not go this route — I have known much pain from using wpa_supplicant 5-6 years ago with AES before the utility was mature.
  16. After playing with the RPi desktop a bit, I powered down and disconnected from the TV, setting it up headless in my office, to be accessed via SSH.
  17. At this point, I tunneled in via SSH and ran an update. I had seen that things weren’t working on the desktop because it needed updating, so, first things first. “sudo apt-get update” did the trick (after about 4 or 5 minutes).
  18. To put apache on there, I did “sudo apt-get install apache2”. Ah, apt-get, the original app store.
  19. Finally, if you’re going to have a web server, it makes sense to give it a static IP. There’s nothing specific to Wheezy about this — it’s just standard Linux networking involving modifications to the network/interfaces file.

And, viola! The transformation from RPi in the box it shipped in to little web server is complete.


Comments: Here’s my Code and I’m Sorry

Heavily Commented Code: The Awful Empathy

Imagine a feeling–that empathy you get when you’re watching someone fail in front of an audience. Perhaps its a comedian relying on awful puns and props or a person in a public speaking course that just freezes after forgetting some lines. Ugh. It’s so awkward that it hurts. It’s almost like you’re up there with them. You start mumbling to yourself, “please, just be funny,” or, “please, just remember your lines.”

BanjoAccordionThe agony of sustained failure in such a situation doesn’t come on all at once. It creeps up on you in a crescendo of awful empathy and becomes memorable as it approaches the crest. But it starts subtly, before you realize it. There are warning signs that the train is unstable before it actually pops off of the rails. A classic warning sign is the “pre-excuse.”

Think of how you feel when someone gets up to talk at a meeting or give a presentation, and they start off with something like, “okay, this isn’t really finished, and Jones was supposed to help, but he got assigned to the Smith contract, and I did things in here that I’m not proud of, and…” With every clause that the speaker tacks onto the mounting lists of reasons that you’re going to hate it, you feel your discomfort mounting–so much so that you may even get preemptively angry or impatient because you know he’s going to bomb and you’re about to feel that tooth-grinding failure-empathy.

Okay. Now that the stage is set and we’re imagining the same feeling, know that this is how I feel when I open code file and see the green of comments (this is the color of comments in all my IDEs) prominently in a file. It’s as though the author of the code is on a stage in front of me, and he’s saying, “okay, so this is probably not very clear, and some of this is actually completely wrong, and changing this would be a nightmare, and you might want a beer or two, heh heh, but really, this will make more sense if you’re drunk, and, you know what, I’m sorry, really, really sorry because this is just, well, it’s just… it’s complete garbage. Sorry.”

That might seem a bit harsh, but think of what you’re looking at when you see code with a comment to actual code ratio approaching 1:1. You’re looking at a situation where someone needed to spend as much space and probably as much time trying to tell you what the code says as writing the code. Why would someone do that? Why would someone write a bunch of code and then write a bunch of English explaining to someone fluent in code what the code does? This is like me sending you an email in Spanish and putting the English equivalent after every sentence. I would do it if one of the two of us didn’t speak Spanish well or at all. And that’s how I feel when I see all those comments–either you don’t speak code very well or you think that I don’t speak code very well. The former occurs a lot with people who program haphazardly by coincidence. (“I better write this down in a comment because I had no idea that’s what an array was for. Who knew?”) The latter generates mind-numbing comments that rot. (“Declares an int called x and initializes it to 6.”) If you aren’t being forced to write comments by some kind of style policy and you’re not Zorro, you’re writing things in English because you’re not bothering to write and illuminate them in Code (I’m using the uppercase to distinguish simply writing some kind of compiling code from writing Code that communicates).

Self-Fulfilling Prophecy

There’s a substantial cross section of the developer world that thinks diligently commenting code is not only a best practice, but also table stakes for basic caring and being good at your craft. As I’ve previously explained, I used to be one of those people. I viewed writing comments in the same way that I view shutting drawers when I’m done using them or making my bed–just grunt work that’s unavoidable in life if you want to be a person that’s organized. Interestingly, I never really viewed them as particularly communicative, and, since adopting TDD and writing tiny methods, I viewed them largely as superfluous except for occasionally explaining some kind of political decision that transcended code (documenting APIs that you’ll release for public consumption are also an exception as this becomes part of your deliverable product). But I started to get increasingly disillusioned with the way comments would look in group code.

I would return to a method that I’d written six months earlier and for which I’d put a very clear doc comment, only to see something like this:

Holy crap! We’re clearly playing Russian Roulette here. Did the requirements change and we’re no longer endangering puppies? Is this code causing terrible things to happen? Who wrote that comment about 15? Hopefully not the same person that wrote the next line! And what should this code do–what the various comments say or what it actually does? Do the people responsible even work here anymore?

I’m pretty sure that anyone reading is chuckling and nodding sympathetically right now. You can only return to a method that you’ve written and see this sort of thing so many times before you come to a few conclusions:

  1. People almost never read your comments or any comments–they’re just a step above contract legalese as far as pointless noise in our lives goes.
  2. Even if someone does read your comments, they certainly won’t fix them along with the code they’re changing.
  3. On a long enough timeline, your comments will all become dirty, confusing lies.
  4. If you want to minimize the degree to which you’re a liar, minimize the comments that you write.

Surely this isn’t really news to anyone, and it’s probably answered with admonishments and mental notes to be more diligent about updating comments that everyone knows won’t actually happen. So why is it then considered good form and often mandated to put lies into source control for the later ‘benefit’ of others? Why do we do this, discounting the bed-making/diligence/good-citizen motivation?

To answer that question, think of the kind of code where you see comments and the kind of code where you don’t. If you see a four-line functional method with a single nested loop and no local variables, do you generally see comments in there? Probably not. How about a fifty line method with so many nested control structures that you need some kind of productivity add-in to know if you’re scoped inside that else you saw earlier or another if, or maybe a while loop? Bingo–that’s where comments go to hang out. Giant methods. Classes with lots of responsibilities and confusing internal state. Cryptically-named local variables. These things are all like cool, dank yards after a storm, sprouting explanatory comments like so many mushrooms. They sit there in mute testimony to the mildew-ridden, fungus-friendly conditions around them.

To put it another way, comments become necessary because the author isn’t speaking Code well and punts, using English instead of fixing the code to be clear and expressive. Thus the comments are compensation for a lack of clarity. But they’re more than that. They’re an implied apology for the code as well. They’re an apology for writing code and not Code. They’re an apology for the fact that writing code and not Code results in the project being a legacy project before it’s even done being written. They’re an implied apology for big, lumbering classes, winding methods, confusing state, and other obfuscations of intent. But most of all, they’re the preemptive, awkward-empathy-inducing, “hang onto your hat because what I’m doing here is actually nuts” pre-apologies/excuses to anyone with the misfortune of reading the code.

So please, I beg you–next time you find yourself thinking, “dude, nobody’s ever going figure this wackiness out unless I spend a few sentences explaining myself,” don’t bother with the explanation. Bother instead to correct the “nobody’s ever going to figure this out” part. Good Code speaks for itself so that you can focus on more important things.


The Code Warriors

Many moons ago, I stumbled across a website containing an index of “Flame Warriors.” The Flame Warriors were caricatures of personality archetypes that might be found in your typical early-to-mid 2000s discussion forum. Inspired by that and by different people with different characteristics that I’ve met in various capacities over the years, I decided to create a version called Code Warriors. The Code Warriors are personality types that you likely encounter when interacting with programmers.

Before I present the Warriors, I would like to make an aside about gender, given that this subject is often a sore one in the arena of programming. Almost all of the Warriors have genders assigned to them mainly so that Amanda has something to draw. If not for that, I might simply have made them androgynous. I mostly picked gender either randomly or based on the namesake of the warrior, when appropriate. So please don’t read any attempt at deeper meaning in the genders of the warriors–I’m looking to make no such commentary.

And now, the Warriors…


NeroNero fiddles while the code burns. You might have a show-stopping, mission-critical defect that everyone is in a frenzy to solve, and Nero is stamping his feet that the names of all TextBoxes in the application don’t end with “TextBox.” Your application might be a cesspool of singletons, globals, and cross-couplings, and Nero fires off angry emails about alphabetizing using statements/includes. You might have an unreadable, unapproachable stack of Jenga code, and Nero orders a massive refactoring to ensure that all block comments start at character twenty-six exactly on the line. Nero is generally a team lead or decision maker, though this is not strictly necessary. The defining characteristics of Nero are his complete inability to prioritize and his preoccupation with trivial matters. This is likely the result of being overmatched in his role and exerting some–any–manner of control of what’s happening around him. Like his namesake, Nero is probably not long for leadership one way (mutiny) or the other (complete failure and external intervention). If Nero is not promoted out of danger into a management role and is instead forced to continue in the trenches, possibly demoted, he may graduate to Nascar if he studies hard and learns a few tricks. When he does, he will hate other Neroes.

When he’s not programming: Organizing his pantry so that all can labels face outward, badgering patient waiters about the difference between “slightly browned medium rare” and “not quite medium.”
Chops: 1-3


LiferLifer has been programming at this company since you were in diapers and he’s still going to be doing it when your grandchildren are in diapers. He’s seen fads come and go for so long that he really doesn’t like the idea of any kind of change. If you propose change, he’ll be the first to say that it’s all been tried before and it will never work. He will then set about sabotaging your efforts and cite this sabotage later in post-mortems as proof that it’s pointless to try changing things. Lifer doesn’t need your fancy object-orientamation and text editors–he’s been making working software using a paperclip, a typewriter, and assembly code since 1974 and there’s no sense fixing what ain’t broke. Why a paperclip, you ask? Because screw you and mind your own business, that’s why. If you have any ideas of trying to outlast Lifer, you can just forget about it–he’ll never let the fact that he hates the company and his job interfere with staying there forever.

When he’s not programming: Screaming at neighborhood children to get off of his lawn, bemoaning the price of produce these days
Chops: 6 in theory, 2 in practice

Patient Zero

Patient ZeroImagine the following. You come to work one morning, and those in before you are scurrying around in panic or staring intently at their screens. Disconcerted, you perform your morning ritual of getting the latest version of the code, and things go wrong. Horribly wrong. The code won’t build. There are files suddenly missing. The source control system itself doesn’t seem to be working. The network connection is spotty. All hell has broken loose. After half a day of frenetic effort from the entire group, the issues are finally resolved, and after two days, the forensics are all in, indicating what went wrong. And what went wrong is what always goes wrong: Patient Zero. Patient Zero is the lady who is always breaking the build, failing merges, and generally creating havoc. You will hear her say things like “oh yeah, I saw that message about source control conflicts so I just clicked the ‘permanently wipe everything on the server and upload whatever crap I have’ button–hope that’s alright.” She will say these things with a goofy grin or an “aw shucks” expression that utterly defies belief and threatens to turn your face all colors of the rainbow as you suppress your rage. Whenever anything goes wrong–especially things that render everyone unable to work–there’s a near certain chance it’s the work of Patient Zero.

When she’s not programming: Blocking the box in busy intersections, presenting 742 coupons to the only grocery clerk open in the store
Chops: 2-3


ZorroIt’s pretty easy when looking at a code base to know whether Zorro has been through or not.  He writes decent enough code, but it has a certain style to it.  A very recognizable style.  This is because Zorro puts his name everywhere.  If he adds code to an existing method, he puts his initials in a comment above the line he changed, adds his initials to the method comment header, and, if it wouldn’t mean too much refactoring, he might even add his initials to the beginning of the method name itself.  In code bases where he does more than maintenance programming, there will be methods and classes named after him and naming schemes where everything starts or ends with his initials.   When other warriors stumble into a particularly Zorro-heavy section of the code, the vibe can be a bit like that moment in crime dramas where detectives enter a house and discover that the perfectly normal-seeming homeowner has erected a shrine to the victim in his attic.  They shudder and back away slowly, not yet ready to cope with the rich tapestry of psychological issues that led to this moment.  Zorro is generally competent enough and affable, but if he catches you de-Zorro-ing the codebase, his demeanor will cool noticeably.  Zorro is usually too weird to be allied with or against most other warriors, though Style Sergeant is often enraged by him.

When he’s not programming: Carving his name into public rest room stalls, poring over various social media and dating profiles, telling himself he could still wind up being famous
Chops: 3-6

Beer Thirty

BeerThirtyBro, you know what’s even better than programming time? Miller Time. Beer Thirty is a programmer by day and a beer-shotgunning machine by night (and sometimes by day also). And while most would prefer to keep those worlds separate, Beer Thirty (generally due to his young age) is not one of those people. No code review will slip by without a mention of beer pong conquests. No meeting will pass without apologies for being “a little out of it” today. No lunch will be eaten without Beer Thirty mentioning that it sucks that he can’t have like three Natty Lites with this burger, amirite?!?  Beer Thirty’s demeanor does serve to loosen things up and ease the tension among other, more serious warriors. Conferences and after-hours work events are where Beer Thirty really shines, though. Not to be confused with Mouthbreather, Beer Thirty might make women slightly uncomfortable with Beavis and Butthead style behavior, but he’s mainly in it for the booze. He actually has quite a substantial alcohol tolerance that serves as a buffer against behavior getting too over the top. Beer Thirty will usually get married and chill out, or else he’ll become a full-blown alcoholic, quietly slipping a little Bailey’s into his morning coffee rather than bragging about last night’s quarters domination down at Dirty Steve’s. Either way, there’s usually an upper age limit of twenty-seven or so on Beer Thirty.

When he’s not programming: Pub Crawls, Spring Break, Staring drunkenly at the coffee pot at Denny’s at 3:45 AM.
Chops: 3-7

Fake It ’til You Make It

FakeItTilYouMakeItFake It ’til You Make It is just your average workaday programmer that happens to like what he’s doing an awful lot.  He likes it so much so, in fact, that he tends to ramble on about it, and decides to let his passion for programming and rambling fuel a graduate degree via night school, endless reading, Pluralsight videos for fun, and even a blog.  Fake It ’til You Make It would probably stop all this and worry that he’s a phony, except that he’s usually distracted by excitement about and interest in his subject matter.  He does his best to understand and get along with all of the other warriors in the interest of learning and getting things done.

When he’s not programming: Writing about programming, writing about writing about programming, reading, getting his house’s lights to turn on and off from his phone
Chops: Never as high as he’d like


FashionistaFashionista’s preferences make the bleeding edge look like Betamax tape players. He’s known Ruby on Rails was yesterday’s news since 2005. Functional programming? Pff… maybe back in 2010. NoSQL? You must not have heard that it’s so last year to persist things to disk. No matter what your idea is or what new thing you’ve just discovered, Fashionista has heard of it, mastered it, and dismissed it. He is actually quite intelligent and good at what he does, but for him the goal of satisfying users or producing software that works takes a back seat to using whatever technology just came out, so he’s not especially effective in the trenches. Like some kind of misogynist caricature, Fashionista is principally interested in notching frameworks, paradigms, languages, etc. on his bedpost and laughing at people with fewer notches.  Fashionista is the mortal enemy of Lifer, and has the general ability to anger a good cross section of warriors, but, interestingly, if you put two Fashionistas in a room together their behavior is remarkably similar to Siamese Fighting Fish.

When he’s not programming: Going to Starbucks ironically to make disgusted noises at iPad/iMac users, cleaning T-shirts of bands that made it out of his closet
Chops: 8


GuruGuru is somewhere above the level of architect but still regarded as technical. She routinely speaks at company events and at developer conferences in general. She’s so famous and so well regarded that the young guys and gals often whisper among themselves that there is an Emperor’s New Clothes situation here. Surely she’s overrated, out-of-touch, or some kind of has-been. Every now and then some Grasshopper gets courageous enough to challenge her in some way, at which time she, politely and in good-natured fashion, blows their minds with some of the simplest, most elegant code you have ever seen. Doubters are mortified and even supporters are dumbfounded. Guru is Guru for a reason.

When she’s not programming: Speaking at conferences, advancing the cause of the industry, making people proud.
Chops: 10


JunkywardIf Junkyard is roaming around the office, you can generally smell him before you see him. If you’re walking by his desk, you’ll likely notice crumbs, takeout wrappers, and a sticky residue.  No stranger to audible flatulence, wiping his nose on his sleeve or spitting into empty containers at his desk, Junkyard is a hygiene disaster. He may also be Mouthbreather, but most likely not–he tends to be affable and a genuinely good-natured person, if hard to be around for… superficial reasons. His natural tendency to repel other human beings does free him up to have more time to pursue technical acumen, so he is, on average, slightly better at programming.

When he’s not programming: Sweating, eating, sweating while eating, lettin’ it all hang out.
Chops: 6-7

Brute Force

BruteForceBrute Force is well aware that inspiration strikes at the oddest of times in the oddest of places, and he knows that you have to just roll with it. It might occur to him that the source of recent performance issues in the code base is that people aren’t nulling out references. So Brute Force checks out every source file in existence and sets every variable to null everywhere he thinks it isn’t being used. In any managed language code bases, he does it twice for good measure. If he thinks that the application could benefit from more logging, he checks everything out again and adds logging to the beginning, middle, and end of every method in the entire code base. Are these things good ideas? No time to think about that–there’s a lot of work to do. Brute Force modifies every file in the code base first and asks questions later. Brute Force is often also Lifer and has usually defaulted his way into some position of authority, meaning he is allowed to run amok like Don Quixote through the code base.  He occasionally forms a temporary weekend alliance with Thor that results in the rest of the team coming in Monday morning to find every class in the code base wrapped in a facade.

When he’s not programming: Digging holes in his back yard and filling them back in, painting his entire house with a 1″ brush
Chops: 2-3


MacGuyverMacGuyver is a code-rescue specialist. There is no legacy system that he can’t tame, no environment too hostile, no project too far gone. Are you working on machine control software with no source control, no test environment, and the only way to make changes is to ram them into multi-million dollar production and hope for the best? No problem, just call in MacGuyver. He’s worked with less. He’s happy with any text editor, programming language, compiler, or anything else, even if he hasn’t used it before. MacGuyver could be described as a duct-tape programmer, in a sense, but he transcends that. If you plug him into a disaster, he’ll save it. If you plug him into a well-factored code base, he’ll improve it. If MacGuyver ever tires of the front lines, he probably has a career as Guru waiting for him.

When he’s not programming: Saving children from burning buildings, bringing justice to the world
Chops: 9-10

Ninja Assassin

NinjaAssassainThe Ninja Assassin is the most devastating imaginable combination of stealth and damage. He finds a way to check changes into the code base not detectable by any audit of the source control scheme or any log. But these aren’t just any changes. After he finishes, the code compiles and builds and there are no failing unit tests, but when it goes into production something goes wrong. Horribly, horribly wrong. Ninja Assassin has stolen into the code in the dead of night and killed it so cleanly that nobody even realized it was dead at first. The only difference between Code Warrior Ninja Assassin and his counterpart in other forms of fiction is that the Code Warrior is lethal purely through a combination of incompetence and exceptionalism fallacy.

When he’s not programming: Driving tipsy, sticking his hands out on rides that say “keep hands in at all times”.
Chops: 5 less than whatever he believes he is.


MouthbreatherMouthbreather had a hard time with girls** growing up. A really hard time. Such a hard time, in fact, that his struggles continue to this day as a result of a festering feedback loop of desperation, resentment, desire, and awkwardness. Mouthbreather is generally quite good at programming since he has had a lot of time and frustration to direct into perfecting his craft, but he’s unlikely ever to advance particularly far in his career. He gives everyone on the team the creeps, but especially the women. Over the course of time and lots of tense HR meetings, there is an uneasy equilibrium in which Mouthbreather is given solo assignments and allowed to work from home. A lot.

When he’s not programming: I don’t want to say and you don’t want to know.
Chops: 7-9

**Mouthbreather is not necessarily male or heterosexual, but I’ve yet to see a counter-example in the wild.

Big Sis’

BigSisBig Sis’ is the person in the department that helps preserve your sanity.  She’s generally a senior developer that isn’t necessarily in charge, but she’s good, she has pull, and most importantly, she’s actually nice and pleasant to work with.  When Nero is yelling at you about camel casing, Brute Force is hacking your classes to death and Lifer is griping about your use of syntax coloring, Big Sis’ is a breath of fresh air who comforts you, restores your faith in mankind, and shows you how to navigate the minefield of other warriors and their egos to be productive and write good code.  She has carved out enough reputation for herself that when she steps in to defend you, other warriors generally put down their torches and scatter, grumbling as they go.  Perhaps there is hope that being respected is better than being feared.

When she’s not programming: Volunteering at the local shelter, getting thoughtful presents for people.
Chops: 7-9


AnarchistAnarchist firmly believes that you can’t like own software. The only real software is free and open source software. To illustrate this point, she writes “Micro$oft” whenever given the opportunity and calls anyone owning Apple products a “fanboy” (or perhaps “fanboi”). Utterly disdainful of the notion that people might shell out money for convenience, Anarchist is convinced that the only reason someone would pay for software is because he’s too stupid or technically incompetent either to write it himself or make it happen from the Linux command line using regular expressions, sed, and a whole bunch of elbow grease. Any open source or free software developer who decides to turn entrepreneur and ask for money immediately makes Anarchist’s “Enemies List” because there is no greater betrayal in her world. Anarchist spends enough time reinventing wheels and cobbling together ill-suited products that she’s not terribly productive, but the flip side of this equation is that she is incredibly good.  Anarchist really has no allies among other warriors, though she and Fashionista have a grudging and reluctant respect for one another.

When she’s not programming: Thrift store shopping, spray painting people wearing fur coats, sneering.
Chops: 8-9


MoneyballMoneyball is obsessed with statistics about the code that he works on. He knows impressive-sounding terms, like, “Cyclomatic Complexity,” and “Afferent Coupling,” and he doesn’t hesitate to use them. Just as Nero might graduate to Nascar, Nascar may later graduate to Moneyball.  Moneyball is at the top of the “consider one factor at the exclusion of all others” food chain since his area of focus is actually pretty likely to improve code bases, but as long as he thinks any one characteristic of code and development always trump all others, there will be an upper bound to his chops.  Moneyball’s Achilles’ heel for improvement is his tendency to believe anything can be folded into statistics meaningfully–he isn’t interested in going out to lunch with coworkers to bond unless you can show him hard data that eating at Chipotle leads to at least a twelve percent increase in bonding as measured by voice inflection during afternoon meetings.

When he’s not programming: Playing twelve separate fantasy football teams, refreshing the stock ticker on CNN.com
Chops: 6-8

Style Sergeant

StyleSergeantStyle Sergeant is who Style Cop reports to, and, mister, she runs a tight ship.  Style Sergeant may be the architect/lead, or she may simply have gotten herself appointed to the role of some kind of auxiliary authority by one of those people.  Either way, she has a seventy-eight-page, single-spaced manual on styling for all situations, and if you think she doesn’t know every line of it by heart, you’re sorely mistaken.  There is no issue too trivial and no piece of originality and non-conformity too harmless to escape her exacting eye.  If you go over the maximum approved number of syllables for a class name or any method has more than the allotted number of the letter ‘T’ in its member variables, you’re going to get an earful.  Unfortunately for Style Sergeant, her authority is limited by pragmatism and she is something of a paper tiger, generally unable to enforce the severe consequences that she would prefer for violations.  If Dwight Schrute were a programmer, he would be Style Sergeant.  One would think that Nero and Style Sergeant would be natural allies, but it rarely turns out this way since Style Sergeant is motivated by a desire for conformity and Nero is driven by quirky obsessions.  They have an uneasy truce when Nero appoints Style Sergeant, but with any other arrangements, they battle bitterly (and comically) over placement of curly braces and the more arcane points of Hungarian notation.

When she’s not programming: Running for president of the condo association, complaining about the length of grass in other people’s yards
Chops: 2-4


GrasshopperGrasshopper is an engaged and hard-working warrior that is relatively new to the industry and something of a blank slate.  He may be entry level or have simply gotten into the programming game recently.  Interested in learning, working hard, and getting better, Grasshopper has a natural tendency to want to learn as much as he can from coworkers and peers.  This can turn out great when those mentor figures are Guru, Big Sis’ or MacGuyver, but there’s always the danger of Nero or Lifer converting him to the Dark Side.  Grasshoppers and their impressionability wind up having a lot to say in the fate of departments over the course of time.

When he’s not programming: Reading, teaching himself new things, having “aha!” moments
Chops: 2-5, but with very high eventual upside

General Custer

GeneralCusterLooking out over a battlefield where most would see hopelessness and back away, General** Custer sees certain victory and charges. Unlike his namesake, his field of combat is not the battlefield but rather the corporate meeting room, where he fearlessly champions untenable positions and demonstrably wrong matters of fact. He will argue that all conditions must go in separate if statements because there is no such thing as “short circuiting.” He will confidently assert that null and zero are the same concept in all languages. He will look at compiling code or passing unit tests and state that the code won’t compile and the tests won’t pass. Like the actual figure in American history, General Custer holds a position of authority to the detriment and disbelief of his subordinates and, like the same figure, he will most likely lead them to technical disaster in spite of their noble efforts to reign him in. General Custer has an opinion on every matter regardless of understanding as he is never one to let failing to understand something prevent him from telling others how it works.  A standoff between Custer and Fashionista, Anarchist, or Guru can be particularly dreadful to watch and Big Sis’ or Beer Thirty must often intervene to preserve decorum.

When he’s not programming: Getting lost on road trips, losing fights to bouncers, coming in last in the football pool.
Chops: 3-4

** I realize that Custer was not actually a general during the ill-fated Little Bighorn campaign, but this is how he is best known and I’m not writing a history textbook.


NascarNascar feels the need for speed. Everything he does is done ostensibly in the name of performance improvement, whether or not it actually has that effect. But Nascar’s approach goes beyond simple premature optimizing or just thinking, “how could we make things faster”–it’s a design philosophy. Making code readable, well-written, correct or possible to reason about is a luxury that simply cannot be afforded in “well-performing” code. Things like Linq or closures or managed languages or even C and C++ are just creature comforts for wusses that are afraid to be close to the metal. If this web service file import is going to really be screaming fast, every picosecond of server processing time counts. If you mention sequential bottlenecking, Nascar will become confused and then enraged, and suggesting actual time trials of pieces of code will just make things worse.  Nascar and Nero are actually kindred spirits, though Nascar has better chops and a slightly more legitimate preoccupation. Interestingly, however, they tend to be at one another’s throats since Nascar proudly and vocally eschews readability and Nero is focused entirely on the aesthetics of the source code.  More formidable warriors mainly just ignore Nascar.

When he’s not programming: Downing a special espresso-Redbull cocktail that he’s known for, trying to overclock his microwave
Chops: 3-6


PawnUnimaginative, timid, and incurious, Pawn does whatever he is told, no matter what.  A less compliant warrior might hesitate and ask for clarification if a superior made a typo in an email such as “make sure the constructor of the main window does throw an exception no matter what.”  Not Pawn.  He’ll just throw that exception and ship the code.  At first, managers tend to appreciate and praise Pawn for being a “team player,” but they figure out relatively quickly that they’ve actually hired Siri in human form.  Nobody knows whether Pawn is secretly brilliant and completely pliant or utterly inept and, well, completely pliant.  It doesn’t really matter either way.  Pawn is mostly harmless, but can easily be purposed for pointless or destructive tasks by warriors like Nero, Nascar, and Brute Force.

When he’s not programming: Buying extended warranties, looking after the kids while his wife takes his credit card and three of her friends to Vegas once a month.
Chops: 1

Romance Author

DanielleSteeleLike her namesake, Romance Author is recognizable in two ways for her contributions to your group’s source control: high volume and low quality. You gape in stark awe at her ability to churn out a 14,000 line class in twenty minutes. Does she use some kind of code generator? Is she a wizard with copy and paste? How is it possible? And what is… is that a… is that an infinite while loop with no body at all?!? And that over there… does that method really have sixty-two parameters?!? And this, how does it even compile?!? All of these questions abound as you stare in wonder and terror at the reams and reams of code she produces. Sometimes other warriors will intervene to try to stem the tide, but management generally looks at her lines-of-code-per-hour metric and concludes that she should be allowed to work unencumbered as she is the most productive group member.  Style Sergeant and Nero tend to hate her, but they’re generally overmatched by the sheer volume of her output.

When she’s not programming: Stocking up at garage sales, clogging your inbox with email forwards
Chops: 1-2


ThorIn Norse mythology, Thor is big and strong, and he has a hammer. In the programming world, Thor just has a hammer. A golden hammer. And Thor thinks that all problems are nails. The nature and shape of the hammer may be different from Thor to Thor, but the reasoning is the same. Need to ensure that there’s only one user session at a time? Singleton. Need to sort a data set dynamically by a property at runtime? Singleton. Need to reason about a complex thread interleaving? Singleton. Need to have exactly twelve instances of an object and no global point of access? Singleton. Everything can be answered with “Singleton,” at least until Thor turns the page in the Gang of Four book and realizes that all of the aforementioned problems are really calling for Adapters. It’s easy to think of Thor as purely a hack, but credit must be given to someone so adept and inventive at cramming square pegs into round holes.  Thor’s only natural ally is Nascar, provided Thor’s latest kick is performance improvements.  Outside of this, he operates orthogonally to aesthetics-oriented warriors and to the quiet amusement and derision of Anarchist and Fashionista, who view his fumbling as ironically endearing.

When he’s not programming: Using Kanban to organize his toiletries, banging on his DVD player to get it to work
Chops: 4-6


Bringing Entry Level Programmers up to Speed

Welcome Aboard, New Grad

I recently answered a question on programmer Stack Exchange, and it got me to thinking. The premise of the question was (paraphrased), “we hired a bunch of entry level people as an investment in tomorrow but we’re not quite sure what to do with them today–what do you think?” The most popular answers at a glance appeared to be along the lines of “give them tiny features, let them fix defects, have them read documentation, etc.” My reaction to this (and hence my response) was a sense of vague disquiet, with the exception of the “have them read documentation,” which made me throw up a little in my mouth at the thought that one might learn to do something by reading some hastily-written, outdated, often tautological body of desiccated text written by someone being told to do so on pain of corporate demerits. “Welcome to the company, Bill, but before you get started talking at meetings, why don’t you read this dictionary from 1924 to get a feeling for public speaking. Really focus on ‘S’ because a lot of words seem to start with that one.”

But I digress. The point of the discussion is to figure out what to do with the juniors. A common point of consensus is to spoon feed them small tasks so that they notch a series of wins and gain some confidence. One common example that I’ve seen prescribed for juniors (and sometimes new mid-level or senior developers for that matter) is “go and fix some defects.” Apart from the documentation, this is the one that really bothered me, and I couldn’t quite figure out why. So I left the Stack Exchange page open and went to go brush my teeth and get ready for bed. Halfway through brushing my teeth, it hit me like a bolt of lightning–so much so that I’m sitting here typing this sentence with my toothbrush dangling from my mouth.

GiantMosquitoThe problem I have with starting newbies (and especially entry level people) with defect fixing is that you’re saying to them, “Welcome aboard! Now go get an eyeful of the worst that our code base has to offer.” I mean, ipso facto, you’re sending them off to track down things that don’t work, and the source of things that don’t work is wrong and often bad code. Think about your code base or code bases you’ve seen before. Where do the defects hang out? Are you going to be showing these newbies heavily unit tested utility classes or the polished pieces of code, or are you arming them with a dull machete and sending them off to fend for themselves in the dense underbrush of some monstrous, almost-but-not-quite-threadsafe singleton? Watch out for the mosquitoes, heh heh! (But seriously, you could actually potentially get malaria from this code.)

Isn’t that sort of fundamentally backward and maybe even a touch demented when you get right down to it? If you come to me and tell me you want to learn to dance, I don’t get really drunk, stumble around and tell you to point out what I’m doing wrong. And like trying to decipher the patterns and motivations of drunks, there’s really no value in trying to understand bad code. There’s a downside, in fact. Programmers who are introduced to software development in this fashion learn to love debugger. They’re going to learn programming by coincidence and become very proficient at tweaking variables and coaxing the execution flow into various blocks and around various exceptions. Before you know it, they’ll be checking in fixes with weird, unpredictable, and far-reaching consequences because they’re learning from badly written code how to push the dirty mop water around to check this defect off the list. And as for the other defects they’re introducing–well, that’ll just give them more to work on later so they won’t be bored to tears reading your obsolete documentation.

If Not Documentation and Defects, Then What?

I once worked in a shop where the development manager had gone through a few iterations of how to bring new people on board. He eventually settled on what I considered to be an excellent approach. He would have new developers dump a version of the code from source control and give them a dummy assignment. In this assignment, they would have to implement a feature that was pretty representative of the kinds of features that other developers implemented in reality and one that had them touch a pretty large cross-section of the code base. This was purely an exercise. The work was tossed at the end, but they got good experience and meaningful feedback with zero risk.

I had the good fortune to watch this state of affairs develop, and my firsthand impression was that the developers who implemented this bogus feature were ready for prime time much more quickly than previous onboarding sessions where people were encouraged to read sparse documentation, fix defects, etc. This actually worked, and it wasn’t demotivational or boring. The only drawback is that there might have been a bit of a tendency to loaf, as the newbies knew from the get-go they weren’t implementing a real feature. I always wondered how it might have gone to let them think it was real until the end and feedback stage.

I consider this an excellent example of a productive thing to do with new developers, especially entry level ones. Yes, I’m serious that working on a throwaway feature is productive. Sure, it won’t be shipped and their initial time isn’t contributing to the bottom line, but then again, neither is documentation. And defect fixing is really a crapshoot since they’re just as likely to use their dull machete accidentally to hack off the arm of another programmer as they are to chop down a defect successfully. If there’s a fifty percent chance of marginally positive productivity and a fifty percent chance of marginally negative, you’re right back at square one.

Here are some other activities that you can give to entry level developers right away to help them get up to speed quickly and contribute meaningfully:

  1. Teach them to unit test and task them with getting (meaningful) coverage over legacy code.  There’s no better way to see how the code actually works, the automated test suite grows, and this is a virtually no-risk activity.
  2. Have them write documentation–not read it.  I consider this fundamentally inferior to having them write tests, but it’s certainly better than putting them to sleep with documentation reading that will mean nothing to them.  In order to write about something, you need some degree of understanding.  (In the end, you can probably toss what they’ve written since it will just become obsolete anyway. Value the knowledge they’ve acquired instead.)
  3. Pair them with a senior developer and start them out watching one hundred percent of the time. Start ratcheting that figure down by five percent or ten percent every few days until they’re writing code and getting immediate feedback.  The drain on the senior’s time will prove worth it in the long haul.
  4. Turn them loose to try their hand at actual feature development (making sure they get quick and helpful feedback–daily or more).  The worst case scenario, assuming that you have a sane source control paradigm, is that you discard their work and they learn a lot from their failure.  Best case scenario is that they rise to the task.

If you have more ideas for what to do with newbies besides these, I’m interested to hear.  I have no doubt that there are more approaches and good ideas out there.  I’d just like to encourage anyone reading not to underestimate the new hires and risk boring them into leaving.  I’d also like to encourage anyone reading not to throw them in them right into the trenches with the carnage in your code base and traumatize them into bad habits and cynical outlooks.  Invest in them, encourage them to try and fail, mentor them, and make sure you provide quick and meaningful feedback.  I promise you that you won’t be sorry in the end.