Stories about Software


I Make Software

Announcement Housekeeping

I’m back from my vacation, and while I was gone my first Pluralsight course was published and I’m now officially listed as an author. The course is about continuous testing and NCrunch, if you have interest and a Pluralsight subscription. If you don’t have a subscription, I would recommend one, and that’s a plug independent of my affiliation–I’ve been a loyal subscriber and video-watcher for the last two years before becoming an author.

I have updated the tagging on the Expert Beginner posts so that you can see all of them by choosing the “Expert Beginner” tag. They appear in order from newest to oldest. The posts span a reorganization of categories and tags that I did, so things weren’t as organized as they could have been. And, speaking of those posts, I’m going to be finishing up the series this weekend. That series and another will be coming soon in e-book format, details to follow. The Japanese translation’s release date is TBD, tamil. 🙂

And now, back to your regularly scheduled posting.

A Programmer by any other Name…

Euphemism in the context of validating occupations, or, more generally, decisions in life, is a subject that I find pretty fascinating. To be a little less wordy and more concrete, this is what happens when a stay-at-home mom starts referring to herself as a “Domestic Engineer” or when we call secretaries, stewards/stewardesses, and janitors something different every ten years or so (excuse me, administrative assistants, flight attendants, and custodian–or perhaps sanitation engineer). A lot of people call this “political correctness,” but frankly that’s just another euphemism. All of this behavior is really just marketing and the fascinating bit is what makes people decide that image touch-up is necessary.

Lest you think I’m being snide toward other lines of work, we programmers (excuse me, software engineers) seem to do this as well. John Sonmez wrote an interesting post about this while I was on my vacation recently. My post here actually started out as a comment response to his but grew into an unruly beast that I think needs to be its own blog post. In his post, he calls for plain speaking about our line of work and less preening with titles like architect, senior software engineer, etc. (He also suggests a list of titles that we don’t use when trying to make our work seem more grandiose than it is, and that list will definitely make you chuckle). I agree wholeheartedly with the sentiment of the post and with almost all of the individual theses that I gleaned from it. To wit, these are excellent points:

  1. There is no centrally agreed-upon title ranking and one man’s software engineer IV is another man’s principal senior lead developer, more or less.
  2. Debating whether we should officially be “developers” or “programmers” or whatever is silly.
  3. Impressive-sounding title does not mean impressive skill or competence (I don’t think any regular reader would dispute my agreement with this point).
  4. It’s probably easiest to communicate what you do by saying “programmer” than by the show of force of “Well, I’m a Tenured Level 12 Architect Fellow!”

But there’s one point on which I can’t agree with him, and it saddens me. Specifically, “job titles don’t mean jack.”

Must… Rank… Ourselves!

I want to agree with that point–badly. I would agree with it if it were, “job titles shouldn’t mean jack,” or, “job titles don’t mean jack when it comes to your competence, contribution level or personal worth.” But as stated, I can’t get there.

I’m relaxed, refreshed, and cheerful these days, so I didn’t intend to do another realpolitik-oriented post where I might be accused of cynicism, but c’est la vie. Job titles are one of our main talismans of self-evaluation in the corporate world. National leaders measure worth by things like approval ratings or time in office, athletes by titles and victories, generals by battles won, accomplished scientists by publications, awards, or even Nobel Prizes. All of those have money and power. You get the idea–high-achieving outliers tend to have visible evaluation metrics that put stamps of greatness on their achievements in life. But in the banal world of bottom-heavy corporate politics, we have only a handful of such things, and they can be boiled down to this: where you sit, what you get paid, how late you can arrive at meetings, and what the title says under your name on your business card (and, of course, what your business cards are like).


Titles tie into all of these metrics insidiously. With a title like programmer, you get a cube and not an office, much less a corner office. With a title like programmer, you don’t get paid nearly as much as a senior programmer, lead programmer, architect, or CTO. With that title, you’d better be at meetings on time or early, and you probably don’t have a business card. What would a peon like you need with that? Titles in a company are relative data points that we gather and use to understand how much or little we’re valued. They help signal that you’ve arrived or that you have a long way to go as far as the company is concerned. In a vacuum, they mean nothing, but as soon as more than one is introduced, they establish the relative pecking order and they mean everything, and that’s sad.

I’ve written and talked about how depressing I find it that we bury decades of our lives in a pursuit and count ourselves among the elite in life if get to work in a room that has a door. “Well, Jones, in honor of you investing 30,000 hours of your life in this corporation, you can now spend eight hours per day in a slightly bigger space and keep your former friends and new underlings at bay by closing your door.” If that’s the high water mark of existence, ugh. But if you think about what’s really going on, when laid bare that way in all its triteness, it’s easy to see that the office and the business card with a watermark isn’t really the end goal, nor is it important. What’s important is that offices and business cards are the work-a-day corporate equivalent of battles won, Nobel Prizes earned, and championships brought home. They are the things that say you’ve fought the good fight, earned distinction, bested your peers and vanquished your foes. Because the thing of it is, as soon as you introduce distinction, human nature will stack rank it and attempt to place itself at the head of the stack.

Stripping the Status from Titles

What if every programmer on earth right now were title-renamed “programmer?” You might find that a company tried to hire an embedded systems specialist to touch up some CSS, at which point the former would say, with a mild note of disgust, “oh, no–I’m not that kind of programmer.” Or perhaps they’d offer 50K per year to a senior architect that had been raking in 150K per year, to which she would reply with more than a mild note of disgust, “surely you jest–I’m not that kind of programmer! That’s a hack. I’m more like an-an-an engineer of programming! Or maybe an architect of programming, even!” This isn’t too far off from “oh, you’re just a janitor, eh?” being answered by “no, no–I’m a custodial engineer! That sad sack over there is a janitor.”

John is absolutely dead on when he says, “you can’t know anything about a job or person by their job title.” Whether they’re a programmer or architect, janitor or flight attendant, you know nothing about their drive, commitment, intelligence, competence, or worth as a person from that trivial, reductionist title. And no amount of artificial puffing or grandstanding will change that. But as long as we’re in the business of abbreviating people’s lives, achievements and worth with reductionist, elevator-pitch words (titles), people are going to look to change theirs to their advantage to signify that they have achievements and that their lives are going places.

I make software. If you ask me what I do, I can honestly say that, and I’ve been able to say that my whole career. But over that time, my pay has changed, my role has changed, where I sit has changed, my business cards have changed, and my position in the stack ranking stew of various organizations has changed. Along with that, my title has changed and changed as a predictable avatar representing all of those other changes. From company to company, the avatar’s interpretation may vary somewhat, but within a margin of error, the title serves as a way for organizations to quickly identify how you’ve been stack ranked by other organizations and to then rank you accordingly.

It’s because I don’t like this system and because I agree with John’s statement if amended to “job titles [shouldn’t] mean jack,” that I like outfits like stack overflow, github, and coderbits. It’s nice to see value placed on works, rather than scripted career status evaluations. I think that for me, the ultimate goal is to separate “what do you do?” from “how much value to you provide?” What do I do? I make software. Perhaps I should be titled “Software Maker.” How much value do I provide as a “Software Maker?” Well, that’s a more complicated question that you can’t answer in a word or two. So perhaps it’d be better if you didn’t try.


Self-Correcting Organizations: Fall of the Expert Beginner

Today, I’m going to make what will be, for now, the last post in the Expert Beginner series. I edited the first post in the series to add a blurb about this, but I’ve actually been working on compiling these posts into an e-book that will sell for a few dollars. More specifics on the availability and timeframe of that to follow.

Also, I’m going to be traveling for a couple of weeks with very limited access to internet, so I doubt that there will be any posts to this blog before Memorial Day (May 27th). I plan to resume a normal posting cadence then. Thanks for your patience.

The Human Cost

If you’ve followed this series of posts, it’s pretty likely that you empathize with observing and dealing with Expert Beginners. That is, you’ve most likely encountered someone like this in your travels and been stymied, belittled, annoyed, exasperated, etc. by this Expert Beginner. So you’re probably rooting for the outcome in the title of the post. This is the post in which the cosmic scales are rebalanced and the arrogant Expert Beginner finally gets his comeuppance: The Fall of the Expert Beginner. But not so fast–there’s some ground to cover first, and if you’re looking for a nice resolution where the bad guy is brought to justice, you might be disappointed.

I mean, it’s nice to read the Daily WTF and see the occasional story about a bungling but nasty manager or architect being dressed down or laid off, but in your life, the players involved are actual people and everyone suffers real consequences. If you hire on with an organization dominated by an Expert Beginner and then leave in frustration, you’re investing time that you’ll never get back and incurring the hassle of a job search sooner than expected. You also probably came on board because you liked the company and its goals and mission, and you leave knowing that its interests are being sabotaged by incompetence and that your friends and everyone else still working there are not doing as well as they could be if the company were enjoying more success. And even if the Expert Beginner does wind up being disgraced somehow, via demotion or termination, that’s a person who now must explain to a family that they’re going to have to batten down the hatches financially until he figures something out.

Escaping Intact

In the last post in this series, I left off with a teaser for this post where I said that Expert Beginners generally enjoy high odds for short term success which drop to zero on a long enough timeline. Here, I’d like to talk about the means by which some Expert Beginners tend to escape that fate before describing it in detail.

The secret to success in the Expert Beginner world is to understand that programming (or really any line-level expertise) has to be a means to an end only. It’s not a skill that you’re going to master, but one of which you’ll fake mastery for just long enough to profit (literally and figuratively) and bail out. This requires some ability to tolerate cognitive dissonance and swallow pride, albeit in a way that allows for ample spinning of the truth. And really, there’s only one category of Expert Beginner from the three that I defined in the previous post that can get out of the game as a success: the Company Man.

Let’s consider casino poker as a metaphor for explaining the fate of Expert Beginners. Expert Beginners are essentially poker novices who sit down at a low stakes table, catch a run of incredible cards, and wind up with a big fat stack through the vagaries of chance. From there, the paths diverge depending on the archetype.

Xenophobe stays at the low stakes table because on some level he knows that he’ll get slaughtered by good players at the high stakes tables. He doesn’t tell himself this, naturally, but rather insists that he likes the down-to-earth vibe of the table or something. He also doesn’t cash out because being good at poker is important to him. So he rides his initial luck as far as it will go, but, sooner or later, that luck runs out. Slowly he loses control of his modest fortune, one bad bet and wrong play at a time until he’s chip-less. He eventually leaves with nothing in his pocket, unable to understand why repeating the exact behaviors that earned him success didn’t continue to work.

Master Beginner takes his initial luck and interprets it brazenly as utter poker mastery. He sits at the tables that have the highest stakes and goes all in all the time, perhaps without even looking at his hand. His beginners’ luck allows him to parlay a larger stack into an intensely successful (but brief) series of bluffs which catch the sharks and good players completely off guard, feeding back into the cycle and making him feel invincible. Once people figure out his game, they quickly and decisively dismantle him no matter at which table he’s seated, but his brief, intensely bright and meteoric rise is as memorable as the explosion and flameout.

It’s the Company Man approach that winds up with a chance for escape. Company Man has neither Xenophobe’s neurotic need to believe himself a poker expert nor Master Beginner’s complete faith in his delusion, so he is the one that might actually cash out and go do something else with the money before it’s all gone. There’s no guarantee, but at least he has a fighting chance.

Tragicomic Explosion: Fall of the Master Beginner

The Master Beginner’s fate is really the least interesting because it’s so entirely predictable. In the poker analogy, he blows into the high stakes table like a hurricane, creating massive disruption before blowing out just as quickly. In the real world, Master Beginners don’t last, either. Their timeline is highly accelerated.

A Master Beginner that is new to a company will come in and proclaim that everything is wrong and loudly bang his own drum as some kind of Messianic figure sent in to save the masses from themselves. Everyone believes him at first–even Experts. The reason is partially what I mentioned in the previous post: people assume someone this brazen must be right. But it’s also partially that people in the Competent to Expert range are aware that they’re not all-knowing and are inclined to accept initially at face value that someone knows things they don’t.

It isn’t long before the Competents, Proficients, and Experts figure out that Master Beginner is a bag of hot air. The only remaining questions then are (1) how long until management starts listening and acts on the words of their good developers; and (2) how many hilarious things happen before it does.

Some Master Beginners mount an impressive enough initial assault to be promoted quickly or named to a position of authority, but this just buys them a few more months or, in extreme cases, years, once the jig is up. The Master Beginner rockets through the atmosphere like a meteorite: blazingly fast, with blinding light, and ending in a spectacular conflagration.

Master Beginners are probably the least pitiable not only because they’re usually insufferable, personally, but also because they tend to land on their feet. If one’s shtick is being able to pull off a ridiculous skill bluff for a little while, securing interviews and getting job offers tends not to be a problem. Most people who know Master Beginners tend to shake their heads and say, “I can’t believe people keep hiring that guy!” Master Beginner inevitably fails at his goal because his goal is to receive the recognition he deserves as a consummate expert, and that never lasts for any length of time, wherever he goes.

Slow, Agonizing Defeat: Fall of the Xenophobe

Xenophobe’s arc is a longer-playing one by far than Master Beginner, and there is actually some remote chance for limited success. The goal of Xenophobe is to freeze the world in its current state, within the cocoon of his comfort zone. He wants to keep the same members on the same team using the same technologies to do the same work, in perpetuity. If you’re a bettor, you probably wouldn’t take those odds on a long timeline. Nevertheless that’s what he aims for.

If he happens to work for some remote outfit, nestled snugly within some byzantine bureaucracy, he might be able to keep the dream alive as he runs out the clock toward retirement. But situations where nothing about the work environment changes are rare, especially in software, and are only becoming rarer. There aren’t that many opportunities to lead a team that cranks out maintenance updates to some COBOL system and plans to keep doing so until 2034.

The far more common case is that things do change. People come and go. New frameworks must be learned. New ideas sneak in through various channels, and all of it chips away at the credibility of Xenophobe’s qualifications. He can manage at first, but eventually management overhears whispers from other developers of ways of doing things that could save tons of time and money. People from other departments hear about tech buzz words and Xenophobe doesn’t even know what they are. Day after day, month after month, his credibility erodes until something happens.

That something can vary. Perhaps it’s the appointment of a “co-architect” or a reorganization of the group. Perhaps he’s shuffled onto a different project or asked to continue to maintain the old version while an up-and-comer is tasked with architecting the rewrite. It could be outside consultants brought in as “staff augs” or farming off of whole projects elsewhere.

Interestingly, end for Xenophobe is rarely a termination. Unlike Master Beginner, Xenophobe doesn’t squirt gasoline on bridges and gleefully ignite them. He’s more pitiable and shrewd. So what happens is that he’s effectively put out to pasture in all but name. He might even get a better title or an office or something, but his responsibilities are divvied up and portioned out to others until he just collects a handsome wage to sit in his office and do very little.

While Xenophobe’s capacity for self-delusion is high, as is generally the case with Expert Beginners, his tolerance for cognitive dissonance is extremely low. This makes this “reorg” too much for him to take lying down. He may rage-quit–a sad option since he’s probably going to need to take a massive pay-cut to get hired anywhere else. He may simply rage, at which point his management is likely to show him a starker view of reality than he’s accustomed to seeing, which is a sad sight. Or he may do neither of those things and bitterly accept the new situation.

The fate of Xenophobe is actually intensely depressing. If you’ve worked with him directly, you probably don’t find it such during the short term since he’s often pretty hard to work with, but he’s not a pathological grand-stander like Master Beginner. He’s just a guy that lucked out, believed his own hype and got out of his depth. In a way, he’s like a lottery winner that squanders his fortune and winds up broke. Almost invariably, Xenophobes drift bitterly toward retirement, stripped of all real responsibility and collecting paychecks at the mercy of mid-level managers that continue to bolster (fake) the business case for keeping him on staff. When he’s not so lucky, he winds up in the same boat as the rage-quitter–taking a huge pay and responsibility cut, or crawling back to his former employer and then taking a huge pay and responsibility cut.

A Glimmer of Hope: The Company Man

Company Man lacks the neurotic pride of Xenophobe and the pathological cockiness of Master Beginner, and that has the potential to provide a way out. But let’s consider what happens to Company Men who don’t escape first. These are the ones who find their way into project management or line management and squander the false capital of their ‘technical expertise.’

At the core of the Expert Beginner experience is a quest for status and recognition. It’s not about money or even organizational power (beyond the software group, anyway). Truly. If it were, the Expert Beginner would never become Expert Beginner. He’d recognize that the path to a corner office usually doesn’t wind its way through the land of “knowing the Java compiler inside and out.” Someone interested primarily in being a C-level executive would recognize that programming is something you do for a few years and put up with until you can make the jump to project management, then line management, then VP-hood, etc. Expert Beginners relish being the best bowler in the alley and are willing to chase better bowlers away with baseball bats to protect their status if it comes down to it (or simply claim they won in spite of having a lower score, in the case of wildly delusional Master Beginner).

Company Men who don’t make it fail to recognize a life raft being floated to them. Once put into a managerial position of authority, they rule like technical Expert Beginners (architects or tech leads or whatever they used to be). To put it another way, they micromanage. In their previous role, they likely had some actual programming to do or else their control wasn’t absolute, so others could defy them, pick up the slack, or do what needed to be done to keep the wheels on the machine as it flew down the tracks. But a micromanaging Expert Beginner has nothing to do but meddle, bark orders, and chew people out for thinking for themselves. The wheels start to come off pretty quickly under his (mis-) management.

This Company Man unwittingly sabotages himself by finally having and exerting total technical control. Ironically, he sinks the ship by totally assuming the helm. Work stops getting done, morale plummets, projects fail, and HR issues abound as employees choose between defying the Expert Beginner and getting things right or obeying and having the project fail. Attrition mounts in these circumstances, and the Dead Sea Effect cycle time is radically accelerated with developers jumping ship like rats. Clearly, this is unsustainable, and the Company Man is demoted or let go. This is a tough spot for Company Man because he’s bad at tech but has a good track record for it on paper. He could theoretically be less incompetent at managing, but he’s crashed and burned in his only stab at that role. So he likely winds up hiring on as some senior developer elsewhere and trying to repeat the cycle. He isn’t quite as nimble as Master Beginner, but he’s not utterly trapped like Xenophobe, either. He’ll move on and probably have a chance to get management right the second time around by ceasing to play at technical acumen: a face-saving strategy.

And that brings us to the successful escapee of Expert Beginnerism: the (subconsciously) self-aware Company Man. He’ll never admit it, even to himself, but the successful Expert Beginner can feel the wolves closing in as the world changes and his policies are increasingly not successful. As he contemplates where to go from “Architect That Frequently Squabbles with Some of his Senior Developers,” this is the guy who hears a little, nagging voice in the back of his head that says, “You know, times are changing here faster than you want to, so perhaps its time to hang up your obviously quite impressive spurs and ‘retire’ to management.”

When he makes the jump, he also makes a clean break with his former life. He’s content to be known as the guy who used to be the architect but is now in management. There will be some amount of shared, mutual fiction between him and his formerly restless techie underlings as they’re grateful for his departure and wish him the best, in earnest, so that he stays where he’s at. They’ll agree with him that he was truly an awesome architect whose incredible skill set is just needed elsewhere. Everyone wins here, so why not?

And from here, there’s a new period of acquisition and the slate is wiped clean. The former technical Expert Beginner reaps the benefits of being considered an ‘Expert’ as he embarks on a new learning curve. And while certain personality leanings make this possible, there’s no guarantee that he’ll become an Expert Beginner at management. He might excel in it and be receptive to continued learning in a way that he wasn’t as an erstwhile techie. He might also become an Expert Beginner in management, but the odds here aren’t nearly as bad since management is really a lot more subjective–competence versus incompetence is harder to assess concretely. By keeping his hands off of the ship’s helm, sails, and really anything of import, the former Expert Beginner can be a decent captain by relying heavily on his competent crew, even if he was a poor sailor.

A Sad Tale

Following the career arc of Expert Beginners is really quite sad. In the early stages, one feels annoyed and a little indignant while watching advancement by luck instead of competence. As things progress, real damage is caused by poor implementation and wrong-headed approaches, resulting, for a lot of people, in stress, frustration, failure, and at times even lost jobs and failed ventures. In the end, the fate of the one that caused these things is probably poetically just, but it’s hard to find happiness in. A person ill-suited for a role assumed it, caused problems, and then suffered personal hardship. It’s not a great story.

This is my last Expert Beginner post on the blog until after the release of the E-book, when I will eventually publish the conclusion, entitled, “Wasted Talent: The Tragedy of the Expert Beginner.”

But the one thing to take away from this post is a bit of ability to assess what effect Expert Beginners may have on your career. You will usually see them crash and burn on a long enough timeline, if you can outlast them. Occasionally they will be promoted out of your way. Should you stick around and fight them or wait for their demise (or try to help them, if you’re altruistic and masochistic)? That certainly has to be a decision for you to make, but it should help to know that even slow-acting or overly-loyal organizations will self-correct eventually, provided they have a track record for success. So consider the company, its Expert Beginner, the type of Expert Beginner, and the distance along in the process of their fall from power when you make your decision.

Edit: The E-Book is now available. Here is the publisher website which contains links to the different media for which the book is available.


Is He Technical?

A short post today–I’m still sort of in frantic mode and switching gears in a variety of ways, but I didn’t want to go the whole week with just the one post.

Some time back, I observed some people working on a project in which the team consisted of some developers of varying experience levels and skill sets. There was also a project manager assigned to the project, but he definitely wanted to put the “manager” in “project manager.” Rather than Gantt charts and status reports, he insisted on being part of every technical decision, however coarse or fine grained. It was hard to tell, from my outsider perspective, whether his inputs (orders) made any sense or whether he was just wasting time and clouding the issue when he could have been focusing on logistics, communication, and removing obstacles from the path of the developers, as one might expect from a pure project manager.

It appeared to me that he wasn’t just failing to remove obstacles, but that he was an obstacle. This was confirmed by a conversation that I later overheard among a few of the developers in the form of a simple but profound and damning question. My understanding of this project manager’s background was that he was the sort of PM who had cut his teeth as a developer for a number of years and ‘graduated’ to project management. The unintentionally damning question from one of the developers was a simple, frustrated, “is he even technical?”

That might not seem like it matters at first blush, but that’s the kind of thing where, if you let it wash over you, there’s something important and fundamentally bad happening. The PM either has a technical background or not, and the badness is present either way. If he does not have a technical background, the obvious question is “why is he attempting to stick his nose in development and design discussions?” But if he is technical…ouch.

If he is technical, he’s communicating so poorly or getting concepts so wrong during the course of (micro) management that the developers are genuinely unclear on whether or not he has a programming background. Unintentionally damning. They’re not accusing him of anything or gossiping or anything along those lines–they’re so underwhelmed by his contributions that they think he doesn’t even possess table stakes, bare-minimum competence in the field.

The “duh” lesson here is not to blather on or bark orders when you don’t know what you’re talking about, but that’s really kind of an edge case. I’d say the take-away for the readership here is to ask yourself, assuming you’re in a position of authority, whether anyone would quietly wonder if you’re technical. Maybe it’s because you’ve been doing too much delegating or are busy with other things, but still, don’t let this be said about you. I’ve touched on this subject before in the context of a team lead, but this is a broader concern. As you go along working with others, take inventory from time to time, asking yourself whether anyone might be wondering skeptically how you came to be in a position of authority. If you think they might be, don’t blow that off and think it’s not worth proving. It is. Responsibility without respect is empty, so remember to earn yourself some respect from time to time.


The Weird Winds of Change

This is sort of an announcement post and sort of a meandering jaunt into my own personal journey. Also thrown in will be bits of apology, opportunity, and regret. So, let’s get right down to brass tacks.

A few weeks back, I gave notice at my job. I had come on board with a consulting firm to do heavy architectural work with object-oriented design, mainly in the .NET space, but fate had other ideas. I did a good bit of .NET work at first, but the vagaries of the local market and demand for software work were such that the business was pivoting increasingly toward customizing third party software installations such as Sharepoint, Salesforce, Microsoft Dynamics, etc. Doing simple, run-of-the-mill customization of these pieces of software is certainly good work for someone, but that someone isn’t me, so after biding my time and hoping for more compatible work, I decided to pull up anchor and chart my own course.

Actually, I more decided to shove off in a lifeboat without any oars, sails, or motor because I defied all career advice that I’ve ever received from saner people and just gave notice without lining up another job. There was a method, of sorts, to this madness. I’ve never really liked the way you get another job by slinking around behind your current employer’s back, and I was getting a lot of emails from recruiters, and well, just lots of things in general. In fact, I had reached a bit of a crossroads. I had various opportunities to generate passive income, a good number of requests to do freelance work in a variety of languages and frameworks under the DaedTech LLC umbrella, a lot of different interview opportunities. (I actually got an email about a job opportunity literally as I was typing this sentence.) The one thing I lacked was time. So I shoved off from the mothership, adrift in the night-sea, but with good intelligence that various islands were nearby with bananas and fresh water and friendly, helpful island monkeys and whatever else you see in fantasies where castaways build island paradises.

My intention was to do a bit of gonzo work-seeking. I’d tie up some loose ends and serve out the remainder of my notice time, and then I’d sit back, take inventory, and start the process of deciding what to do next, blogging all the while about my adventures while listening to people heckle me justifiably for being reckless with my career. I thought that would give me some time to deliberate between potentially working for a major tech player, relocating, casting my lot with a start-up, taking a stable local job, or just being the Founder and Principal of DaedTech LLC full time. Maybe I’d turn it into some kind of book and try to trade on the fact that pretty much anyone can get lucky at being a writer these days.

But fate, it would seem, had other plans. Interestingly, on the day that I gave notice, John Atten submitted the first Expert Beginner post to Reddit where it got enough love to rocket to the top for a day or so and drive a lot of traffic to the blog. This resulted in a surprising and awesome variety of invitations that I alluded to above, and it also occupied a good bit of my time keeping up while I wrapped things up at work. Add to this the fact that sending out a few actual resumes to some interesting companies and informing a few recruiters that I knew of my situation generated a good bit of interview activity right away, and I have been insanely busy for the last couple of weeks. Busy in a good way, but busy. Really, really busy.

I kept meaning to get around to announcing my job search with some grand blog post and to follow it up with tales of interviews, applications, and whatever else happens during a developer job search. I figured that I’d use this as a staging point to kick off a heavily networking-based, developer-community-oriented search for my next venture, but I actually wound up taking a job before I had time for any of that (I had actually left the post about job descriptions in my drafts folder for a couple of months–that wasn’t inspired by my situation these past couple of weeks). I got a great offer that was basically impossible to pass up, so I accepted and will be running a modestly-sized software development group starting on Monday, May 6th, doing double duty managing and serving as architect.

With this change, I’m hoping that the dust will settle a bit and my life will resume some sort of relatively normal pace instead of the break-neck speed it’s been at of late. Beside the change of jobs, here are some other new things in the pipeline that may be of interest to those reading:

  1. I am going to be authoring courses for Pluralsight–stay tuned for my first course to come out later this month.
  2. I mentioned it as a quick edit to the first Expert Beginner post, but look for that posting series to be wrapped up and published as an E-Book.
  3. Time to start reading others’ blogs and listening to podcasts again. I haven’t had time in the last several weeks, and I feel so out of touch that it’s a little icky.
  4. Looking to be better about responding to everyone’s comments. I really try to give thoughtful responses to everyone that takes the time to leave a comment, but I’ve definitely been a little lax about this lately, and I’m planning to be better about it.
  5. For those of you who have emailed me or otherwise contacted me about freelance work or joint programming ventures, you won’t be competing with interviews and recruiters and such, so I’ll be better about responsiveness.
  6. Normal posting cadence is Monday, Wednesday, Friday, though I’ve struggled at that pace recently. Planning to get back on track.
  7. Also, look for more programming-oriented posts as I’ll have my hands back in code with a lot more frequency
  8. And, most likely, look for most of this in earnest after Memorial Day. After my first week of work, I’ll be out of the country for a couple of weeks. When I come back, hopefully rested, I also plan to do some non-programming-related reading lest I become too one dimensional.

Thanks for your patience with the jerky post cadence and more rant-oriented, less code-heavy content of late, and most of all, thanks for reading.



What Your Job Descriptions Are Saying to Developers About Your Company

Every week I get a fairly steady stream of emails from recruiters, announcing an opportunity for some software development related job: engineer, programmer, senior developer, architect, and so on and so forth. These emails come in all shapes and sizes and, probably owing to my eclectic, polyglot background, they cover a range of different technologies and programming languages. One relatively common characteristic is that below the actual text of the email is pasted a job description. More often than not, I read this (or at least start to) out of general curiosity as to the state of the market. Some of them are reasonable and straightforward, making me think that the company in question would be a good, or at least decent, place to work. But others contain things that I’d call red flags.

Extrapolating beyond what gets sent to me via secondhand emails and generalizing to job boards and sites and other places where companies solicit talent (I can’t speak directly to these since I haven’t looked at them in quite a while), I think companies would be well served to consider what their job descriptions say to developers about them. It may not always be what’s intended. Consider some of the following characteristics of a job description and what they imply about the job.

Alphabet Soup of Technologies

“We favor and value superficial exposure and grandstanding over depth of knowledge and thoughtfulness.”

If your job description lists ten, twenty, even thirty (they get pretty ridiculous) different acronyms covering a smattering of programming languages, markup types, development methodologies, design patterns, and things that may not even actually exist, you’re sending the message that you value prospects that engage in a kind of bedpost-notching gamificiation when it comes to programming. If you stop and think about it, how would a developer acquire experience with all of those different technologies? Would you prefer he cram them all into a single project? Would you prefer that he pick or lobby for two to three new ones for each project he does and do a lot of projects? Would you prefer he never work on the same thing twice?

If the answer to any of these questions is “yes,” then you’re actively putting on the front porch light for people more concerned with playing with new toys than getting work done (like Fashionista). If the answer is “oh, well that’s not what we’re saying” then you’re asking the impossible. And you’re apparently targeting the sort of people who consider “I think I read a blog post about that once” a qualification for adding it to their resume. That leads to the hire of General Custer. So with this kind of ad, you’re targeting a group dynamic where people value breadth over depth of knowledge and are willing to exaggerate or even lie about either.

Emphasis on Years Spent on Particular Technologies

“We work harder, not smarter.”

Do you need someone that’s been banging out Java code for at least seven years? It has to be seven? Not six? If I’m at six and a half, should I follow the “always round up” method or the “round to even” method? I need to know so that I’ll know whether or not I’m qualified to program for you. I can round up? Great! Oh, wait. It says need four years of XML (whatever that means) and I only have three. I feel so inadequate. Unless… can I count non-contiguous years? I’m pretty sure that I “did XML” for a while about eight years back. Yessiree–I came into the office, day after day, and did XML. In fact, I think it was the same file, even. I did nothing but create the same XML file by hand every day for months, so that’s got to count for a lot, right?


Here’s the thing. You don’t actually want people who have “done Java” or “done XML” or “done whatever” for X years. What you actually want is people who are good at Java, XML, or whatever, and you mistakenly think that a good measure (or at least indicator) of that is how many years they’ve spent doing it. The problem is that this assumes that people acquire skill at the same rate, which is demonstrably false. It also assumes that they are spending all of that time improving, which, I would argue, becomes increasingly improbable with each additional year of experience. Certainly there are people who simply like working with a technology and wouldn’t have it any other way, but if you find someone who has been banging out Java code day in and day out for a decade, it might occur to you to ask them things like, “why aren’t you a lead or manager or architect or something?” The answer might be that they love having their hands on the keyboard, but it also might be (not said, of course) “I’m just not good enough at it to achieve anything besides not being fired.”

Are those the people that you want to hire? Probably not, but are you that confident that you can cull them out in an interview when the stakes are pretty high? As an awesome saying goes, you run the risk of hiring not a Java developer with ten years experience but a Java developer with the same one year of experience ten times. If you want talent and achievement, what you should actually want is people who are good at programming and design in general. It really doesn’t even matter what language(s) the developer knows if she’s good, and it certainly doesn’t matter how many years she’s been cranking out code in it. But if you start focusing on years/tech metrics, you’re going to get candidates optimized for that–you’re going to have a department dominated by worker bees who’ve been churning out innovation-free code for decades.

Applicants will Take a Forty-Five Question Test

“However extensive your previous experience, you’ll always be junior to us.”

What you ask candidates to do resonates with them beyond the interview process and into their employment; it sets the tone for what their tenure will be like. And what do you think it says to them when you give them something reminiscent of an SAT subject test? It says, “alright young student, if you can pass this standardized aptitude test, you are deemed worthy of learning at the feet of our esteemed senior developers.” Standardized tests and the hiring process are both necessarily reductionist activities, since they involve culling a very large percentage of potential applicants down to a much smaller percentage, but there the similarities end. Standardized tests are administered by nameless teachers, graded by faceless graders, and judged by admissions officers the students will never know.

Standardized job application quizzes are administered by internet or hiring authority, graded by the same, and judged by the same. If the applicant doesn’t score an 80% or whatever is necessary to move on, then no big deal. But if they do wind up hiring on, it will be with people to whom they’ve submitted to a student-professor/grader/administrator/gatekeeper relationship. That person can always point out at any time during your tenure that you didn’t know when filling out your scantron that the C# compiler will not choke on “virtual public void MethodName.” I recognize that this could be claimed to some degree with any method of candidate evaluation, but nothing says, “you’re no different than an entry level kid” like simulating the kinds of standardized testing that most people haven’t done in years or decades.



“We’re embarrassingly waterfall and we don’t know how to fix it.”

Companies that are proud of waterfall development methodologies come right out and tout it as their way of doing things (or they call it something like “Rational Unified Process”). That’s not going to be ideal for a lot of top talent, and it might even be a deal-breaker for some of them, but at least it seems self-aware. If you swap this frank assessment for the rather meaningless term “SDLC” (short for “Software Development Lifecycle”), it says that you don’t actually want people to know your software development methodology is. Be honest–if this is on your job description, and a candidate asks whether or not your process is agile as part of the “questions from the candidate” section, how are you going to respond? My money is on hem, haw, and make a comment about how you’re “in the process of getting a little more agile but we kind of *ahem*, that is, ah, we’re kind of still somewhat, er mostly waterfall.” Why do I say that? Well your “SDLC” says, “kinda-sorta-maybe-something-other-than-waterfall,” but your “phases” says, “really, really waterfall.”


The reason that I say this is more of a bad sign for candidates than “waterfall and proud” is that “waterfall and proud” indicates that there is purpose and belief in that process, making it somewhat more likely that things are stable and sane. In smaller shops or places that do small fixed bid types of projects, for instance, you can probably have some success with a waterfall approach. Candidates recognize that (or else they’re simply unaware that there’s an alternative to the waterfall “procrastinate-rush” way of doing things). But if you hide your waterfall behind vague acronyms, it tells candidates that you’re aware that your process is far from ideal but you haven’t done anything about it. From this, candidates can only infer that you’re lazy/sloppy when it comes to process or else that you’re not competent when it comes to process. Neither one exactly rolls out the welcome mat for top-notch talent.

If you want to describe your development methodology and it isn’t something simple like “Scrum” or “XP,” I’d suggest asking for experience with exactly what you want: probably design, implementation, and stabilizing/sustaining. Whether your approach has “phases” or “sprints” or whatever, it’s going to have those activities, so you may as well list them by name. Rightly or wrongly, SDLC has drifted from being a way to describe software in different states of development and has come instead to describe a process that’s hard to pin down and even harder to follow. You don’t want to broadcast that, true or not.

Be Prepared to Answer Some Real Brain Teasers!

“We think we’re MENSA” or “We think we’re Google” (which thinks it’s MENSA)

Applicants get it. You want to hire clever people. You want to hire people that think outside the box. Literally. And not only that, but you want to demonstrate that you think outside the box by asking non-programming or heavily algorithm-related questions when gauging whether candidates think outside of the box. It would be so in the box to ask programmers questions about programming or to have them program. You’re looking for some kind of box-thinking-outside synergy where everyone has their secret puzzle decoder ring and the cliches flow like box wine.


To you, it looks selective. To most people, it just looks gratuitously self-congratulatory. If you actually are a Google or another respected tech titan and you have the rep to back it up, applicants will prostrate themselves and tolerate this silliness for a chance to punch their ticket with your name on their resume. But if you’re Acme Inc. and you specialize in making shoelaces, you’re threatening to drive away serious talent and be left with goofballs, word-game enthusiasts, and trivia experts more interested in standing behind metaphorical velvet ropes as VIPs than doing high quality work. Unless your business model is this, you’d be better served to hire people who can write code than people who know how to measure exactly four gallons using three and five gallon jugs.

So Then What To Say?

If it seems as though I’m impossible to please, I’m really not. In fact, just having these things in your job description in no way means that what I’ve said is true about your company–it just means that this is the vibe you’re giving off. But if you want to give off a better vibe, I’d suggest a simple description of what the job’s responsibilities are and what would be necessary in order to do that job successfully. There’s no number of years or soup of technologies that do that–what does it is something like this: “we’re looking for Java web developers who are familiar with IoC containers and can meet deadlines with minimal supervision.” No gimmicks, no window-dressing on potentially unfavorable realities, and no weird, degrading exams.

So then how do you go about separating the wheat from the chaff during the interview process? Without exception, the places I’ve found that seem best at doing this are the ones that dole out actual programming assignments. It’s one of those things that is apparently so blindingly obvious that most don’t think of it; if you want to determine whether someone can complete programming assignments, give them one to complete. If you try to interview developers the way you would project managers, middle management, salespeople, etc., it’s kind of crapshoot. A developer that’s very good at memorizing trivia about the compiler or reciting the benefits of object-oriented programming may not actually be able to program. A standard, two hour interview with the trivia lightning round, followed by classic tradeoff-type questions, will not uncover this nearly so well as asking the person to spend five to twenty hours coding up some sample assignment.

If that’s not practical for logistical reasons or because of hiring particulars at your institution, you might at least ask for code samples to evaluate. Or perhaps you could spend a few hours pair programming with the candidate or doing a code review of open source code. Whatever you do, though, the important thing to remember is that you want to send the message to developers that you’re looking for people who are competent and demonstrate as much when asked to do so. By all means, evaluate and select based on other important criteria–personability, communication skills, organization, etc. But what you’re looking for, at the core of it, are people who are going to be efficient and competent developers. So when you roll out the welcome mat for them in the form of a job description, consider the first impression that you’re making. Ask yourself if you think it’s one that will intrigue those efficient and competent developers.