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 re-balanced 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, since this could also apply to other engineering disciplines or probably other skilled professions) 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 and the people there or something. But he 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 it runs out sooner or later and he slowly 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 where the sharks and good players are completely caught off guard, which feeds back into the cycle and makes 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. 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: that 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 (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 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, but nevertheless that’s what he wants and 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 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 re-write. It could be outside consultants brought in as “staff augs” or farming off of whole projects elsewhere.

Interestingly, it’s 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, which 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 one 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 really 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 earning or 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 micro-managing 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 and 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 and stop playing techie with 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 stops being Architect. 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 and competence versus incompetence 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 at 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. And, in the end, the fate of the one that caused these things is probably poetically just, but 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.

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.

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.

Cheers!

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.

%Phases%SDLC%

“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.

I got an A in that class. I actually don’t remember which class it was any longer because it happened in a number of them. It happened in high school, college, and graduate school. I started off a B student on subjectively-graded assignments and ‘improved’ steadily for the duration of the course until I wound up with an A. Many of my peers followed the same trajectory. It was a nice story of growth and learning. It was the perfect narrative…for the teacher.

What could be better than a fresh-faced crop of students, talented but raw, eager to learn, being humbled and improving under the teacher’s tutelage? It’s the secondary education equivalent of a Norman Rockwell painting. It gives the students humility, confidence, and a work ethic, and it makes the teacher look and feel great. Everyone wins, so really, what’s the harm in the fiction? So what if it’s a bit of a fabrication? Who cares?

Well, I did. I was a relentless perfectionist as a student and this sort of evaluation drove me nuts. I sought out explanations for early B’s in classes where this happened and found no satisfaction in the explanations. I raged against the system and eventually cynically undercut it, going out of my way to perform the same caliber of work in the before and after pictures, doggedly determined to prove conspiracy. My hypothesis was confirmed by my experiments–my grades improved even as my work did not–and my triumphant proof of conspiracy was met with collective yawns and eye-rolls by anyone who actually paused long enough to listen to me.

I learned a lesson as a child and young adult about the way the academic world worked. Upon graduation from college, I was primed to learn that the business world worked that way too.

The Career Train

There are a lot of weird symmetries, quirks, and even paradoxes in the field of macroeconomics. It’s truly a strange beast. Consider, for instance, the concept of inflation, wherein everyone gets more money and money becomes worth less, but not necessarily in completely equal proportions. We’re used to thinking of money in a zero-sum kind of sense–if I give you ten dollars, then I am ten dollars poorer and you are ten dollars richer. But through the intricacies of lending and meta-transactions surrounding money, we can conceive of a scheme where we start with ten dollars and each wind up with six dollars some time later. And so it goes in life–as time goes by, we all have more money (at least in lending-based, market economics). If things get out of whack and everyone doesn’t have more money as time goes by, you have stagnation (or deflation). If things get out of whack the other way, you wind up with runaway inflation and market instability. They system works (or at least works best) when everyone gets a little more at a measured, predictable, and homogeneous pace.

The same thing seems to happen throughout our careers. We all start in the business world as complete initiates, worth only our entry level paychecks, and we all trudge along throughout our careers, gradually acquiring better salaries, titles, accessories, and office locations. Like a nice but not-too-steep interest rate, people have an expectation of dependable, steady, slight gain throughout their career. Two promotions in your twenties is pretty reasonable. Managing a team by your mid thirties. A nice office and a VP or director title in your later forties, and perhaps a C-level executive position of some kind when you’re in your fifties to sixties. On average, anyway. Some real go-getters might show their prodigious talents by moving that timeline up by five years or so, while some laggards might move it back by the same amount, topping out at some impressive but non-executive title.

Okay, so I know what you’re thinking. You want to shout “Mark Zuckerberg!” at me. Or something along those lines–some example of a disruptive entrepreneur that proves there is a different, less deterministic path. Sure, there is. People who opt out of the standard corporate narrative do so at large risk and large possible reward. Doing so means that you might be Zuckerberg or that Instagram guy, but it means that you’re a lot more likely to be working in your garage on something that goes nowhere while your friends are putting in their time in their twenties, getting to the best cubicles, offices, and corner offices a few years before you do. By not getting on the train when all your friends do, you’re going to arrive later and behind them–unless you luck out and are teleported there by the magic teleportation fairy of success.

So forget the Zuckerbergs and the people who opt out in the negative sense and never get back in. Here in corporate land, the rest of us are on a train, and there’s not a lot of variance in arrival times on trains. If you get right to the front of the train, you may get there a few minutes early, but that’s all the wiggle-room you get. The upside to this mode of transportation is that trains are comfortable, dependable, and predictable. A lot of people prefer to travel this way, and the broad sharing of cost and resources make it worth doing. It’s a sustainable, measured pace.

Everyone Meets Expectations

They don’t stop two trains on the track so that people who are fast and serious about going fast can sprint to the next train. It may be good for a few, but it would enrage the many and throw the system out of whack. That applies to trains, and it applies to your performance reviews. The train runs on time, and the only question is whether you’re in the front (exceeds expectations) or the back (meets some expectations). If you’re perennially in front, you’ll get that C-Level corner office at fifty, but perennially in back, and you’ll just be the sales manager at fifty.

Seem cynical? If so, ask yourself this: why are there no office prodigies? In school, there were those kids who skipped a grade or who took Algebra with the eighth graders while their fellow seventh graders were in Pre-Algebra. There were people who took AP classes, aced their SATs, and who achieved great, improbable things. What happens to those outliers in the corporate world, if they don’t drop out and go the Zuckerberg route? Why is there no one talented enough to rocket through the corporate ranks the way there was in school? Doesn’t that seem odd? Doesn’t it seem like, by sheer odds, there should be someone who matches Zuckerberg as a twenty-something wunderkind CEO by coming up through the corporate world rather than budging back in from entrepreneur-land? Maybe just one, like, ever?

I would think so. I would think that corporate prodigies would exist, if I didn’t know better–if I didn’t know that the mechanism of corporate advancement was a train, a system designed to quite efficiently funnel everyone toward the middle. You might exceed expectations or fail to meet them at any given performance review, but on a long enough timeline, you meet expectations because everyone meets expectations. It’s the most efficient way to create a universal and comfortable narrative for everyone. That narrative is that all of everyone’s work and achievement through life has built toward something. That the corner office is the product of forty years of loyalty, dedication, and cleverness. After forty years of meeting expectations, you, too, can finally arrive.

This isn’t some kind of crazy conspiracy theory. This is transparently enforced via HR matrices. All across the nation and even the world, there are corporate policies in place saying that level six employees can’t receive two promotions before level seven employees receive one. It wouldn’t be fair to pay Suzy more than Steve since Steve has three more years of industry experience. Organizations, via a never-ending collection of superficially unrelated policies, rules, regulations, and laws, take a marathon and put it on a single-file people-mover.

Wither the Performance Review

So if I had a parallel experience with a manufactured narrative in school and the corporate world, how to explain grade-skippers and AP-takers? Simple. In school, the narrative occurs for the benefit of the teacher on the micro (single quarter or semester) level. In the work world, it occurs for everyone’s benefit for the rest of your working life.

So why do organizations bother with the awkward performance review construct? Well, in part because it’s necessary to make justifications about issues like pay, position, and promotions. If people receive titular, “career-advancing” promotions every three to four years, a review is necessary in the first year to tell them that they need to “get better at business” or something. Then in the second year, they can hear that they’re making “good strides at business,” followed in the third year by a hearty congratulations for “being great at business,” and, “really earning that promotion to worker IV.” Like a scout earning a merit-badge, this manufactured narrative will be valued by the ‘earner’ because it supplies purpose to the past three years, even if the person being reviewed didn’t “get better at business” (whatever that means). But the other purpose is providing the narrative for the reviewers. If the reviewers’ reports started out “bad at business” and ‘improved’ under his tutelage, his own review narrative goes a lot better, and so on, recursively, up the chain. What a wonderful world where everyone is helping everyone get better at a very measured pace, steadily, over the course of everyone’s career.

But just as I railed against this concept in school, so do I now. I’ve never received sub-standard reviews. In general annual review parlance, mine have typically been “exceeds expectations but…” where “but” is some reason that I’m ‘not quite ready’ for a promotion or more responsibility just yet. Inevitably, this magically fixes itself.

So what if we did as Michael O. Church suggests and simply eliminate the performance reviews along these lines? Poof. Gone. I don’t know about you, but I might just find a “we’re not promoting you because that’s our policy” refreshingly honest as compared to a manufactured and non-actionably vague piece of ‘constructive’ criticism. (This is not to be confused with a piece of feedback like “your code should be more modular,” or, “you should deliver features more quickly,” both of which are specific, actionable, and perfectly reasonable critiques. But also don’t require some kind of silly annual ceremony where I find out if I’m voted onto Promotion Island or if I’ll have to play again next year.) I certainly don’t have an MBA, and I’m not an expert in organizational structuring and management, but it just seems to me as though we can do better than a stifling policy of funneling everyone toward the middle and manufacturing nonexistent deficiencies so that we can respond by manufacturing empty victories. I can only speak for myself, but you can keep the guaranteed trappings of ascending the corporate ladder if you just let me write my own story in which my reach exceeds my grasp.

So in no particular order, here are some things that you might find helpful if you’re throwing yourself out there on the market.

Avoid the Firehose

Programming jobs are becoming more and more plentiful, and, in response to that demand, and contrary to all conventional logic about markets, the supply of programmers is falling. If you work as a programmer, the several emails a week you get from recruiters stand in not-so-mute testimony to that fact. If you decide that it’s time to start looking and throw your resume up on Dice, Monster, and CareerBuilder, your voicemail will fill up, your home answering machine will stop working, and your email provider will probably throttle you or start sending everything to SPAM. You will be absolutely buried in attempts to contact you. Some of them will be for intern software tester; some of them will be for inside sales rep; some of them will be for super business opportunities with Amway; some of them won’t even be in your native language.

Once you do filter out the ones (dozens) that are complete non-starters, you’ll be left with the companies that have those sites on some kind of RSS or other digital speed dial, meaning that they do a lot of hiring. Now, there are some decent reasons that companies may do a lot of hiring, but there are a lot of not-so-decent reasons, such as high turnover, reckless growth, a breadth-over-depth approach to initial selection, etc. To put it in more relatable terms, imagine if you posted a profile on some dating site and within seconds of you posting it, someone was really excited to meet you. It may be Providence, but it also may be a bit worrisome.

The long and short of my advice here is that you shouldn’t post your resume immediately to sites like these. Flex your networking muscle a bit, apply to some appealing local companies that you’d like to work at, contact a handful of recruiters that you trust, and see what percolates. You can always hit the big boards later if no fish are biting or you start blowing through your savings, but if you’re in a position to be selective, I’d favor depth over breadth, so to speak.

Don’t Be Fake

When it comes time to the do the actual interview, don’t adopt some kind of persona that you think the interviewers want to see. Be yourself. You’re looking to see whether this is going to be a fit or not, and while it makes sense to put your best foot forward, don’t put someone else’s best foot forward. If you’re a quiet, introverted thinker, don’t do your best brogrammer imitation because there’s a ping pong table in the other room and the interviewers are all 20-something males. You’re probably going to fail to fit in anyway, and even if you don’t, the cultural gulf is going to continue to exist once you start.

And above all, remember that “I don’t know” is the correct answer for questions to which you don’t know the answer. Don’t lie or try to fake it. The most likely outcome is that you look absurd and tank the interview when you could have saved yourself a bit of dignity with a simple, “I’m not familiar with that.” But even if this ruse somehow works, what’s the long-play here? Do you celebrate the snow-job you just pulled on the interviewer, even knowing that he must be an idiot (or an Expert Beginner) to have fallen for your shtick? Working for an organization that asks idiots to conduct interviews probably won’t be fun. Or perhaps the interviewer is perfectly competent and you just lucked out with a wild guess. In that case, do you want to hire on at a job where they think you’re able to handle work that you can’t? Think that’ll go well and you’ll make a good impression?

If you don’t know the answers to questions that they consider important, there’s a pretty decent chance you’d be setting yourself up for an unhappy stay even if you got the job. Be honest, be forthright, and answer to the best of your ability. If you feel confident enough to do so, you can always pivot slightly and, for instance, turn a question about the innards of a relational database to an answer about the importance of having a good DBA to help you while you’re doing your development work or something. But whatever you do, don’t fake it, guess, and pray.

Have the Right Attitude

One of the things I find personally unfortunate about the interview process is how it uniquely transports you back to waiting to hear whether or not you got into the college of your dreams. Were your SAT scores high enough? Did you play a varsity sport or join enough clubs? Did you have enough people edit your essays? Oh-gosh-oh-gee I hope they like me. Or, really, I hope I’m good enough.

Let me end the suspense for you. You are. The interview process isn’t about whether you’re good enough, no matter how many multiple choice questions you’re told to fill out or how much trivia an interviewer sends your way in rapid fire bursts of “would this compile!?” The interview process is ultimately about whether you and the company would be a good mutual fit. It isn’t just a process to help them determine if you’d be able to handle the work that they do. It’s also a chance for you to evaluate whether or not you’d like doing the work that they give you. Both parts are equally important.

So don’t look at it as you trying to prove yourself somehow. It’s more like going to a social event in an attempt to make friends than it is like hoping you’re ‘good’ enough for your favorite college. Do you want to hang out with the people you’re talking to for the next several years of your life? Do you have similar ideas to them as to what good software development entails? Do you think you’d enjoy the work? Do you like, respect, and understand the technologies they use? This attitude will give you more confidence (which will make you interview better), but it also sets the stage for the next point here.

Don’t Waste Your Questions

In nearly every interview that I’ve ever been a part of, there’s the time for the interviewer to assess your suitability as a candidate via asking you questions. Then there’s the “what questions do you have for me” section. Some people will say, “nothing — I’m good.” Those people, as any career site or recruiter will tell you, probably won’t get an offer. Others will take what I believe is fairly standard advice and use this time as an opportunity to showcase their good-question-asking ability or general sharpness. Maybe you ask impressive sounding things like, “what’s your five year plan,” or, “I have a passionate commitment to quality as I’m sure you do, so how do you express that?” (the “sharp question” and “question brag,” respectively).

I think it’s best to avoid either of those. You can really only ask a handful of questions before things start getting awkward or the interviewer has to go, so you need to make them count. And you’ll make them count most by asking things that you really want to know the answer to. Are you an ardent believer in TDD or agile methodologies? Ask about that! Don’t avoid it because you want it to be true and you want them to make an offer and you don’t want to offend them. Better to know now that you have fundamental disagreements with them than six months into the job when you’re miserable.

As an added bonus, your interviewer is likely to be a pretty successful, intelligent person. She’s probably got a fairly decent BS detector and would rather you ask questions to which you genuinely want to know the answers.

Forge your Questions in the Fires of Experience

So you’re going to ask real questions, but which questions to ask… My previous suggestion of “ones you want the answer to” is important, but it’s not very specific. The TDD/agile question previously mentioned is an example of one good kind of question to ask: a question which provokes an answer that interests you and gives you information about whether you’d like the job. But I’d take it further than this.

Make yourself a list of things you liked and didn’t like at previous jobs, and then start writing down questions that will help you ferret out whether the things you liked or didn’t will be true at the company where you’re interviewing. Did you like way your last company provided you with detailed code reviews because it helped you learn? Ask what kinds of policies and programs they have in place to keep developers current and sharp. Did you not like the mess of interconnected dependencies bogging down the architecture of the code at your last stop? Ask them what they think of Singleton as a design pattern. (I kid, but only kind of.)

You can use this line of thinking to get answers to tough-to-ask questions as well. For instance, you’re not going to saunter into an interview and say, “So, how long before I can push my hours to second shift and stroll in at 2 PM?” But knowing things about a company like dress code, availability of flex hours, work-from-home policy, etc. is pretty valuable. Strategize about a way to ask about these things without asking–even during casual conversation. If you say something like “rush hour on route 123 out there seems pretty bad, how do people usually avoid it,” the next thing you hear will probably be about their flex hours policy, if the company has one.

Negative Bad, Zero-Sum Fine

Another piece of iconic advice that you hear is “don’t talk badly about your former/current employer.” I think that’s great advice to be on the safe side. I mean, if I’m interviewing you, I don’t want to hear how all of your former bosses have been idiots who don’t appreciate your special genius, nor do I want to hear juicy gossip about the people at your office. Staying upbeat makes a good impression.

That said, there is a more nuanced route you can travel if you so choose, that I think makes you a pretty strong candidate. If I’m interviewing you, I also know that your former positions aren’t all smiles and sunshine or you wouldn’t be sitting in front of me. When talking about past experience, you can go negative, but first go positive to cancel it out.

My current employer has some really great training programs, and I’ve enjoyed working with every project manager that I’ve been paired with. That’s contributed to me enjoying the culture–and feeling a sense of camaraderie, too. Of course, there were some things I might have done differently in our main code base, from an architectural perspective. I’d have liked to see a more testable approach and an IoC container, perhaps, but I realize that some things take time to change, especially in a legacy code base.

Now you’ve communicated that you recognize that the architectural approach to your code base was sub-optimal, but that you maintain a positive attitude in spite of that. Instead of the interviewer hearing, “man, those guys over there are procedural-code-writing cretins,” he hears, “some things were less than ideal, and I’d like them to improve, but I grow where I’m planted.”

Gather your Thoughts

After you’re done, stop and write down what you thought. I mean it. Walk out of the building, and in your car or on a nearby bench, plop down and write your impressions while they’re fresh in your mind. What did you like, what worries you, what questions should you follow up with, what specifics can you cite? Things will be fuzzy later, and this information is solid gold now.

Your brain is going to play weird tricks on you as time goes by and you’re considering an offer or the next round of interviews. Something that struck you as a red flag might be smoothed over in your mind as you grow increasingly tired of your job hunt. I know they said that they’re as waterfall as Niagra and proud, but I think the tone of voice and non-verbal cues might have indicated a willingness to go agile. You’ll fool yourself. You’ll talk yourself into things. That is, unless you write them down and bring them up as concerns the next time you talk with the company or a representative thereof.

Maintain Perspective

Interviewing is an inherently reductionist activity, both for you and for the company. Imagine if marriage worked like job interviews. The proposition would be put to you and your potential mates this way:

Alright, so you have have about two or three cracks at this whole marriage thing before you’re too old for it, so take your time and make a good decision and all that, but do it really fast. You’re going to meet for lunch, a little Q&A, and then you’ll have just enough time to send a thank-you note before you hear thumbs up or thumbs down from your date. If it’s thumbs up, you have a few days to decide if the prenuptial agreement looks good, if you have similar opinions on when to have children and how many, yadda-yadda, and hurry up, and, “do you take this person to be your lawfully wedded, blah, blah, you may now kiss, etc., whatever, done.

Think a few important details might get missed in that exchange? Think you might be left after an inexplicable rejection, stammering, “b-b-but I know how to cook and I really have a lot to offer… why… I just don’t get it.” It’s pretty likely. There are going to be a lot of bad decisions and the divorce rate will be pretty high.

Back to the interview process, just remember to keep your chin up. You might have interviewed for a job that had already been filled except for the detail of technically having to interview a second person. Maybe the CEO’s son got the job instead of you. Maybe you wore a gray suit and the man interviewing you hates the color gray with a burning passion. Maybe you had a lapse when talking about your WPF skills and said WCF, and someone thinks that makes you a moron. The list goes on, and it often makes no sense. It makes no sense in the way that you’ll look at a company’s website and see a weirdly blinking graphic and think it looks unprofessional and decide not to apply there. You make snap judgments, and so do they. It’s the name of the game. Don’t take it personally.

Visualized like this, I think everyone might agree that there’s some point at which the drop is too far, though there’s likely some disagreement on where exactly this is. Personally, I used to subscribe to the “fits on a screen” heuristic and would only start looking to pull out methods if it got beyond that. But in more recent years, I think even smaller. How small? I dunno–five or six lines, max. Small enough that you’ll only ever see one try-catch or control flow statement in there. Yeah, seriously, that small. If you’re thinking it sounds kind of crazy, I get that, but give it a try for a while. I can almost guarantee that you’ll lose your patience for looking at methods that cause you to think, “wait, where was loopCounter declared again–before the second or third while loop?”

If you accept the premise that this is a good way to do things or that it might at least be worth a try, the first thing you’ll probably wonder is how to go about doing this from a practical standpoint. I’ve definitely encountered people and even whole groups who considered method sizes like this to be impractical. The first thing you have to do is let go of the notion that classes are in some kind of limited supply and you have to be careful not to use too many. Same with modules, if your project gets big enough. The reason I say this is that having small methods means that you’re going to have a lot of them. This in turn means that they’re going to need to be spread to multiple classes, and those classes will occupy more namespaces and modules. But that’s okay. If you encounter a large application that’s well designed and factored, it’s that way because the application is actually a series of small, focused components working together. Monolithic doesn’t scale well.

Getting Down to Business

If you’ve prepared yourself for the reality of needing more classes organized into more namespaces and modules, you’ve really overcome the biggest obstacle to being a small-method coder. Now it’s just a question of mechanics and practice. And this is actually important–it’s not sufficient to just say, “I’m going to write a lot of methods by stopping at the fifth line, no matter what.” I guarantee you that this is going to create a lot of weird cross-coupling, unnecessary state, and ugly things like out parameters. Nobody wants that. So it’s time to look to the art of creating abstractions.

As a brief digression, I’ve recently picked up a copy of Uncle Bob Martin’s Clean Code: A Handbook of Agile Software Craftsmanship and been tearing my way through it pretty quickly. I’d already seen most of the Clean Coder video series, which covers some similar ground, but the book is both a good review and a source of new and different information. To be blunt, if you’re ever going to invest thirty or forty bucks in getting better at your craft, this is the thing to buy. It’s opinionated, sometimes controversial, incredibly specific, and absolute mandatory reading. It will change your outlook on writing code and make you better at what you do, even if you don’t agree with every single point in it (though I don’t find much with which to take issue, personally).

The reason I mention this book and series is that there is an entire section in the book about functions/methods, and two of its fundamental points are that (1) functions should do one thing and one thing only, and (2) that functions should have one level of abstraction. To keep those methods under control, this is a great place to start. I’d like to dive a little deeper, however, because “do one thing” and “one level of abstraction per function” are general instructions. It may seem a bit like hand-waving without examples and more concrete heuristics.

Extract Finer-Grained Details

What Uncle Bob is saying about mixed abstractions can be demonstrated in this code snippet:

public void OpenTheDoor()
{
    GrabTheDoorKnob();
    TwistTheDoorKnob();
    TightenYourBiceps();
    BendYourElbow();
    KeepYourForearmStraight();
}

Do you see what the issue is? We have a method here that describes (via sub-methods that are not pictured) how to open a door. The first two calls talk in terms of actions between you and the door, but the next three calls suddenly dive into the specifics of how to pull the door open in terms of actions taken by your muscles, joints, tendons, etc. These are two different layers of abstractions: one about a person interacting with his or her surroundings and the other detailing the mechanics of body movement. To make it consistent, we could get more detailed in the first two actions in terms of extending arms and tightening fingers. But we’re trying to keep methods small and focused, so what we really want is to do this:

public void OpenTheDoor()
{
    GrabTheDoorKnob();
    TwistTheDoorKnob();
    PullOpenTheDoor();
}
private static void PullOpenTheDoor()
{
    TightenYourBiceps();
    BendYourElbow();
    KeepYourForeArmStraight();
}

Create Coarser Grained Categories

What about a different problem? Let’s say that you have a method that’s long, but it isn’t because you are mixing abstraction levels:

public void CookQuesadilla()
{
    ChopOninons();
    ShredCheese();
    GetOutThePan();
    AddOilToPan();
    TurnOnTheStove();
    SprinkleOnionsAndCheeseOnTortilla();
    PutTortillaInPan();
    CookUntilFirm();
    FoldTortillaAndCookUntilBrown();
    FlipTortillaAndCookUntilBrown();
    RemoveCookedQuesadilla();
    RemovePanFromStove();
    ScrubPanWithBrush();
    ServeQuesadillas();
}

These items are all at the same level of abstraction, but there are an awful lot of them. In the previous example, we were able to tighten up the method by making the abstraction levels consistent, but here we’re going to actually need to add a layer of abstraction. This winds up looking a little better:

public void CookQuesadilla()
{
    PrepareIngredients();
    PrepareEquipment();
    PerformActualCooking();
    FinishUp();
}
private static void PrepareIngredients()
{
    ChopOninons();
    ShredCheese();
}
private static void PrepareEquipment()
{
    GetOutThePan();
    AddOilToPan();
    TurnOnTheStove();
}
private static void PerformActualCooking()
{
    SprinkleOnionsAndCheeseOnTortilla();
    PutTortillaInPan();
    CookUntilFirm();
    FoldTortillaAndCookUntilBrown();
    FlipTortillaAndCookUntilBrown();
    RemoveCookedQuesadilla();
}
private static void FinishUp()
{
    RemovePanFromStove();
    ScrubPanWithBrush();
    ServeQuesadillas();
}

In essence, we’ve created categories and put the actions from the long method into them. What we’ve really done here is create (or add to) a tree-like structure of methods. The public method is the root, and it had thirteen children. We gave it instead four children, and each of those children has between two and five children of its own. To tighten up methods, it’s perfectly viable to add “nodes” to the “tree” of your call stack. While “do one thing” is still a little elusive, this seems to be carrying us in that direction. There’s no individual method that you look at and think, “boy, that’s a lot of stuff going on.” Certainly its a matter of some art and taste, but this is probably a good way to think of it–organize stuff into hierarchical method categories until you look at each method and think, “I could probably memorize what that does if I needed to.”

Recognize that Control Flow Uses Up an Abstraction

So far we’ve been conceptually figuring out how to organize families of methods into well-balanced tree structures, and that’s taken us through some pretty mundane code. This code has involved none of the usual stuff that sends apps careening off the rails into bug land, such as conditionals, loops, assignment, etc. Let’s correct that. Looking at the code above, think of how you’d modify this to allow for the preparation of an arbitrary number of quesadillas. Would it be this?

public void CookQuesadillas(int numberOfQuesadillas)
{
    PrepareIngredients();
    PrepareEquipment();
    for(int i = 0; i < numberOfQuesadillas; i++)
        PerformActualCooking();
    FinishUp();
}

Well, that makes sense, right? Just like the last version, this is something you could read conversationally while in the kitchen just as easily as you do in the code. Prep your ingredients, then prep your equipment, then for some integer index equal to zero and less than the number of quesadillas you want to cook, increment the integer by one. Each time you do that, cook the quesadilla. Oh, wait. I think we just went careening into the nerdiest kitchen narrative ever. If Gordon Ramsey were in charge, he'd have strangled you with your apron for that. Hmm... how 'bout this?

public void CookQuesadillas(int numberOfQuesadillas)
{
    PrepareIngredients();
    PrepareEquipment();
    PerformActualCooking(numberOfQuesadillas);
    FinishUp();
}
private static void PerformActualCooking(int numberOfQuesadillas)
{
    for (int index = 0; index < numberOfQuesadillas; index++)
    {
        SprinkleOnionsAndCheeseOnTortilla();
        PutTortillaInPan();
        CookUntilFirm();
        FoldTortillaAndCookUntilBrown();
        FlipTortillaAndCookUntilBrown();
        RemoveCookedQuesadilla();
    }
}

Well, I'd say that the CookQuesadillas method looks a lot better, but do we like "PerformActualCooking?" The whole situation is an improvement, but I'm not a huge fan, personally. I'm still mixing control flow with a series of domain concepts. PerformActualCooking is still both a story about for-loops and about cooking. Let's try something else:

public void CookQuesadillas(int numberOfQuesadillas)
{
    PrepareIngredients();
    PrepareEquipment();
    PerformActualCooking(numberOfQuesadillas);
    FinishUp();
}
private static void PerformActualCooking(int numberOfQuesadillas)
{
    for (int index = 0; index < numberOfQuesadillas; index++)
        CookAQuesadilla();
}
private static void CookAQuesadilla()
{
    SprinkleOnionsAndCheeseOnTortilla();
    PutTortillaInPan();
    CookUntilFirm();
    FoldTortillaAndCookUntilBrown();
    FlipTortillaAndCookUntilBrown();
    RemoveCookedQuesadilla();
}

We've added a node to the tree that some might say is one too many, but I disagree. What I like is the fact that we have two methods that contain nothing but abstractions about the domain knowledge of cooking and we have a bridging method that brings in the detailed realities of the programming language. We're isolating things like looping, counting, conditionals, etc. from the actual problem solving and story telling that we want to do here. So when you have a method that does a few things and you think about adding some kind of control flow to it, remember that you're introducing a detail to the method that is at a lower level of abstraction and should probably have its own node in the tree.

Adrift in a Sea of Tiny Methods

If you're looking at this cooking example, it probably strikes you that there are no fewer than eighteen methods in this class, not counting any additional sub-methods or elided properties (which are really just methods in C# anyway). That's a lot for a class, and you may think that I'm encouraging you to write classes with dozens of methods. That isn't the case. So far what we've done is started to create trees of many small methods with a public method and then a ton of private methods, which is a code smell called "Iceberg Class." What's the cure for iceberg classes? Extracting classes from them. Maybe you turn the first two methods that prepare ingredients and equipment into a "Preparer" class with two public methods, "PrepareIngredients" and "PrepareEquipment." Or maybe you extract a quesadilla cooking class.

It's really going to vary based on your situation, but the point is that you take this opportunity pick nodes in your growing tree of methods and sub-methods and convert them into roots by turning them into classes. And if doing this leads you to having what seems to be too many classes in your namespace? Create more namespaces. Too many of those in a module? Create more modules. Too many modules/projects in a solution? More solutions.

Here's the thing: the complexity exists no matter how many or few methods/classes/namespaces/modules/solutions you have. Slamming them all into monolithic constructs together doesn't eliminate or even hide that complexity, though many seem to take the ostrich approach and pretend that it does. Your code isn't somehow 'simpler' because you have one solution with one project that has ten classes, each with 300 methods of 7,000 lines. Sure, things look simple when you fire up the IDE, but they sure won't be simple when you try to debug. In fact, they'll be much more complicated because your functionality will be hopelessly interwoven with weird temporal couplings, ad-hoc references, and hidden dependencies.

If you create large trees of functionality, you have the luxury of making the structure of the tree the representative of the application's complexity, with each node an island of simplicity. It is in these node-methods that the business logic takes place and that getting things right is most important. And by managing your abstractions, you keep these nodes easy to reason about. If you structure the tree correctly and follow good OOP design and practice, you'll find that even the structure of the tree is not especially complicated since each node provides a good representative abstraction for its sub-tree.

Having small, readable, self-documenting methods is no pipe dream. Really, with a bit of practice, it's not even very hard. It just requires you to see code a little bit differently. See it as a series of hierarchical stories and abstractions rather than as a bunch of loops, counters, pointers, and control flow statements, and the people that maintain what you write, including yourself, will thank you for it.

Now let’s say that in the graph the internal representation of the points is a floating point data type such as, well, float. I’m going to save the nuance of floating point arithmetic for a future practical math post, but suffice it say that floats can exhibit some weird-seeming behavior when it comes to comparisons, truncation/rounding, certain kinds of casting and type representations, etc.

[TestMethod, Owner("ebd"), TestCategory("Proven"), TestCategory("Unit")]
public void Mind_Equals_Blown()
{
    float x = 0.2f;
    float y = 0.1f;
    float z = x + y;
    Assert.IsTrue(z == x + y);  //What the - why does this fail?!?
}

And let’s also say that the person responsible for authoring this graph class hasn’t read a practical math post about floating point arithmetic and is completely oblivious to these potential pitfalls.

And, finally, let’s say that this graph class becomes a mainstay of the business logic in a particular application. It’s modified, extended, and relied heavily upon without a whole lot of attention paid to its internal workings. At least until stuff mysteriously doesn’t work. But when that happens, the culprit isn’t immediately obvious, so strange work-arounds and cargo-cult, oddball solutions spring up when symptoms occur. Extension methods are written, and sometimes entirely different modules are added to the code base because the existing one is “tricky” or “not to be trusted.”

At the application level, this causes maintenance issues, a lot of heated and fruitless arguments, and voodoo approaches to code. From a user interface perspective, this causes quirky behavior. Occasionally a linear graph is completely displaced out of the graph and rendered on some menu somewhere, or the screen goes blank for a few seconds and then the display is restored. Defects and defect reports are created and developers dispatched to track down the issue, but after a few days of fruitless efforts, some project manager quietly sets the defect’s priority from “critical” to “cosmetic” and the software is shipped. It’s embarrassing, but whatcha gonna do. Ya know, computers have a mind of their own sometimes!

Catching it Early

What if, instead of doing things the old-fashioned but all-too-common way, the authors of this code had been writing unit tests and/or practicing TDD? Well, there’s a very good chance that the issue stemming from the graph library is caught immediately as its API methods are being fleshed out from a functionality perspective. There’s a good chance that someone is writing a test and gets to the point that we were at in the code sample above, where they are utterly dumbfounded as to why 1+1 does not equal 2 in float land.

And then, good things happen. The developer in question takes to google or stack overflow, or perhaps he talks to other, more experienced developers on his team. He then gets an explanation, learns something about the language, and leaves the code in a correct state. Contrast this with the non-tested approach of “code it up, build a bad house on the bad foundation, and then ship the result because it’s too late.”

And what if the TDD/unit tests don’t expose this issue? Well, what they’ll do in either case is decouple the code base. So when the issue eventually does crop up via weird GUI behavior, it will be much easier to isolate. When it’s isolated, it will be much easier for the unit-test-savvy developers to write a test that exposes the defect to learn the lesson and fix the issue. It’s still a win.

The point about unit tests helping catch errors and leading to a more decoupled design is hardly controversial. But the benefits go beyond that. Unit tests provide a fast feedback loop for all points in the code base, which lends itself very well to poking and prodding things and experimenting. And that, in turn, leads to better understanding of not only the code, but also the language. If you can execute and get feedback on code extremely quickly, you’re much more likely to ask questions like, “I wonder what happens if I do x…” and then to do it and see. And that sort of experimentation, much like immersion in natural language, leads much more quickly to fluency.

Steinbeck-Driven Development (SDD)

For those of you who’ve never had the pleasure to read John Steinbeck’s “Of Mice and Men,” any SDD practitioner will tell you that it’s a heartwarming tale of two friends who overcome all odds during the Great Depression, making it cross-country to California to start a rabbit petting zoo. And it’s that outlook on life that they bring to the team when it comes to setting deadlines, tracking milestones, and general planning.

Relentlessly optimistic, the SDD project manager reacts to a missed milestone by reporting to his superiors that everything is a-OK because the team will just make it up by the time they hit the next one. When the next milestone is missed by an even wider margin, same logic applies. Like a shopping addict or degenerate gambler blithely saying, “you gotta spend money to make money,” this project manager will continue to assume on-time delivery right up until the final deadline passes with no end in site. When that happens, it’s no big deal–they just need a week to tie up a few loose ends. When that week is up, it’ll just be one more week to tie up a few loose ends. When that week expires, they face reality. No, just kidding. It’ll just be one more week to tie up a few loose ends. After enough time goes by, members of the team humor him with indulgent baby talk when he says this: “sure it will, man, sure it will. In a week, everything will be great, this will all be behind us, and we’ll celebrate with steaks and lobster at the finest restaurant in town.”

Spoiler alert. At the end of Steinbeck’s novel, the idyllic rabbit farm exists only in the mind of one of the friends, shortly before he’s shot in the back of the head by the other, in an act that is part merciful euthanasia and part self-preservation. The corporate equivalent of this is what eventually happens to our project manager. Every week he insists that everything will be fine and that they’re pretty close to the promised land until someone puts the project out of its misery.

Shooting-Star-Driven Development (SSDD)

Steinbeck-Driven Development is not for everyone. It requires a healthy ability to live in deluded fantasy land (or, in the case of the novel, to be a half-wit). SSDD project managers are not the relentless optimists that their SDD counterparts are. In fact, they’re often pretty maudlin, having arrived at a PM post on a project that everyone knows is headed for failure and basically running out the clock until company bankruptcy or retirement or termination or something. These are the equivalents of gamblers that have exhausted their money and credit and are playing at the penny tables in the hopes that their last few bucks will take them on an unprecedented win streak. Or, perhaps more aptly, they’re like a lonely old toy-maker, sitting in his woodshop, hoping for a toy to come to life and keep them company.

This PM and his project are doomed to failure, so he rarely bothers with status meetings, creates a bare minimum of power points, and rarely ever talks about milestones. Even his Gantt charts have a maximum of three nested dependencies. It’s clear to all that he’s phoning it in. He knows it’s unlikely, but he pins his slim hope to a shooting star: maybe one of his developers will turn out to be the mythical 100x developer that single-handedly writes the customer information portal in the amount of time that someone, while struggling to keep a straight face, estimated it would take to do.

As projects go along and fall further and further behind schedule and the odds of a shooting star developer become more and more remote, the SSDD project manager increasingly withdraws. Eventually, he just kind of fades away. If Geppetto were a real life guy, carving puppets and asking stars to make them real children, he’d likely have punched out in an 19th century sanitarium. There are no happy endings on SSDD projects–just lifeless, wooden developers and missed deadlines.

Fear-Driven Development (FDD)

There is no great mystery to FDD projects. The fate of the business is in your hands, developers. Sorry if that’s a lot of pressure, but really, it’s in your hands.

The most important part of a FDD project is to make it clear that there will be consequences–dire consequences–to the business if the software isn’t delivered by such and such date. And, of course, dire consequences for the business are pretty darned likely to affect the software group. So, now that everyone knows what’s at stake, it’s time to go out and get that complex, multi-tiered, poorly-defined application built in the next month. Or else.

Unlike most waterfall projects, FDD enters the death march phase pretty much right from the start of coding. (Other waterfall projects typically only start the death march phase once the testing phase is cancelled and the inevitability of missing the deadline is clear.) The developers immediately enter a primal state of working fourteen hours per day because their very livelihoods hang in the balance. And, of course, fear definitely has the effect of getting them to work faster and harder than they otherwise would, but it also has the side effect of making the quality lower. Depending on the nature of the FDD project and the tolerance level of the customers for shoddy or non-functional software, this may be acceptable. But if it isn’t, time for more fear. Consequences become more dire, days become longer, and weekends are dedicated to the cause.

The weak have nervous breakdowns and quit, so only the strong survive to quit after the project ends.

Passive-Aggressive-Driven Development (PADD)

One of the most fun parts of waterfall development is the the estimation from ignorance that takes place during either the requirements or design days. This is where someone looks at a series of Visio diagrams and says, “I think this project will take 17,388.12 man-hours in the low risk scenario and 18,221.48 in the high-risk scenario.” The reason I describe this as fun is because it’s sort of like that game you play where everyone guesses the number of gumballs in a giant jar of gumballs and whoever is closest without going over wins a prize. For anything that’s liable to take longer than a week, estimation in a waterfall context is a ludicrous activity that basically amounts to making things up and trying to keep a straight face as you convince yourself and others that you did something besides picking a random number.

Well, I broke this task up into 3,422 tasks and estimated each of those, so if they each take four hours, and everything goes smoothly when we try to put them all together with an estimate for integration of… ha! Just kidding! My guess is 10,528 hours–ten because I was thinking that it’d have to be five digits, the fve because it’s been that many days that we’ve been looking at these Gantt charts and sequence diagrams, and twenty-eight because that was my number in junior high football. And you can’t bid one hour over me because I’m last to guess!

But PADD PMs suck all of the fun out of this style of estimation by pressuring the hours guessers (software developers) into retracting and claiming less time. But they don’t do it by showing anger–the aggression is indirect. When the developer says that task 1,024, writing the batch file import routine, will take approximately five hours, the PADD PM says, “Oh, wow. Must be pretty complicated. Jeez, I just assumed that a senior level developer could bang that out in no more than two. My bad.” Shamed, the developer retracts: “No, no–you’re right. I figured the EDI would be more complicated than it was, so I just realized that my estimate is actually two hours.”

Repeated in aggregate, the PADD PM is some kind of spectacular black belt/level 20/guru/whatever metric is used to measure PM productivity, because he just reduced the time to market by 60% before a single line of code was ever written. Amazing! Of course, talk at the beginning of the project is cheap. The real measure of waterfall project success is figuring out who to blame and getting others to absorb the cost when the project gets way behind schedule. And this is where the PADD master really shines.

To his bosses, he says, “man, I guess I just had too much faith in our guys–I mean, I know you hire the best.” To the developers, he says, “boy, your estimates seemed pretty reasonable to me, so I would have assumed that everything would be going on time if you were just putting in the hours and elbow grease… weird.” To the end-users/stakeholders, he says, “it’s strange, all of our other stakeholders who get us all of the requirements clearly and on time get their software on time–I wonder what happened here.”

There’s plenty of blame to go around, and PADD PMs make sure everyone partakes equally and is equally dissatisfied with the project.

public class CustomerProcessor
{
    public void ProcessCustomer(Customer customer)
    {
        try
        {
            if (customer.IsActive)
                ProcessActiveCustomer(customer);
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    private void ProcessActiveCustomer(Customer customer)
    {
        try
        {
            CheckCustomerName(customer);
            WriteCustomerToFile(customer);
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    public void CheckCustomerName(Customer customer)
    {
        try
        {
            if (customer.Name == null)
                customer.Name = string.Empty;
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    private void WriteCustomerToFile(Customer customer)
    {
        try
        {
            using (StreamWriter writer = new StreamWriter(@"C:\temp\customer.txt"))
            {
                writer.WriteLine(customer.Name);
            }
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
}

Every method consisted of a try with the actual code of interest inside of it and then a caught general exception that was then thrown. As I looked more through the code base, it became apparent to me that this was some kind of ‘standard’ (and thus perhaps exhibit A of how we get standards wrong). Every method in the project did this.

If you’re reading and you don’t know why this is facepalm, please read on. If you’re well-versed in C# exceptions, this will probably be review for you.

Preserve the Stack Trace

First things (problems) first. When you throw exceptions in C# by using the keyword “throw” with some exception type, you rip a hole in the fabric of your application’s space-time–essentially declaring that if no code that’s called knows how to handle the singularity you’re belching out, the application will crash. I use hyperbolic metaphor to prove a point. Throwing an exception is an action that jolts you out of the normal operation of your program by using a glorified “GOTO,” except that you don’t actually know where it’s going because that’s up to the code that called you.

When you do this, the .NET framework is helpful enough to package up a bunch of runtime information for troubleshooting purposes, including something called the “stack trace.” If you’ve ever seen a .NET (or Java) site really bomb out, you’ve probably seen one of these–it’s a bunch of code with line numbers that basically tells you, “A called B, which called C, which called D … which called Y, which called Z, which threw up and crashed your program.” When you throw an exception in C# the framework saves the stack trace that got you to the method in question. This is true whether the exception happens in your code or deep, deep within some piece of code that you rely on.

So, in the code above, let’s consider what happens when the code is executed on a machine with no C:\temp folder. The StreamWriter constructor is going to throw an exception indicating that the path in question is not found. When it does, you will have a nice exception that tells you ProcessCustomer called ProcessActiveCustomer, which called WriteCustomerToFile, which called new StreamWriter(), which threw an exception because you gave it an invalid path. Pretty neat, huh? You just have to drill into the exception object in the debugger to see all of this (or have your application configured to display this information in a log file, on a web page, etc.).

But what happens next is kind of a bummer. Instead of letting this exception percolate up somewhere, we trap it right there in the method in our catch block. At that point, we throw an exception. Now remember, when you throw an exception object, the stack trace is recorded at the point that you throw, and any previous stack trace is blown away. Instead of it being obvious that the exception originated in the StreamWriter constructor, it appears to have originated in WriteCustomerToFile. But wait, it gets worse. From there, the exception is trapped in ProcessActiveCustomer and then again in ProcessCustomer. Since every method in the code base has this boilerplate, every exception generated will percolate back up to main and appear to have been generated there.

To put this in perspective, you will never be able to see or record the stack trace for the point at which the exception was thrown. Now, in development that’s not the end of the world since you can set the debugger to break where thrown instead of handled, but for production logging, this is awful. You’ll never have the foggiest idea where anything is coming from.

How to fix this? It’s as simple as getting rid of the “throw ex;” in favor of just “throw;” This preserves the stack trace while passing the exception on to the next handler. Another alternative, should you wish to add more information when you throw, would be to do “throw new Exception(ex)” where you pass the exception you’ve caught to a new one that you’re creating. The caught exception will be preserved, intact, and can be accessed in debugging via the “InnerException” property of the one you’re now throwing.

public class CustomerProcessor
{
    public void ProcessCustomer(Customer customer)
    {
        try
        {
            if (customer.IsActive)
                ProcessActiveCustomer(customer);
        }
        catch (Exception ex)
        {
            throw;
        }
    }
    private void ProcessActiveCustomer(Customer customer)
    {
        try
        {
            CheckCustomerName(customer);
            WriteCustomerToFile(customer);
        }
        catch (Exception ex)
        {
            throw;
        }
    }
    public void CheckCustomerName(Customer customer)
    {
        try
        {
            if (customer.Name == null)
                customer.Name = string.Empty;
        }
        catch (Exception ex)
        {
            throw;
        }
    }
    private void WriteCustomerToFile(Customer customer)
    {
        try
        {
            using (StreamWriter writer = new StreamWriter(@"C:\temp\customer.txt"))
            {
                writer.WriteLine(customer.Name);
            }
        }
        catch (Exception ex)
        {
            throw;
        }
    }
}

(It would actually be better here to remove the Exception ex altogether in favor of just “catch {” but I’m leaving it in for illustration purposes)

Minimize Exception-Aware Code

Now that the stack trace is going to be preserved, the pattern here isn’t actively hurting anything in terms of program flow or output. But that doesn’t mean we’re done cleaning up. There’s still a lot of code here that doesn’t need to be.

In this example, consider that there are only two methods that can generate exceptions: ProcessCustomer (if passed a null reference) and WriteCustomerToFile (various things that can go wrong with file I/O). And yet, we have exception handling in every method, even methods that are literally incapable of generating them on their own. Exception throwing and handling is extremely disruptive and it makes your code very hard to reason about. This is because exceptions, as mentioned earlier, are like GOTO statements that whip the context of your program from wherever the exception is generated to whatever place ultimately handles exceptions. Oh, and the boilerplate for handling them makes methods hard to read.

The approach shown above is a kind of needlessly defensive approach that makes the code incredibly dense and confusing. Rather than a strafing, shock-and-awe show of force for dealing with exceptions, the best approach is to reason carefully about where they might be generated and how one might handle them. Consider the following rewrite:

public class CustomerProcessor
{
    public void ProcessCustomer(Customer customer)
    {
        if(customer == null)
            Console.WriteLine("You can't give me a null customer!");
        try
        {
            ProcessActiveCustomer(customer);
        }
        catch (SomethingWentWrongWritingCustomerFileException)
        {
            Console.WriteLine("There was a problem writing the customer to disk.");
        }
    }
    private void ProcessActiveCustomer(Customer customer)
    {
        CheckCustomerName(customer);
        WriteCustomerToFile(customer);
    }
    public void CheckCustomerName(Customer customer)
    {
        if (customer.Name == null)
            customer.Name = string.Empty;
    }
    private void WriteCustomerToFile(Customer customer)
    {
        try
        {
            using (var writer = new StreamWriter(@"C:\temp\customer.txt"))
            {
                writer.WriteLine(customer.Name);
            }
        }
        catch (Exception ex)
        {
            throw new SomethingWentWrongWritingCustomerFileException("Ruh-roh", ex);
        }
    }
}

Notice that we only think about exceptions at the ‘endpoints’ of the little application. At the entry point, we guard against a null argument instead of handling it with an exception. As a rule of thumb, it’s better to handle validation via querying objects than by trying things and catching exceptions, both from a performance and from a readability standpoint. The other point of external interaction where we think about exceptions is where we’re calling out to the filesystem. For this example, I handle any exception generated by stuffing it into a custom exception type and throwing that back to my caller. This is a practice that I’ve adopted so that I know at a glance when debugging if it’s an exception I’ve previously reasoned about and am trapping or if some new problem is leaking through that I didn’t anticipate. YMMV on this approach, but the thing to take away is that I deal with exceptions as soon as they come to me from something beyond my control, and then not again until I’m somewhere in the program that I want to report things to the user. (In an actual application, I would handle things more granularly than simply catching Exception, opting instead to go as fine-grained as I needed to in order to provide meaningful reporting on the problem)

Here it doesn’t seem to make a ton of difference, but in a large application it will–believe me. You’ll be much happier if your exception handling logic is relegated to the places in the app where you provide feedback to the user and where you call external stuff. In the guts of your program, this logic isn’t necessary if you simply take care to write code that doesn’t contain mistakes like null dereferences.

What about things like out of memory exceptions? Don’t you want to trap those when they happen? Nope. Those are catastrophic exceptions beyond your control, and all of the logging and granular worrying about exceptions in the world isn’t going to un-ring that bell. When these happen, you don’t want your process to limp along unpredictably in some weird state–you want it to die.

On the Lookout for Code Smells

One other meta-consideration worth mentioning here is that if you find it painful to code because you’re putting the same few lines of code in every class or every method, stop and smell what your code is trying to tell you. Having the same thing over and over is very much not DRY and not advised. You can spray deodorant on it with something like a code snippet, but I’d liken this to addressing a body odor problem by spraying yourself with cologne and then putting on a full body sweatsuit–code snippets for redundant code make things worse while hiding the symptoms.

If you really feel that you must have exception handling in every method, there are IL Weaving tools such as PostSharp that free you from the boilerplate while letting you retain the functionality and granularity you want. As a general rule of thumb, if you’re cranking out a lot of code and thinking, “there’s got to be a better way to do this,” stop and do some googling because there almost certainly is.