DaedTech

Stories about Software

By

Ace Your Exit Interview Using Little White Lies of Omission

Ah, the exit interview.

If you’ve had this experience, the first one probably arose in confusing fashion.  You put in your notice and the team scheduled your goodbye lunch.  At someone point, HR put a meeting request on your calendar that prompted you to say, “an exit what — what is this?”

And then you had an exit interview.

Or, maybe you’ve never had this awkward experience at all so far in your career.

Whether you’re an exit interview veteran or googling it for the first time, though, I’ve got some pointers for how to handle this.  I’ve given general advice on whether to quit a job and how to quit a job before, but this will be specific to the exit interview portion of quitting.

What Is an Exit Interview?

First things first.  What actually is an exit interview?

It’s not the most naturally intuitive concept, but you can probably infer what it involves from its name.  Still, you might wonder, “what’s the point?”

Ah, the exit interview. Crack a beer and tell 'em how you really feel.

An exit interview is a meeting that someone, usually the HR department at a decent sized company, schedules with you.  It’ll generally happen the day of or the day before your departure, and it’ll take half an hour or maybe an hour if they really want to cover a lot of ground.

They’ll ask you a lot of questions, effectively looking for a private, Glassdoor-style review of the company.  For instance, here are some blue chip exit interview questions.

  • Why are you leaving?
  • What did you like most about working here?  Least?
  • How was it working with your manager and your coworkers?
  • Did you have what you needed to do your job effectively?
  • How could your manager improve?  How could the company?

You get the idea.

The exit interview is a standard practice for the company to collect and, hopefully, incorporate feedback from departing employees.  Theoretically, it offers them a unique window into people’s real thoughts about the company, since they can speak freely and without consequence.

Theoretically.

Read More

By

The Different Pair Programming Styles

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, check out their products that help you wrangle production issues in a hurry.

The world of professional programming produces some pretty intense debates.  For example, take a look at discussions about whether and how to comment code.  We have a hard time settling such debates because studying professional programming scientifically is hard.  We can’t really ask major companies to build the same software twice, using one control group and one experimental group.  So we muddle through with lots of anecdotes and opinions and relatively scant empirical data.  Because of this conundrum, I want to talk today about pair programming styles rather than taking a stance on whether you should pair program or not.

I’ve talked previously about the benefits of pair programming from the business’s perspective.  But I concluded that post the same way that I’m introducing this one.  You can realize benefits, but you have to evaluate whether it makes sense for you or not.  To make a good evaluation, you should understand the different pair programming styles and how they work.

That’s right.  Pair programming involves more than just throwing two people together and telling them to go nuts.  Over the years, practitioners have developed techniques to employ in different situations.  Through practice and experimentation, they have improved upon and refined these techniques.

The Effect of Proficiency on Pair Programming Styles

Before looking at the actual protocols, let’s take a brief detour through the idea of varied developer skill levels.  Although we have a seemingly unique penchant for expressing our skill granularly, I’ll offer just two developer skill levels: novice and expert.  I know, I know.  But those two will keep complexity to a minimum and serve well for explaining the different pairing models.

With our two skill levels in mind, consider the three possible pairing combinations:

  • Expert-Expert
  • Expert-Novice
  • Novice-Novice

Now when I talk about expertise here, bear in mind that this accounts for context and not just general industry experience.  Tech stack, codebase familiarity, and even domain knowledge matter here.  I have two CS degrees and years of experience in several OOP languages.  But if I onboarded with your GoLang team tomorrow, you could put me safely in the novice camp until I got my bearings.

Each of these pairing models has its advantages and disadvantages.  Sometimes, however, fate may force your hand, depending on who is available.  Understanding the different pairing models will help you be effective when it does.  It also bears mentioning that novice-novice pairings offer a great deal of learning for both novices, but with risk.  Therefore, the suitability of such a pairing depends more on your appetite for risk than the pairing model.

Read More

By

In Defense of Using Your Users as Testers

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download a trial of NDepend and take it for a spin; you can try it for free.

In most shops of any size, you’ll find a person that’s just a little too cynical.  I’m a little cynical myself, and we programmers tend to skew that way.  But this guy takes it one step further, often disparaging the company in ways that you think must be career-limiting.  And they probably are, but that’s his problem.

Think hard, and some man or woman you’ve worked with will come to mind.  Picture the person.  Let’s call him Cynical Chad. Now, imagine Chad saying, “Testing? That’s what our users are for!”  You’ve definitely heard someone say this at least once in your career.

This is an oh-so-clever way to imply that the company serially skimps on quality.  Maybe they’re always running behind a too-ambitious schedule.  Or perhaps they don’t like to spend the money on testing.  I’m sure Chad would be happy to regale you with tales of project manager and QA incompetence.  He’ll probably tell you about your own incompetence too, if you get a couple of beers in him.

But behind Chad’s casual maligning of your company lies a real phenomenon.  With their backs against the wall, companies will toss things into production, hope for the best, and rely on users to find defects.  If this didn’t happen with some regularity in the industry, it wouldn’t be fodder for Chad’s predictable jokes and complaints.

The Height of Unprofessionalism

Let’s now forget Chad.  He’s probably off somewhere telling everyone how clueless the VPs are, anyway.

Most of the groups that you’ll work with as a software pro would recoil in horror at a deliberate strategy of using your users as testers.  They work for months or years implementing the initial release and then subsequent features.  The company spends millions on their salaries and on the software.  So to toss it to the users and say “you find our mistakes” marks the height of unprofessionalism.  It’s sloppy.

Your pride and your organization’s professional reputation call for something else.  You build the software carefully, testing as you go.  You put it through the paces, not just with unit and acceptance tests, but with a whole suite of smoke tests, load tests, stress tests and endurance tests.  QA does exploratory testing.  And then, with all of that complete, you test it all again.

Only after all of this do you release it to the wild, hoping that defects will be rare.  The users receive a polished product of which you can be proud — not a rough draft to help you sort through.

Users as Testers Reconsidered

But before we simply accept that as the right answer and move on, let’s revisit the nature of these groups.  As I mentioned, the company spends millions of dollars building this software.  This involves hiring a team of experienced and proud professionals, among other things.  Significant time, money, and company stake go into this effort.

If you earn a living as a salaried software developer, your career will involve moving from one group like this to another.   In each of these situations, anything short of shipping a polished product smacks of failure.  And in each of these situations, you’ll encounter a Chad, accusing the company of just such a failure.

But what about other situations?  Should enlisting users as testers always mean a failure of due diligence?  Well, no, I would argue.  Sometimes it’s a perfectly sound business or life decision.

Read More

By

Deploying Guerrilla Tactics to Combat Stupid Tech Interviews

I’ve realized something about my situation.  I work for myself, building businesses and still, occasionally, consulting at times.  But of course that’s not news to me.  Nor is the fact that I’ve moved out to a quiet, remote place where I wear T-shirts exclusively, fish a lot, work when I feel like it from a room in my house, and often cook dinners over a fire in my backyard.  The realization came from marinating in that lifesyle for a while, and then noticing that I have absolutely no reason to pull any punches with my opinions.  No affiliations, no politics, no optics to manage.  So why not have some fun expressing those opinions, provocative or not, as DaedTech posts?

Today, I’d like to take on the subject of tech interviews.  Of course, talking about the deeply flawed hiring process isn’t new for this blog.  But I’m going to take it a step further by suggesting how we, as individuals, can try to fight back against Big Tech Interview.

The seed for this came from an idle internet clicking sequence that brought me to a blog.  The company to whom the blog belongs, Byte by Byte, offers the motto, “your one stop shop for acing your coding interview.”  Below that, it says, “master the coding interview game”  (emphasis mine).  It struck me then.  Yes, of course.  It really, truly is a game, and a stupid one at that.  But let me come back to the cottage industry of Princeton Review for tech companies later.

The History of the Job Interview

For this history, I’ll offer an excerpt from my book, Developer Hegemony, describing the history of the job interview in general.

In 1921, tired of hiring college graduates that didn’t know as much as he did, Thomas Edison made up a giant trivia questionnaire to administer to inbound applicants. According to Mental Floss, questions included “Who invented logarithms?” and “Why is cast iron called Pig Iron?” If you look at the sorts of questions that modern day tech companies seem to think they’re cute for asking, courtesy of cio.com, they include such profundities as “Why is the Earth round?” and “How much do you charge to wash every window in Seattle?” If you mixed Edison’s and tech companies’ questions together, you’d be hard pressed to tell the difference.

To summarize, almost 100 years ago, an aging, eccentric, and incredibly brilliant inventor decided one day that he didn’t like hiring kids that weren’t his equals in knowledge. He devised a scheme off the cuff to indulge his preference and we’re still doing that exact thing about a century later. But was it at least effective in Edison’s day? Evidently not. According to the Albert Einstein archives, Albert Einstein would not have made the cut. So the biggest, trendiest, most forward thinking tech companies are using a scheme that was dreamed up on a whim and was dead on arrival in terms of effectiveness.

But surely it’s evolved somehow. Right? Well, no, at least not in any meaningful way. In this piece from Business Insider about the “evolution” of the job interview, we can see that what’s actually changed is the media for asking dumb trivia questions. In Edison’s day, interviewers had to get cute face to face. Now they can do it over the phone, through a computer screen or even via a mobile app. Who knows what the future will hold for the job interview; they may be able to beam the stupid directly into your cerebral cortex!

Google Looks Critically at Tech Interviews

In the book, I cover a lot more ground than I can or will here.  I lay out a case for how uniquely pernicious this interview process is for tech.  It artificially depresses software developers’ wages and manufactures job scarcity in a market where demand for our labor is absolutely incredible.  But let’s seize on a different point for this particular post.

I have specific styles of modern tech interviews in my sights as worse than others.  Specifically, the whiteboard interview, the trivia/brain-teaser interview, and the “Knuth Fanatic,” algorithm-obsessed interview.  These serve mainly to make the interviewer feel smart, rather than to reveal anything about candidates.  But don’t take it from me.  Laszlo Bock, former head of Google HR, said this:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

And also this:

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess.

Read More

By

Side Hustle Ideas: 5 Simple Ones for Software Developers

I was originally going to write the next corporate realpolitik explained post, this time about the software architect.  And, while I can and will still do that (tweet at me or something if you’d like to speed it along), I’m just not feeling cynical these days.

I have a nice winter of drifting through the US south planned, running a lifestyle business and generally enjoying myself.  So why not write about something instructional and uplifting?

Like side hustle ideas.

What’s a Side Hustle?

It’s not so complicated.

If your full time work is your full time hustle, then your side hustle is work you do on the side.  You could think of it as a hobby that makes you some money.

For some, that’s all it is and all it stays.  Others might look to it as an eventual job replacement.

If you work 40 or more hours per week, this might seem daunting.  And, it can be.

Instead of spending your recuperation time reading, watching TV, or appreciating your family, you’re carving off a slice to do even more work stuff.  For that reason, you should be sure to find something you like doing.

And also for that reason, I’m going to emphasize more manageable and iteratively achievable side hustle ideas.

This post is mainly aimed at salaried software developers that have never made money outside of a salaried context.  Anyone is, of course, welcome to read along — it’s not like side hustle ideas are exclusive in any way.

But understand who I’m talking to with this advice.

I’m talking to folks with full time jobs that don’t want to risk running afoul of employers (say, by moonlighting) and don’t want to spend all of their waking hours on the side hustle.

Before the Side Hustle Ideas, a Suggestion: Don’t Build Software as a Side Hustle

First up, let me recommend a few hustles not to pursue, particularly for those of you that are first timers at this.  It’s not that there’s anything wrong with these things.  They’re just not where you want to start.

First of all, don’t make a mobile app or build a SaaS.

Yes, you heard me correctly.  You’re a software developer and I’m steering you away from software development.

Why?

Here’s the thing.  You spend all day, every day writing software for a living already.  You know software — you live it and you breathe it.

So if you go home and start a side hustle building software, all you’re going to do is build software.  You’re going to build it, then build it some more, and finally, after that, when it’s finally time to ship, you won’t ship so that you can spend another year building it.

I’m exaggerating, but not a ton.  Bias toward familiarity makes for great procrastination.

Why do you think software developers contemplating a blog spend weeks agonizing about what platform to use or whether to hand code it.  Because you know software and you don’t know writing.  So you dither over unimportant software decisions.

Side hustles are about earning some extra money, sure.

But they’re also about teaching yourself business, which I heartily endorse since continuing to improve as a generalist programmer starts to yield diminishing returns after a while.  So lay down the IDE and dive fully into the business world.

Read More