DaedTech

Stories about Software

Jul
30

By

How To Quit Your Job

Category: You Asked For It Tags: , | 10 Comments

Before you get any ideas, this isn’t about Amway; I’m not going to follow “how to quit your job” with an ellipsis and then a bunch of promises about how you can make a 7 figure income emailing pictures of cats to people. In fact, this post has nothing whatsoever to do with whether or not you depend on having a job. I’m not offering advice on how not to need a job or how to “quit the game” or anything like that. I’m speaking quite literally about how to resign from your job when the time comes (usually when you’ve accepted an offer from another organization) and all of the considerations around that. I’ve received a surprising (to me anyway) number of requests for advice on this topic, so I thought I’d share my thoughts. As someone who has managed people and who has moved around some, I certainly have perspective on the matter that, perhaps, you will find worthwhile.

This "How to Quit Your Job" post is not about cat memes, like the one pictured here.

Before I get right down to it, I’d like to make a quick note about “rage-quitting.” Don’t rage quit; be a grownup. Okay, moving on.

Prelude to Quitting

Before you decide to quit a job (consciously, anyway) you generally dip your toe into the job market, sending off some resumes, doing some phone interviews, etc. This is the phase in which it feels like you’re doing something kind of wrong but exhilarating — cheating on your current employer (or at least flirting). You’ve grown tired of your situation and you’re starting to daydream about a new one where they don’t follow such a stupid development methodology, you won’t have to deal with Steve from two rows over anymore, and they even have ping pong tables. Ping pong — do you hear me?! So why does this make you feel a little guilty? Well, it should — the game is setup this way. You have to sneak around, claiming to be sick when you’re not and doing other quasi-unscrupulous things. It’s a bummer, but it’s the way the game is played, unfortunately. Perhaps a better system will come along and obviate this practice.

Until that happens, however, you have to make do. It might be tempting to tell your employer what you’re doing either for the sake of honesty or to make them sweat, but resist this impulse. You don’t want to tip your hand at all because it’s option-limiting for you. If you throw in their face that you’re out job-hunting, they may scramble to please/keep you in the short term, but they’ll certainly start forming contingency plans in the long term. And, it also makes you sound like a prima donna.

If you think that your employer can correct whatever is causing you to want to look elsewhere, state your case without threats. If you’re paid below market value, come in with data from salary.com, your last few performance reviews, and a level-headed pitch for more money. Same general idea if you think you should have more responsibility or a better title. Don’t bring threats into it — and make no mistake, that’s what telling them you’re going to look for other jobs is — instead, sell yourself. If it doesn’t work, thank them for their consideration, tell them they’ve actually convinced you that they have the right of it, and start lining up interviews. Hey, you gave them a chance.

When you’re lining up interviews, space them out and separate the wheat from the chaff. (This is mainly applicable to programmers, who will be inundated with interview requests in today’s economy.) It can be tempting, especially if you’re disgruntled, to book 12 interviews over a Monday-through-Friday span, but what plausible, non-suspicious reason do you have for a run of absence like that? Your supply of mornings to come in late, afternoons to sneak out early, and random “sick” days is going to be quite limited, particularly if you’ve just made a pitch for a better title and been refused. Use these wisely. Filter out all but the best opportunities. Don’t take ‘interviews’ with recruiters (they’ll cave — just tell ’em you’ll call a different recruiter). Feel free to push back on things and let them go for a week or two. It’ll be okay.

A bird in the hand is worth two in the bush, and your current job is in hand, earning you money. Until you have an offer, it’s clearly your best prospect.

Dotting I’s and Crossing T’s

After a bit of sneaking around, your activities paid off. You managed to snag a good offer and you’re ready to march in and let everyone know that you’re moving on to bigger and better things. Settle down, because you have work to do first. First of all, you need to sign the offer and have it returned to you, counter-signed, before you have anything of substance (and theoretically, an employer can even go back on a signed offer letter — it’s not a contract, per se — even though it would be bad faith). Next, you need to see what the offer is contingent upon.

Are they going to call your references? Do a background check? Credit check? Drug test? Something you’ve never heard of before like an obstacle course or feats of strength? These things aren’t mere formalities — they’re grounds for rescinding the offer. Do not give notice at your current job until all of these things are taken care of. Never done any drugs in your life and nothing in your background to hide, you say? Great, but that doesn’t mean a false positive is impossible. It’d certainly be a bummer if your offer got yanked because some other Joe Smith made the local police blotter for stealing a car. It’s a situation that could likely be straightened out, but you’re in no-man’s-land until it is.

Make sure there are no possible obstacles before you take an irrevocable step with your current employer who is, still, even with contingent offer in hand, your best prospect.

Actual Resignation

Alright, so no one dropped a bunch of poppy seeds into your urine and no one sharing your name stole any cars recently, so everything went smoothly with the offer and contingencies. Now, you’re ready to make it official. But, what to do? Tell your manager in passing? A phone call? An email, since that’ll be an awkward conversation? How do you drop this bombshell? None of the above. You’re going to type up a letter of resignation, sign it, and bring it along with you to a one on one meeting that you’ll request with your direct supervisor (perhaps someone above that person in the chain in an odd situation such as your boss being on vacation for a week or something).

Yikes, so what to type in the letter? Not much. Make it very short, polite and unremarkable. Here’s more or less what I use:

Dear {Boss}:

Please accept this as my formal resignation from the position of {your official title} at {official company name}, with my last day being {date of last day}. I very much appreciate you giving me the opportunity to work for {informal/abbreviated company name}.

This decision was made very difficult by the fact that I have thoroughly enjoyed my time and experience here. Please let me know how I can be of assistance with any knowledge transfer or final work over the next {duration of notice period}.

Again, thank you very much for the opportunity to work for you.

Sincerely,

{your first and last name}

Put a header with your address on top of it on the right and the company’s address, C/O your boss on the left below it, leave 5 lines between Sincerely and your name, and sign it once you print it. This is not the venue for a soliloquy on how you’ve grown with the company, and it’s not the place to skewer people you hate. This is basically just going to go in a folder somewhere as proof for HR that you left voluntarily rather than them firing you. It’s not likely anyone will even read it.

With that in hand, schedule some time with your boss to talk and, when in there, get to the point. Say something like, “I just want to let you know that I’m going to be resigning, effective X date, and I’m happy to help with any knowledge transfer or whatever you need, and here’s a letter to that effect.” Don’t send an email or make a phone call or leave a note or something. Grab a few minutes of the manager’s time, look him or her in the eye, and offer your resignation.

Also, offer two to three weeks of notice. Two weeks is pretty standard, and most prospective new employers will understand up to three weeks of notice before you start (a little extra notice and maybe a long weekend for you to decompress or something). Giving less than two weeks is poor form (and no new boss should expect this of you). Giving more than three weeks seems like it’d be a really courteous thing to do, but in reality, it’s just kind of awkward. You take on a dead man/woman walking status once people know that you’re leaving and things get kind of weird. You really don’t want to drag this out for too long.

Keep it Classy

Once you’ve handed in your resignation, the reaction you face is likely to vary. If you’re close with your manager and have a good working relationship, they probably expect it. If not, you’re going to be catching the person off guard, so expect reactions that range from disappointment to dismay to anger to sadness. On occasion, you might even get happiness, if they don’t like you (or if they really like you and don’t like the company very much). Having been on the manager’s end of the table, I can tell you that you’re almost never expecting someone dropping by your office to say, “hey, I quit,” so expect a bit of unguarded emotion from the manager before they get their bearings.

All that said, it’s fairly unusual for a manager to have a real outburst of any kind. The most common reaction will be to ask you why you’re quitting (even if they already know), and at this point, it’s vital to stay classy. There’s nothing for you to gain by launching a volley of negativity at them — just say that you have an opportunity that you think is a better fit or a chance to advance your career or whatever. Be positive about your new gig — not negative about the current one.

On the rare occasion that you are subject to a hissy fit, take the high road. Deep breaths, calming thoughts, and level-headed coolness are your allies. If it gets too heated, you can always leave the room (I mean, what are they going to do to you?). Go in knowing that yours is a position of strength and don’t worry about things like, “what if they fire me on the spot?” Not to say that it would never happen, but a manager or higher-up berating or even firing a quitting employee is spectacularly stupid. If they’re doing that they might as well hang a sign in the building that says, “if you’re going to quit, you’re better off doing it without notice!” Managers and leaders need notice to arrange a replacement, line up knowledge transfer, craft a message about the departure, etc. Knowing all of that should help you stay calm in the face of whatever happens. But, nothing much will probably happen beyond the obligatory, “sure hate to see ya go, but good luck!”

AngryArch

The Counter-Offer

Assuming that your boss or someone higher in the food chain hasn’t acted like an idiot in reaction to your quitting, a common thing to which you’ll be exposed is the counter-offer. Michael Lopp calls this an attempt at a “diving save.” On Monday, you tell your boss that you quit, and later that afternoon or evening, boss has a meeting with the CTO, some other managers, and maybe even the CEO in which they discuss your offer of notice. Since programmers are so hard to hire and keep these days, it’s decided that they have to try to keep you. So, Tuesday morning when you come in, you have a meeting invite asking you to come to that conference room way across the building with the leather chairs and the little fridge with sodas in it, and there on the meeting roster are a bunch of people that have always been too important to be in meetings with the likes of you. Until today, that is.

In this room, they smile and offer you a soda, and they tell you how important you are to the company. They tell you that they have your best interests at heart, and they warn you that a lot of people who leave wind up being unhappy elsewhere. Then, they lay the good stuff on you. They’ll bump you from Software Engineer III to Software Engineer IV and bump your pay by 9, count-em 9 thousand dollars per year. You lick your lips and do a little quick math, realizing that’s $750 extra dollars per month and, even after tax, a pretty nice car payment for the new car you’ve been needing. Heck, it’s even more of a bump than the offer you got from the new company. Should you take it?

If you want to hear arguments as to why counter-offers are a bad idea, just ask any recruiter to whom you talk. Recruiters work by taking a percentage of your first year’s salary from the company that hires you, and they lose that cut if you sign and then decide to stay. Counter-offers are recruiters’ mortal enemy, so if you ask them about whether you should accept a counter offer, you will be treated to a polished, well-rehearsed, convincing argument that counter-offers are such a terrible idea that it’s not unheard of for them to lead to cancer. They’ll tell you about how the company is in a bind but once you agree they’ll start trying to replace you. They’ll tell you that bosses don’t like to have a gun placed to their head and will resent you. They’ll tell you about the dreaded HR matrix and how if you accept a counter offer you won’t get a promotion for 8 years.

But here’s something I’ve never heard them say, and the reason I tend to think that accepting counter offers is a bad idea. Returning to the relationship metaphor from earlier when I mentioned the idea of “sneaking around” on your employer, consider what a resignation is. You’ve had kind of a vacant stare for a while and a feeling that something just isn’t working. You go out, flirt a little with other companies and then decide, “you know what — it’s over — time for a change!” You muster up the courage to take that plunge and have that difficult conversation, and your partner is then hurt and perhaps a bit in denial. After sleeping on it, though, bargaining starts the next day. “Alright, I know you said that you aren’t happy, so here’s what I’m going to do: you get to pick the pizza topping every Saturday instead of us alternating, you never have to come to my parents’ house except on Christmas, and I’ll take over the dishes and the vacuuming.” You’ve initiated a breakup due to existential unhappiness and the other party responds with an appealing set of superficial improvements. So do you then say, “Gosh, I was pretty unhappy, but really, every Saturday night we can have mushrooms and pepperoni? Hello, relationship bliss!” If so, how long before the blank stare comes back?

In the article I linked, Lopp says the following of the diving save:

Diving Saves are usually a sign of poor leadership. People rarely just up and leave. There are a slew of obvious warning signs I’ve documented elsewhere, but the real first question you have to ask yourself once you get over the shock of an unexpected resignation is: “Did you really not see it coming? Really?”

The question then becomes whether you really want to work at a place that only addresses your discontentment at the absolute last conceivable moment. Do you want to work at a place that’s only interested in your happiness when faced with your eminent departure? There’s probably a reason that you want to go, and that reason is probably tied heavily into a corporate culture where you’ve felt that no one who mattered was interested in championing your cause. You’re going to get that $750 and buy a car, and then it won’t be an awesome sum of money but rather ho-hum, just what you make. Your life will be basically the same as it was before they shoveled that money your way in a desperate attempt to keep you. They’re not going to consider you almost leaving a wake-up call to stop taking you for granted; they’re going to consider you a problem solved via bribe.

The Awkward Two Weeks And Exit Interview

Let’s assume you’ve politely declined any counter-offers that are made and you’re just riding out your last two weeks. First of all, continue staying classy and maintain a positive attitude. This is not the time to tell off people that you don’t like or make a lot of snarky comments. Be polite and helpful with knowledge transfer activities and finishing up any last work. If you disagree with who is going to be replacing you on things, keep that to yourself. These shouldn’t be hard things to do and it shouldn’t be hard to stay optimistic — you’re going to be free soon and there’s a light shining very clearly at the end of the tunnel.

At some point, HR will want to bring you in for an exit interview in which they ask all sorts of candid questions about your time with the company. Let me be clear about this — there is zero upside for you when it comes to being honest about criticism of the company. The smartest course of action is for you to walk in there, smile, and tell them how wonderful the company is and that you really hate to leave but it’s just too good an opportunity to pass up. Why? Well, what’s going to happen is that your responses are going to be reviewed by various manager and VP types as matters of feedback for improving the company. So the very people that might later offer you references or even hire you back later (stranger things do happen) are going to be seeing your feedback. And, those people are humans who probably won’t enjoy reading about how they’re “completely clueless” or “incompetent” or whatever you might feel like saying.

I’m not telling you not to be honest. I’m just telling you that there’s no benefit to you in being honest beyond how momentarily cathartic it might be to tell someone what you’ve really thought this whole time. It might be that you have friends working there and someone giving feedback about how everyone hates some activity or has real problems with some person might help your friends that will continue to work there. Fine, great, go for it if you want. Just understand that there’s no upside for you and there’s definite potential for downside.

Last Day and Beyond

Your last day will probably be the weirdest. You should spend some time making the rounds, saying your goodbyes, exchanging contact info, and wishing people well. I would also recommend an offer, if appropriate and within the bounds of your new employment agreement, to consult here and there if your former group/boss needs it. Typically this sort of consultation is easy, extra money for you and ensures a good professional relationship on an ongoing basis. Even just the offer will probably be well received, even if politely declined.

Once you’ve left, keep contact with your friends if so desired, and perhaps go for a drink or meal now and then. But on top of that, I’d keep in touch with former managers or people in authority positions as well. At minimum, if they like you, they can be excellent references. But on top of that, they may leave and go elsewhere and want to hire people. Or the landscape may change at your former employer and it might be worth considering again for you. Or maybe none of that is the case, but hey, what does it cost you to be friendly and exchange an email with someone every now and then? I’ve been around for a while in this industry and in a variety of roles and I never once have found myself thinking, “ugh, I wish I hadn’t stayed in touch with that guy!”

Throughout the whole bizarre and awkward process of leaving a job, the main thing to remember is to be classy and professional and always to take the high road. It can be tempting to do otherwise and leave in a blaze of sour grapes, telling people what you really think. But your career is really a fancy wrapper around the concept of your own earning power, and your earning power is your ticket to comfort and security throughout your life. It’s not worth jeopardizing for a youtube-able moment that might go mildly viral for a few days or something. Take the long view and do your best to leave organizations with an even more positive view of you than they had when they made you the initial offer.

Jul
6

By

The Secret to Avoiding Paralysis by Analysis

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

A while ago Scott Hanselman wrote a post about “paralysis by analysis” which I found to be an interesting read.  His blog is a treasure trove of not only technical information but also posts that humanize the developer experience, such as one of my all time favorites.  In this particular post, he quoted a stack overflow user who said:

Lately, I’ve been noticing that the more experience I gain, the longer it takes me to complete projects, or certain tasks in a project. I’m not going senile yet. It’s just that I’ve seen so many different ways in which things can go wrong. And the potential pitfalls and gotchas that I know about and remember are just getting more and more.

Trivial example: it used to be just “okay, write a file here”. Now I’m worrying about permissions, locking, concurrency, atomic operations, indirection/frameworks, different file systems, number of files in a directory, predictable temp file names, the quality of randomness in my PRNG, power shortages in the middle of any operation, an understandable API for what I’m doing, proper documentation, etc etc etc.

Scott’s take on this is the following:

This really hit me because THIS IS ME. I was wondering recently if it was age-related, but I’m just not that old to be senile. It’s too much experience combined with overthinking. I have more experience than many, but clearly not enough to keep me from suffering from Analysis Paralysis.

(emphasis his)

Paralysis by Lofty Expectations

The thing that struck out to me most about this post was reading Scott say, “THIS IS ME.” When I read the post about being a phony and so many other posts of his, I thought to myself, “THIS IS ME.” In reading this one, however, I thought to myself, “wow, fortunately, that’s really not me, although it easily could be.” I’ll come back to that.

Scott goes on to say that he combats this tendency largely through pairing and essentially relying on others to keep him more grounded in the task at hand. He says that, ironically, he’s able to help others do the same. With multiple minds at work, they’re able to reassure one another that they might be gold plating and worrying about too much at once. It’s a sanity check of sorts. At the end of the post, he invites readers to comment about how they avoid Paralysis by Analysis.

For me to answer this, I’d like to take a dime store psychology stab at why people might feel this pressure as they move along in their careers in the first place — pressure to “[worry] about permissions, locking, concurrency, atomic operations, indirection/frameworks, different file systems, number of files in a directory, predictable temp file names, the quality of randomness in my PRNG, power shortages in the middle of any operation, an understandable API for what I’m doing, proper documentation, etc etc etc.” Why was it so simple when you started out, but now it’s so complicated?

NervousTestTaker

I’d say it’s a matter not so much of diligence but of aversion to sharpshooting. What I mean is, I don’t think that people during their careers magically acquire some sort of burning need to make everything perfect if that didn’t exist from the beginning; I don’t think you grow into perfectionism. I think what actually happens is that you grow worried about the expectations of those around you. When you’re a programming neophyte, you’ll proudly announce that you successfully figured out how to write a file to disk and you’d imagine the reaction of your peers to be, “wow, good work figuring that out on your own!” When you’re 10 years in, you’ll announce that you wrote a file to disk and fear that someone will say, “what kind of amateur with 10 years of experience doesn’t guarantee atomicity in a file-write?”

The paralysis by analysis, I think, results from the opinion that every design decision you make should be utterly unimpeachable or else you’ll be exposed as a fraud. You fret that a maintenance programmer will come along and say, “wow, that guy sure sucks,” or that a bug will emerge in some kind of odd edge case and people will think, “how could he let that happen?!” This is what I mean about aversion to sharpshooting. It may even be personal sharpshooting and internal expectations, but I don’t think that the paralysis by analysis occurs as a proactive desire to do a good job but out of a reactive fear of doing a bad job.

(Please note: I have no idea whether this is true of Scott, the original Stack Overflow poster or anyone else individually; I’m just speculating about this general phenomenon that I have observed)

Regaining Your Movement

So, why doesn’t this happen to me? And how might you avoid it? Well my hope is that the answer to the first question is the answer to the second question for you. This doesn’t happen to me for two reasons:

  1. I pride myself not on what value I’ve already added, but what value I can quickly add from here forward.
  2. I make it a point of pride that I only solve problems when they become actual problems (sort of like YAGNI, but not exactly).

Let’s consider the first point as it pertains to the SO poster’s example. Someone tells me that they need an application that, among other things, dumps a file to disk. So, I spend a few minutes calling File.Create() and, hey, look at that — a file is written! Now, if someone comes to me and says, “Erik, this is awful because whenever there are two running processes one of them crashes.” My thought at this point isn’t, “what kind of programmer am I that I wrote this code that has this problem when someone might have been able to foresee this?!?” It’s, “oh, I guess that makes sense — I can definitely fix it pretty quickly.” Expanding to a broader and perhaps less obtuse scope, I don’t worry about the fact that I really don’t think of half of that stuff when dumping something to a file. I feel that I add value as a technologist since even if I don’t know what a random number generator has to do with writing files, I’ll figure it out pretty quickly if I have to. My ability to know what to do next is what sells.

For the second point, let’s consider the same situation slightly differently. I write a file to disk and I don’t think about concurrent access or what on Earth random number generation has to do with what I’m doing. Now if someone offers me the same, “Erik, this is awful because whenever there are two running processes…” I also might respond by saying, “sure, because that’s never been a problem until this moment, but hey, let’s solve it.” This is something I often try to impress upon less experienced developers, particularly about performance. And I’m not alone. I counsel them that performance isn’t an issue until it is — write code that’s clean, clear, and concise and that gets the job done. If at some point users want/need it to be faster, solve that problem then.

This isn’t YAGNI, per se, which is a general philosophy that counsels against writing abstractions and other forms of gold plating because you think that you’ll be glad you did later when they’re needed. What I’m talking about here is more on par with the philosophy that drives TDD. You can only solve one problem at a time when you get granular enough. So pick a problem and solve it while not causing regressions. Once it’s solved, move on to the next. Keep doing this until the software satisfies all current requirements. If a new one comes up later, address it the same as all previous ones — one at a time, as needed. At any given time, all problems related to the code base are either problems that you’ve already solved or problems on a todo list for prioritization and execution. There’s nothing wrong with you or the code if the software doesn’t address X; it simply has yet to be enough of a priority for you to do it. You’ll get to it later and do it well.

There’s a motivational expression that comes to mind about a journey of a thousand miles beginning with a single step (though I’m really more of a despair.com guy, myself). There’s no real advantage in standing still and thinking about how many millions of steps you’re going to need to take. Pick a comfortable pair of shoes, grab some provisions, and go. As long as you pride yourself in the ability to make sure your next step is a good one, you’ll get to where you need to be sooner or later.

Jun
17

By

Code Reviews Should Be about Incremental Improvement

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

Persuasion tends to happen at the micro-level, in terms of information volume and breadth. For instance, if I explain that I use “var x = 6” instead of “int x = 6” because a productivity add-in squawks if I don’t, you’re likely to be swayed if you find my case persuasive. If, instead, I explain that sometimes I use implicit typing and sometimes I don’t, and then I proceed to list dozens of heuristics, you’re most likely to tune out and, if I’m lucky, process and be swayed by one or two individual bullets that I mention. In these cases the grain of the subject matter is fine, but it works for coarser grained concepts as well: I may sway you on whether or not to write unit tests, onion versus layered architecture, or C# over Java. It isn’t the scope of the topic that matters, but rather the relative narrowness of information and message. Persuasion simply works better when the thesis is clear, and the arguments convincing and too the point.

This bit of human nature is incredibly important to understand when sitting for code reviews, both as a reviewer and reviewee. When I review code and someone starts telling me all in a rush about design patterns that they like and why these six classes communicate over a conceptual bus implementation and why there’s a private method in each class called “PreserveInvariants()” and so on, I’m overloaded with information. Are some of these things good ideas? Probably, I imagine. Are all of them good ideas? I don’t know — slow down. I’m not smart enough to leap instantly into a shared context in which the last several weeks of your design decisions and thinking are jacked into my brain, The Matrix style.

Neo

You’re not going to solve the world’s problems in a given code review. Really, you’re probably not even going to solve all of that many of the code bases’s problems either. But, you can decisively solve or address a few. Much as TDD forces you to focus on one problem at a time, I think well done code reviews follow suit. Aim for a handful of ways in which you can make the code better and upon which all parties agree, and consider that a win for the day. This limtiation to a handful of things to cover will keep the scope of the persuasion narrow enough to be effective, whether it’s the reviewee persuading the reviewer to agree with the choices or the reviewer convincing the reviewee to change things. Or, perhaps it will wind up being a bit of both.

As a reviewer, I generally read through the code, offering first blush impressions and asking questions. “Wow, this method seems pretty big.” “Why did you decide to make that method public rather than private?” There, now there’s one narrow point to address in each case, and we can make our attempts at convincing one another. You can explain by describing where this fits in within the big picture or by whatever means you feel available. This dialog lets us explore your code, style and reasoning together. But if you tell me up front, without prompting, the entire philosophy of your approach and all of your decisions, it will be overload, and you’ll fail to persuade. You’ll succeed only in confusing me. I know it’s tempting to address people’s possible objections before they can raise them (gives the feeling of control), but that’s usually just confusing.

As someone whose code is being reviewed, I let the reviewer process the code under review before the dialog begins. I try to resist the impulse to jump in and explain every facet of my design because it will fall on deaf ears until the code has really been groked, and maybe even after if I’m bombarding the reviewer with information. If I want to provide this information, a writeup is definitely the preferred way to do it since this allows the reviewer to pull the information as desired, rather than having it sprayed like a firehose.

So, code reviews ought to cover a handful of concepts only, to allow for the maximum back and forth of persuasion as necessary. All well and good, but you have a lot of code to cover, right? Well, to address this concern, have the code reviews more frequently or even do semi-regular or regular pairing sessions. If your code only gets reviewed once per quarter, there’s a natural tendency for the review to become a performance evaluation of you as a programmer. But that’s a terrible vehicle for narrow, focused persuasion. If you’re having your code reviewed three times per day, then when the reviewer notices a fourth point of discussion, he’s more likely to say, “meh, three is enough for now — we’ll get this other one next time.”

In the end, code reviews are about persuasion. And effectiveness is really what’s important when trying to persuade someone that your way of thinking makes sense. It pretty much goes without saying that the most important part of being persuasive is making a good case, but I’d argue that a close second is the narrowness of focus on the subject for persuasion. I’m unlikely to persuade you that you should copy every facet of my life, but I might just be able to persuade you pick your battles in code reviews.

Jun
11

By

The Zen of Rejection: Let Companies Go In That Other Direction

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

The Courtship

There’s nothing like the beginning of a job search. It’s often born out of a time of transition or frustration, and perhaps uncertainty and worry, but no matter how it starts, there’s a rush and glow as you start to peruse the jobs that are out there. Why do you feel a rush and get a glow, no matter how unhappy you’d been feeling up to that point? Well, it’s because the world comes alive with possibilities as you look at Dice or Stackoverflow Careers or whatever. These aren’t just jobs — they’re the next chapter in your life.

And oh, how appealing they are. And it’s not just because you’re unemployed or sick of your current situation or just wanting a change of pace — it’s because they’re wonderful. They do Agile to your Waterfall and let you flex your hours instead of a rigid 9 to 5. That 401k match sure looks nice too, and they’re using the latest version of the language and the IDE. But, oh, there’s so much more. Casual dress. Free food and soda. Why, they even have a chef to cook you gourmet lunches and stationary bike-desks that you can use to exercise while you work. You can bring your dog in. They have X-Boxes and Playstations and Wiis. It’s really more like going on a cruise than going to work, and they’re beckoning to you, welcoming you, and telling you to become part of their exclusive club — nay, their family. You too can be one of the group of smiling, diverse people pictured in the “Careers” section on their website, having the absolute time of your life.

DreamJob

You submit your application. Really, how could you not? This is your chance at happiness, but now, the nerves set in. What if they don’t call you? But then they do, and the nerves only increase. What if you’re stumped in the phone screen? What if you screw up and tell them that you’re leaving because you don’t like your boss instead of what you’re supposed to say: “I’m just excited at the prospect of joining your organization?” But whew, you manage to avoid too much honesty and to secure an invitation to talk in person. Now, at this point, you put on your absolute best outfit, get in your car to drive over and make sure you get there very early, all the while telling yourself, “whatever you do, don’t be yourself — be that confident, diplomatic, smooth-talking version of yourself that will make you want to collapse from exhaustion the moment you leave.”

The interview passes in a surreal whirlwind as you meet with 8 different people, improvise on strange questions, answer with relief when you know what to say, pivot subtly when you don’t know what to say, remember not to fidget, and smile the whole time. You walk out into the parking lot, sweating under your nice clothes as you heave a huge sigh of relief, make yourself comfortable in your car, and get ready to plop down on your couch at home with a beer. But even that relief is short-lived, because now you have to wait to hear back, which makes the days seem like weeks, and weeks seem like years.

Finally, it comes: the offer. Now, it’s time for giddiness, assuming the pay, benefits and title are in line. You’ve been invited to Shangri La, and you’ve gratefully accepted. You gear up for the first day there, not knowing quite what to expect. And really, how could you? You’ve gone to great lengths to show them a completely air-brushed version of yourself in response to the unrealistic utopia they’ve shown you. So now, starting on your first day, you can see what the other looks like when it’s no longer the evening of the grand ball. Oh, but you’re already married. Better hope no one’s coach turns into a pumpkin (but here’s the catch: to some degree or another, it will, on both sides).

And that’s if everything goes really well. But what if it doesn’t? What if they decide to “go in another direction?” Oh, the rejection, disappointment, angst, and heartbreak.

Culture Shock

I’ve sort of mulled over how to make this point without sounding like a conceited jerk, but that’ll be hard, so I think I’ll just power through it and hope that most of my readership can relate. We’re programmers, and programmers are generally pretty intelligent. I’d imagine that most of you reading are no strangers to overachieving.

When I was growing up and attending school, test time was my time to shine. Whether it was getting into the advanced track math classes, taking standardized tests, trying out for clubs, applying to colleges, or pretty much anything else you can think of, those were things where I showed up and won. I got straight A’s in high school and graduated valedictorian. I won academic scholarships. I was never even cut from a high school sports team. In the sieve of primary and secondary school stratification, I was always the one that received the metaphorical job offer, and I’m sure it was the same for many of you. We grew up in a culture where a bunch of kids in a room working on a test meant you were about to get some accolades and general validation. If the real world were like high school, we’d all have had to rent storage to house all of our offer letters. Wake-ups would come later.

The first one I got, personally, was in my orientation week at college. The Carnegie Mellon CS department is pretty selective, and to prove that we were no longer in the minor leagues, so to speak, they asked all of us in our entering class of 150 people or so to raise our hands if we’d been the valedictorian of our high school. Something like a third of the hands in the room went up, and my jaw dropped. I wasn’t in Kansas anymore, and I no longer won anything just by showing up.

But if college was tough in this circumstance and some that would follow, the “real world” was downright depressing and seemed to have no interest in a fresh computer science grad (graduating at the end of 2001 as the dotcom bubble was bursting sure didn’t help). I failed job interviews before they even talked to me. I sent out resumes and they crossed the event horizon of some HR black hole. I’d get the occasional phone interview and then a “no thanks,” email if they bothered responding at all. In my life growing up, I’d barely ever heard, “I’m sorry, but we’re going in a different direction,” and now I was lucky to hear it because at least I was hearing something. The effect on my self esteem was profound. At the time, I thought my degree to be useless and I felt that some sort of confusing betrayal had occurred, rendering past academic success entirely non-predictive of continued success in this cruel new world I had entered.

Returned Mojo, Anger, and Preemptive Rejection

Eventually, I did get a job. I somehow managed to convince someone to hire me, and I was incredibly grateful and terrified. I was grateful because I could stop moonlighting and taking retail jobs to make ends meet, but terrified because if I’d learned anything from the job search it was that I was great at school but bad at life. But I made it in the real world. In fact, I more than made it. After a stumbling out of the gate, once I was employed, I consistently earned excellent performance reviews and was rapidly advanced and given greater and greater responsibility.

I started to regain some dignity and then some swagger. I was no longer “kid with no industry experience” — I was a software engineer that took business trips, met with clients and, most importantly, got things done. During this time, I also started earning my MS degree in Computer Science via night school, and by the time I hit the job market again in coming years, I was ready.

In fact, I was more than ready. I had learned my lessons from the previous job search and hit the ground running when I wanted a change, doing all of the right things. Interviews were easy to get for someone with my (now miraculously no longer useless) degree pedigree and years of experience in several programming languages, and I did well enough to receive offers. And this time, I’d figured out an important fact: any company that didn’t make me an offer clearly had a flawed interview process. Any form of rejection I haughtily interpreted as ipso facto process failure on their part. This arrogant self-righteousness, I believe, was misdirected resentment at my culture shock from the first go-round. I had done well in school, and then done well in the business world, and was getting offers from most companies with which I interviewed, so how dare those other companies and the ones from years ago make me doubt myself the way I had, very deeply, as a new grad?

As the “chip on the shoulder” mentality started to fade a bit (with me maturing and realizing this was petulant and comically egotistical), left in its place was a more antiseptic tendency to preemptively reject certain companies. I didn’t like rejection any better than at any time in my life — who does — but I didn’t view it as an insult or a mistake, either. I came closer to seeing it this way: “if I don’t apply, I’ll never be rejected, but if I apply and am rejected, I’d always have to say, if asked under oath, that I wasn’t good enough for that company.” By this time, I had become a good sport about “thanks but no thanks,” but I sought to avoid it. If, based on the job requirements or phone screen, it seemed like an interview might not go well, I told the company, “no thanks,” before they could tell me the same. Aha! The rejector has become the rejected! Take that! I would only play in games where I felt the deck had been stacked in my favor, which is good for a small king in a small kingdom, but bad if you ever want to reach and push yourself.

The Reality and Rejection Zen

I spent a lot of years going through this progression of my view on interviews. The feelings of inferiority, regaining my confidence but compensating with righteous indignation, and picking and choosing my spots to minimize rejection all played into an internal mantra of “there’s so much wrong with the interview process and it’s so reductionist, and I won’t do that to people.” If I were a character in Animal Farm, I would be Napolean, however. Like him, I wound up becoming that against which I railed. As my career wound on and I was in a position to make hiring decisions, I surprised myself by being reductionist. “Oh, that was the woman who didn’t really understand what unit tests were,” or “that was the guy who stumbled weirdly when trying to explain why he liked ASP MVC instead of ASP Webforms.” Human lives — and probably imminently capable humans — reduced to a single mistake they had made or passed over in consideration for someone who had happened to impress that day.

It was from this perspective that I realized the sad reality of the interview process. I had been viewing it wrong all along; you’re not really “rejected” from jobs and the interview process isn’t an evaluation of your intrinsic worth in the same way that something like the SAT purports to be (even at companies that make it a point to try to make their interview process exactly that). At best (and probably more in the realm of ideal), it’s an evaluation of mutual fit — something like, “we have a team with characteristics X and Y, and we’re looking for compatibility with X and Y, but also someone who brings Z.” You can be a wonderful human, full of X and Y, but not familiar with or interested in Z, and the position won’t be a good mutual fit. For instance, if I’m hiring someone to be a DBA and your interest is in client side web programming, neither of us pursuing things past the phone interview phase is not a rejection.

What I finally understood, particularly after seeing how the sausage is made and then making it when it comes to candidate selection, is that an interview is really more like you calling up a buddy and saying, “hey, wanna go see that new X-Men movie tonight?” Most likely, the answer will be no because there are a million reasons it could be no. Your buddy might be sick, he might be working late, he might have a date, he might be watching a game on TV, he might be annoyed with you, he might not like movies… the list goes on forever. Some of his reasons could be related to you and some completely based on other factors.

So it is with the interview process. A company may think you’re great and perfectly able to do the work, but have someone else in mind that’s just an absolute perfect match. Or the CEO might be forcing them to hire his nephew. Or they might have decided not to hire after all. In fact, it could be that they never intended to hire, and the whole process was a sham to humor some muckety muck (and before you doubt me, I’ve seen this happen). Again, as many reasons as stars in the night sky.

Once I wrapped my head around this, I stopped fearing or much caring about interview “rejection” beyond simple disappointment that I didn’t get a job about which I was excited or perhaps regret at the fruitless time investment. It was as if I’d called my friend about the movie and he’d said offhandedly, “meh, not tonight.” The response then becomes, “okie dokie, maybe some other time.” A little disappointment is in order if you were hoping to go together but, hey, you have other friends and you could always go on your own.

This is how I got over the feeling that interviews are some measure of your competence or worth — a feeling that I have no doubt is quite pervasive among those reading as well, even if you tell yourself or others that you’re fine with it. So next time you don’t get a job offer, imagine saying in your head, “well, maybe we’ll catch the movie work together some other time or maybe I’ll just invite someone else apply somewhere else.” It seems silly, but I invite you to try it. I imagine that you’ll find it takes the sting out of that call/email/letter/non-response to some degree, if not totally. At the very least, I hope my story might help your confidence not be shaken.

This is the end of the first part of this series, but I anticipate several more. Stay tuned for next time when I tell you why this zen state that I’ve reached depresses me in a kind of detached way and as I delve into how seriously, seriously dysfunctional I think the employee-employer pairing process is in our society (including the likely controversial assertion that the interview process might conceivably not be worth doing). By the end of the series along these lines, I’m hoping to collect my thoughts enough to end on an up note, offering ideas as to how things could be improved.

Jun
1

By

Armchair Tour Guides and Presenters

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

The blog has been quiet for the last 10 days or so and that’s because, as I mentioned previously, I was heading off on vacation. We had a good time; a few days in Seattle, a brief stop in Vancouver, and then a cruise along the Inner Passage of Alaska, where we stopped in a variety of cities and towns. It was a lot of fun. I got to fly over glaciers and an ice field in a small sea plane, go on a whale watching boat ride, see glaciers calve up close, and get a good look at a lot of indigenous wildlife (yes, including grizzly bears).

A lot of this was accomplished via paid tours and group outings, and, apart from enjoying myself, I had the opportunity to bemusedly observe a phenomenon that I came to think of as “armchair tour guiding.” Let me explain with examples. On my sea plane adventure, we boarded a bus to head to the docking area where the planes were tied up, and our chaperon was a girl who introduced herself as a 2-week-since high school graduate and part time employee of the sea plane company. Not wasting any time, a blowhard on the tour started grilling her about the planes — their make and model, their type of engine, and various other things that skittered out of my consciousness since I’m neither a pilot nor do I play one after reading a bit of wikipedia. The girl looked a little flummoxed, and asked the bus driver, and between them they were able to answer at least some of the guy’s questions. “As you can see, I do my research,” the man said, not bothering to hide his smugness at all. I had the distinct impression that not having all of his questions answered was the exact desired outcome. He won a contest in which only he had competed and no doubt became an even greater legend in his own mind.

On another tour on the trip (they did an excellent job, by the way, if you’re ever in a position to check them out), we took a boat out into the bay near Juneau to watch humpback whales and whatever other aquatic life we might happen to see. Our guide was very knowledgeable, and we learned a lot about the humpbacks, other marine life, and the area in general from her. That is, we learned a lot when a handful of armchair tour guides on the trip could restrain themselves from vying for center of attention. There were several, but the ringleader felt the need, at times, to interrupt the tour guide to explain that she took a whale watching tour once in Monterey Bay and learned something different. I was pretty excited to hear from vacation-lady, since clearly, my girlfriend and I had shelled out $400 for the day to hear what some woman remembered of some California vacation she took once. That was superior in every way to hearing the expert we were there to hear. /sarcasm

Why do I harp on this on a technical blog? Well, because in a strange way it reminded me of being at technical user groups or conferences. In those venues, I’ve frequently sat in a room and listened to an audience member or two completely derail the presentation with questions about minutiae or grandstanding games of “stump the presenter.” I’ve sighed and rolled my eyes through long-winded ‘questions’ whose only purpose was clearly to brag: “So, how do you think this ‘Introduction to Java’ presentation can help someone who has written 16 compilers — someone like, oh, let’s say, me?” I tweeted about this once and vulgarly called it “Q&A-hole” but I think I like the ring of “Armchair Tour Guides” (or perhaps “Armchair Presenters” or “Armchair Experts”) better.

ArmchairPresenter

Don’t be that guy. Don’t be an armchair anything. It’s tempting for all of us, including me. Gameshows and games about trivia wouldn’t exist if possession of knowledge weren’t a fierce source of human pride, and it’s perfectly natural to want to showcase what you’re proud of, but this isn’t the venue. Even if you aren’t deterred by how rude it is to hijack a session, then be deterred by how unimpressed those around you actually are that you googled airplanes before a plane tour or that you once went on a tour somewhere like this tour or that you’ve played with the technology about which someone is presenting. Seriously — no one cares. Ask yourself who those in attendance have paid or come to see, and if the answer isn’t “you” then you’re going to have a really, really hard time stealing the show. People don’t walk out of those types of presentations thinking, “wow, I’m glad that one guy showed up and hijacked the presentation and man am I impressed with how much he knows!” They walk out thinking, “if that idiot is in another talk I plan to attend, I’m leaving.”

By all means, engage and ask questions of presenters, but, as an exercise, ask yourself whether others would find the answers to those questions interesting or helpful. If the answer is “probably not,” then wait until the presentation is over and engage the presenter one on one (or email him or her later or something). And, if you’re going to interrupt to share your own experiences, a better rule of thumb is, “don’t because no one cares.” Now, is this universally true? No. I’m sure there are examples you can think of where some witty audience member interjected a quip or corrected a presenter and it was actually valuable and helpful, but that is oh-so-rarely the case, compared to the number of times people do it, assuming it will be the case. I’m not offering hard and fast rules of existence, but rather guidelines for behavior that will make you far less likely to inspire annoyance and loathing in your fellow humans. It’s amazing how far common courtesy goes, sometimes.

« Older Posts
Newer Posts »