DaedTech

Stories about Software

Sep
4

By

Keeping Your Eyes on the Prize

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

I’ve heard people say things like, “we need to use the strategy pattern here” or “we need a repository layer between the services and domain objects.” Let’s take that at face value and assume that these are things that they “need” to do, in the sense that they’re solid solutions to some problem. The point of confusion then comes from a lack of understanding of the goal. I mean, I doubt that the goal is “to use the strategy pattern” or “add a repository layer,” so someone is explaining a means of achieving a goal.

If the context of the discussion is two people well aware of and in agreement upon the actual goal, then this is entirely unremarkable. It’s just a couple of people collaborating to solve a problem. Somewhat more interesting is the case of the two people not sharing a common goal. For instance, if the first person’s goal is “make it easy to add a new implementation to the code base” while the second person’s goal is, “practice using the strategy pattern,” agreement becomes a matter of coincidence rather than collaboration, and the possibility of tragi-comic feuding emerges. The most noteworthy case, however, is where one or more people are unaware of the goal or don’t actually have a broader goal. “We need to use the strategy pattern because my Software Engineering textbook says Gang of Four is good.” Or, in the Expert Beginner world, “we need to use Strategy Pattern because that’s just what we do.”

Lack of a Goal

I’m not going to spend a whole lot of time on this because it’s pretty straightforward. Assuming that the person in question isn’t a nihilist or troublemaker, this is the epitome of cargo cult. I think that perhaps the most iconic example of this is the pervasive mid-2000’s use of Systems Hungarian Notation. This gives rise to the following type of terminally stupid conversation:

Interloper: Why did you do this: “const char* lpcstr_str”
Cult Member: I wanted to declare a string.
Interloper: Okay, but why did you name it that?
Cult Member: Because it’s a string.
Interloper: That name seems inscrutable and redundant — what’s the upside?
Cult Member: I don’t understand the question. It’s a string. That’s what you name strings.

Cult member has no goal whatsoever because his routine has become a goal unto itself. And really, that’s sort of a sad state of affairs not worth elaboration.

Pawn

Lack of Consideration of a Goal

Not all participation in routine is the celebration of routine. Routine does, in fact, have a purpose. It’s sort of the human-natural way of prioritizing cognition. What I mean is, imagine a world where you approached everything as if it were a riddle requiring critical thinking. Every morning you’d stop to ask yourself if there wasn’t, in fact, a better way to brew your coffee than using your Keurig. And, the drive to work? Should you find a new route? Should you drive at all?

Nobody has time for this, so a great many activities are conducted on auto-pilot with rationale revisited only strategically. Every now and then you may wonder if you should make your coffee differently or drive to work via a different route, most likely as a result of ongoing frustration with something. And that’s fine. In fact, it’s probably efficient.

This applies in a limited way to programming. I say limited because programming is knowledge work and it’s also rarely repetitive if you’re doing it well. Programming isn’t like driving to work or making coffee; you’re generally blazing a new trail even if you’re doing something comparably formulaic like some kind of forms-over-data/CRUD app. The domain changes, the languages/frameworks/tools in use change, and the business context changes. There may be aspects of the craft that you don’t revisit as often, such as, say, which source control tool or programming language you use, but by and large programming demands fewer brain reps on auto-pilot than most other things in life. In this context, lack of consideration of a goal puts you in danger of settling in to a rut and not being at your sharpest.

Keeping your Eye on the Goal

As you go through your life as a programmer, I have a definite suggestion for how you can avoid a rut. Always be able to rattle off your goal when asked about what you’re doing. That’s it, really. The goal doesn’t necessarily have to be great, and your means of achieving it doesn’t need to be either (I mean, do your best, but I’m making a point here). Just knowing what it is you’re trying to accomplish well enough to articulate it will help you a lot.

So if you’re overhead saying, “we need to implement the strategy pattern here” and someone asks you why you think that, be ready with “the goal is to allow future implementations with a minimum of violence to the code base ala the Open/Closed Principle.” Now, it could be that the strategy pattern is a poor choice or that you’re gold plating or whatever else, but at least you’re not caught flat-footed when challenged on your motivation and, more importantly, thinking in terms of goals creates a concrete link between your solution and added value.

And if the next question you want to ask is, “what if someone asks you for the goal behind your goal,” this absolutely iterates. A logical follow up would be “why are you worried about future implementations,” and your logical answer may be, “we’ve been asked to add 3 already, so it seems like a 4th and perhaps beyond are likely.” Now, your connection of solution to broader goal is “business has created a lot of churn around X, so I think we can use the strategy pattern to minimize the risk associated with any more similar churn.” Want to go another round? How about the fact that each time this has churned it’s cost your company $15,000, and you think that, with the strategy pattern, you can cut that to $5,000.

So, where does the iteration end? Perhaps at “we’ll have more money if we do this.” Perhaps further (“we need more money so that…”). Perhaps not that far. But, really, the further back along the path of your reasoning, the better. The more you can tie your specifics to broader, strategic goals, the more persuasive you’re going to be and the more likely you are to have solutions that, even imperfectly executed, will be a help. So the next time you find yourself talking about patterns or repositories or frameworks or whatever, do an exercise and see how far back you can iterate if you were confronted with a child asking, “but, why?” ad nauseum. Worst case scenario? You waste a few minutes practicing justifications of your decisions.

Aug
20

By

A Developer’s Guide to Recruiters

Category: The Life of a Programmer Tags: , |

More and more of my posts these days are in response to reader questions, but this one actually isn’t. However, I’ve been asked about specific aspects of this general theme frequently enough that I figured this was a good subject to cover. I’ve dealt with a lot of recruiters in my career, both as a candidate and a candidate seeker, and this has put me in a position to at least have an informed opinion about the subject. It’s something that’s at times overwhelming and often counter-intuitive, so hang with me, and let’s take a tour through the subject. Even if you’re a savvy job-hopping veteran, maybe I can at least offer you a different technologists’s perspective.

First Up, Check Yourself

Okay, so there are a lot of recruiters out there, and you’ve probably seen a less than stellar display from some of them. “5 Years of Experience with Swift.” “Mad XML coding skills.” “C-Pound a plus.” It’s common for developers to laugh together at these antics. There are even (hilarious) twitter accounts lampooning this. It can also be annoying to get repetitive emails from some organization about jobs that are not fits for you or to have a guy call you three times in a day, saying things like, “I couldn’t help but notice you hadn’t returned my first two calls.” I get that.

But here’s the thing. You’re incredibly, ridiculously fortunate to be in a position where so many people are saying, “hey, please come interview for this job for more pay” that you find it annoying. I’m not saying “you’re fortunate” in the sense that you lucked into it — I know this isn’t easy work — but that you’re fortunate the market is and remains so strong. It can be overwhelming at times, but imagine the alternative of being stuck in a dead end job and being thrilled when some company wants to schedule a phone interview after you’ve sent out 100 resumes through monster.com or something. You might not even know what monster.com is, and that’s because you don’t have to go looking for jobs like other people. That’s the reason that recruiters exist — because the only way to find software developers is to go prying them loose from other firms, and it’s not like CTOs are going to take it upon themselves to start cold-calling competitors’ developers to offer them interview opportunities (though some larger companies do have staff recruiters that do this).

Also to consider is that recruiters are humans, and often they are humans probably no more interested in cold calling you than you are in receiving cold calls from them. Their paycheck depends on calling up a bunch of people who are most likely to sigh angrily and tell them to lose their numbers. That’s not exactly the stuff dreams are made of, so you might extend them a touch of sympathy and understanding if they’ve built up a thick skin and don’t seem overly sensitive to your social signals. They’re out there trying to make a living by getting you job interviews.

The Nature of the Game

Alright, up front caveats aside, the next thing to understand is how the game actually works. Follow the money and understand everyone’s motivations. Understanding everyone’s motivations is the key to knowing whether you’re being fed a line or whether you should take what you’re being told at face value.

Recruiters are sales people. Their customers are companies that need software developers. Their product is mutually beneficial employment agreements, which really means that their product is you, developer. Recruiters sell you to companies. Kinda literally. Typically, their cut is 20% of your first year’s pay, give or take. So, if Devs’R’Us places you with Acme Inc for a starting salary of 100K, Acme Inc. writes Devs’R’Us a check for 20K, and the individual recruiter (typically) gets some kind of commission on this. (This obviously doesn’t apply to companies with internal recruiting staffs, except that I’d wager their recruiters are still incentivized with a commission structure.) If things blow up before an allotted time period (often 6 months) and you and the company part ways, recruiting firm has to cough back up their cut in the form of a refund.

So, you’re a “customer” of recruiters the same way that you’re a “customer” of Facebook or Google — you aren’t. You get a benefit for free by allowing something of yours to be sold to a bidder (your labor, in the case of recruiters, your ice bucket challenge videos in the case of Facebook, and everything short of your soul in the case of Google). Understanding this is the key to understanding recruiter behavior.

Amway

So Hot and then So Cold

This leads to sort of a weird arrangement. Typically, when you hear from a recruiter, you’re more than likely to ignore them or politely decline their invitations. But, if you don’t — if you show some interest — suddenly they’ll start blowing up your phone with interviews on which they want to send you. “Let’s pencil you in tomorrow morning for a phone call with Intertrode and how does your Thursday look for an in-person with Initech, and also my boss, the senior recruiter, would like to get on a call with you, and…” Wow. But then you say no thanks on Initech and Intertrode says no thanks on you, and suddenly you never hear from the recruiter again. Curious, you call and leave a message, and nothing. Maybe they get back to you halfheartedly.

Here’s the reason that this is happening. When you decide to stop ignoring the recruiters of the world, you suddenly become “fair game.” What the recruiter then does is evaluate every one of its clients that are seeking candidates and send you on a bunch of speed dates, trying to be the one to place you before anyone else snatches you up. But if none of those things works out, you’re yesterday’s news and not really worth revisiting until later when they’ve filled enough positions and taken on enough new openings that they can cross reference you against a bunch of new things.

Of course, not all recruiting firms are identical in their approach, but this is extremely common. I can’t tell you how many times I’ve heard from a recruiter that was extremely excited about a few gigs or even a single gig, and then radio silence for 3 or 6 months, only to have this repeated again and again. Recruiters’ clients are the companies, so they systematically go looking for people that would match that particular vacancy. Once they find you to match that one, they’ll economize by considering you for any others as well, but after that initial wave, it’s on to the next set of people.

If you can find a recruiter or a recruiting firm that is developer-focused — that is, one that gets your resume and talks to you, and then regularly checks in with you about potential positions — hang onto this one and partner with them on a long timeline. This is not common and it’s a nice resource for you.

They Say the Damndest Things

When you’re actively engaged in the interview process courtesy of a recruiter, the recruiter wants everything to go well. They want you to show up on time for the interview and make a good impression. They want the interview to go well and both sides to be impressed. They want things to sail along, resulting in offer, acceptance, and employment for at least six months. Cynically, that’s it, anyway. In reality, they probably want both sides pleased over the semi-long term so that companies keep giving them business (though they also depend on market fluidity, so they probably don’t want anyone sticking anywhere for too long). They want to pluck you from companies and put you in a new job as quickly as possible because higher churn rate means more money. Toward that end, they’ll say a lot of things, some of which are solid advice (such as their position on counter offers, described here), and some of which are nonsense.

Bear in mind their goal and the fact that they don’t mind a bit of reality distortion to achieve that goal, and it’ll be easier to understand why they say what they do and whether you should believe it. Here are some things that I’ve heard multiple times from different sources that you shouldn’t let fool you:

  • “Why don’t you come in for an in person interview with us?”  Nah, don’t do that.  It’s not a good use of your time.  They basically want to make sure that you’re not going to embarrass them and cause them to look silly to their clients, so they’d prefer to make sure you can dress and act like a human.  You can offer to do a chat over Skype, and they’ll usually be fine with that.  I personally just decline outright with no offer of anything because there are plenty of fish in the sea.  Almost invariable they say, “oh, yeah, that’s okay.”  If you’re employed, you don’t get that many absence excuses — don’t waste the ones you have going to meet with recruiters.  A lot of the savvier recruiters will often ask to meet you 20 minutes before your interview, so you could even suggest something like that.
  • “It’s okay for you to call in sick again, people do it all the time.”  No, that’s not true.  People don’t call in sick on a Monday morning and then again on a Wednesday afternoon “all the time.”  To be clear, the recruiter doesn’t care a lick if you get in trouble or jeopardize your current role — in fact, they’d probably prefer it because it would make you more likely to accept an offer, should one be made.  Do not ever listen to recruiter ‘advice’ about how to handle your job search when it comes to your current employer.
  • “We really need to get you over there today or tomorrow because they’re probably going to fill this role soon.”  Don’t rearrange your schedule as part of a pressure sale.  One of two things is happening here.  The first is that the recruiter is trying to light a fire under you to move quickly, in which case, who cares.  Schedule things when they make sense for you, not to let the recruiter squeeze in a commission before month’s end.  The other case is that the company is really scrambling to fill a role, and if that’s the case, you’re probably better off moving on anyway.  I mean, can you picture a company like Amazon, Facebook or Google saying “we really need a warm body in here in the next few days, so even though your resume is impressive, if you’re not here by Wednesday we can’t use you?”  That sort of reeks of desperation and I would consider it a red flag.
  • “Yeah, it’s not technically a senior title, if that’s the kind of thing that matters to you, but this is a great opportunity that you should take.”  Senior title.  Certain pay grade.  Certain benefits/perks, whatever.  If you have requirements you’ve made clear up front, don’t let them wheedle/coax/beg/manipulate/browbeat/guilt you into thinking that you’re being silly or overly picky.  Your requirements are requirements for a reason, but the recruiters don’t care at all about that reason or your ambitions.  If you want to leave your current role to become a “Senior Software Engineer” somewhere, don’t let them cause you to doubt your goals.  They want their placement fee, no matter what your title/pay/benefits/etc.
  • “Look, I make more money if you make more money, so I want to get you as high a salary as possible, but you really should take this offer as-is.”  Yeah, well, let’s talk expected value.  If there’s a 100% chance of offer acceptance of a 100K offer, there’s a 100% chance of the recruiter getting 20K for an expected value of 20K.  If there’s a 50/50 chance of an offer acceptance at 110K, the negotiated wage, the recruiter has an expected value of only 11K (50% chance of 22K and 50% chance of zero-Ks).  And they know it.  Like real estate agents, they don’t want you to have the highest wage — they want you to sign the offer.
  • “This is really a great opportunity and you should take it.  I’ve helped place billions of developers just like you and I know a little something about this industry.  Think of how much it will benefit your career and your personal life and everything else to blah, blah, blah….”   You don’t need life coaching from a recruiter.  This ‘advice’ when there’s an offer in hand is something you should utterly and completely ignore.  Think of the conflict of interest.  It’s like a car salesman telling you how important car ownership is when you’re contemplating a purchase.  Of course they’re going to say it, whether or not it’s true.  So it’s literally just noise.  Tune out the recruiter and make your decision.

You may hear these exact things, variants thereof, or even arguments I haven’t encountered, but the important thing is always to keep in mind how they make their money and what their motivations are.  Their goals are mostly aligned with yours — you both want you to be placed in a new role that makes you happy.  But to you “makes you happy” is most important and to them “placed in a new role” is most important.

Working Effectively with Recruiters

With your goal and their goal being pretty similar, it’s not terribly hard for your relationship with them to be a beneficial one.  Here are some tips that I’ll offer for getting the most out of working with recruiter:

  • Decide your requirements for changing jobs ahead of time and be crystal clear about them when talking to any recruiter.  In fact, state up front that you’ll immediately shut down the interview process if at any point you discover one of them won’t be met.  If they believe you on this count, they’ll have no incentive to try to shoe-horn you into something with the hopes that they’ll figure out how to persuade you to take it.
  • Be firm about things, but be polite.  Sales pitches of any sort can be annoying, but keep your cool.  Stick to your guns, make your position clear, but resist the temptation to get worked up in any way.  They are, after all, trying to help you in general.
  • Screen your phone calls.  If you’re actively engaged with a number of recruiters in a job search, you’ll probably get a lot of calls that might be awkward to take during the day.  They might also be pinging you with needless status updates or check-ins.  Your mileage may vary, but I’ve generally found it helpful to let them leave messages and call them back later.
  • In advance of dealing with recruiters, decide on your preferred times of day/week for phone interviews and recruiter calls and also decide on your preferred medium of communication, such as email, text, phone call, whatever.  Make this clear to the recruiter up front.
  • Let them address and cover your mistakes.  Just like they’re trying to sell you on the company, they’re trying to sell the company on you.  If you had a brain fart and thought your phone interview was tomorrow morning instead of this morning, call the recruiter and ask what to do.  Most likely, they’ll apologize to the company and say it was their miscommunication.  Smoothing over logistical snafus is something they’re good at and usually willing to do.
  • Let them help you negotiate and do things like thank you notes.  I know I said that they’ll want you to accept offers as is, but once it’s clear that you won’t be deterred from negotiating, they’ll turn right around and apply the same shtick to the company about you.  Having this intermediary is nice because it defrays conflict between you and someone who is about to be your employer.  In general, the recruiting firm is good at maintaining the best face of both you and the company to the other party.
  • Avoid giving recruiters specifics of leads/offers you’ve obtained through other recruiters.  They’re clearly just going to try to talk you out of whatever it is, so there’s really no need to have the conversation.
  • Whatever happens, don’t take it personally.  Ideally, you land a job, and the company, recruiter and you are all happy.  But maybe you get two offers and then decide to take the other one.  Maybe you even accept an offer and then quickly switch to taking a better one (or decide to stay put).  Maybe you pass on an offer.  There are a lot of end-games where recruiters might resort to more desperate techniques: lecturing you, affecting anger, sadness or disappointment, telling you that you’ll never get a better offer, even vaguely threatening you.  It’s all part of the game.  I promise you that no matter what they might say to you and how you might react, they’ll call you in three months about a new full stack senior role as if nothing ever happened.  It might be offensive to you, but it’s just part of the game.

Recruiters provide a service that matters to our industry where job hopping is common and demand is through the roof.  They grease the skids for us to be able to move fluidly between gigs.  The paradigm isn’t ideal, but it’s the best we have for now, so you might as well get used to the idea that you’re going to be playing this game and then, and enlist their help to play it well.

Recruiters are really just sales people, and the relationship between developers and sales people is generally a somewhat reluctant ones.  We’re makers that want to build things so well crafted that adoption is a no-brainer and requires no selling.  Sales people are relationship-oriented and deal mainly in people.  Within organizations, these groups often have natural friction, so the friction only increases when the software people are the product being sold.  But if you can get past the intense weirdness of this arrangement and work effectively with recruiters, it will only benefit your career.  Work with a lot, find firms that you like and work well with, and remember them for next time you’re on the market.  You won’t regret it.

Aug
15

By

Walk a Mile in Their Shoes

Category: The Life of a Programmer Tags: |

It’s easy enough to look back and chuckle at your own foolishness in your younger days, but sometimes I have the weird, sadistic (masochistic?) thought that I’d like to rip a little hole in space-time so that I could get my money’s worth. I’d go back and actually belly laugh and point at 12 or 13 year old Erik. Then I’d settle down and tell me to trust me because we’d be better off for it in the long run, lest you think that I’m cruel.

But I Have So Much To Offer!

What’s so funny? I have this memory of being convinced that some girl or another couldn’t possibly help but be interested in me if only she could see me how good I was at knocking aluminum cans over from 6 or 7 feet away with a bull whip. You tell me that isn’t funny — I think it’d be like laughing at Ralphie after shooting his glasses with his Red Ryder BB Gun.

ChristmasStory

So the back story was that my father, at some point, had gone to Australia or some far off land on business and brought back an Indiana Jones-style bull whip as a souvenir. Over the course of my childhood I became quite accurate with this thing, able to hit small targets and take impressive chunks out of them when I did. In my early teenage years, at the crossroads between wanting to be Indiana Jones and wanting to find young women to take on dates, this odd juxtaposition took place. As kids, we sat in school all day, confined to relatively run-of-the-mill social interactions and activities, and the lone hope you might have for standing out in such an environment was to create some sort of ruckus by misbehaving. There was no chance for anyone, least of all girls that I wanted to impress, to see the unique and clearly very appealing set of skills that I had, such as knocking over cans with a bull whip.

One of the iconic things that you hear children utter, at least in movies of the “16 Candles” genre, is “s/he doesn’t even know I exist.” That wasn’t my problem; I went to a small enough junior high school that pretty much everyone in the grade was aware of one another. My problem was that people knew I existed but didn’t particularly care. But it was a problem that could be solved if I could just devise some way that the entire school was threatened and only someone who was pretty accurate with a bull whip could save it. Or something.

I Can Guess What Interests You

I wised up. Certainly not all at once, and I make no claim to have figured out, even at the age of 34, a foolproof plan to make someone sympathetic to my cause. But I did learn that no girl in my junior high would be interested in watching me shred cans with a bull whip unless she were already interested in me for some other reason. I kind of had to wise up, earlier than some and later than others, or else I would have been the socially stunted Napolean Dynamite character who, at the age or 17 or 18, thinks that girls liked guys with “Bo skills, nun-chuck skills…”

There’s a spectrum of ages at which people come to understand this social lesson. And, I’m not talking about figuring out what attracts girlfriends or boyfriends at an age when bodies and minds are changing on a weekly basis, but rather I’m talking about the lesson of recognizing alien approaches to and outlooks on life. Children have a simple and rather solipsistic view of the world, even as they tend to have a high amount of empathy. The child will be genuinely flummoxed that you could enjoy the taste of brussel sprouts when he cannot, but is also liable to start crying if you start crying. In a way, this empathy is part of the simplicity — all for one and one for all, with the all and the one being external clones of the child.

But at some point, I figured out that me thinking it was cool to whip cans did not cause the various girl-crush of the week to agree with me. I learned that she did not empathize. Together as aging children, in fits and starts, we shed both our empathy and our belief in our opinions and values being shared by all. Budding psychopaths probably get there quicker than others. After all, they never had any empathy to start with and glib social chameleons tend to be the best at manipulating social situations to get reactions that they want. A psychopath would be entirely too busy running a series of social experiments to have private emo moments and thoughts of, “if she only knew how awesome I was.” Psychopath would think, “tricking her into thinking I’m awesome will be fun.”

I mention this because it’s not really matter of “EQ,” exactly, to adapt to the alien outlooks of others — it’s pretty much a feedback loop with the slowest to adapt being among the more introverted and leery of spending social capital on potentially doomed experiments. And so it went, and so it went. I learned, slowly but profoundly, that a lot of people wouldn’t be impressed with me, wouldn’t value what I valued, wouldn’t necessarily approve of me, and perhaps flat out wouldn’t like me. It wouldn’t necessarily be any fault of my own — it could be a matter of circumstance or misunderstanding.

What I learned from this, particularly as an introverted sort, was to spend a lot of time trying on masks of other people’s outlooks on life. Please don’t confuse this with empathy — I’m not particularly empathetic. I just got good over the years at putting myself in the shoes of others to understand their motivations and predict their behavior.

You Have Nothing that I want

In case it wasn’t entirely apparent, I’ve drifted away from talking about love interests and am just talking about life interactions. That is, I didn’t go to singles nights and try some kind of Sherlock Holmes shtick to deduce what would endear me to women. But I did carry my bullwhip and its valuable life lesson with me to adult social interactions, jobs, engagements, etc.

Why does Steve in accounting give me dirty looks whenever I pass by? I’ve never done anything to him. Well, rather than just chalk it up to Steve being a scumbag, maybe I do a bit of listening and a thought exercise. Maybe I learn that one of Steve’s big initiatives had been pushing to have the software group write a series of extensions onto Quick Books that could, ideally, be parlayed into a side business venture for the company and thus into impressive resume fodder for himself. Maybe I also learn that this initiative had died on the vine when they brought me in to overhaul the company’s software practices and that, as a result, Steve’s stock had dipped some with the company. Maybe I also learn that Steve is sort of paranoid, so he perceives this mild dip as an existential threat to his livelihood. So maybe, I am a threat to Steve earning a living. This makes no sense to me, and it would probably make no sense to most people, but none of us is Steve.

I was a pretty weird kid with pretty weird interests, so the profound lesson that I learned had a lot of reinforcement. It was unusual for others to share my outlook, and this gave me a whole lot of practice figuring out theirs for the sake of relatability. When I was younger, this skill was needed for me to form friendships and romantic relationships, but having squared those things away and as an increasingly reclusive adult, it no longer helps me attain things that I want; it helps me maneuver deftly through professional situations. I don’t want anything from people, except, by and large, pleasant professional collaboration. I’m a maker and builder and I’m comfortable with the square I’ve carved out for myself, so my days of using the skill of walking miles in others’ shoes to get things are long past. I just want peace.

So what to do about Steve? Well, the natural thing to do would be to approach him and ask him if, given his expertise, he might have some ideas for software initiatives and that I was thinking of asking some higher-ups if we could give him more of a challenge, given how marketable he is. He most likely wouldn’t assume that I’ve quietly assimilated information and made an effort to understand what life is like looking out from Steve’s brain. He’ll no doubt be distrustful and skeptical, but he’ll also probably start to adopt a different attitude toward me, if subtly. And what does any of this cost me, whether or not I follow through with any of it? Nothing, really.

I’ve come full circle. Steve is out whipping cans and feeling spiteful toward anyone who doesn’t agree with him that this is a wonderful skill. I think his skill is silly and I’d laugh at him for this privately, the way I laugh at 13 year old Erik, but I don’t want his spite. So I’ll watch him do his thing stoically and then offer some praise when he’s done.

What’s the lesson in all this? Why am I posting about it? Why did I spent so much time on narrative and so little time relating it to your life? Well, the point is pretty simple. When you have conflicts with people in a work environment — when you distrust, dislike, or even despise a colleague — fight the urge to categorize others as adversaries or enemies. Almost without exception their behavior, however capricious, childish or cruel it may seem to you, will make some kind of sense if you really get inside their head and understand how they look at the world. It may even be that you have to preface this to yourself, “if I were a petty, sadistic person…” So be it. However alien, you need to understand it. And I say this not to heal the world or advocate that you seek understanding and turn the other cheek, but to counsel you toward simple pragmatism. If you understand those around you, then you’ll understand what it is they want, and how you can steer interactions with them toward favorable outcomes.

So, take a few deep breaths and try to understand what makes those around you tick. It’s not the empathetic thing to do, but rather the practical thing to do.

Jul
11

By

What’s Your Greatest Weakness: The Employer-Candidate Impedance Mismatch

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

I recently posted about why you shouldn’t take interview rejection to heart.   I promised at least another post, if not more, to follow on that one, and here I am, making good.  This is where I question the value of interviews as we know them and describe what I consider to be vaguely depressing about the way we come into work.  Naturally, I’ll start this off with a non sequitur about circuitry.

In the world of circuitry, there’s a concept known as “impedance matching,” which, (over) simplified, says that you should match the output impedance of one component to the input impedance of the component into which the first one feeds. In this fashion, you prevent inefficiencies in or possible damage to the circuit that you’re constructing. The term was co-opted and inverted in the world of software (“impedance mismatch“) to describe the awkward transformations that occur when object oriented applications use relational databases to store information. Colloquially, you might say “you’ve got two puzzle pieces that don’t fit together quite right and you’re jamming them together.”

And so it goes, I would argue, with employee-employer matches in the corporate world. Of course, it doesn’t seem like it on the surface when you consider labor as a simple market transaction (or even when you factor in the middle-man, quasi-rent-seeking behavior of technical recruiters). A job seeker is selling labor and an employer demands labor, so the two negotiate on the price, with each trying to maximize its own interest (pay, but also benefits, days off, cultural perks, etc). Cut and dry, right?

Well, not so fast. Employers don’t make hires in a vacuum but rather they commonly hire people with some regularity and have a “general hiring strategy.” Employees do, on the other hand, get hired in a vacuum and their only strategy is maximizing their situation using rational self interest. So employees seek to maximize the perks with the best offer, but I would argue that companies in their hiring optimize for eliminating worst case scenarios rather than maximizing the upside of any individual hire. Put simply using examples and probability theory, consider the following scenario.

A company has a choice. They can hire Alice or Bob. Bob is a known commodity and a decent software developer. He’s not going to blow anyone’s socks off, but he’s not going to check in terrible code. Alice, on the other hand, is a divergent thinker and extremely creative. Based on her history, there’s a 75% chance that she will be a game-changing hire in a good way, delivering way more value than most people, improving those around her, and bringing true innovation to bear. But, there’s a 25% chance that all of the things that make her special will fail to mesh with the existing team, and there will be fireworks followed by a flameout in short order.

In my experience, most companies will tend toward hiring Bob, even though the expected value of offering the job to Alice is higher (calculated, say, by Bob having a 100% chance of delivering a 5 out of 10 and Alice having a 75% chance of delivering a 10 and a 25% chance of delivering a 0). Established companies favor avoiding disaster more than reaching for the stars. Bob has a zero percent chance of delivering a zero, so Bob it is. And so, we have an impedance mismatch between the zero sum games being played by both sides. Applicants operate in a world where each side is maximizing expected value, but companies play in a world where they are minimizing worst case scenarios.

This has a resulted in a depressing process by which job offers tend to happen — an interviewing process focused at every turn on “screening.” Take this test. Let’s do a phone screen. Come in for a first round interview. All of these activities are generally oriented around thinning the herd rather than finding the leader, and they’re also intrinsically tolerant of false negatives. Gotta break some eggs to make an omelette or, in other words, “sure, you’ll reject some qualified candidates, but you’ll (theoretically) guarantee that no complete duds will be hired.”

But once you make it past the “screening” hurdles, it switches gears and really does become a matter of selecting the preferred candidate.  That is, in most candidate searches, once all but a handful are screened, the question becomes “which of these do we like best?”  And this question is answered by talking to the candidates for a few hours and then choosing one (or perhaps more, depending on whether hiring is being done for a specific position or to compensate for attrition/allow growth).  So, let’s think about that — after a comparably objective filtering out process comes a largely subjective game of “based on a conversation of a few hours, let’s find someone to spend the next several years with.”

I have an operating hypothesis that I’m not really in any position to test for the time being.  So, be warned — here comes some frankly unsubstantiated conjecture.  My hypothesis is that this reductionist “pick the best of five” activity would be no different, statistically, than random selection of a candidate.  However much we might think that this personal interaction-based reading of the tea leaves brings the ‘best’ candidate to the top, it really doesn’t matter.  For every “bad attitude” candidate you successfully pass on, you’ll filter out “better attitude having bad day.”  For every candidate you hire because she nails the “what’s your greatest weakness” question due to cultural fit, you’ll hire someone whose greatest weakness is being a lying but convincing sociopath.  The “interview five, pick one” process strikes me as the same kind of process I go through when squinting at mutual funds for 10 or 15 minutes before deciding how to allocate my 401K.  I have no idea what I’m doing, so I just pick one and hope that everything works out.  My hasty “research” is entirely a self-administered placebo designed to make me feel better about some kind of due diligence.  And that’s how we, as a society, hire people.

So, the typical hiring process is one that is designed to first filter outliers and then secondarily to pick from the best of those still standing.  But there are two core problems.  Filtering outliers means filtering all outliers and not just the bad ones, meaning a potential drive toward mediocrity (or at least standard) and picking from among the best is essentially (axiomatically, here) window dressing on random choice.  So the candidate search, for all its clever questions, stress interviews, fancy clothes, synergies and whatever else we dream up really just boils down to “filter for slightly above average and pick at random.”  And I’m pretty sure that you could do that with submitted SAT scores and a dartboard, saving everyone time, money, and dry-cleaning bills.

Before you think I’m some kind of self-righteous voice from the clouds with everything figured out, I’m not.  I’ve conducted and participated in this process, willingly, from both sides.  I think everyone would agree that candidate selection is a reductionist activity with an insanely high margin for error and the fact that many companies have actual protocol in place for dealing with hiring misses attests to that very fact.  Gains made by introspection tend to be heuristic and not algorithmic, but I’ve played the good soldier with the rationale of “this is the worst way of doing it, except for all of the other ways I’ve considered.”

I still don’t have a particularly concrete solution, but I do have the beginnings of some ideas.  Github is quickly becoming an industry standard place to say, “look what I can do, left to my own devices.”  Stack Overflow is a place where not only can developers showcase their knowledge and accumulate points, but they can prove to would-be employers that their peers consider them to be knowledgeable.  Blogs are somewhere that interested employers can go to see whether a candidate would be a good fit in a waterfall shop. Coderbits pulls a lot of theses sources together into a single point of information.  These sources of information are freely available, asynchronous, and aggregate.  My life is summed up much better in these venues than it is by me sitting in a conference room, wearing a suit, and talking about a time I faced and overcame a challenge.

But I think there’s room for additional improvement as well.  How better to know whether a candidate will do well on a project than putting that candidate onto that project?  What I’m about to talk about is not currently tenable, but imagine if it were.  Imagine if there were a way that an organization could structure its work in such a way that onboarding time was virtually nil and so prospective developers could be tossed an assignment and get started on contract.  Is it working out after a week?  Great!  A month?  Great!  Now it’s been six months?  Great — let’s move to a more permanent W2 arrangement and thus from dating to marriage.

Employers could dispense with the prognostication games and tests and simply shuffle ‘candidates’ in and out, keeping the ones that were the best fit while passing on the ones that weren’t.  For candidates, this is great too.  You’d no longer be faced with these, “do I take this huge, life changing leap or pass and watch my situation deteriorate?” decisions and be able to generate income while shopping around.  A mutual feeling out period would allow a fit based on experience, rather than conjecture and games.

There are two enormous hurdles to this.  The first is the problem of benefits and the mind-numblingly unfortunate practice of health insurance being tied to employment.  If the USA has a spasm of collective sanity in this regard, perhaps that problem will go away at some point.  The second problem is actually making it viable for organizations to take on developers and have them go from unknown to “writing productive code” in a single day.  And solving that problem is also non-trivial.

But personally, I’d like to see more discussion around hiring processes that involve trial periods and shortening of obligatory worker-labor consumer relationships.  This isn’t to say that I think everyone should endure the stress of a job search on an almost constant basis, but rather that I think it should be easier for people and organizations to move seamlessly into arrangements that are better fits.  We should dispense with the pretense that indefinite stays are the norm and recognize that it’s going to vary widely by individual taste and personalities and projects involved.  In the end, moving in a direction like this could conceivably do wonders for morale across the industry and go a long way toward eliminating institutional knowledge hoarding in favor of beneficial cross pollination.

Update: This post has been in my drafts folder for a week, but I happened recently to stumble on this video:

“Pick the fourth resume from the top.” I’m not alone in my hypothesis that random selection would be a reasonable replacement for conversational interviews.

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.

« Older Posts
Newer Posts »