DaedTech

Stories about Software

Mar
8

By

Don’t Take My Advice

Category: The Life of a Programmer Tags: , | 5 Comments

A Brief History of My Teeth

When it comes to teeth, I hit the genetic jackpot. I’m pretty sure that, instead of enamel, my teeth are coated in some sort of thin layer of stone. I’ve never had a cavity and my teeth in general seem impervious to the variety of maladies that afflict other people’s teeth. So this morning, when I was at the dentist, the visit proceeded unremarkably. The hygienist scraped, prodded, and fluoridized my teeth with a quiet efficiency, leaving me free to do little but listen to the sounds of the dentist’s office.

HygienistThose sounds are about as far from interesting as sounds get: the occasional hum of the HVAC, people a few rooms over exchanging obligatory inanities about the weather, coughs, etc. But for a brief period of time, the hygienist in the next station over took to scolding her patient like a child (he wasn’t). She ominously assured him that his lack of flossing would catch up to him someday, though I quietly wondered which day that would be, since he was pushing retirement age. I empathized with the poor man because I too had been seen to by that hygienist during previous visits.

The first time I encountered her a couple of years ago, she asked me if I drank much soda, to which I replied that I obviously did since my employer stocked the fridge with it for free. I don’t drink coffee, so if I want to partake in the world’s most socially acceptable upper to combat grogginess, it’s Diet Pepsi or Mountain Dew for me. She tsked at me, told me a story of some teenager whose teeth fell out because he had a soda fountain in his basement, and then handed me a brochure with pictures of people’s mouths who were apparently ravaged by soda to such a state where I imagine that the only possible remedy was a complete head transplant. My 31 year steak of complete imperviousness to cavities in spite of drinking soda was now suddenly going to end as my teeth fell inexorably from my head. That is, unless I repented my evil ways and started drinking water and occasionally tea.

I agreed to heed her advice in the way that one generally does when confronted with some sort of pushy nutjob on a mission–I pretended to humor her so that she would leave me alone. When I got home, I threw out the Pamphlet of Dental Doom and didn’t think about her for the next six months until I came back to the dentist. The first thing that she asked when I came in was whether I was still drinking a lot of soda or not. I was so dumbfounded that I didn’t have the presence of mind to lie my way out of this confrontation. I couldn’t decide whether it’d be creepier if she remembered me from six months ago and remembered that I drank a lot of soda or if she had made herself some kind of note in my file. Either way, I was in trouble. The previous time she had been looking to save the sinful, but now she was just pissed. Like the man I silently commiserated with this morning, she proceeded to spin spiteful tales of the world of pain coming my way.

Freud might have some interesting ideas about a person that likes to stick her fingers in other people’s mouths while trying to scare them, and I don’t doubt that there’s a whole host of ground for her to cover on the proverbial therapist couch, but I’ll speak to the low hanging fruit. She didn’t like that I ignored her advice. She is an expert and I am an amateur. She used her expertise to make a recommendation to me, and I promptly blew it off, which is a subtle slap in the face should an expert choose to view it that way.

It Isn’t Personal

It’s pretty natural to feel slighted when you offer expert advice and the recipient ignores it. This is especially true when the advice was solicited. I recall going along once with my girlfriend to help her pick out a computer and feeling irrationally irritated when we got to the store and she saw one that she liked immediately, losing complete interest in my interpretation of the finer points of processor architectures and motherboard wiring schemes. I can also recall it happening at times professionally when people solicit advice about programming, architecture, testing, tooling, etc. I’m happy–thrilled–to provide this advice. How dare anyone not take it.

But while it’s often hard to reason your way out of your feelings, it’s a matter of good discipline to reason past irrational reactions. As such, I strive not to take it personally when my advice, even when solicited, goes unheeded. It’s not personal, and I would argue it’s probably a good sign that the members of your team may be nurturing budding self-sufficiency.

Let’s consider three possible cases of what happens when a tech lead or person with more experience offers advice. In the first case, the recipient attempts to heed the advice but fails due to incompetence. In the second, the recipient takes the advice and succeeds with it. In the third and most interesting case, the recipient rejects the advice and does something else instead. Notice that I don’t subdivide this case into success and failure. I honestly don’t think it matters in the long term.

In the first case, you’re either dealing with someone temporarily out of their depth or generally incompetent, who might be considered an outlier on the lower end of the spectrum. The broad middle is populated with the second case people who take marching orders well enough and are content to do just that. The third group also consists of outliers, but often high-achieving ones. Why do I say that? Well, because this group is seeking data points rather than instructions. They want to know how an expert would handle the situation, not so that they can copy the expert necessarily, but to get an idea. Members of this group generally want to blaze their own trails, though they may at times behave like the second group for expediency.

But this third group consists of tomorrow’s experts. It doesn’t matter if they succeed or fail in the moment because, hey, success is success, but you can be very sure they’ll learn from any failures and won’t repeat their mistakes. They’re learning lessons by fire and experimentation that the middle-of-the-roaders learn as cargo cult practice. And they’re not dismissing your advice to offend you–they earnestly want to understand and assimilate your expertise–but rather to learn from you.

So when this happens to you as a senior team member/architect/lead/etc., try to fight the urge to be miffed or offended and exercise some patience. Give them some rope and see what they do–they can always be reigned in later if they aren’t doing well, but it’s hard to let the rope out if you’ve extinguished their experimental and creative spirit. The last thing you want to be is some woman in a dentist’s office, getting irrationally angry that adults aren’t properly scared of the Cavity Creeps.

Feb
13

By

The Council of Elders Anti-Pattern

Category: The Life of a Programmer Tags: , | 2 Comments

Convene the High Council

Today I’d like to talk about something that I’ve observed on some occasions throughout my career. It sort of builds on the concepts that I’ve touched on in previous writings “How to Keep your Best Programmers” and the Expert Beginner posts, including Bruce Webster’s “Dead Sea Effect.” The phenomenon is an anti-pattern that is unique to shops with fairly mature Dead Sea/Expert Beginner presences, and I’ll call it “Council of Elders.”

To understand what I mean by this, let’s consider what happens in an organization with a more vital software group full of engaged, competent, and improving engineers and not bogged down in the politics and mediocrity of seniority-based advancement. In such a group, natural divisions of labor emerge based on relative expertise. For example, you might have an effective team with the “database guy” and the “architecture gal” and “markup guru” and the “domain knowledge expert” or some such thing. Each resident expert handles decision making within his or her sphere of influence and trusts other team members to likewise do the right thing in their own areas of strength. There might be occasional debate about things that blur the lines or occur on the boundary between two experts, but that’s just part of a healthy group dynamic.

And truly, this is a healthy group. There is no dead weight, and all of the group members have autonomy within a subset of the work that is done, meaning that people are happy. And that happiness breeds mutual trust and productivity. I’m oversimplifying and prettying up the counterexample a bit, but it really is something of a virtuous cycle with team members happily playing to their own strengths and areas of interest.

TheCouncilBut what happens in particularly salty Dead Sea shops where authority comes neither from merit nor from expertise, but rather from tenure with the company? What happens when the roost is ruled by Expert Beginners? Well, for one thing, the lords and ladies here tend to guard their fiefdoms more jealously since expertise on the part of others is more threat than benefit. Perhaps more importantly and broadly, however, knowledge and expertise are devalued in favor of personal politics and influence with debates being won on the basis of “who are you and how loud/charming/angry/glib/etc. are you” rather than on the merit of ideas. The currency of Dead Sea departments is everything but ideas–in benevolent ones, it may be “how long have you been here” or “how nice a person are you,” and, in “high pressure culture” ones, it might simply be psychopathy or other cutthroat forms of “might makes right.” And with evaluation of ideas out the window, every council member is freed to hold forth as an expert on every topic, regardless of how much or little he knows about that topic. Nobody is going to dispute anything he says–non-members are cowed into submission and fellow members recognize the importance of putting on a unified public front since they want to be be able to do the same without being questioned.

If you put this political yeast in the oven and let it rise, some of the results are fairly predictable: idea stagnation, increasingly bone-headed solutions to problems, difficulty keeping talent, etc. But an interesting consequence isn’t necessarily intuitive–namely that you’ll wind up with a kind of cabal of long-tenured people that collectively make all decisions, however big or small. I call this the “Council of Elders,” and it’s like one of those Magic Eye paintings that’s hidden but couldn’t be more obvious once you see it.

The Council of Elders is sort of like the Supreme Court of the department, and it’s actually surprisingly democratic as opposed to the more expected ladder system which ranks people by years and months with the company (or if you’re a fan of The Simpsons, the system in the Stonecutters episode where all members of the club are assigned a numeric rank in the order of joining, which determines their authority). The reason that it’s democratic is that actually assigning rank based on years/months of tenure would unceremoniously poke a hole in any illusion of meritocracy. So the council generally makes entrance to the club a matter of tenure, but status within the club a shifting matter of alliances and status games once past the velvet rope.

The Council is fundamentally incapable of delegation or prioritization of decision making. Since entrance is simply a matter of “paying your dues” (i.e. waiting your turn) and largely earned by Expert Beginners, it’s really impossible to divide up decision making based on expertise. The members tend to be very good at (or at least used to) company politics and procedures but not much else. They mostly have the same ‘skill’ set. The lack of prioritization comes from the main currency in the group being status. If a decision, however small, is made by someone not on the Council, it threatens to undermine the very Council itself, so a policy of prevention is adopted and any attempts at circumvention are met with swift and terrible justice (in the form of whatever corporate demerits are in place).

Recognizing Your Elders

What does this council look like in the wild, and how do you know if one is pulling your strings? Here’s a set of symptoms that you’re being governed by a Council of Elders:

  • In any meeting convened to make a decision, the same group of people with minor variants is always present.
  • Members of the software group are frequently given vague instructions to “talk to so and so before you do anything because his cousin’s dog’s trainer once did something like that or something.”
  • There is a roster, emailed out or tacked up, of people who can “clear” you to do something (e.g. they give code reviews, approve time spent, etc.)
  • Sparks fly when something wasn’t “cleared” with someone, even when a few others “approved” it and it has apparently nothing to do with him. “Someone should have told me.” More than one or two people like this and you have a Council.
  • People in the group often feel caught between a rock and a hard place when involved in the political posturing of the Council (e.g. Yoda tells the intern Padiwan to implement the new hours tracking app using SQL Server, but then Mace Windu screams at him that this is a MySQL shop–the Council settles this matter later with no apologies)
  • There is a junta of team members that seem to do nothing but shuffle from meeting to meeting all day like mid-level managers.
  • There are regular meetings viewed by newbies and junior developers as rites of passage.

These are just easy ways to detect Councils in their natural habitat: “where there’s smoke, there’s fire” situations. But lest you think that I’m trying to paint every software department with senior developers that go to meetings with this brush, here is a list of specific criteria — “minimum Council Requirements,” if you will:

  • Lack of clearly defined roles on the group/team or else lack of clear definition for the assigned roles (e.g. there is no ‘architect’ or if there is, no one really knows what that means).
  • A “dues paying” culture and promotions, power and influence largely determined by length of tenure.
  • Lack of objective evaluation criteria of performance, skill and decision-making acumen (i.e. answers to all questions are considered subjective and matters of opinion).
  • Proposed changes from above are met with claims of technical infeasibility and proposed changes from juniors/newbies or other groups are met with vague refusals or simply aren’t acknowledged at all.
  • Actions of any significance are guarded with gatekeeper policies (official code reviews, document approval, sign-off on phases, etc).
  • Line manager tacitly approves of, endorses or is the product of the Council.
  • A moderate to large degree of institutional bureaucracy is in place.
  • New technologies, techniques, approaches, etc are met systematically with culturally entrenched derision and skepticism.

Not a Harmless Curiosity

At this point, you might think to yourself, “So what? It might not be ideal, but rewarding people with a little gratifying power in exchange for company loyalty is common and mostly harmless.” Or perhaps you’re thinking that I’m overly cynical and that the Council generally has good advice to dispense–wisdom won in the trenches. Of course all situations are different, but I would argue that a Council of Elders has a relatively noticeable and negative effect on morale, productivity, and general functioning of a group.

  • The Council is a legitimate bottleneck in its micromanagement of other team members, severely hampering their productivity even with the best assumption of its judiciousness
  • A group of people that spends all its time debating one another over how to rule on every matter doesn’t actually get much work done. The SCOTUS, for example, hasn’t represented a lot of clients lately, but that’s because their job is to be a ruling council–yours probably has titles like, “Senior Software Engineer.”
  • People lacking expertise but put in positions of authority tend to overcompensate by forming strong opinions and sticking to them stubbornly. A room full of people meeting this criterion is going to resemble the US House of Representatives with its gridlock more than a software team.
  • Major problems are likely to languish without solutions because the committee doesn’t do much prioritizing and is likely to be sidetracked for a few days by the contentious issue of what color to make the X for closing the window.
  • Important decisions are made based on interpersonal dynamics among the council rather than merit. Jones might have the best idea, but Jones shorted the check at lunch that day, so the other Council Members freeze him out.
  • Councils make it hard to give meaningful roles or titles to anyone and thus give rise to preposterous situations in which departments have eight ‘architects’ and five developers, or where a project manager decides what database to use while a DBA writes requirements. If everyone on the Council has authority and is an expert at everything, project roles are meaningless anyway.
  • Even under the best circumstances, democratic voting on software design trends toward mediocrity: see Design by Committee Anti-Pattern
  • People toiling away under the rule of a Council, if they don’t leave, will tend to wind up checked out and indifferent. Either that, or they’ll be assimilated into the Council culture.
  • The Council is a natural preservation agent of the Dead Sea problem. Being micromanaged by a team of people whose best qualification is being around for a while and negotiating power will separate the wheat from the chaff, but not in the good way.
  • The only thing that unites the Council is outside threats from above or below. If managers or newer members want change, the Council will lock together like a Praetorian Legion to preserve the status quo, however dysfunctional that may be.
  • Suggestions for improvement are construed with near universality as threats.

If you’re in a position to do so, I’d suggest breaking up the cartel. Figure out what people are good at and give them meaningful roles. Keep responsibilities divided, and not only will autonomy become more egalitarian, but also people tenured and new alike will develop complementary skills and areas of expertise. With people working together rather than forming shifting alliances, you’ll find prioritizing tasks, dividing up work, and getting things done becomes easier. The Council’s reptile brain will take over and it will fight you every step of the way when you try to disband it, but once you do, it will be good for everyone.

Feb
8

By

Wherefore Thou Shalt Fail at Software Requirements

Category: The Life of a Programmer, Uncategorized Tags: , | 6 Comments

On Being Deliberately Unclear

For whatever reason lately, I’ve been drawing a lot of inspiration from Programmers’ Stack Exchange, and today brings another such post. However, unlike other questions, reading this one seriously made me sad. The questions, the answers, its existence… all of it made me sad in the same kind of way that it’s vaguely depressing to think of how many hours of our lives we lose to traffic jams.

I had a conversation with a coworker once that involved a good-natured disagreement over the role of legalese in our lives. My (cynical) contention was that legalese has evolved in purpose–has even self-bastardized over the years–to go from something designed to clarify communication to something that is specifically used to hinder communication. To put it another way, by freezing the language of law in pedantic and flowery period-speak from the 18th century, lawyers have effectively created a throwback to the feudal practice of having a language for the nobles and a different language for the commoners. This language of the lawmaking nobles builds a bit of social job security in a way that writers of inscrutable code have picked up on–if you make it so no one understands your work and yet everyone depends on your work, then they have no choice but to keep you around. (Lawyers also have the benefit of being able to make laws to force you to need lawyers, which never hurts.)

My colleague appropriately pointed out that the nature of jurisprudence is such that it makes sense for lawyers to phrase things in documents in such a way that they can point to decided case law as precedent for what they’re doing. In other words, it’s ironically pragmatic to use language that no one understands because the alternative is that you write it in language less than 200 years old but then have to systematically re-defend every paragraph in various lawsuits later. I conceded this as a fair point, but thought it pointed to a more systemic flaw. It seems to me that any framework for bargaining between two parties that inherently makes communication harder is, ipso facto, something of a failure. He disagreed, being of the opinion that this old language is actually more precise and clear than today’s language. At this point, we agreed to disagree. I’ve since pondered the subject of language rules, language evolution, and precision. (As an aside, this bit of back-story is how the conversation went to the best of my recollection, so the details may be a little rough around the edges. It is not my intention to misrepresent anyone’s positions.)

Requirement Shock and Awe

Because of this pondering, my strange brain immediately linked the SE post with this conversation from some months back. I worked for a company once where the project manager thunderously plopped down some kind of 200-page Word document, in outline form, that contained probably 17,000 eerily and boringly similar statements:

  • 1.17.94.6b The system shall display an icon of color pink at such time as the button of color red button is clicked with the pointing device commonly known as a “mouse.”
  • 1.17.94.6c The system shall display an icon of color pink at such time as the button of color red is clicked with the pointing device commonly known as a “mouse,” 1st planet from Sol, Mercury, spins in retrograde, and the utilizer utilizes the menu option numbering 12.
  • 1.17.94.6d The system shall display an icon of color mauve at such time as the button of color purple is clicked with the pointing device commonly known as a “mouse.”
  • 1.17.94.6e The system shall require utilizers to change their underwear every half hour.
  • 1.17.94.6f The system shall require utilizers to wear underwear on the outside of their pants so that it can check.
  • 1.17.94.6g The system shall guarantee that all children under the age of 16 are now… 16.
  • 1.17.94.6h The system shalt not make graven images.

YeRequirements2A week later, when I asked a clarifying question about some point in a meeting, he furrowed his brow in disappointment and asked if I had read the functional-requirement-elaboration-dohickey-spec-200-pager, to which I replied that I had done my best, but, much like the dictionary, I had failed at complete memorization. I stated furthermore that expecting anyone to gain a good working understanding of the prospective software from this thing was silly since people don’t picture hypothetical software at that level of granularity. And besides, the document will be woefully wrong by the time the actual software is written anyway.

While I was at it with the unpopular opinions, I later told the project manager (who wasn’t the one that wrote this behemoth–just the messenger) that the purpose of this document seemed not to be clarity at all, but a mimicking of legalese. I gathered that the author was interested primarily in creating some kind of “heads I win, tails you lose” situation. This juggernaut of an artifact assured that everyone just kind of winged it with software development, but that when the barrel crashed at the bottom of the Waterfall, the document author could accuse the devs of not fulfilling their end of the bargain. Really, the document was so mind-numbing and confusing as to make understanding it a relative matter of opinion anyway. Having gotten that out in the open, I proceeded to write software for the release that was ahead of schedule and accepted, and I never looked at the intimidating requirements encyclopedia again. I doubt anyone ever did or will if they’re not looking for evidentiary support in some kind of blame game.

Well, time went by, and I filed that bit of silliness under “lol @ waterfall.” But there had been a coworker who was party to this conversation that mentioned something about the RFCs, or at least the notion of common definition, when I had been on my soapbox. That is, “shall” was used because it meant something specific, say, as compared to “will” or “might” or “should.” And because those specific meanings, apparently defined for eternity in the hallowed and dusty annals of the RFC, will live on beyond the English language or even the human race, it is those meanings we shall (should? might? must?) use. I mention these RFCs because the accepted answer to that dreadful Stack Exchange question mentioned them, clearing up once and for all and to all, including Bill Clinton, what the definition of “is” is (at least in the case of future tenses simple, perfect, continuous, and perfect continuous).

The only problem is that the RFCs weren’t the first place that someone had trotted out a bit of self-important window-dressing when it came to simple verb usage. Lawyers had beaten them to the punch:

First, lawyers regularly misuse it to mean something other than “has a duty to.” It has become so corrupted by misuse that it has no firm meaning. Second—and related to the first—it breeds litigation. There are 76 pages in “Words and Phrases” (a legal reference) that summarize hundreds of cases interpreting “shall.” Third, nobody uses “shall” in common speech. It’s one more example of unnecessary lawyer talk. Nobody says, “You shall finish the project in a week.” For all these reasons, “must” is a better choice, and the change has already started to take place. The new Federal Rules of Appellate Procedure, for instance, use “must,” not “shall.”
…

“Shall” isn’t plain English… But legal drafters use “shall” incessantly. They learn it by osmosis in law school, and the lesson is fortified in law practice.

Ask a drafter what “shall” means, and you’ll hear that it’s a mandatory word—opposed to the permissive “may”. Although this isn’t a lie, it’s a gross inaccuracy… Often, it’s true, “shall” is mandatory… Yet the word frequently bears other meanings—sometimes even masquerading as a synonym of “may”… In just about every jurisdiction, courts have held that “shall” can mean not just “must” and “may”, but also “will” and “is”. Increasingly, official drafting bodies are recognizing the problem… Many… drafters have adopted the “shall-less” style… You should do the same.

Bringing things back full circle, we have lawyers misusing a variant of “to be”–one of the most basic imaginable concepts in the English language–in order to sound more official and to confuse and intimidate readers. We have the world’s middle manager, pointy-haired types wanting to get in on that self-important action and adopting this language to stack the deck in CYA poker. And, mercifully, we have a group defining the new Federal Rules of Appellate Procedure who seems to value clarity over bombastic shows of rhetorical force designed to overpower objections and confuse skeptics. On the whole, we have a whole lot of people using language to impress, confuse, and intimidate, and a stalwart few trying to be precise.

A Failure of Both Clarity and Modernity

But believe it or not, the point of this post isn’t specifically to rag on people for substituting the odd “utilize” for “use,” sports-announcer-style, to try to sound smart. From academia to corporate meetings to dating sites (and courtrooms and requirements documents), that sort of thing is far too widespread for me to take it as a personal crusade. It might make me a hypocrite anyway to try. My point here is a more subtle one than that, and a more subtle one than pointing out the inherent, RFC futility of trying to get the world to agree to some made up definitions of various tense forms of “to be.”

The meat of the issue is that using slightly different variants of common words to emphasize things is a very dated way of defining requirements. Think of this kind of nonsense: “well… shall means that it’s the developer’s responsibility, but shalt means that it’s an act of God, and will means that project management has to help, and optional means optional and blah, blah blah…” What’s really going on here? I’d say what’s happening is some half-baked attempt to define concepts like “priority” and “responsible party” and “dependency.” You know, the kind of things that would do well, in, say, a database as fields. Pointy-haireds come for the semantic quibbling and they stay for the trumped-up buzz speak, so it winds up being harder than it should be to move away from a system where you get to bust out the fine verbal china and say impressive sounding things like “shall.”

The real problem here is that this silliness is a holdover from days when requirements were captured on Word Documents (or typewriters) as long, flowery prose and evaluated as a gestalt. But with modern ALM systems, work items, traceability tools, etc., this is colossal helping of fail. Imagine a requirement phrased as “when a user clicks the submit button, a JSON message is sent to the server.” That string can sit in a database along with a boolean that’s set to true when this accurately describes the world and false when it doesn’t. You want priority? How about an integer instead of bickering over whether it should be “JSON message {shall, will, ought to, might, mayhap, by-Jove-it-had-better, shalt, may, etc.} sent to the server”? When you’re coding, it’s an anti-pattern to parse giant chunks of text in a database field, so why isn’t it considered one to do it during requirements definition?

We have far better tools for capturing and managing requirements than word processors, pointless arguments over misappropriated grammar, standards used to define ARPANET in the 60’s, and polyester bell-bottoms. It’s 2013, so let’s not define and track requirements like it’s 1999… or 1969. Ditch the RFCs, the waterfall, the BS Bingo talk, and the whole nine yards if you want to get things done. But if you’d prefer just to focus on figuring out who to blame when you fail, then you should/shall/will/must/might/shalt not change a thing.

Jan
22

By

The Code Warriors

Category: The Life of a Programmer Tags: | 16 Comments

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…

Nero

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

Lifer

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

Zorro

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

Fashionista

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

Guru

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

Junkyard

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

MacGuyver

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.

Mouthbreather

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

Anarchist

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

Moneyball

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

Grasshopper

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.

Nascar

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

Pawn

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

Thor

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

Jan
21

By

Bringing Entry Level Programmers up to Speed

Category: The Life of a Programmer | 2 Comments

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.

« Older Posts
Newer Posts »