The Many-Worlds Interpretation of Developer Interviews

A recent post by Yegor Bugayenko titled Why I Don’t Talk to Google Recruiters highlighted a common misconception about careers in the software industry, certainly a misconception that I had in the early years of my career.

Yegor described a very unproductive interview experience he had with Amazon, where he was subjected to the dreaded whiteboard hazing:

Some programmers who didn't know a thing about my profile asked me to invent some algorithms on a white board for almost four hours. Did I manage? I don't think so. Did they make me an offer? No.

If [the Amazon recruiter] would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms. There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them.

I stopped nodding my head long enough to write a sympathetic tweet:


Like many developers, I fantasized about working for companies like Google—a company with cool products that I admired and with legendary perks for its employees. It took me a long time to understand that Google selects for a certain kind of programmer, one that I fundamentally was not.

As Jon Galloway explained in a post back in 2008, one that was highly influential on me at the time:

Steve Yegge works for Google. Steve and I are both professional programmers; in fact we both work on web applications. Yet, our jobs are no more related than if we were both doctors in different fields - say, a podiatrist and an orthodontist. For example, if you work for Google, you're going to be concerned with how to make your applications run against huge data sets using large, unreliable computer clusters. None of those are priorities in applications I work on, since I'm generally working against a relational database which aren't running at high volume or scale. So, Steve is thinking about how to build Google-scale applications running on Map/Reduce, while I'm working on comparatively small projects running against relational databases.

I still believe that Steve's questions would be useless in hiring someone to work on my current projects. I don't care if a candidate can check if a high-order bit is set, to the point that I might be a little turned off by an applicant whose answer revealed they were a bit-twiddler. I've hired bit-twiddlers before, and while they interviewed well, they weren't much help in shipping applications. Worse, we're wasting valuable time talking about hexadecimal formatting when we should be covering things like database access and rudimentary knowledge of HTML and HTTP.

What it comes down to is that the “software industry” is comprised of many kinds of people, working for many different companies, working on very different things, with very different priorities.

Don’t beat yourself up if you don’t spend your free time on Project Euler or if the idea of working through the linked list algorithms in a book about technical interviews makes you want to slit your wrists.

Most software jobs outside of Silicon Valley are not with high profile tech companies that hire for these kinds of traits. Most companies are interested in hiring people with experience in solving real, everyday business challenges with the technologies they’re invested in.

Find your world.

Small Diffs and Code Reviews

I enjoyed reading Dan McKinley’s recent post, Ship Small Diffs, in which he explains some of the benefits that fall out of committing code in very small amounts, perhaps a dozen lines.

My favorite benefit of doing this is the way it gives code reviews a fighting chance of being useful.

Dan writes:

Submitting hundreds of lines of code for review is a large commitment. It encourages sunk cost thinking and entrenchment. Reviews for large diffs are closed with a single “lgtm,” or miss big-picture problems for the weeds. Even the strongest cultures have reviews that devolve into Maoist struggle sessions about whitespace.

Looking at a dozen lines for mistakes is the sort of activity that is reasonably effective without being a burden.

In my experience, code review is one of those “best practices” that teams tend to adopt in a sort of “put a check mark here” way where they’ve heard it’s a good thing to do, and lots of good tech companies do them, but they never take the time to do them in a way that actually adds value to their development process.

Looks fine.

Submitting a thousand-line diff that traverses many files for code review is almost worse than useless. No one has the time to rebuild the mental context of the person who wrote this pile of code, to a point where they could even hope to intelligently criticize its design.

A code reviewer who receives a diff like this will 9 times of out 10, pull out their LGTM stamp and continue on with a productive activity. If you’re lucky, maybe they’ll notice a variable name is misspelled or something. If you’re unlucky, the reviewer will turn into the world’s most inefficient linter, and point out all the places you used double-quotes instead of single-quotes.

Looks good to me.

Unfortunately, to get any real benefits out of code reviews, the team must internalize some lessons about breaking down large changes into minimally viable increments. It’s not as simple as just saying, “Yep, we do code reviews.” and patting yourselves on the back.

But…when you get there, the benefits go so far beyond effective code reviews.

Different Strokes for (Remote) Folks

There was a recent article on the popular topic of remote work that made the rounds and generated a lot of discussion.

I cannot trust employers to provide me with an adequate work environment, and this holds me back from doing the best possible work for them.

In the case of working from home/remote work, some employees do not do their best work from home, or simply don’t like it. That is fine—but you should trust your employees and treat them like adults. Let them make the call for themselves.

- Yan Lhert

There’s nothing that engenders respect within me for a company more than when they give me autonomy over my own working conditions. And I, like most people, give the greatest effort to a company I respect. A vibe of “We trust that you know what’s best for yourself” is extremely motivating.

It’s so interesting reading through the comments on Hacker News when articles about remote work come around. I could summarize most of the back-and-forth like so:

Person A: I work best like [this], and I think it’s ridiculous you like to work like [that].

Person B: Well, I work best like [that], and I think it’s ridiculous you like to work like [this].

Jeez! It’s almost like we’re all adults who have strong preferences for the way we like to work.

The solution to this conundrum begins and ends with Autonomy.

Here are some old sayings that capture the sentiment:

One Workplace Design to Rule Them All is doomed.

I’m a believer in hybrid workplaces. The company has an office (or offices), but no one is forced to work in the office every day on a compulsory basis. And the office itself is a hybrid: sections are open plan for the people who prefer that environment, and there are quiet sections with a partitioned “cube farm” or small private rooms. Choose your own adventure.

There are two caveats I feel I must mention.

  1. The employer must actually care about having high-performing employees. There are plenty of “body shops” out there who don’t necessarily care about this, and likely can’t differentiate high performers anyway.
  2. Employees must understand the common theme throughout the working world that the highest performers get the most latitude. It’s up to the individual to take that autonomy with good grace, and kick so much ass that no one would dream of messing up your flow.

Different strokes for different folks.

If You Can Lean, You Can Clean

With the inevitable slowdown in new projects that comes around during the holiday season, I was reminded of a saying I heard several years ago (attributed to Ray Kroc of McDonald’s fame):

If you've got time to lean, you've got time to clean.

As I touched on in my post on the Boy Scout Rule, I relish these bits of downtime as opportunities to clean up a little.


I always cringe when I hear a colleague say that they have “nothing to do.” Or when a person’s manager inquires about what they’re working on, and the person reports that they’re simply “waiting” for something.

At least as a software developer, I can say confidently that there is always something to do.

  • Remove some junk from your codebase (unused files/folders, ancient commented-out code, dead code)
  • Update that wiki article
  • Change that little thing that’s been bothering you but was too small to take time away from other work

Some of the nicest things are accomplished in small gaps between “real” work.

If you can lean, you can clean.

Be the Automator

In my first job as a professional software developer, the “lead developer” (there were only two of us!) introduced me to a product called CodeSmith.

My reaction to discovering this thing called a “code generator” was disgust. “But…but…I’m the code generator!” I thought. I was incredulous that a professional software developer was promoting a tool that automatically wrote code—the exact thing our employer was paying us to do! It was quite a shock to a young programmer just starting his career. Luckily, code generators were more of a curiosity to him, and we quickly forgot about it. Phew!

Fast-forward a decade plus, and there is nothing I would rather have than a tool that would automatically write all my code for me. Code sucks!

Dan the Automator

In a sort of ironic twist, I have come to feel strongly that the foremost responsibility of a professional is to make their own job go away. I love working in the field of software engineering, but I also wish we could teach computers how to do it. It can be damn tedious at times.

There has been a lot of talk in the last few years about the future of “jobs” in general. People are facing the idea that jobs lost in the Great Recession may never be coming back. As companies invest more and more into automation, there are entire categories of human labor that might simply disappear in the not-too-distant future.

We folks who make our living in the software industry are at the forefront of automation. I like to joke sometimes that my job is to put people out of work. A dark idea, but it’s essentially true.

Automation is simply inevitable—the benefit of having a machine do a human’s job cheaper, more consistently, with no sick time, and no complaining ever, is too great.

And yet, while being at the forefront of automating other people’s jobs, there are so many aspects of our own work that can be automated. For example, I cringe when I see “QA people” following written instructions while clicking on this button, and then that link, and then typing in foo, and then clicking this other button, and then confirming that this other thing says bar. When the viability of your job depends on your boss never hearing about Selenium, you’re in a bad way. I like to call this “Job Security by Obscurity”. The same goes for developers spending months writing and maintaining their own artisanal ORMs—if Active Record can do your job better than you can, just admit it and move on.

So my career advice to a younger me is this: Be the automator.

Don’t let someone else discover how much of your job can be automated. Find these opportunities yourself and own them. If someone is going to automate your work, it’s going to be you dammit! Teach the stupid computer how to do it, and then apply your working hours to stuff that humans are still way better at.

In the fullness of time, the last remaining “job” is that of the Automator. Be the Automator until there’s nothing left to automate.

A Healthy Disdain for Technology

I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.

If you're programming in PHP, you're not running around talking about "convention over configuration," giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.

Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.

-- swalsh (Hacker News commentor)

I like it when people use rough language toward technology.

Code kinda sucks, doesn’t it? Wouldn’t it be great if there were less of it? Isn’t it a pain in the ass to deal with?

Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it.

-- Jeff Atwood (Coding Horror)

Like many in the software industry, I’m looking on through fingers over my eyes at the horrorshow of front-end web development in 2016.

-Look, it’s easy. Code everything in Typescript. All modules that use Fetch compile them to target ES6, transpile them with Babel on a stage-3 preset, and load them with SystemJS. If you don’t have Fetch, polyfill it, or use Bluebird, Request or Axios, and handle all your promises with await.

We have very different definitions of easy. So, with that ritual I finally fetched the data and now I can display it with React right?

-Is your application going to handle any state changes?

Err, I don’t think so. I just need to display the data.

-Oh, thank god. Otherwise I would had to explain you Flux, and implementations like Flummox, Alt, Fluxible. Although to be honest you should be using Redux.

I need to display data on a page, not perform Sub Zero’s original MK fatality.

-- Jose Aguinaga (“How It Feels to Learn JavaScript in 2016”)

Some times it feels like it’s not enough for teams to simply produce valuable software for their customers, they must do so while demonstrating “craftsmanship”, using the most lovingly-curated, artisanal stack of JavaScript frameworks, transpilers, chat tools, NoSQL databases, and text editors.


On the contrary, I believe we need technologists that have a healthy disdain for technology.

Be suspicious by default. Make every framework and tool fight its way in, justifying its existence at every step. Have the courage to say YAGNI to MEAN, blow a KISS to JSX.

And most importantly, get back to shipping great software to your customers.

Humility in Software Development

Kent Beck approved

I think many software projects would end better if we developers would say these things more often:

  • No, we can’t get that much work done in the time span you’re suggesting.
  • I don’t think we’re disciplined enough to see this complicated feature through to production-readiness.
  • We should probably buy a third-party solution for this because we won’t be able to solve the problem as well as they already have.
  • This thing is extremely difficult to do well, and you probably won’t get your money’s worth by having us do it.
  • You’re too optimistic about this project.
  • This requirement is not unique, and we should probably just copy the approach taken by another team.
  • There is already a product that does this—you should use that rather than have us develop custom software for you.