Stories about Software


Prove It

I’m thinking this is going to wind up being a shorter post, and so might some others going forward. Fact of the matter is that I’m burning the candle at both ends a bit lately. I’m under contract for my next Pluralsight course, and I’m also mired in the bureaucratic morass of marching toward a real estate closing, so between that and 55-60-hour work weeks, I’m a little pressed for time. But, that said, we’ll see how it goes.

I was sitting in a meeting today where participants were discussing a recent initiative. (I was, at this point, a relatively passive observer with no horse in the race.) The gist of it was that the initiative was something that would be mildly pleasing to the user base but had some cost associated with it. It was accepted that this would be a bit of a financial loss on the balance sheet but that the ROI would be an eventual bolstering of the brand via goodwill and reputation points, so to speak. The leader of the meeting put a halt to this talk of generalities saying something to the effect of, “okay, so how much is it costing us, how many users are aware of it, and how positive was their response?” The people who had been discussing this got sort of deer-in-headlights. They seemed nonplussed that they were being asked to quantify something like this. I loved the questions, personally. I thought, “yeah, get those metrics, and then we can at least begin modeling scenarios for evaluating if this is worth doing.”

After that meeting, I retreated to my desk, and worked into the evening at the kind of tidying up that I can only seem to get done after business hours when I close the office door. One of the miscellaneous tasks was to come up with material to present tomorrow at the inaugural team lunch and learn — an initiative that I recently started. I don’t have a talk in my back pocket at the moment, so I was weighing options for it and settled on showing a video of a Michael Feathers talk about the synergy between testability and good design. I’ve recently introduced unit testing to the team, and it seems like a good perspective about unit testing beyond some of the more standard rationales. In the early part of the talk, Michael says (paraphrased from memory) that he often annoys developers by telling them that if their design isn’t testable, it’s not a good design. It’s quite a concept — if it can’t be easily verified, it isn’t very good.

Earlier this evening, I was relaxing and working my way through The Clean Coder by Uncle Bob Martin. In it, Bob cites something that Kent Beck told him about arguing — if an argument goes on for more than five minutes or so, then it’s really a religious war. If arguments are being based on facts, data, and empirical evidence, they’re settled pretty quickly. Rather than continuing to argue and get angry, both sides should regroup, do some research, and revisit the issue later. You can’t make a persuasive case for something without raw, hard data.

This struck me as interesting. Within the span of half a day, I was exposed to three separate events with a very fundamental and powerful underlying theme: “prove it.” If it can’t be proved, what good is it? As the characters in the Game of Thrones books seem to like to say, “words are wind.” Don’t tell me that users like it so it’s worth doing; show me evidence of that. Don’t tell me that your design is great; show me that it works for the required inputs. Don’t argue with bluster; show me that you’re right in such excruciating detail that there is simply no argument.

I don’t think anybody would find what I’m saying here controversial — proving and demonstrating are obviously better than simply claiming things without support. But I think the challenge for all of us is to prove (or at least to attempt to prove) things that we wouldn’t necessarily think of proving. How do you prove that user goodwill justifies spending X dollars? I don’t know, but it’s an interesting challenge. And beyond being an interesting challenge, it’s the kind of question that being able to answer will set you apart from the people you work with and make you in high demand. Do everything that you do in your professional life operating under the assumption that someone will audit your thought process and demand, on the spot, to know why you decided to do what you did. Why did you spend a day changing all methods in the code base from Pascal to camel case? Can you justify what that cost your group in terms of labor? How would you make the case for that?

I’m not suggesting that we should all operate constantly as if there were some insane, whip-cracking micromanager monitoring our every movement. What I am saying is that you can stand out by constantly and easily demonstrating the value and sense in the decisions that you make and the actions that you decide to take. Be that guy or gal. It’s less common than you think.


Notes on Job Hopping: Fear, Loathing, and Paying Your Dues

I was in a hotel the other night, and I had forgotten my Kindle at home, so I laid in bed for some time, catching up on my RSS feeds. I came across this post by John Sonmez, which I read with interest all the way through before I clicked over to read the post to which he was responding. John and I have very similar work ethics, so the part of his post about soldiering on during times when the ‘fun’ thing you started has lost its new car smell really resonated with me. Almost identically to him, I started blogging purely because I thought it’d be fun, but now there are nights where I have no queued posts and I really don’t feel like writing one. But I usually do anyway. A lot of things in my life follow that pattern, even beyond just programming — home improvement projects, setting up an ALM and ticketing system at work, gardening, etc.

And the point-counterpoint of these posts was interesting. The original poster, Loren, basically said that he’d been passionate about joining a startup, but fast forward two years and the job became soul sucking and unfulfilling even as it was cushy and relatively easy — startup Hotel California. So, in a celebratory announcement post, he said that he’d decided to quit his job and see where the wind blew him and that he’d already felt the passion start to reignite for things he likes to do.

I read John’s counterpoint to this as essentially saying, “don’t be that guy.” The guy I mean is the one you knew as a kid who had a closet full of hobbies and interests he’d started and abandoned after a few weeks. There was a violin he’d played for a little while, that old yellow belt from a brief karate stint, a rock tumbler, a football helmet, etc. We associate that with childhood behavior because, as a child, there really aren’t any stakes to just kind of quitting things and picking up new ones as you please. But as an adult, being a dilettante like this tends to have real life consequences. Most people outgrow it as obligations like spouses, mortgages and children enter the picture. But you still occasionally find Uncle Bill with the grown-up closet full of failed dreams of the moment: menus from the restaurant he tried to start, a Microsoft Programming Certificate, his tools from briefly trying to flip houses, etc. I think John was saying, “Don’t Be Uncle Bill. You’re never going to love something the way you did when you fell in love with the idea, and you can’t chase that dragon forever or it will bankrupt you.”

Simple enough: “I want to go chasing rainbows and I think that’s great” versus “chasing rainbows isn’t a career strategy.” Except, in the comments section on Loren’s post, things took a turn for the weird. At first I thought some of the hostility there was really bizarre for a post that just amounted to “I quit my job and I feel a lot better.” Then I thought that it was probably just a byproduct of coming from Hacker News. (If it is principally a “content and comment” engine like HN, YouTube, Reddit or Slashdot, I find that reading the comments tends to be a vaguely depressing experience, like riding a train through a crowded city with lots of debris and graffiti and broken windows everywhere.) But in the comments I saw a trend where the phrase “pay your dues” was repeated a number of times, and it made more sense to me.

Thank You, Sir, May I Have Another

I had intended this series to be a trilogy, rounded out by a post in which I prognosticated about the future of job-hopping (and that’s still coming), but I decided to add a chapter after reading these posts the other day. In the last post, I talked about the dues-paying culture in a corporate setting as one in which a general standard of mediocrity is forced upon the employees in an attempt to make everyone equally (dis)satisfied without playing favorites — you’ll wait three years for your promotion and pay your dues just like everyone else, mister.

At this point, I’d like to point out that I agree with the sentiments in John’s post from a rational self-interest perspective. That is, I think that quitting a job to spend some time with your hobbies is not a smart career move, and telling yourself otherwise is just a rationalization (though I have no quarrel with someone choosing to do this — I’m very small “L” libertarian when it comes to matters of “live and let live.”) But I do differ from John on a small point, which is really his invocation of the concept of dues paying. That is, he makes a reference to paying your dues in a sense that I think of as simple time investment. You start a project and it’s fun, you keep at it when it stops being fun, and eventually you deliver and reap the benefits. I don’t really think of this as paying dues but as investing time into an effort, pure and simple.

Distinguishing my idea of dues paying from John’s may seem like semantics, but I consider it important for two reasons. Firstly, the rest of this post is frankly going to be an attack on the mentality of “people should pay their dues,” and I don’t want to include John’s message about following through in the attack. Secondly, I think that dues paying is actually a perversion of investment. (For a lengthier dive into this topic, feel free to check out the conclusion of the Expert Beginner ebook when it comes out). Investing in one’s future is working hard now for greater opportunity later, whereas dues paying is some combination of Ponzi scheme and working hard now so you can be lazy later.

First of all, dues paying has a literal meaning and an idiomatic meaning. The literal meaning is that you exchange something of value (generally money, but not necessarily) for membership in some sort of club or organization. Dues-requiring organizations that come to mind, off the top, are unions, professional organizations, country clubs, condo associations, fraternities and sororities, and gangs (often weird barter dues involving violence). By and large, you trade something of value for a personal identifier — I pay club dues because I want to be a member of the club. Dues paying, literally, is a way to purchase identity status and its attendant privileges.

Frat Guy

The idiomatic meaning has evolved to be this: you suffer in the here and now for rewards to be reaped at a later date. It has culturally-ingrained, protestant-work-ethic overtones as well. It isn’t just that you sacrifice now to be rewarded later, but that the sacrifice — the pain, suffering and indignation — is a character-building, humbling benefit tied up with a mastery and maturity bow in the end. It’s a nice narrative, like that of the Karate Kid.

But how do you get from point A, a payment in order to recieve a certificate of identity and belonging, to point B, a humble prostration before a pack of the worthy? I mean, shelling out 20K a year for the right to play golf hardly evokes images of Daniel-San waxing his way on and off to the karate championship. So what gives? Well, I’d say what gave was the increasing status disparity between early and later members. To put it more bluntly: the more people that get into a club, the more ridiculous the things they make new members do. And, thanks to the cognitive biases, the more the new members do those ridiculous things, the more they start to manufacture value for the experience. Before you know it, victims of horrific and bizarre hazing rituals actually reflect fondly back on them as character-building events that make the club they’re in that much better. They were just payin’ their dues, proving they wanted to be in the club badly enough to get in.

Dues Paying in the Workplace

Doesn’t it strike you as fundamentally weird to juxtapose club membership and salaried employment? That is, when people around the office talk about “paying your dues,” stop for a minute and think how odd that is (unless it’s their union rep talking to them). Organizations that collect dues are selling identity whereas corporations are purchasing labor from their employees. So if I have to “pay my dues” in a company, that means that it’s purchasing labor from me and I’m purchasing identity from it. I’m selling my labor to belong to some cabal of tenured people there that get to mete out the good assignments as they see fit, like fraternity pledge masters handing out the chores to the pledges or gang leaders handing out drugs or whatever to their soldiers. Within the organization, a club forms. It acts orthogonally to the organization’s best interests as it bolsters its own social currency on the backs of captive, hapless newbies who, unlike college freshmen, can’t simply say, “leave me alone — I’m not interested in your stupid club.” At least, they can’t say that without job hopping.

It’s in this culture that the corporate notion of dues paying really thrives. It’s the people that have been with an organization the longest that get to form the club and define its rules, currency (real or social), hazing rituals and customs. It’s cultures like this that marry dues paying to time invested rather than quality. And it’s the hapless job hoppers that bounce around until they find somewhere that this self-important silliness is muted to a minimum.

Of course, almost nothing infuriates a member of the club like someone not wanting to play — it’s a direct rejection of a carefully crafted culture and a whole lot of manufactured value. “Well, Jim, you’re new, but the guy with the most years here gets the best donuts, so — what, you don’t like donuts? Oh, sure, whatever. Heh, you’re clearly jealous.” I say almost nothing infuriates like opting out, because the one thing that really redlines club members is someone who scoots in with some kind of favored status, effectively bypassing the hazing, the rituals and the traditions. That’s a dogfight.

People who talk to you about dues paying in a corporate setting (and mean it in the sense I’m talking about here) have one of three main motivations: jealousy, a sense of being threatened, or external rationalization. Jealousy is the easiest to understand and probably the most common, especially from a veteran of dues-paying cultures in the abstract. This was on display in the wailing and gnashing of teeth from the HN set in Loren’s post. It doesn’t take Freud to figure out that a person getting disproportionately angry about someone else quitting his job to have fun is jealous.

A feeling of threat to one’s validity is also closely related. If you get promoted to architect at age 30 whereas a crowd of “wait your turn” dues payers around you didn’t get there until 40, it triggers thoughts of “what’s wrong with me that I didn’t get there at 30?” That’s a rather existential threat that’s hard to swallow, and it goes beyond simple jealousy. There’s an up-and-comer on the way, and he’s clearly gunning for this position. It’s this second motivation that tends to trigger the most action in a corporate setting, with the Council of Elders appealing to some AVP somewhere that these kids don’t know the value of respect. The Council will bring the full weight of their clique’s political influence with the company down on the newbies, refusing to rest until the youngsters are scrubbing PHP code off the toilets and doing pushups in the server room. It’s good for them. Kids these days have no respect and need to pay their dues.

The final motivation is rationalization. It’s the most interpersonally benign and depressingly insidious. This motivation occurs after the club has dominated and stamped out meritocracy altogether and some manager is left to explain a soul-crushing HR promotion matrix to a talented recent hire. This is when a boss says to his report something like “we think you have a bright future here, so pay your dues and you’ll be rewarded down the line,” when what he really means is “I’d promote you, but there’s a rule that I can’t for three years and I think that happened because there’s all of these lazy senior people here that have already paid their dues and will throw a fearsome temper tantrum if we give you tasks that are challenging and fulfilling before the three-year mark.”

My message to Loren, if you’re reading, and to anyone in general is don’t bother paying dues. That’s for MacLeod losers, golfers and unions members. If you can skip dues paying and enjoy success, by all means do it. Define yourself by what you produce and what you accomplish, not by how much you suffer for some kind of token acceptance from some group primarily interested in you succeeding no more rapidly than they did. Don’t stick around waiting for them to let you in — leave and start your own club where you set the rules and regulations. Create a place where you’re free to abide by the rules of meritocracy and ambition.

Both your money and your time are finite resources. You have to choose between putting them toward corporate/industry identity membership and investing them in your own career, yourself, and your life. I think it’s a no-brainer, personally. Paying your dues gets you comfortably in the door if you just hang around long enough and absorb the hazing, but blazing your own trail lets you buy the property that the clubhouse is built on.


Defining Done for Your Deployment Process

A Tale of Debugging

The other day, someone came to me and told me that a component of one of the web applications that my team maintains seemed to have a problem. I sat with her, and she showed me what was going on. Sure enough, I saw the issue too. It was the kind of integration thing for which we were able to muster up some historical record and see approximately when the problem had started. Apparently, the problem first occurred around the last time we pushed a version of the website into production. Ruh roh.


Given that this was a pretty critical issue, I got right down to debugging. Pretty quickly, I found the place in the code where the integration callout was happening, and I stepped through it in the debugger. (As an aside, I realize I’ve often made the case against much debugger use. But when legacy code has no unit, component or integration tests, you really don’t have a lot of options.) No exceptions were thrown, and no obvious problems were occurring. It just hit a third party API, went through it uneventfully, but quietly failed.

At this point, it was time for some tinkering and reverse engineering. When I looked at the method call that seemed to be the meat of the issue, I noticed that it returned an integer that the code I was debugging just ignored. Hovering over it, XML doc comment engine told me that it was returning an error code. I would have preferred an exception, but whatever — this was progress. Unfortunately, that was all the help I got, and there was no indication what any returned error code meant. I ran the code and saw that I was getting a “2,” so presumably there was an error occurring.

Maddeningly, there was no online documentation of this API. The only way I was able to proceed was to install a trial version of this utility locally, on my desktop, and read the CHM file. They offered one through their website, but it was broken. After digging, I found that this error code meant “call failure or license file missing.” Hmm… license file, eh? I started to get that tiny adrenaline rush that you get when a solution seems like it might be just around the corner. I had just replaced the previous deployment process of “copy over the files that are different to the server” with a slightly less icky “wipe the server’s directory and put our stuff there.” It had taken some time to iron out failures and bring all of the dependencies under source control, but I viewed this as antiseptic on a festering sore. And, apparently, I had missed one. Upon diving further into the documentation, I saw that it required some weirdly-named license file with some kind of key in it to be in the web application root’s “bin” folder on the server, or it would just quietly fail. Awesome.

This was confirmed by going back to a historical archive of the site, finding that weird file, putting it into production and observing that the problem was resolved. So time to call it a day, right?

Fixing the Deeper Issue

Well, if you call it a day now, there’s a good chance this will happen again later. After all, the only thing that will prevent this after the next deployment is someone remembering, “oh, yeah, we have to copy over that weird license file thing into that directory from the previous deploy.” I don’t know about you, but I don’t really want important system functionality hinging on “oh, yeah, that thing!”

What about a big, fat comment in the code? Something like “this method call will fail if license file xyz isn’t in abc directory?” Well, in a year when everyone has forgotten this and there’s a new architect in town, that’ll at least save a headache next time this issue occurs. But this is reactionary. It has the advantage of not being purely tribal knowledge, but it doesn’t preemptively solve the problem. Another idea might be to trap error codes and throw an exception with a descriptive message, but this is just another step in making the gap between failure and resolution a shorter one. I think we should try avoid failing at all, though having comments and better error trapping is certainly a good idea in addition to whatever better solution comes next.

What about checking the license file into source control and designing the build to copy it to that directory? Win, right? Well, right — it solves the problem. With the next deploy, the license file will be on the server, and that means this particular issue won’t occur in the future. So now it must be time to call it day, right?

Still no, I’d argue. There’s work to be done, and it’s not easy or quick work. Because what needs to happen now is a move from a “delete the contents of the server directory and unzip the new deliverable” deployment to an automated build and deployment. What also needs to happen is a series of automated acceptance tests in a staging environment and possibly regression tests in a production environment. In this situation, not only are developers reading the code aware of the dependency on that license file, not only do failures happen quickly and obviously, and not only is the license file deployed to where it needs to go, but if anything ever goes wrong, automated notifications will occur immediately and allow the situation to be corrected.

It may seem pretty intense to set all that up, but it’s the responsible thing to do. Along the spectrum of some “deployment maturity model,” tweaking things on the server and forgetting about it is whatever score is “least mature.” What I’m talking about is “most mature.” Will it take some doing to get there and probably some time? Absolutely. Does that mean that anything less can be good enough? Nope. Not in my opinion, anyway.


Notes On Job Hopping: You Should Probably Job Hop

Last week, in a post that either broke the Google+ counter mechanism or blew up there in very isolated fashion, I talked about job hopping and meandered my way to my own personal conclusion as to whether it might be construed as unethical. I don’t think it is. Today I’d like to talk a bit about practical ramifications for the individual, as promised at the end of that post.

The title of this sounds like link bait, but that’s not really more my goal. I wrote the post without giving it a title and then reread it. This title was the only thing that I could think to call it, as I realized, “wow, I guess I’m recommending that people job hop.”

A Scarlet J

Conventional wisdom holds that there is some kind of sliding scale between loyal employee and job hopper and that you get into a bit of a danger zone if you move around too much. Everyone can really imagine the scenario: you’re in an interview and the interviewer awkwardly asks, “since you seem to switch jobs a lot, how do I know you’d stay here long enough for the hire to be worthwhile?” And you’d fire a blank at this point, you job hopper, you. You’d be unable to convince this hiring authority to take a chance on you. And what’s worse is that this would be a common reaction, getting you turned down in interviews and probably even tossed from a number of resume piles in the first place. You have a scarlet J on your chest, and nothing but time will remove it.


If, on the other hand, you opt for the loyalty route and keep the number of job changes pretty minimal, you’ll have no trouble finding your next job. Without that scarlet J, the townsfolk are more than happy to give you an offer letter. They figure that if you’ve spent a decade at Initech, you’re likely to spend the next decade working for them. And, really, what could be better for them? Everyone knows that turnover is expensive. There are training periods and natural inefficiencies to that concept; it’s just a question of how bad. If Bob and all of his tribal knowledge walk out the door, it can be a real problem for a group. So companies look for unfaithful employees, but not employees that are unfaithful too often — otherwise the awkward question arises: “if he’ll cheat on his old company with me, how do I know he won’t cheat on me with Initrode?”

Apparently, there’s a line to straddle here if your eye starts wandering. Job transitions are a finite resource, so you’d better make them count. But that’s not exactly a reason not to job hop, but a reason not to do it too often. It’s the difference between having a few cold ones on the weekend and being Kieth Richards, and I’ll come back to this point later. But, in the meantime, let’s look at some reasons not to change jobs.

Should I Stay…

One of the biggest reasons people stay at a job is simple inertia. I’m listing that first because I suspect it’s probably the most common reason. Even though a lot of people don’t exactly love their jobs, looking for a new job is a hassle. You have to go through the interview process, which can be absurd in and of itself. On top of that, it typically means awkward absences from work, fibbing to an employer, getting dressed up, keeping weird hours and putting in a lot of work. Job searching can be a full-time job in and of itself, and the prospective job seeker already has a full time job. And if job searching weren’t enough of a hassle, there’s a whole slew of other issues as well. You’re trading what you know and feel comfortable with (often) for the unfamiliar. You’re leaving behind a crew of friends and associates. You’re giving up your seniority to become the new guy. And none of that is easy. Even if you decide in the abstract that you’re willing to do all of that in the abstract, it’s likely that you’ll put it off a few more weeks/months — and keep putting it off.

Another common and more uplifting reason to stay at a position is due to a high rate of job satisfaction. I think this is less common than simple inertia, but it’s certainly out there. Perhaps you spent the early part of your career doing help desk support and all you ever wanted was a shot at uninterrupted programming in a R&D outfit, and now you have that. Maybe you’ve always wanted to work for Microsoft or Facebook or something, and now you’re there. You’d pass on more lucrative offers or offers of more responsibility simply because you really want to be doing what you’re doing, day in and day out. Genuinely loving one’s job and the work there is certainly a reason not to job hop.

I think that a decreasingly common reason for staying put is loyalty to a company. I observe this to a degree in the boomer set, but it’s not common among gen-Xers and is nearly nonexistent among millennials. This is a desire to stick it out and do right by a company instead of leaving it high and dry. It may take on the form of the abstract loyalty to the company itself, or it may be loyalty to a boss and/or coworkers. (“I’d hate to leave now, they’d be so screwed if I took off that I can’t do it to them.”) I personally view this as a noble, albeit somewhat quixotic, sentiment, tinged with a form of spotlight effect bias. I think we tend to radically overvalue how high and dry an organization would be without our services. Businesses are remarkably good at lurching along for a while, even when understaffed or piloted by incompetents.

Rounding out the field of reasons that I’ll mention is a more specialized and less sympathetic form of inertial (and perhaps even loving your job), which is the golden handcuffs. You’re an Expert Beginner or the “residue” in the Dead Sea Effect, and your company drastically overvalues you both in terms of responsibility and pay. To put it bluntly, you stay because you have no choice — you have a relatively toxic codependent relationship with your employer.

There are certainly other conceivable reasons to stay at a job, but I think that you might loosely categorize them into these four buckets and cover the vast majority of rationales that people would cite. So if these are the reasons to stay, what are the reasons to go? Why does jumping from job to job make sense?

Or Should I Go?

First off, let’s talk money. If you stay in place at a run-of-the-mill job, what probably happens is that every year you get some kind of three percent-ish COLA. Every five years or so, you get a promotion and a nice kick, like five to ten percent. If, on the other hand, you move jobs, you get that five to ten percent kick (at least) each time you move. So let’s follow the trajectory of two people that start out making 40K per year out of college as programmers: one who hops every two years and one who stays loyal. Let’s assume that the hopper doesn’t get COLAs because of when he’s hired at each position. We’ll just give him ten percent kicks every two years, while his loyal peer gets three percent COLAs every year as well as the ten percent kicks. The loyal guy is making 61.3K at the end of ten years, while his job-hopping friend is making 64.4K. If we were to add in the COLAs for the hopper, because he timed it right, that balloons to 74.7, which is almost 25% more than his friend. Neither of those salaries may seem huge, especially given all of the turmoil in the hopper’s life, but consider that for the rest of your career, there’s no bigger determining factor of your salary than your previous salary, and consider the principle of compound interest. Even assuming that after year ten both people in this thought experiment make the exact same career moves, the difference between their salaries and net worth will only continue to widen for the rest of their lives. It pays to job hop. Literally.

In fact, I might argue that the case I just made above is actually somewhat muted because of another job-hopping-related consideration: career advancement. Before, we were just talking about what probably amounts to token promotions — the loyal guy was “software engineer III” after ten years, while his hopper friend was now “software engineer V.” But here’s another thing that happens when you hop: you tend to accumulate more impressive-sounding titles, kicking off a chicken-egg kind of scenario about qualification and title. What I mean is that you don’t just number positions like job shifts, but you start to rack up qualifiers for title like “senior” or “lead” or “principal.” So now our two subjects are a software engineer making 60K and a lead software engineer making 75K, respectively. Which one of these do you think is likely to get promoted to management or architect first? Done right, job hopping earns you better pay and better titles, which earn you still more pay.

Related to this skipping around for better circumstances is the middling corporate narrative that the job hopper is escaping — specifically one of “dues paying.” For a bit of background on this concept as it relates to programmers, take a read through section 5, “Career Development,” in Michael O. Chruch’s post about what programmers want. Dues-paying cultures are ones in which advancement is determined not by merit but by some kind of predetermined average and set of canned expectations. For instance, if you hear things from companies like, “we don’t hire lead architects — we only promote from within to that position,” or, “we don’t offer development promotions more than once every three years,” you have a dues-paying culture on your hand. Call it what you will, but this is essentially a policy designed to prevent the mediocre, tenured natives from getting restless. It seems insanely childish and petty, yes. But I have personally witnessed plenty of cases where person X with ten years of time with a company had a hissy fit because someone got to engineer level IV in three years when it took person X four years to get there. Enough tantrums like that and promotion governors are slapped on the engine of advancement at the company, and dues-paying periods become official.

But this need not concern the job hopper, who won’t be around long enough to play this game anyway. This is a win on two fronts for him. It’s an obvious win because he promotes himself within a year or two instead of waiting three or four for the HR matrix to catch up. He also avoids the endowment effect of earning his way past the dues-paying rope. In other words, if he did stay around long enough to ‘earn’ the coveted lead architect title, he’d overvalue it and stick around even longer to savor it because he’d be thinking subconsciously, “being a lead architect at this awesome company is truly amazing or else I wouldn’t have twiddled my thumbs all these years waiting for it.” He’d be a lot more likely to stick around for the even more coveted (at that organization) “super lead architect” position that one can only ‘earn’ after another four years.

Speaking of empty titles, there is another powerful argument in favor of job hopping: avoiding and minimizing interaction with Expert Beginners. On the more obvious front, jumping around helps you avoid becoming an Expert Beginner since you can’t build seniority capital of questionable value to use in lieu of well-reasoned arguments or genuine skill. If you’re bouncing around every year or two, you can’t start arguments with “I’ve been here for 20 years, and blah, blah, blah.” But a willingness to job hop also provides you with an exit strategy for being confronted with Expert Beginners. If you start at a place and find some weird internal framework or a nasty, amorphous blob of architecture and the ranking ‘experts’ don’t seem to see it as a problem, you can just move on. Your stays will be longer at places that lack Expert Beginnerism in their cultures and shorter at places with particularly nasty or dense Expert Beginners. But whatever the case may be, you as a job hopper will be the water evaporating in Bruce Webster’s metaphor, refusing to put up with organizational stupidity.

And putting up with organizational stupidity is, in fact, something of a career hazard. Job hopping gives you a sort of career cross-pollination that hanging around at the same place for 20 years does not, which makes you a lot more marketable. If you work somewhere that has the “Enterprise Framework,” it’s likely you’ll spend years getting to know and understand how some weird, proprietary, tangled mess of code works in an incredible amount of detail. But in the market at large, this knowledge is nearly useless. It only holds value internally within that organization. And, what’s more, if you have a sunk intellectual property cost at an organization in some gargantuan system written in, say, Java, you’re going to be pretty unlikely to pick up new languages and frameworks as they come along. Your career will be frozen in amber while you work at such a place. There are certain types of organizations, such as consultancies, where this is minimized. But if you doubt the effect, ask yourself how many people out there are cranking out stuff in Winforms or even VB6.

What To Do?

We can summarize the pro arguments for job hopping as money; advancement; avoiding mediocre, dues-paying cultures; avoiding Expert Beginners and organizational stupidity; and being marketable. On the other side, we can summarize the con arguments for job hopping by tagging them as inertia, satisfaction, loyalty and golden handcuffs. You’ll notice that I didn’t mention the stigma in either category, even though that’s ostensibly a clear negative. (I will return once again to the stigma angle in the third and final post in this series that addresses the future of job hopping). This is because I view the stigma as neutral and a simple matter of market realpolitik.

When are you most likely to be branded with the scarlet J — scratch that — when is the only time that you’ll be branded with that scarlet J? Obviously, while you’re applying and interviewing. You’ll be working at Initech and considering a switch to Initrode, and Initrode takes a pass on you because you seem to skip around too much. So you just keep working at Initech and put in another year or two to let the stigma fade. As long as you don’t quit (or get laid off) without something else lined up, the job-hopper stigma really doesn’t matter. It happens when it happens, and you actually have a peek-ahead option to find out that it’s about to happen but without dire consequences (again, assuming you aren’t laid off and are generally competent).

And really, this makes a certain kind of sense. I have, in the past, been told to stay put in a situation I didn’t like for fear of acquiring a scarlet J. People were advising me to stay in a situation in which I was unhappy because if I got out of that situation I might later be unhappy again and this time unable to move. Or, in other words, I should remain definitely unhappy now to avoid possibly being unhappy later. That strikes me as like sitting at home with a 105 degree fever because the ambulance might crash on the way to the hospital and put my health in jeopardy. The stigma argument seems actually to be something of a non-starter since, if it happens, you can just wait it out.

So, on to the million dollar question: should you job hop? Unless you’re happy where you are, I don’t see how the answer can be anything but “yes.” The “no” arguments all involve personal valuations — with the exception of “golden handcuffs,” which really just means that job hopping is impossible because you missed that boat. Are you too busy with family to conduct a job search? Do you really like your coworkers and working environment? Do you love the work that you’re doing right now? Do you really love the company? I can’t lobby for personal decisions like that in people’s lives, and there is certainly more to life than career advancement, money, and responsibility.

But in terms of objective considerations like money, position and title, there’s really no argument. Job hopping will advance you more quickly through the ranks to better titles, paychecks, and career opportunities in general. You will have more breadth of experience, more industry contacts, more marketable skills, and more frank and honest valuations of the worth of your labor. Companies are generally optimized to minimize turnover, and if you want a path that differs from steady, slow, measured advancement, staying in one place isn’t in your best interests. Should you job hop? I say absolutely — as often as your personal life and happiness will allow, and as long as you manage to avoid the scarlet J. I’d imagine that at some points in your career you’ll settle in for a longer stay than others, and perhaps eventually you’ll find a calling to ride out the rest of your career in a place. But I think that you ought to spend your career always ready to trade up or to change your scenery as often as necessary to keep you moving toward your goals, whatever they may be.



A while back, I wrote a post in which I talked about offering too much code and too many options to other potential users of your code. A discussion emerged in the comments roughly surrounding the merits of the design heuristic affectionately known as “YAGNI,” or “you ain’t gonna need it.” In a vacuum, this aphorism seems to be the kind of advice you give a chronic hoarder: “come on, just throw out 12 of those combs — it’s not like you’re going to need them.” So what does it mean, exactly, in the context of programming, and is it good advice in general? After all, if you applied the advice that you’d give a hoarder to someone who wasn’t, you might be telling them to throw out their only comb, which wouldn’t make a lot of sense.

As best I understand, the YAGNI principle is one of the tenets of Extreme Programming (XP), an agile development approach that emerged in the 1990s and stood in stark contrast to the so-called “waterfall” or big-design-up-front approach to software projects. One of the core principles of the (generally unsuccessful) waterfall approach is a quixotic attempt to figure out just about every detail of the code to be written before writing it, and then, afterward, to actually write the code. I personally believe this silliness is the result of misguided attempts to mimic the behavior of an Industrial Revolution-style assembly line in which the engineers (generally software architects) do all the thinking and planning so that the mindless drones putting the pieces together (developers) don’t have to hurt their brains thinking. Obviously, in an industry of knowledge workers, this is silly … but I digress. YAGNI as a concept seems well suited to address the problematic tendency of waterfall development to generate massive amounts of useless code and other artifacts. Instead, with YAGNI (and other agile principles) you deliver features early, using the simplest possible implementation, and then you add more and refactor as you go.

But YAGNI also has a smaller scale design component as well, which is evident in my earlier post. Some developers have a tendency to code up classes and add extra methods that they think might be useful to themselves or others at some later point in time. This is often referred to as “gold plating,” and I think the behavior is based largely on the fact that this is often a good idea in day-to-day life. “As long as I’m changing the lightbulb in this ceiling lamp, I may as well dust and do a little cleaning while I’m up here.” Or perhaps, “as long as I’m cooking tonight, I might as well make extra so that I have leftovers and can save time tomorrow.” But the devil is in the details with speculative value propositions. In the first example, clear value is being provided with the extra task (cleaning). In the second, the value is speculative, but the odds of realization are high and the marginal cost is low. If you’re going to the effort of making tuna casserole, scaling up the ingredients is negligible in terms of effort and provides a very likely time savings tomorrow.

But doesn’t that apply to code? I mean, adding that GetFoo() method will take only a second and it might be useful later. Well, consider that the planning lifespan for code is different than casserole. With the casserole, you have a definite timeframe in mind — some time in the next few nights — whereas with code, you do not. The timeframe is “down the line.” In the meantime, that code sits in the fridge of your application, aging poorly as people forget its intended purpose. You wind up with a code-fridge full of containers with goop in them that doesn’t exactly smell bad, but isn’t labeled with a date and you aren’t sure of its origin. And I don’t know about you, but if I were to encounter a situation like that, the reaction would be “I don’t feel like risking it, I’m ordering Chinese.” And, “nope, I’m out of here,” isn’t a good feeling to have when you open your application’s code.

So there is an overriding design principle YAGNI, and there is a more localized version — both of which seem to be reactions toward a tendency to comically overplan and a tendency to gold plate locally, respectively. But does this advice always hold up, reactions notwithstanding? I’m not so sure. I mean, let’s say that you’re starting on a new .NET web application and you need to test that it displays “hello world.” The simplest thing that could work is F5 and inspection. But now let’s say that you have to give it to a tester. The simplest thing is to take the compiled output and manually copy it to a server. That’s certainly simpler than setting up some kind of automated publish or continuous deployment scenario. And now you’re in sort of a loop, because at what point is this XCopy deploy ever not going to be the simplest thing that could work for deploying? What’s the tipping point?

Now I’m sure that someone is primed to comment that it’s just a matter of how you define requirements and how stringent you are about quality. “Well, it’s the simplest thing that could possibly work but keeping the overall goals in mind of the project and assuming a baseline of quality and” — gotta cut you off there, because that’s not YAGNI. That’s WITSTTCPWBKTOGIMOTPAAABOQA, and that’s a mouthful. It’s a mouthful because there’s suddenly nuance.

The software development world is full of metaphorical hoarders, to go back to the theme of the first paragraph. They’re serial planners and pleasers that want a fridge full of every imaginable code casserole they or their guests might ever need. YAGNI is a great mantra for these people and for snapping them out of it. When you go sit to pair or work with someone who asks you for advice on some method, it’s a good reality check to say, “dude, YAGNI, so stop writing it.” But once that person gets YAGNI — really groks it by adopting a practice like TDD or by developing a knack for getting things working and refactoring to refinement — there are diminishing returns to this piece of advice. While it might still occasionally serve as a reminder/wake-up call, it starts to become a possibly counterproductive oversimplification. I’d say that this is a great, pithy phrase to tack up on the wall of your shop as a reminder, especially if there’s been an overplanning and gold-plating trend historically. But that if you do that, beware local maxima.