I.

“Aperture: Senior QA (2004-2005)” is an account by an ex-Apple engineer who worked on Aperture, a photo organizing app. There was some unpleasant stuff, apparently, but at the same time while reading it I acutely felt that I missed something important in life.

Here is a sample of the unpleasant stuff. Requiring people to work nights and weekends:

One day, they sent out a group email saying everyone needed to start working nights and weekends until the very end of the project. Keep in mind that the project still had roughly six months to go! People with kids would be sacrificing their entire summers.

Feels unthinkable to me. And so does this shouting incident:

I replied that I couldn’t go along with the mandatory work hours. [...] The person that sent that email came to my office within minutes. He slammed the door and shouted at me so loud that people heard it five offices away. HOW DARE YOU, he bellowed. I was fucking up the whole project, he said.

It’s not that “shouting” and “work” never occurred together in my life – I did once shout at a colleague for making my life harder by misunderstanding “git rebase”. But still, something feels very off there. As well as here:

Another fun story was that I was dragged into bug review meetings several times with management. They seriously yelled at us for writing bugs. ‘This bug should never have been written!’ they shouted. They argued that we shouldn’t write bugs on incomplete features. [...] My feeling was if you find a bug, you have to record it, or you won’t remember to check it later. [...] These managers were trying to keep their bug counts down, so they adopted all these tactics.

What?

Managers love to plot bug counts and try to see if they can make the graph get to zero by a specific date. I found out second-hand that a high-level meeting took place late in the project where they were discussing risks to the project shipping on time. I was considered a risk to the project because of the number of bugs I filed.

...What?

II.

Looking back, I have always worked according to “when it’s done, it’s done”. Even when there were deadlines, I would try to spend as much time as possible on the parts that did not have deadlines attached – refactoring, writing specs/documentation, improving the build process, working on continuous integration, etc.

When I worked on features with hard deadlines, I was stressed about getting them done in time, but what I cared about was getting them perfect. I remember a dialog from the time I was coordinating a two-week feature sprint at Wire:

— Me: Let’s rename this field in our public API from X to Y.
— Web team: But two days ago you said it would be called X.
— Me: Yeah, but now I think Y is a better name.
— Web team: Let’s leave it as X.

I wanted to say “BUT THEN A SUBOPTIMAL NAME WILL BE IN OUR PUBLIC API FOREVER”, but didn’t. I’m still slightly upset about it.

On the other hand, I did not care about temporary infelicities as long as I could eventually fix them:

— Me: Let’s add a fake endpoint implementation until I’m done with the real implementation.
— Backend team: What? Let’s not.
— Me: But then the web team will be able to move forward faster.
— Backend team: Still, let’s not.
— Me: WE HAVE TO, THE DEADLINE IS SOON, THE SKY IS FALLING
— Backend team: Fine :/

III.

What does it mean to have something “done”?

On the implementation side, things have to be as consistent as possible – same naming conventions, same code formatting, same technologies used. No duplication anywhere – pieces should be abstracted away where possible. Automatic tests for everything. No known bugs. (How can you ever require people to file less bugs? You might miss some if you do it!)

The codebase doesn’t have to be perfect as in “written exactly like you would write it if it was the N-th version of the codebase, with N approaching infinity”. But it should be in a local optimum – no easy ways to improve it, no low-hanging fruit.

On the product side, it gets trickier – something along the lines of “it’s perfect when any possible complaint can be dismissed as illegitimate”. If your app only works on Windows, well, you can say “it’s Windows-only”. If it works on Windows and macOS but not Linux, you no longer have an excuse and you should work on the Linux version.

In other words, you need to have every feature that you can’t justify not having, and the only admissible justifications are either “I don’t know how to do it” or “it goes against the product vision”. Note that “it’s not a priority” is not an admissible justification.

These quotes from a Twitter thread by Allen Holub perfectly capture my ideal workflow:

One assumption that underlies the belief that Jira is good is that a backlog is an infinitely long list of up-front requirements captured by experts who pass those requirements to teams to implement as specified. 1/6

Those requirements must be tracked to make sure they don’t get lost, and you succeed by retiring the requirement. 2/6

The requirements are (a) fixing all bugs anyone was able to find, and (b) implementing all features I can think of. When it’s done, the product deserves to graduate out of beta, but no earlier.

Maybe in some cases it’s even a good approach – I don’t know. But so far it seems to be a disaster.

I don’t want to work like this anymore.

IV.

Going back to the Aperture story, I see why I feel that “everyone needed to start working nights and weekends” is unthinkable. Not just unacceptable – “you can’t treat people this way” – but more like... why would you ever want to? When it’s done, it’s done; why does it matter if it gets done earlier or later?

And this is what I missed – the sense of urgency caused by having goals that are not about producing a perfect artifact. Those goals can be anywhere from “not getting fired” to “beating competitors” to “solving an important problem for customers”; they don’t necessarily justify asking people to work overtime, but they move it out of the territory of “why would I” into the territory of “I choose not to”.

I’m not saying I want to have worked somewhere I am shouted at, or made to work nights and weekends. But maybe it would have helped.