Work

Building Better Habits

These are my notes on an interview with James Clear: Designing Your Environment to Shape Your Behavior

  • Improving habits basically means overcoming your orientation toward immediate gratification to instead improve delayed returns.
  • To create habits that stick, you need to:
    • Make it obvious
      • This is the cue/trigger to remind you to do the thing
      • Design your office/home/desk/etc. to encourage the habit you want
      • E.g., don’t hide your fruit & vegetables in the crisper drawer, put them on the counter!
    • Make it attractive (the more attractive it is, the more you crave doing it)
    • Make it easy (the lower friction it is, the better)
    • Make it satisfying (he more satisfying it is, the more you want to repeat it)
  • The goal of doing these is to remove willpower from the equation
    • People who are successful in maintaining good habits are the ones who do not face temptations… not the ones who are magically more strong-willed
    • Willpower can’t sustain you long term
    • Resisting negative cues in your environment is very fatiguing
  • For negative habits (stuff you want to stop doing; “habits of avoidance”), do the opposite:
    • E.g., make it non-obvious—don’t tempt yourself by seeing it!
    • A few approaches to making the negative habit satisfying:
      • Replace the bad habit with a good one
        • This is important: you need some sort of reward for doing the new thing
        • It still needs to satisfy the same craving that you used to have
        • It can’t just be about having willpower to resist doing the original thing
      • Increase the friction massively to do the bad thing (remove the exposure to trigger yourself)
      • Make “doing nothing” more satisfying than doing the bad thing
        • E.g., instead of buying a coffee, every time you were going to buy one, put $5 in a savings account
        • Gives you a benefit for when “nothing happens”
  • For big, important, key areas of your life, you can start by making the habit really easy (and basic), and make it successively more difficult to get the “reward”
    • E.g., start with 1 minute of working out a day, scale up to 30 mins or whatever
    • Only applies to areas you want to be truly great
    • For most things, good enough is good enough (it’s not worth being the best flosser ever)
  • Reaching more abstract goals (e.g., write 25 blog posts this year) by shaping your habits
    • The key is to make it *feel* immediate and concrete
    • Give yourself a strong visual of your progress
      • E.g., start with two bowls, one full of paper clips; each time you take the action, you move one paper clip over; your goal is to move all the paper clips from one jar to the next
      • Habit trackers work the same way
        • Putting an X on the calendar is satisfying
        • Each X reminds you to do it again
  • Automatic habits (stuff you do without even being aware of it) can lead to really important routines
    • You want to make the first 2 minutes or so of your important routine effortless
    • E.g., if I get home from work and put on my workout clothes, going to the gym becomes automatic and easy; but, if I have to make a conscious decision to put on my workout clothes, it might not happen at all
Advertisements

The Worst Bug I Ever (Nearly) Shipped

The year was 2014. I was wrapping up about a year’s worth of work on the X-Plane 10 Mobile release, and we were all set for a Christmas release. Timing this was difficult—we were pressed for time, and the App Store approval process takes an indeterminate amount of time; you submit a binary, then wait (in those days, at least 7, sometimes more than 14 days) and hope they approve it. If they don’t—if they reject the app for any reason—you have to go fix the issues they identified, then submit a new binary (and go to the back of the line).

To make matters worse, the App Store approval process shuts down entirely for about a week around Christmas. So, if we missed the December 22 deadline, we wouldn’t get the app out at all until the first of the year.

So, on December 16th, Chris (the project manager for the mobile app) called me. “Congrats,” he said. “We made it! They’ve approved us, and I’m going to go do a little bit more testing and then mark the app for sale.”

“Awesome!” I said. “I’ll do a little more testing as well.”

…

You can tell where this is going.

All the aircraft in X-Plane Mobile are sold separately, somewhere between $0.99 and $4.99. But, we offered two ways to try the paid planes for free: a 60 second trial flight, or a free 24-hour “unlock” with one catch: you had to post something on Facebook or Twitter about X-Plane in order to get the 24 hours of playtime. This whole “pay-with-a-post” thing was my brainchild… I had read about other apps doing it, and I had been 100% responsible for the implementation.

In my testing, I discovered that sharing to Facebook worked fine… but the app wasn’t actually unlocking the planes after you did so!

I had inadvertently introduced the most infuriating bait-and-switch imaginable.

I was nearly ill as I called Chris. I explained what happened—how my screwup was going to force us to have to pull the app, resubmit it, and entirely miss the Christmas release window. To his credit, Chris was devastated, but he didn’t berate me about it. Bugs happen, he said, so let’s just get it fixed ASAP and move on.

I got the one-line fix committed as soon as we got off the phone. Chris was able to contact Apple and explain the situation. As luck would have it, they took pity on us and went ahead and reviewed the fixed version of the app (without sending us to the back of the line). We got the app out the door the next day, in time for Christmas break, and we both breathed a huge sigh of relief.

Hiring Software Developers

We recently hired a pair of software developers at work, and I’ve gotten a couple requests to write up how we did it.

The traditional hiring process—source a billion resumes, eliminate them based on keywords, interview the top hundred people, then pick one—is pretty broken. Fundamentally, filtering by pre-existing experience with your tech makes you miss the enormous swath of smart people who could get up to speed on your stack quickly, and potentially become tremendously valuable to you. Whenever I hear people lament that it’s impossible to hire developers, my first question is always: how many good devs are you excluding from your search?

In addition to unduly weighing resume keywords, the traditional interview process also massively penalizes people who can’t code or problem solve under pressure. There’s a certain class of people who do well in high-pressure interviews, but that skill isn’t strongly correlated with overall value as a developer.

The alternative to all this is: just have people write code that exemplifies the role you’re hiring for. We wanted anyone who might be a good fit to apply, and we would narrow our choices by comparing the code they wrote.

At a high level, our interview process looked like this:

  1. A blog post asking for applicants. (This obviously only worked because we have a large number of developers reading our blog; I think the same principles could have applied to a StackOverflow job listing and the like.)
  2. A preliminary chat over email, to answer any questions they have and generally make sure they aren’t vastly under-qualified.
  3. A small set of “homework” problems—problems that are characteristic of the most difficult type of work they’d be doing, with a definite right answer (or set of right answers).
  4. A phone interview with the top performers on the “homework” questions.

Let me break down how we handled each of these stages…

The call for applications

In our blog post, we were very careful not to eliminate any potential hires. We wanted to hear from any smart, self-disciplined developer, period, and let the homework problems show us who to pursue.

In retrospect, specify a CS degree as a requirement was a mistake, one we won’t make next time; one of the two candidates we hired doesn’t have a degree, and he’s one of the strongest developers I’ve ever met. I hate to think that we would have weeded him out for no reason at all if he hadn’t had the self-confidence to apply anyway. Strong self-confidence is not a job requirement!

The instructions in the post were simple: send us an email introduction  with a brief overview of a project (or projects) you’ve enjoyed working on, and a discussion of projects you have not enjoyed working on. I tried to make it clear: there’s no need to stress about this email!

One final note about the call for applicants: this is also a time to sell your company.

The intro email

In the intro email the applicants sent, I was looking for a few things:

  • Past projects (not necessarily professional) that indicated this person knew software development. I didn’t follow up with the people whose projects amounted to “hello world.”
  • Interest in the type of work they’d be doing. If the person’s description of what they were interested in directly conflicted with the job we were trying to hire for, I sent back a response gently explaining why I didn’t think this would be a good fit.
  • Strong English communication skills. We’re an English speaking team, and especially for a development role, we can’t afford to have ongoing communication issues.
  • Ability to follow simple directions. This one was inadvertent, but I got quite a few emails lacking the details we requested in the blog post. I did not follow up with these people.

I also used the email chat to answer any questions they have and generally make sure they aren’t vastly under-qualified. My primary goal at this stage was to not eliminate anyone who could potentially knock our socks off in the coding challenge… but at the same time, to not waste anyone’s time.

I was also up front at this stage with people I expected we couldn’t offer competitive compensatation. For instance, a developer with 15 years experience in database programming working in Silicon Valley probably commands $150k+, but a) as a distributed company, we’re not going to pay SV premiums, and b) their (vast) experience is in a totally unrelated field. Some applicants were okay moving forward with the interview processs despite the expected pay cut, some were not.

The homework problems

The most important feature of the homework problems is that they had objective criteria on which they could be compared. Each problem had dozens of scoring criteria, such that anyone on our dev team could grade them and we could differentiate a really good solution from an okay one. And because we gave the same problems to everyone, we could compare their performance to the rest of the applicant pool.

I was aiming for a total time cost to the interviewees of under 2 hours for people with prior experience in the problem domain (in this case, performance tuning an algorithm in C++). But, for people who had never worked on something like this, they might have needed a significant amount of reading to get up to speed—whether that’s a primer on what sorts of things govern an algorithm’s performance on modern CPUs, or simply a crash course in C++. I did my best to provide any resources the applicants needed—again, I wasn’t trying to filter by previous experience!—such that a smart applicant could read the provided reference material and turn it into a strong homework submission given enough time. (For applicants that didn’t want to invest the time to go from zero knowledge to a working solution, I completely understood… but obviously we couldn’t move forward with those people.)

The interview

We scheduled Skype interviews with the six candidates who submitted the best homework solutions. Each interview was conducted by two to three senior devs on the team, in a (hopefully) low-stress discussion format.

Since the homework told us everything we needed to know about the person’s ability to code, the interview was focused on their ability to communicate about technical issues. We talked about their homework solutions, asked about their past work, etc. We also did our best to make sure they would be a good fit for the level of independence and autonomy that we need from our developers.

A few of my favorite questions we asked in person:

  • Can you tell us more about some of the challenges you faced on [some past project]? (This question works best if you can ask about a specific subsystem that you, the interviewer, have some domain knowledge on.)
  • In any sufficiently large codebase, you tend to accumulate some old, awful, legacy code that’s kept around because “it ain’t broke.” As a developer, it feels skeezy to leave that code in such a horrendous state, but you probably don’t need to touch it in order to implement any given feature/fix. What do you do? (My goal with this question was to assess how they balanced business needs against personal “hygeine.”)
  • Development teams operate on a continuum between “total developer anarchy” and “micromanagement of every task.” Where do you prefer to be along that continuum? (This question is trying to ensure the person won’t expect more oversight than we can give, and I tend to follow up with questions about how they’ve handled management in the past.)

Results

We were extremely happy with how this worked out. The two people we ended up hiring are phenomenal, but honestly, I expect that any of the people that made it to the phone interview would have been great hires… and most of those would have been filtered out in step 1 if we had posted the typical list of “job requirements.”

How (and Why) to Ask for a Raise

A family member asked me for my thoughts on asking for a raise, and after a handful of massive text messages, I decided I should probably just write a blog post.

Before I get into it, one disclaimer: My working experience is entirely confined to small businesses. If you work for a megacorp, for instance, salary discussions probably look entirely different (and are probably tied to an annual review or something). My experience is limited to places without any type of formal process in place.

Why ask for a raise

Fundamentally, your relationship with your employer is a business deal. You have no obligation (aside from whatever the legal minimums are) to them beyond what you agree to, and you can rest assured that they feel no obligation to you.

You work for them because you like the money, or the hours, or the environment, whatever.

In turn, they pay you to do a job because they like the deal they’re getting—they like the price-to-performance ratio they get from paying you.

So, when your performance improves, it’s reasonable that the price for your work should go up too—especially if you can make the argument that they’re still getting a good deal. Continue reading →