The Art of Interviewing

May 28, 2022 by Gabriel

The job interview process is a high-stakes dance that’s notoriously difficult and full of missteps — on both sides. (At least, in software engineering it is. If you care about another industry, <Jedi hand wave/> this is not the article you’re looking for.) Avoiding the missteps is an art, just like it is in dancing; we get better with practice, just like dancing; it’s a lot of fun when it goes well, just like dancing; and leading with dexterity is paramount. This article focuses on that last bit: not on what questions to ask or how to structure the time, but rather on artfully leading an interview. First, however — because it’s a crucial part of the interview context — we should start with how the job candidate views the process. Just like dancing.

Because while for Larry the Interviewer, it’s just a small fraction of his day — maybe an annoying one that pulls him from the dynamic programming problem he was definitely not working on — for Jane the candidate, it’s one of the most important events of her life. The median job tenure is about 4 years, so people will only have somewhere around 10 jobs their whole professional life. And each of those jobs is going to significantly affect Jane’s life both during, and after, it. The CV builds on the shoulders of the previous job, yes, but work also where we spend the bulk of our weekday, make friends, and develop a large part of our identity.

So what does Jane go into this high stakes dance equipped with? If the company is large, maybe she can get a sense of the general culture from Glassdoor, or news articles, or social media. Otherwise, maybe a sense of how it wants to be seen, from its marketing. But even then: what will her daily life be like there? Would she like her new boss? Her teammates? The bureaucracy? The tasks she’ll be working on over the next year? Four years? Unless she knows someone on the inside, these questions mostly won’t get answered until after the start date. Sure, she’ll get to peek in now and then through cracks in the process and through the five minutes of each interview in which she can ask stuff, but: largely unanswered. Which means it all adds up to a big gamble.

The gamble is better for more mercurial and adaptable personalities than those more averse to change, but your resume can only tolerate a couple of quick stints before it starts getting tossed aside. So it’s a big gamble for everyone. Or rather, I should say “for every job searcher”, because well… it’s a small gamble for Larry the Interviewer. Worst case for him? It isn’t even giving his thumbs up to a terrible employee — because someone truly terrible will get fired before too long. No, the worst case is that he gives his thumbs up to a really annoying Taylor that ends up on his team and really annoys him for the next 4 years. And also produces mediocre work that Larry then has to constantly deal with. But Taylor isn’t annoying enough and the work just isn’t bad enough to get fired or even be put on a PIP. Taylor kind of coasts just baaaarely on the good side of the policy. And in doing so, makes Larry’s work life feel like a chirping smoke alarm that he can never find. That is the worst case for Larry.

The best case? He ends up with a really awesome coworker. Which, depending on the existing coworkers, may or may not matter a lot. But in any case except for the narrow and unlikely one of Taylor, the stakes for Larry are much, much, much lower than for Jane. And yet, this is who decides Jane’s fate.

The irony is that all of us will — at different times — be the Jane, but most of us will also be the Larry at other times. And when we are the Larry, interviewing a job candidate, do we act as the interviewer we’d like to have interview us, when we’re searching for a job? When I grudgingly leave the house, I usually drive, and sometimes I walk, and sometimes I bike. And what I find fascinating is that when I’m a driver, I get mad at other drivers, when I’m a cyclist I get mad at drivers, and when I’m a pedestrian, I get mad at everyone. Even though I know exactly what challenges they’re all going through.

Through this lens, how should Larry — all of us, when we are the Larry — conduct his interviews? How can we be the Larry we want to see in the world?

Larry does have a concrete output from the interview; he needs to answer one simple question: is Jane likely to be successful in this role? “But wait,” you ask, “can Jane’s ideal Larry even answer that question? Can he both be empathetic and figure out if she should be hired?” To which I say: “not only can he, but that’s the best way to do go about it!” Let me illustrate by looking at some questions Larry should not be trying to answer:

Did Jane answer all my questions correctly?
Was Jane quick on her feet and graceful under pressure?
Did Jane pick up on my algorithmic hints?
Was her solution complete?
Do I like Jane, as a human being? Could we be friends?

Those are certainly signals one can get in an interview, but are they relevant to her success in the role? Does her answering all of Larry’s questions correctly mean there’s a good chance she’ll get a high performance rating next year? It depends on the questions, right? Well then, what about the inverse: does getting answers wrong correlate with bad performance reviews? Or does it correlate with nervousness? Or miscommunication? Or ignorance of a concept that Jane could learn in the first week on the job?

The hard truth is that while most interviews test something, that something is more likely to be “ability to pass our interview” than “ability to do the job well”. Which — if the abstract interview is indeed a conscious choice, which more often it is not — then the argument for it goes like this:

We want people that will do what they need to in order to succeed; if they study hard for our arbitrary and irrelevant interview process and pass it, it means they (a) really want to work here, and (b) can do the same for a real-world project

Even for well-known companies that can attract enough people to run their gauntlet, this is of dubious value, because they’re filtering for a specific criteria: studiousness; and simultaneously filtering out many that are at odds with it, starting with people that don’t have the luxury of time to study for their interview.

Instead, I think interview questions should be relevant for the job and tailored to illuminate whether Jane will be successful in it. Does it matter if Jane came up with a coding solution in 10 minutes versus 20? How much time would she have in the course of her job for that problem? Does the job require her to be well-versed in algorithms? Even if Stack Overflow didn’t exist. Is it relevant that she didn’t finish the last part, even though she explained how it would work? Are the people we like more productive than the ones we don’t? Do these rhetorical questions make my point?

Which is that the interview is not a test and it’s certainly not an interrogation. It is above anything else a conversation, ideally between equals, in which both parties are trying to figure out if an employment arrangement would be a win/win scenario. And as the interviewer, by leading it with empathy, you accomplish two things:

Have a much better chance at arriving at the truth
Leave the candidate with a great impression

So how should Larry approach the interview? I like to think about role models, because we humans are great at mimicking, and in this case I think the right archetype is a podcaster. They have a guest on their show and they generally try to make the experience pleasant, to keep the content interesting, and to really get at what makes their guest tick in their particular way. If they have an actor on they try to figure out what makes them a great actor, if it’s a business tycoon, what makes them great at business, if it’s a scientist, what makes them great at science. And similarly, Larry’s job is to figure out what makes his guest great at programming.

In order to successfully do that, the guest has to first and foremost be comfortable. People won’t let you in unless they’re comfortable. And if they won’t let you in, it is a giant barrier to understanding them. So Larry should spend some time in the beginning of the interview breaking that ice. He should make small talk — genuine small talk, not awkward conversation about the weather. Tell Jane a little about himself: what he does at the company, what he’s passionate about in his work, and what his background is. Things that will give Jane an understanding of him and help them find common ground. It’s not only worth the investment, but it’s what makes the rest of the interview worthwhile.

Once a good rapport has been established — or Larry’s given up on such happening — only then should he go into the topics he needs to cover. And he should always remember to treat Jane as he would a valued guest in his home. To be kind, to be forgiving, and to give her the benefit of the doubt. If she says something that sounds incorrect, he should make sure it’s not due to a simple mistake or misunderstanding. He should ask polite questions that help him understand how much Jane knows and understands about graph traversal or whatever — not merely that she does (or doesn’t) know that those words are the answer to his question. Because in the end, Larry’s job isn’t that of a proctor, to simply grade Jane on her performance as if this were an audition or a midterm exam. Larry’s job is actually much more difficult: it’s to create, in 45 to 60 minutes, a sorely incomplete mental model of Jane from a certain angle — be it programming ability or cultural fit or leadership style or what have you — and to then decide if that mental model is a good match to fill the open role.

Again: this is hard and it takes a lot of practice to do well, just like dancing. But taking shortcuts will just lead to lots of false positives or negatives. Tech companies love to industrialize the process and create complex questions with “objective” answers and rubrics that tally up those answers into a simple pass/fail exam and then also point to that process when talking about fairness. But in truth, there’s nothing fair about standardized tests — which is why higher education is finally moving away from the SATs.

They add a veneer of objectivity on top an industrialized process that answers not so much what a person understands, but what they’ve been exposed to and what they can quickly recall in a stressful situation. It’s like being tested for ticking time bomb diffusal for a job making watches. And the opportunities for subjectivity still abound: from how comfortable or nervous the candidate is, to how many hints they’re given, to how much sleep they got the night before, to whether they’ve seen a similar question recently, and to the leniency of the proctor.

What sets Oxford and Cambridge apart from most other universities is that they use the Tutorial System, in which students learn the subject matter in whatever way makes sense, meet in very small groups with a tutor and have a discussion — in which it will become readily apparent how well they understand the subject.

It has been argued that the tutorial system has great value as a pedagogic model because it creates learning and assessment opportunities which are highly authentic and difficult to fake.
from Tutorial System at Wikipedia

Software interviews of a similar ilk have the same value.

But the one thing to remember is that regardless of the questions we ask when we’re being the Larry — no matter how good or fair or comprehensive they are — the questions are just a means to an end, and not the end. They are a conversation starter, and it’s up to us to guide that conversation in such a way that will allow us to understand our guest to such a degree that we can answer the only question that matters: “is this person likely to be successful in this role?”

Lessons Learned on the Job Search

February 11, 2022 by Gabriel

I’m starting what I’m sure will be a great new job at an awesome company soon, but before I got that offer (and four other great ones), I was on the interview circuit for a few months. When I started looking, I figured that in this boiling job market (of mid-late 2021) it would take like around a month. For better or worse though, I hit a string of bad luck on what turned out to be an already overly-optimistic timeline: two hiring freezes (both at the offer stage in the interview loops) and a conflict of interest (after an offer).

I say “for better”, because this bad luck did come with a silver lining: it prolonged the process enough that I ended up in a lot of interviews: 79, over 34 interview loops. Which, on the one hand, was exhausting; but on the other hand, it gave me huge exposure to the current landscape of interview processes for engineering leadership at tech companies. I’ll write another article on how I think these processes can be improved, but this one is about how to deal with them — as a job seeker. Specifically, an engineering leader, such as management, or staff-level IC and higher.

This experience was so radically eye-opening for me, because aside from a random interview now and then, I’d never been exposed to it on this level. And in the pre-pandemic world, this gauntlet would’ve been impossible, due to the travel alone. My previous jobs came to me — which is a completely different dynamic — so I’m writing this to share what I’ve learned, mainly for others that are looking for a change, and are as unfamiliar with the landscape as I was.

The main takeaway: interviewing is a skill onto itself. It’s largely unrelated to the day-to-day of the job, it matters a great deal, and it’s absolutely something that can be learned. It’s like dating that way: the first few dates are crucial, and making a good impression is paramount, but the impressions you get on those early dates contain a lot of not only false signals — like being nervous or interested in everything your date loves — but also superfluous signals, that don’t matter a year into the relationship — like your favorite band.

And unfortunately, both dating and interviewing are optimized for charming (and good looking) people, who will always win out if everything else is equal. Fortunately, being a polished interviewee is a skill that I think most people can master with practice. Not unlike the premise of the movie Hitch. Because you could be the most amazing engineering leader in the world but, if you don’t interview well, no one will ever know that — aside from the people who’ve worked with you.

Before we get into the details, some more context: I interviewed with a wide range of companies, from Big Tech like Meta/Facebook and Amazon to smaller ones like like Etsy and Reddit, to startups at various stages. I applied for only remote roles, roughly evenly split between Engineering Manager (EM), Sr. EM, and Director — with a few senior IC roles added in — and all my interviews were remote, via Zoom or the like.

And I kept statistics.

But don’t worry, there’s a TL;DR section at the end that you can always skip to, if it gets too dry.

Anatomy of a Loop

Most companies have a 4±1 step process:

Screening call with an internal recruiter
- 30% of my interview loops skipped this step
A first round, which is generally a role-fit discussion with the hiring manager (HM)
- I consider this to be the first round of the loop
- For me, 76% of the 25 of these I had were just a casual discussion with the HM
- Of the remaining six:
  - four were a panel (two of which had technical components)
  - one was a coding challenge
  - one was a design challenge
A second round, consisting of one or more people, sometimes as a panel (meaning multiple interviewers are in the video call), sometimes as a string of video calls with individual interviewers. But all pre-scheduled together.
- Eight of the 13 I went through had a technical bent:
  - four included a technical chat
  - three design challenges
  - one coding challenge
- Six of them were also panels:
  - one of the design challenges, and three technical chats
A third round, which is usually the opposite of the second: if they did a panel first, then this is not a panel; and vice-versa. If they have a technical screen and the second round was technical, then this won’t be; and vice-versa.
- 29% of my interview loops skipped this step
- Three of my five were panels, and one of those was technical
- The other two were informal chats with a CTO or VP
Hopefully, an offer
- Most of my interview loops skipped this step 🙂
- All five of the offers I got had a fairly consistent base, plus 10-20% bonus, but big variation on equity — not just in terms of value, but also type: from no equity to private options to public RSUs. Equity ended up being the deciding factor for me.

For me, the average time from resume submission to some kind of decision was 32 days, but the max was 93 days, and 18% took over 45 days. Most of this was just waiting a long time for the initial response, and then for the next steps to be scheduled, each of which generally took a week or two.

The average time from resume submission to some kind of response was 17 days, but the max was 70.

What Worked at Each Stage

Resume

As you can see above, this was the biggest rejection stage, by a Grand Canyon-sized margin. A full quarter of my resume submissions were rejected, but even more (39%) were ghosted, and I never heard anything about them. I put a lot of work on my resume — and it always helps for it to be short (one page, if possible, because no one has time to screen them), to include the buzz words you’re skilled with and interested in (to make it past recruiters), and to be visually attractive (you can find lots of great templates for Google Docs on Etsy, for under 5$) — but that’s not what made the difference, as I found:

It basically all hinged on referrals, which increased my chances of getting to a recruiter or hiring manager from 5% to a whopping 63%! That’s a 12x improvement, which is impossible to get any other way. I’m sure it helped that my resume looked sharp, but I’m also sure that even with my previous, plain and long-ish resume, the referral success rate would still be multiples of the cold application.

So if you’re looking for a job: tell everyone you know in the industry, and hopefully they know of an opening or know someone who does and even if they can’t vouch for you personally: if all they do is pass your resume along with a “this person might be good for this role”, that itself does wonders. Also, if you find a job posting you really like, try to find a recruiter or someone in your network from that company. If you don’t know anyone directly, look at 2nd connections on LinkedIn, and then ask your mutual connection to introduce you.

Ironically though, in spite of all of this, I ended up at one of the 3 companies in the bar graph above where I had no network connection. And for all three of those, I wrote a thoughtful message in the freespace of the application. Now, I also did that for probably at least a dozen others, so not a great success rate there, but: if you’re applying cold, it definitely helps to write the recruiter a note about why they should choose your resume out of the pile. None of my other cold applications made it out alive.

The other big category is getting recruited. Most of the ones that reached out to me were either Big Tech companies or startups I’d never heard of, and most of those were clearly automated messages. I entertained almost all of them, if for nothing other than the interview experience. And here, LinkedIn is key: using the appropriate phrasing and buzz words and highlighting the experience relevant for the kind of job you want. Recruiters use various tools to search through the hundreds of thousands of potential candidates, and a little SEO goes a long way.

Recruiter Screen

At this stage I did pretty well: 3 rejections out of 18 conversations, for a pass rate of 83%.

What the recruiter wants is to make sure you’re not going to embarass them. They’ve seen your resume and decided that based on your history and so forth, you’d probably be a good candidate. So all you really have to do is sound competent, back up your resume with your voice, and fit within the logistical parameters for compensation, location, time zone, etc.

Hiring Manager Screen

Of the 19 HM screens I was in, my pass rate was 68%, and I have to say that most of the rejections at this stage were surprising to me. I thought almost all of them went well, and in fact I had at least two of the HMs tell me they’d like to move me forward, only to get a Dear John email a few days later from the recruiter. I imagine they talked to someone they liked more the next day, but one of the more frustrating parts of the process is that rejection feedback is exceedingly rare. The unfortunate truth is that the overwhelming majority of companies do not provide feedback, largely for legal reasons.

But like the recruiter, the HM largely wants to make sure the person behind the resume is a solid candidate, that they seem personable and would fit on the team, and at least part of this conversation is them selling you on the job. They ask more poigniant questions than the recruiter obviously, and have more details around the position and what they’re looking for and have a better sense of how you’d succeed in the position, but largely this stage shouldn’t be hard, and if you don’t pass, you probably wouldn’t have fit in on the team anyway — not that you’re not qualified, but team dynamic is a real thing.

Behavioral Interview

The vast majority of leadership interviews I was in were what has become the norm the tech industry: storytelling. I can’t tell you how much PTSD I have over the phrase “tell me about a time when …”. The idea is that an experienced manager can (a) demonstrate that experience by recollecting tales from a storied career, and (b) knows to emphasize the parts that the interviewer wants them to emphasize. In the beginning of my job search, I would fail miserably at the second part with the mind-reading, because I didn’t realize there was a hidden agenda to the question.

So they would ask me to tell them about a time when I promoted someone, and I’d literally tell them about such a thing and move on. When in fact, they also wanted me to tell them about my philosophy (a.k.a framework) around promotions, and maybe even around career development in general, and emphasize how that’s an important part of a manager’s job, etc, etc. And because of that, my pass rate in the second round (where behavioral interviews would often take place) fell to 54%, and was my lowest. And that’s after I cracked the code. It helped when reviewers would nudge me in a certain direction, but that didn’t happen often, and certainly not with Big Tech, where the rubric is king.

If you’re interested in seeing examples of this tactic, watch some videos on ExponentTV (and paying for Exponent is probably a great return on investment as well) to get a better sense of the kind of answer interviewers are looking for. And make a list of stories you can cycle through quickly, on the spot. The answers are supposed to given in the STAR format. There are various lists out there, but here are some of the ones I actually got:

Tell me about a time when…

you had to manage someone out
you had to deal with a difficult employee
you had a disagreement with a peer
you promoted someone
your project was late
you failed
you dealt with a DEI issue
you motivated your team
you affected change without using authority
you were part of a large undertaking

One prevalent theme was essentially #6 above, and that was also something I wasn’t quite sure how to answer. It felt like the old joke to me, about the interviewer asking what the candidate’s greatest weakness is, who replies that he works too hard.

But the reason people ask this is twofold: first, because experience implies failure, since no one has a perfect batting average. And so the idea is that if you’re able to talk about a time you’ve failed, you’re more likely to be an experienced leader. Second, being able to talk about failure in a way that shows humility is important in that it demonstrates some good leadership qualities such as empathy, the ability to learn from mistakes, and the ability to turn things arounds.

And herein is why getting good at interviewing and storytelling is so important, because it’s not enough to merely have those qualities: you have to realize when you’re being subtly prompted to reveal them and to do so in a tactful way. But again: it’s definitely a skill that can be learned.

Technical Interview

Only 20% of my post-recruiter-screen interviews were rigorous technical ones, and I think about half of the loops had such a stage. So it’s definitely possible to get a job without running into one, but they’re very common in Big Tech.

Of my nine technical interviews, five were design questions — and one of those was a take-home exercise. Another two were presentations of a project I’d done in the past, and the last two were coding challenges.

One of the coding challenges consisted of two leetcode-type algorithmic/data structure questions. There’s nothing to be done about this except grinding on leetcode until that part of the brain that lay dormant since your CS college courses has sprung back awake. Yes, it has nothing to do with anything in a real job, but such is life.

For the presentations, I gave essentially the same one both times: passed one, failed the other.

The design questions generally ask you to design some kind of system you’ve likely dealt with before: a search engine, a messaging service, a URL shortener. Here, it’s important to start at a high level — the main components and connections — make sure you’ve covered enough there (and take hints in the form of questions from the interviewer) and then go a level lower and talk about technologies, protocols, tradeoffs, and so on. Anything to make the interviewer feel comfortable that you have the technical chops to design things. Again, Exponent has some great videos to give you an idea of what a good one looks like.

TL;DR

Interviewing processes are very broken at most companies, and as a job seeker, there’s not much you can do about it except refusing to take part in broken processes — such as live coding challenges — if you have the luxury of doing so. For many people though, especially in the new remote world of SF/NY salaries, this would mean walking away from a significant pay raise.

Otherwise, the things I wish I had known at the onset:

It will likely be a multi-month process, due to the speed at which most companies operate; I would prepare for roughly 3 months
The best thing to get your resume noticed is to make use of your network
When you do have to cold apply, writing a paragraph to the recruiter is worth the investment
A polished, short, beautiful resume is worth the investment
Optimizing your LinkedIn profile for recruiter searches is worth the investment
Feedback, about why you were rejected, is an endangered bald eagle: rare to come across and wondrous to behold
Practicing storytelling for the behavioral interview, and looking for the question behind the question, are both crucial
Practicing leetcode is needed for many interviews at Big Tech companies
Good PowerPoint skillz might come in handy
There are lots of mock interviews available to watch — both behavioral and design — and they help a lot

All of this can be boiled down to, as Patrick McKenzie put it, “becoming aware of how power operates (versus how virtue is generally described) and choosing to join it”. Like with many concepts in the tech world (microservices, cloud computing, Agile project management) this fairly narrow interview process has evolved and largely caught on, and being familiar with it is a shibboleth that’s as important as anything else in a job search, in the early-2020s tech world anyway.

The 8 Engineers You Might Know

August 31, 2021 by Gabriel

A few years ago, I was asked to give a talk to a class of early engineering college students about the characteristics of a “good” engineer, so that they may begin to emulate those traits — or, presumably, drop out of the program if the very thought of such a thing made them ill. But as I was thinking about what these characteristics might be, I realized that there’s no such thing as a model engineer. In thinking back through my career I could identify, at least, several pretty distinct kinds of engineers, each with their own special sauce that made them great at different things. But there was no kind of Renaissance engineer, at least in my experience, that could simply excel at everything. So I started the presentation with this quote:

Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
of unknown origin, but not Einstein

I know brilliant developers who cannot work well in a team, but can debug a field problem like no one else. And amazing architects that come up with the most elegant designs, but who can’t stick to one thing too long. Or the opposite: deep tinkering thinkers who would give you the death stare if you tried to pull them off their passion project.

For the college kids, I came up with some examples, like the above, of great engineers and the situations that they excel in, but I couldn’t let go of the notion that there probably exists something like the Meyers-Briggs Types or the classical Four Temperaments, but for engineering. Pseudoscience yes, inasmuch as people don’t fit into nice and tidy boxes like that, but still helpful in thinking about strengths and tendencies.

Googling didn’t turn up anything like this existing in the tubes, and since the idea wouldn’t leave me alone, dimensions that seemed useful to me eventually took shape:

Teamwork: collaboration vs vision. Do they value teamwork more for its own sake, or for seeing their vision be realized?
Focus: design vs goal-oriented. The journey, or the destination? The means or the end? The architecture or the building?
Scope: broad vs specific. Do they like working on lots of different things, either at once or in fairly quick succession, or to focus on one thing for as long as it makes sense?

Three dimensions with two values each means 2³ = 8 broad kinds of engineers, which also felt like a good number for this sort of thing. We’ll take a look at those eight kinds next, and I’ll leave the more dry discussion on methodology until the end, but before we go any further, a caveat:

If you use these concepts for anything, it should be either for fun or as a thinking exercise, but because this is in no way scientific, it should NOT be used for anything serious -- just like the MBTI should not be. Please don't try to create questionnaires out of this, or use it to justify leadership decisions, or anything of that sort. 
What I'm hoping for is that this framework provides some insight for engineers to maybe think about themselves and their career path, a shorthand for talking about certain behaviors, or probably more than anything: just as a fun lunch conversation.

All models are wrong, but some are useful
of unknown origin

Hopefully this is somewhat the latter. Okay: with all that out of the way, here is the creamy center.

The Types

The Generalist

This persona is collaborative, design-oriented, and has broad interests. They love to hear and incorporate people’s ideas and feedback, they love to produce a beautiful cathedral of a codebase, and they don’t really care what they work on as long as it’s interesting. Design and requirements meetings are something they enjoy, and many times organize, and they take no particular pride in the cathedral because they see it as the group effort it really is, with their role as a facilitator more than anything.

I think of this persona as the typical systems engineer or spec writer, or sometimes architect. Often times, because of their people skills, they end up in leadership positions.

The Specialist

Same as the Generalist, but with specific interests. Not necessarily narrow, but they enjoy being an expert in some small number of things, and then working with teams that need that expertise. They love deepening their knowledge on the subjects they master, and they love putting that knowledge to good use to efficiently and elegantly solve challenging problems that, without their expert advice, might otherwise take the team twice as long to create something half as good. They’re often the special guest in the meeting, because they’re an expert in authentication or databases or whatever, and this team needs some authentication or database know-how imparted upon them.

The Builder

Collaborative, goal-oriented, with broad interests. They just love to build things. They have preferences of course, but by and large are open to working on a wide variety of projects. They don’t really care what it is or what the tools involved are or what the platform or the frameworks are — they’ll learn it all and make it work, and work well. If there’s a design in place, they’ll follow it, but if there isn’t, they’re happy to make one. They work very hard, will do everything possible to hit a deadline, and will deliver as good a product as you can expect.

Because of their broad interests, they gain broad experience, and because they’re goal oriented and get a reputation for meeting those goals, they tend to end up in leadership positions also.

The Conductor

Same as the Builder but with specific interests, the Conductor loves to get a particular thing done. But she’s collaborative, and the combination of traits here means this is almost always someone who quickly gravitates toward leadership. Project management, if that position exists, or whatever other role fulfills that function: tech lead, manager. The important thing is to be able to work in a team and motivate that team to do the thing well. Before she was in leadership, she got frustrated time and time again when the goal wasn’t met, and vowed that she could do better.

She doesn’t get involved in all the details of how every component works, because what she cares about is her specific role in it: to orchestrate all the moving parts so that the thing will ship on time. But she’ll get involved in whatever is required, do whatever it takes, and set up as many meetings as is needed to make sure someone will fix the situation so that the thing will ship on time.

The Architect

Now we’re in the Visionary half, where other people are, at best, a necessary evil to accomplish the vision, and at worst, something to be avoided as much as possible. The Architect, like the Generalist, loves building cathedrals; the difference is that they have a specific cathedral in mind. They don’t necessarily want your input, but the good ones will fight that urge and still consider it, if for no other reason than to improve their future visions.

With broad interests, they’ll work on pretty much anything they can, as long as the work is interesting, and they can put their spin on a beautiful design that will be implemented to the letter. Even if they have to implement it all themselves. Even if it takes 3x the allotted time. Even if the technology doesn’t exist, and they have to invent it themselves. Perhaps especially then. This is someone you want to take the thing to the next level. Depending on many, many things you might end up with the Wardenclyffe Tower or the Taj Mahal.

The Artisan

I would bet a small sum of money that the guy who maintains ntpd is an Artisan; probably the two that maintain OpenSSL, too. Unsurprisingly, they have a specific interest: working in some domain or in some technology or theme or whatever else is the singular thing that drives them. They love improving it and polishing it and crafting it into a beautiful creation that is their life’s work. They are watchmakers. They have a vision, often very specific, and will work tirelessly to see it come to life and possibly be successful — the latter is less important. What’s important is the act of creation.

Artisans are the developers that you talk about going into a cave and emerging with The Work some months later. The great ones do it mostly to spec, but creative license is something you generally have to deal with here, because that mode of operation is how Artisans produce the best work. Put them on a sprint team working on random tickets off the queue and they’ll wither and disengage. Give them a challenging problem with a corresponding amount of freedom, and they’ll make sure to wow the whole team.

The Hacker

A clarifying point for those not of the software industry, who may be reading this:

A computer hacker is a computer expert who uses their technical knowledge to achieve a goal or overcome an obstacle, within a computerized system by non-standard means. Though the term hacker has become associated in popular culture with a security hacker – someone who utilizes their technical know-how of bugs or exploits to break into computer systems and access data which would otherwise be unavailable to them – hacking can also be utilized by legitimate figures in legal situations
Wikipedia

But that’s a great definition for our purposes here too: a goal-oriented, singular visionary with broad interests. Could also be called a “fixer”. They have a lot of confidence to learn what they need to and figure out the situation, through whatever means necessary, irrelevant of pressure, to get the thing done. They don’t really care if the thing is duct taped together so much — as long as it works for now. It can always be done properly later, but what’s important is that the goal was met, the crisis averted, and the mountain was climbed swiftly.

This is the kind of person you want on a diagnostics/field-support team. Or on a critical release that can’t be late. Or on a proof-of-concept that might create a lot of value, if anyone could get it to actually work somehow. Just don’t saddle them with process and red tape, and let them hack the planet.

The Marshal

The counterpart of The Conductor, the difference is that The Marshal has a vision for how the goal will be achieved. Much like The Architect, they don’t necessarily want input, but the good ones will know that they’ll get a better success rate at achieving the goal by getting the council of knowledgeable people they admire. Unlike The Hacker, they have no interest in working on different things — they have one goal, and it’s usually a sizeable one. Like freeing Europe from Hitler’s grip. Though the term “General” is too… wait for it: generic.

Marshals are great at leading focused efforts of outsized value. Because they are laser-focused on delivering, they don’t want to deal with too many personalities or process, and so need the right kind of team around them, in the right kind of environment. And under those circumstances, they lead with passion that energizes the team and they swat away all distractions, jump in and pull the weight of three people, and lead the crew to defeat Khan against all odds.

The Disengaged

There’s one more type of engineer, and this one’s not described by the model. If you’ve tried to figure out what motivates someone who is smart and capable, but their performance is consistently at best mediocre, and nothing really works out well… it might just be that they’re not interested in the work.

Maybe they don’t like the environment (the team, the project, the company, etc) or maybe they’re distracted by bigger problems in the real world or maybe they don’t like engineering and ended up doing it because someone told them it’s a good job. Whatever the reason, some people are just there to work for eight hours a day because they can’t get much enjoyment out of the work.

Passion Pushers - Why Doing What You Love Is Bad Advice

And that’s okay. Most people need a job, and if they bring value to the team, there’s a place for them. There’s always too much work for someone that has a clear niche, there’s always enough on the backlog that no one wants to do but that still needs to be done, and there will always be emergent situations that someone needs to attend. The Disengaged can be great for essentially doing whatever the project requires at that time, without having to worry about what motivates them — because nothing might, except more time off, or more money so they can retire earlier.

Cheat Sheet

Type	Teamwork	Focus	Scope
Generalist	Collaborative	Design	Broad
Specialist	Collaborative	Design	Specific
Builder	Collaborative	Goal	Broad
Conductor	Collaborative	Goal	Specific
Architect	Visionary	Design	Broad
Artisan	Visionary	Design	Specific
Hacker	Visionary	Goal	Broad
Marshal	Visionary	Goal	Specific

8 Engineering Types

Methodology

The most accepted model for personality traits is the Big Five, which has five binary dimensions:

Extraversion (outgoing/energetic vs. solitary/reserved)
Agreeableness (friendly/compassionate vs. critical/rational)
Openness, to experience (inventive/curious vs. consistent/cautious)
Conscientiousness (efficient/organized vs. extravagant/careless)
Neuroticism (sensitive/nervous vs. resilient/confident)

To me, these seem like great dimensions on which to differentiate personalities in general, but not as useful in terms of engineering. In our industry, being extraverted and agreeable only matter insofar as they’re important for working with and leading others, so I collapsed those two into “teamwork”. Similarly, “conscientiousness” and “neuroticism” aren’t as meaningful on their own, but when looking at them through the lens of what drives people, these two made more sense as a single “focus” dimension, where we differentiate between the journey and the destination. Finally, “openness” seemed an important trait on its own merit, but through my engineering lens, it became “scope” — “broad” being “curious” and “specific” being “consistent”.

But besides the Big Five, I also looked at the Four Temperaments, which is the classical view of personalities, and which is not too far off base — and is probably why it survived the centuries. It defines four personality types:

Sanguine: extraverted, social, charming, risk-taking
Choleric: extraverted, decisive, ambitious
Phlegmatic: introverted, agreeable, philosophical
Melancholic: introverted, detail-oriented, perfectionistic

If you look not-all-that-closely, two dimensions of the Big 5 are mostly at play there as well: extraversion and conscientiousness. In terms of this engineering model, you could say:

Sanguine: collaborative and design-focused, the Generalist and the Specialist
Choleric: collaborative and goal-focused, the Builder and the Conductor
Phlegmatic: visionary and design-focused, the Architect and the Artisan
Melancholic: visionary and goal-focused, the Hacker and the Marshal

The Four Temperaments were also used to seed the Keirsey Temperament Sorter, which expands them and maps them onto the Meyers-Briggs Type Indicator. Like the MBTI, it defines four dimensions:

Concrete/observant vs abstract/introspective
Temperament: cooperative vs pragmatic
Role: informative vs directive
Role variant: expressive vs attentive

They map into 16 personalities, but I had trouble mapping these to anything useful in the engineering world. On its face, going backwards from the 16 personalities, the dimension that seemed not important (aside from management and QA) was cooperative vs pragmatic, but of course that trait is very important in other roles too, so it just doesn’t seem to be a good model for our domain.

The three dimensions I ended up with, to me, highlight the most important differences in engineers: those who love to work with others vs those who love to go into the cave; those who love to release code vs those who love to create beauty; and those who love to work on anything as long as it’s challenging vs those who have a particular passion.

Again, this is all such super-soft methodology that would put whipped cream to shame and shouldn’t be used for anything serious — not only from recognizing the many shortfalls of a model like this, but also the fact that people change all the time, and that they don’t fit neatly into one or two or even eight boxes.

But I do think that, especially as a people leader or as an introspective individual contributor, being aware of these sorts of inclinations can help with knowing what kind of work makes a person happy, which is very important because of the old proverb: “do what you love, and you’ll never work another day in your life.” A happy employee is the most productive they can be.

Let me remind you of General Yamashita’s motto: be happy in your work
General Saito in The Bridge on the river Kwai (1957)

On Engineering Consensus

July 22, 2021 by Gabriel

The main reason science works is, of course, the scientific method. It forces rigor into the process and it’s what began to fork hard science from philosophy. Engineering, while not a science per se, is a sibling discipline. It too benefits from the scientific method (though more so in the realm of testing) and the engineering method is similar:

	Scientific	Example	Engineering	Example
1	Ask a question	“Does fire destroy matter?”	Consider a problem	“How can I seal a container?”
2	Form a hypothesis	“Burning stuff in a sealed container should tell us”	Design a solution	“Maybe putting silicone on a jar lid will do it”
3	Make a prediction	“If the container weighs the same, the matter just turned to gas”	Implement the solution	Put the silicone on the lid
4	Run a test	Burn some stuff in a sealed container	Run a test	Burn some stuff in the sealed jar
5	Analyze the results	See if it weighs the same or is lighter	Analyze the results	See if any smoke got out, and if there were any bad side effects, like melting

We can generalize them both to something like:

Have an idea
Figure out what to do about it
Do that thing
See if it worked

In any case, they’re related. And one overlooked aspect of science is that it’s not all that cut and dry. Rare is the experiment that produces unequivocable results that are obvious to any layman. Lavoisier’s experiments on the conservation of matter seem straightforward to us now, but the test could’ve been wrong in a lot of ways: the sealed glass vessel could’ve had a microscopic leak, the scales might not have been sensitive enough to detect that some matter was destroyed, and Lavoisier himself could’ve had his finger on the scale!

This is why science relies on not just the method, but equally so, also peer review. Other people had to read about Lavoisier’s experiment or maybe observe it in person. People that were experts enough in the field that they understood all of the details about creating a sealed vessel and about the accuracy of scales and other aspects of the experiment. And eventually, other people recreated his experiment and got the same result, and only then was the scientific consensus attained that no — matter cannot be destroyed.

Good science works because regardless of the prestige of the scientist or the seeming quality of the experiment, the certification of the finding is independently verified by other experts in the field, peers who know what to look for and what notions to accept as scientific fact.

Good engineering works the same way. Instead of peer review of research papers we do peer review of design documents and pull requests, and if that step of achieving engineering consensus is missing, the quality of the work suffers.

“But,” you say, “the testing will prove the quality of the work!” Except that there’s a fine distinction there: tests will prove that the solution works as intended; it says nothing about how well it’s built. It could be held together by duct tape, it could be an overly complicated Rube Goldberg device that’s impossible to maintain, or it could be a pile of spaghetti that’s impossible to refactor. In engineering as in life, the ends rarely justify the means. And so we need consensus on whether those means are good.

Cosensus is a tricky thing though. I dread submitting my code for review, even when I’m very happy and confident with it, because I know there are things I might have missed, and as much as I want to embrace learning from my mistakes, I really don’t like to make mistakes. However, when certain smart, experienced people are on vacation, I don’t mind it so much, because I know I haven’t made any mistakes junior developers are likely to catch, and I can make a good argument if there are questions on my approaches. But those arguments might not fly past more senior developers, who might have insight that I’m lacking and the experience to know what works and doesn’t to back their stance with.

So it’s not enough to just get the consensus of any two people: for quality consensus, it has to be two (or more) of your peers. Developers operating on your level or higher, who not only have the general experience and skills to recognize whether your work is good, but also have the specific experience with the surrounding landscape — be it the type of thing you’re designing, if it’s a design document, or the codebase that you’re changing, if it’s code.

And it should be people who aren’t afraid to speak up. Some talented engineers that would otherwise be good peer reviewers might be intimidated by a Bob that’s less talented. Maybe this Bob is higher up the totem pole, or maybe he bullies, badgers, or simply exhausts all opposition.

The choice of peer reviewers should be truly peers. People who are:

Technical equals
Organizational equals
Up for a debate
On good rapport

(That last one is to avoid a situation where Chelsea always nitpicks Bob’s code because she thinks he’s the worst.)

This is a kind of ideal engineering consensus to strive for, and for better or worse, in practice there are two reasons why it wouldn’t happen all the time:

Most teams are small and there’s no equal to the tech lead, either technically or organizationally.
Most things aren’t important enough to spent a lot of time reaching consensus

Which exposes an important point in technical leadership: one of the reasons having good leaders matters is for the times when consensus matters. Good tech leaders have good rapport with the team, they mentor and build expertise in others, they set high standards for excellence, and encourage healthy debates from the team members. Over time, good leadership results in exactly the kind of savy, comfortable team that generates worthwile consensi. Consensuses? Consensi. Please excuse me while I look up the consensus on this matter.

DRY Code, WET Comms

June 9, 2021 by Gabriel

The principle of DRY code is probably one of the most important bedrocks of professional programming. It’s a hallmark of what separates an amateur coder from a legitimate engineer: thinking ahead; designing your codebase; making it flexible, modular, and maintainable.

If you haven’t come across the acronym before, it stands for Don’t Repeat Yourself, and it means that pretty much any time you find yourself duplicating blocks of code or logic, you should think about pullling it out into its own function or class or whatever, that would then be called from both of those places.

Why? Because when you later find a bug in it, you can just fix it in one place, instead of fixing it in one place and forgetting to fix it in the other. Or worse, not knowing there even is a second place to fix it in, because you didn’t write the code in the first place, or you did, but it’s been more than three days and you forgot. It also helps you separate your concerns and (HEY WAKE UP) construct a codebase with purpose, that’s separated in a logical manner that others can learn and navigate. Sorry this paragraph was a bit dry — pun intended.

This, being the opposite of copying and pasting the same for loop all over the place, because you’re just learning how to program and you’re not sure how to import modules, or really even what a function signature is. That style of programming is WET, because you Write Everything Twice. It’s amateurish and it’s something that a lot of good engineers learn to avoid on their own, after having to fix everything twice, or refactor everything twice, or three times, or six times.

However, people are not CPUs. In fact, we built CPUs, because we’re so bad at being CPUs. For us, seeing the same thing more than once is boring. It’s something we filter out, because boring is not dangerous. The motionless green grass won’t kill us, and so we hardly even notice it. But if it moves in a funny way, suddenly we think it’s because of a snake, and it’s the only thing we can see. We are neural networks. We are built to recognize patterns, to flag any dangerous ones, and to recognize them with high urgency. And so, we are not having fun adding a long list of numbers. Or cross-referencing scientific texts. At least not most of us.

But there’s a tendency, especially in the technical manager, to still think DRYly. “From now on, we’re going to use RabbitMQ for all asynchronous messaging, unless there’s a good reason not to”, you write in the the #dev-general Slack channel, adding that it’s already part of the deployment anyway, that it’s very performant, that it usually doesn’t make sense to reinvent the wheel, and that it’ll be easy to adapt existing code to use it. When you’re done typing this pithy paragraph, you tag it with @channel, giddily dismissing warnings about how many people in what timezones will be getting dinged. “Good! Ding them!”, you cackle. You handle the handful of questions and complaints that arise, explaining that they can still use JSON, that you don’t have to rewrite the project in Erlang, and that yes it’s weird that Dell used to own RabbitMQ. And VMWare. And SpringSource. And that VMWare still owns it. Yes, it’s literally a list of companies you wouldn’t expect… can we move on?

Satisfied with how you navigated that, two weeks go by and you’re in a design meeting and someone pipes up asking why RabbitMQ is now part of the design diagram. Your ears prick and you jump in “Hey Frank, did you not see my Slack announcement a couple of weeks ago?” As soon as you say it, you realize that no, he did not — for he was on vacation. You quickly acknowledge it and say you’ll send it to him, and you search for it because you forgot to pin it in the channel, but that’s fixed now.

Two more weeks go by and you come across a defect ticket being worked, on the old, homegrown asynchronous message service. “How did this even make it into the backlog??” You look at the names on the ticket and DM them “hey guys, there’s some kind of disconnect, because I see this ticket, but we were supposed to stop using the old messaging service.” It’s news to both of them. They remember seeing the Slack announcement, but didn’t realize they should start using Rabbit right away. They thought it was just for new development. “Hmmm… I guess the announcement could’ve been clearer”, you realize.

Two more weeks go by and you’re looking over a giant pull request from Stan when you notice … no … it can’t be. He’s added a whole mechanism for pushing messages over WebSockets! You look at it again, and it’s true. It’s exactly what that cowboy is doing. He just completely ignored the announcement and spent weeks working on this giant component that replicates exactly what Rabbit is supposed to do for us, and fragmented the architecture in the process.

"What Slack announcement is this?"
<you send him the link>
"Oh. Sorry, I don't remember seeing this. I don't normally pay attention to Slack unless someone DMs me."
"Seriously?"
"Yeah, can't concentrate with it dinging me all the time, so I turned notifications off."

After you’re done slamming your head against the desk, he tells you that he actually considered RabbitMQ on his own, before dismissing it because he already needed the WebSocket connection for bidirectional communication and it would’ve made the whole message path more brittle to go over two connections. All of which are good arguments, and fits into the “good reason not to” clause.

The story has a happy ending because I’m not GRRM, but it easily could have not. And a fourth one might not. The point here is that there are all kinds of opportunities and good reasons for people to not internalize things. Here are some:

They didn’t get the memo, for various legitimate reasons ranging from being out that day to technical glitches
They didn’t understand all or part of it
They skimmed it, didn’t think it affected them, and promptly dismissed it
They don’t comprehend things well in that medium: some people need to see pictures and read things, some people need to hear them, some people don’t read Slack but do read email, some are the opposite
They heard it, understood it, and forgot it anyway

As a leader, I feel like it is absolutely part of the job to be the positive version of Marty McFly’s 2015 boss, that tells him he’s fired via TV and three different faxes, for some reason. Send that Slack announcement, but also send it in an email, and say it out loud in three different meetings with slightly different people, and iMessage that one guy that doesn’t pay attention to anything but iMessage, and paste it in a document and file it in a good place in your document hierarchy and make sure it uses good, searchable words, and add a joke or a pun or something to make it memorable. And repeat it every time the subject gets anywhere close to it, until people audibly start groaning in your direction. That’s when you’ve succeeded.

In other words, for the important stuff, do whatever is necessary to make sure it gets through to the right people. Go to them. Meet them on their own terms, in whatever way they process information. Write everything five times. People are different, both from themselves and from machines. Embrace those differences, because it’s what makes a team a powerhouse of creativity. So you have to repeat yourself — it’s well worth it.

The Best Testers Are Scientists

April 17, 2021 by Gabriel

It doesn’t take long to appreciate a great software tester. And it doesn’t matter if she’s a manual tester or writes automated tests, because what really matters are the types of tests being run: curious tests. Tests that don’t just discover a bug and quickly document it away in a ticket, along with the state of the whole world at the time of discovery. But instead, tests that try to find the exact circumstances in which the bug occurs.

The more defined those circumstances, the more helpful the ticket is to the developer and, ideally, will take their mind right away to the exact function that is responsible for the bug. In those cases, you can almost see the light bulb go off:

Tester: I’ve only seen the bug on the audio configuration screen, and it usually crashes the app after single-clicking the “source” input, but I’ve seen it a couple of times from the “save” button too. And it seems to only happen after a fresh install on Android 10.
Dev: ohhhh! That’s because the way we handle configuration in Android 10 changed and the file the audio source is saved in doesn’t exist anymore!

This is exactly the kind of dev reaction you want to a bug report. It’s an immediate diagnosis of the problem, which was only made possible by a very well-researched and described bug. But notice how that description could, with changes only to the jargon, have been written by an entomologist:

Entomologist: I’ve only seen the bug on a tiny island off the coast of Madagascar, and it’s usually blue with green spots, but I’ve seen a couple of them with yellow spots too. And it seems to only come out right after sunset in the wet season.

Which is kind of obvious when you think about it, because what do scientists do? They test the software that is our reality. Galileo’s gravity experiments is one of the more famous in history (and likely didn’t happen), but what is it, in software terms? He wanted to know if the rules of our universe took weight into account when pulling things toward the Earth. A previous power user, Aristotle, figured that the heavier a thing was, the faster it would fall. But that user failed to actually do any testing. So thank God that talented testers, like John Philoponus and Simon Stevin, came along and figured out that things mostly fall at the same rate through air, and then bothered to update the documentation.

What Aristotle did was assume the software worked in a certain way. Granted that he didn’t have the requirements to reference, but he probably noticed that you have to kick a heavy ball harder to go the same distance as a lighter ball, and he figured that the Earth kicks all things equally hard. That’s the equivalent of our tester above seeing the “source” input work on Android 9 and not bothering to test it on 10. Or seeing that it worked on the video configuration screen and not bothering to test it on the audio one too.

And that’s okay, because Aristotle was not a tester. He was more like a fanboy blogger. But what testers should be, is bonafide scientists, like Simon Stevin, who follow the scientific method:

Ask a question
Form a hypothesis
Make a prediction, based on your hypothesis
Run a test
Analyze the results

In our example with the “source” input, after the tester saw it the first time, she probably did something like this:

“why did it crash?”
“maybe it was because I pressed the ‘source’ input”
“if so, that’ll make it crash again”
Relaunched the app, tried it, it crashed again.
“okay, that was definitely the reason”

Aristotle might stop there and file the bug: “app crashes when using the ‘source’ input”. And the developer would try replicating it on their Android 9 phone and kick the ticket back with “couldn’t replicate”, and that whole cycle would be a waste of time. But our tester asked another question:

“does it crash on this other phone?”
“if it doesn’t, it’s a more nuanced bug”
“I think it’ll crash though”
Tried it on the other phone: it didn’t crash
“what’s different about this phone?”

And she continued the scientific process like that, asking more and more pertinent questions, until the environment that our bug exists in was fully described. Which is exactly what you want in a bug report, because anything less will, in aggregate, be a productivity weevil, wasting both developer and tester time with double replication efforts and conjectures about the tester’s environment and back and forths. A clear, complete bug report does wonders for productivity.

So then, why not just teach all your testers the scientific method? Because it doesn’t work in the real world. We all learn the scientific method, but few of us become scientists. And I imagine that, just like in any profession, a not-insignificant number of scientists aren’t good scientists. Knowing things like the scientific method is necessary, but not sufficient to make a good scientist. You also need creativity, in order to ask the interesting questions, and more importantly, curiosity to keep the process going until it’s natural conclusion — to uncover the whole plot.

Tangentially, curiosity is a hugely important trait in great developers, too. But for testers, even more so.

My Slack Tips

March 12, 2021 by Gabriel

You know those recipe websites filled mostly with the backstory of how they discovered this amazing cookie recipe that changes their lives, and what joy it brings their three free-spirited, yet precocious children every time they make the cookies? This is kind of like that, so scroll down to “The How” if you don’t care about “The Why”.

The Why

I love Cal Newport‘s ideas about deep work. He writes a lot about how to protect your time so that you focus for stretches measured in hours instead of minutes, with no distraction. For Joel Spolsky the same concept was “getting in the zone”:

We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.
from “Where do These People Get Their (Unoriginal) Ideas?“

Joel followed that up by explaining how task switching is bad, Jeff Atwood echoed him, Rands showed us how he kept distractions at bay and years later, after Slack arrived on the scene making this problem worse, how he used Slack. It being such an important topic — especially with the boom of remote work making Slack even more common — this is my version of that Rands article, with a few years of more Slacking under the belt.

For programmers, standard Slack policy should pretty simple, flowing out of the principle of guarding “the zone” fiercely:

Turn off all notifications, except for when you’re being specifically @ mentioned
Specific mentions aside, only read Slack during your downtime — between meetings or while your VM is rebooting or whatever.
Don’t feel like you have to read everything in all the channels. Start with your favorite channels, and go as far as your downtime will let you.

For engineering leaders though, especially manager- and architect-types, it’s not so simple. The broader your scope is in the organization, the more pertinent info you will learn via Slack discussions, and the more value there is in being in a lot of different channels, so you can glean stuff like team Aardvark being in trouble because they’ve been complaining about their infrastructure daily for a week; or you can quickly unblock Bob who can’t remember where the functional spec is for the login screen, or focus a search API design discussion between Carol and Dave, and then build rapport with the other foodies in #random-food.

At the bottom of it all, underneath all of the turtles, programming is about communication between people. The source code isn’t for the processor, but for other programmers. And every successful team is a well-oiled communication machine. The best teams are the ones that have shorthand and can finish each others sentences. You just know that a team like that — and full of smart people — is going to be off the charts with productivity.

So as an engineering leader, possibly the single most important job we have is to do everything in our power to facilitate effective communication. Which these days, includes being a Slack Jedi. But, we also need to get some actual tasks done, so we can’t let it take over the whole day (at least not every day), which means there’s a balance to be found. Below, is how I found that balance.

The How

I’ll caveat these 11 weird tricks with the fact that this is what works for me, in my situations so far, and while your mileage will probably vary, at least some of this might be helpful. So:

Tweak the in-app Slack notifications. The default notification settings inside Slack are mostly fine: it notifies you for DMs, mentions, and keywords. But I do make a few small changes:
- I usually add a few keywords, like my name, team names, or project codenames
- I go into the notification settings of any “system down” or other emergency situation kind of channels and set them to get notified of all messages in those channels.
- In the macOS desktop Slack app specifically, in the “Notifications” section:
  - I uncheck the “Bounce Slack’s icon…” checkbox
  - If I’m in multiple workspaces, I also uncheck the “Show a badge…to indicate to activity” checkbox. Which keeps the badge icon from getting a red badge everytime someone says anything in any other workspace.
Turn off all notification types from the OS, except for the badge icon. Not inside the app, but in the Notification settings of macOS/iOS/Windows/whatever, I have the Slack app set to not be allowed to make a sound, to never pop anything up, to never bounce anything — to never do anything at all, for any reason, other than (on Apple OSes) make the badge counter appear over the app icon. That way, I can get in the zone when I need to, and won’t get distracted by Slack, but can still glance at it, once in a while, at opportune moments to make sure it doesn’t have 57 urgent messages for me.
Low barrier to enter channels. I’ll enter most channels as I come across them, because in the bad case, I don’t read them and in the worst case, I leave.
- Slackbot helpfully and periodically reminds you about channels you might wanna leave, also.
Low barrier to create channels. Whenever a topic starts getting enough airtime, or when there’s any other reason for it to have a dedicated channel, I create that channel. The more the merrier.
- You can go overboard, but as long as the reason for the channel is clear, go ahead and create it. You can always archive it later if it was a mistake.
- Channels are free and an organized Slack is a happy Slack, because it is way easier to find that important conversation about search API design if you know it happened in #dev-search.
- If you actively want to foster conversation in a channel, consider making it private. People feel safer talking in them, and the Slack stats I’ve seen bear out the fact that the large majority of messages happen in private channels or DMs.
Organize the channels in groups and make them disappear. This is a fairly new feature, I think from late 2020, but you can create channel groups in the sidebar, order the groups however you want and for each group, show all the channels or just the unread ones. You can also order the channels within the group in different ways.
- I order them by priority within each group and show just the unread ones.
- My groups are about related topics, ordered by how important they are to my role: my team’s channels and DMs in the first group, various dev channels in the second, then management channels, field support, water cooler, etc
Embrace speed reading. The human brain is great at patterns, and you can quickly pick up the importance of a conversation from some key signals like what channel it’s in, who the participants are, how long the conversation goes for, key words being repeated, emojis being used, etc.
- In some channels, like ones about nascent projects or downtimes, I read every word carefully — but that’s very much the minority.
- For the majority, I scroll through at a good speed, slowing down only when my spidey sense tells me I’m speeding through something worthwhile. It works well — false negatives are rare.
Embrace emojis. Not only do they make conversations fun, but they also convey tone (which is super important) and, as reactions to messages, they serve as pithy replies that add value to the conversation without also adding volume to it.
- e.g., using a check mark to indicate that you read something without indicating judgement, or a dart that their message was right on the money, or an up arrow as an upvote — they’re small, very helpful gestures that significantly improve the conversation.
Use reminders. When I do go into Slack, I like to at least clear all my mentions that turn channels red. But sometimes I can’t actually service a message. Maybe that’s because it’s asking a question I have to research, and I’m in the middle of something. Or I want to make sure that I follow up on a conversation after my current meeting. Or I got an action item in that meeting that I need to do tomorrow morning. I use reminders for all of that.
- Most of my reminders are set on existing messages that I need to do something about
- Some of them, I create with the /remind command
- All of them, I snooze extensively until the time is right to work on them
Don’t use threads. It’s quite possibly the worst feature in Slack. Some people love them, but don’t be those people. Terrible UX aside, all threads are is a way to hide conversations for no good reason. If you want to read every word in a channel, and you’ve read them all, but then Ethan decides to start a thread off of someone’s message 50 messages up, guess what? You’ll never even know.
- Some people use threads because they came too late upon a conversation that’s scrolled away, and want to continue it; there is a better way: share the message into the same channel, and that posts it at the bottom, with your comment attached.
- “But I don’t want to bother everyone in the channel with my thread”. The conversation either belongs in the channel, or it doesn’t. If it doesn’t, create another channel or group DM. But there’s no reason to hide it.
Nudge people toward the proper channels. Most people are trying to get their job done and aren’t so worried about keeping Slack organized, so when they start a conversation about lunch in #dev-breakfast, it’s probably because they didn’t even know #dev-lunch existed, or because they had been talking about brunch and it morphed into lunch.
- The point being that, as is generally the case, people don’t intend to break the rules and usually just make mistakes.
- I, as Slack Jedi, have to minimize the chance of mistakes by establishing good channel-naming conventions and keeping topics narrow, but when mistakes do happen, it’s not the end of the world, and an innocent mention that the lunch channel exists is normally the only thing that needs to be done.
- Be super nice and soft about it, because creating anxiety about the proper channels is kind of antithetical, since it then stifles communication.
Try to mark everything read by the end of the day. I don’t always clear my email inbox every day (or longer), but I almost always clear my channels, to give me peace of mind.
- On days filled with meetings, it’s harder, but I keep up with the @ mentions and high priority channels as I can, and then quickly scroll through the less important ones, just to make sure I’m not missing anything important.
- Yes, the Slack FOMO is strong with me, but the clearing doesn’t take long. I’m in dozens if not hundreds of channels, in a Slack with hundreds of people and — active conversations aside — I can clear a day’s worth of chatter in about a half hour, knowing then that I’m on top of things and won’t be surprised the next morning by Fiona with a “so what are we gonna do about that nasty database locking issue?”

So that’s how I stopped worrying and learned to love the Slack: by putting it in its corner and giving it attention on my terms — no more and no less attention than is beneficial.

Be The Lorax

February 16, 2021 by Gabriel

I am the Lorax. I speak for the trees.
“The Lorax”, 1971

This was Dr. Seuss’ favorite of his books. If you haven’t come across it, it’s a great fable about a woodland creature who keeps warning an industrialist to stop cutting down all the Truffula trees; but the guy doesn’t listen and proceeds to destroy the ecosystem.

From time to time I feel like the Lorax, but instead of the trees, I speak for the developers, who are every software company’s most precious resource¹. And I think this is a crucial, but often overlooked part of the software manager’s job: litigation.

At times the plaintiff, other times the defendant, but usually in opposition to someone named Taylor from another department, like finance or HR, who doesn’t understand engineers. Sometimes Taylor is someone very high up, who used to be an engineer a lifetime ago, but they’ve forgotten what it’s like, now that their days are filled with meetings about sales projections and synergy. And here you come, Sr. Cat Herder, with a request to change the new dress code policy.

“You might not have heard, but we had a bit of a problem in Marketing, so we had to institute the dress code. We didn’t want to, but you know Legal.”

You see, Taylor’s not a villain. Almost nobody is. They’re just trying to do their best, and one thing people outside of Engineering are pretty bad at doing is putting themselves in an engineer’s shoes. It would be easier for most people to pretend they were a parakeet. But this is where you come in — you who have knowledge of the way of life in the dark cave of Engineering.

So you use your nerdy charm and wit to show that having a policy is fine, but that it just needs to be tweaked, because while the developers have no intention of causing problems, roughly half of them will quit before dressing “professionally” at work. And a third of those, have not worn long pants or closed toed shoes in years — and won’t start now. Not when they can get a good job by just whispering the words “I’m looking for a change” into the ether that’s continuously monitored by eager recruiters. Because as it turns out, those developers are a lot of the best ones we have, and they’re past putting up with well-intentioned policies. And if even one of them leaves, it’ll cost us a ton in recruiting, on-boarding, shipping delay, and general business risk, which is surely worth tweaking the policy to allow cargo shorts and sandals.

“But it’s 45°F outside!”, Taylor exclaims.
“It doesn’t matter, because they’re almost never outside,” you reply, and then continue with a whisper, “and they’re really stubborn.”

If you do this well, the policy will get tweaked before the developers are even told what was in the policy email they deleted, and the builds go on without a blip.

Sometimes you have to be the change you want to see in the company, which is a bit harder. Convincing the powers that be to allow flexible hours, or to get Engineering more expensive laptops, or that the savings were not worth switching to Microsoft Teams — these are the kinds of things that might need a Powerpoint. A beautiful, well-researched, entertaining Powerpoint, which will take a lot of your precious little coding time.

But these are the things you have to do as a good manager and the sacrifices you have to make, because you are the Lorax, and you speak for the devs. Though… hopefully better than the Lorax, in that you actually succeed in preventing the collapse of the ecosystem.

Footnote

Just to be clear: I was using “resource” metaphorically. As much as nature abhors a vacuum, I abhor calling people resources. Trees and laptops and StackOverflow articles are resources — people are not.

Software & Opera, Part 3: Design & Test

January 28, 2021 by Gabriel

This is the third and final part of a series on opera and software. Part 1 explained why they’re related, part 2 explained the development process used to produce an opera, and this part explores what can be applied to the software development process.

But first, the disclaimers: I’ve never worked backstage anywhere else, so I don’t know how other opera houses operate — they could be exactly the same, or wildly different. Also, everything in this article comes from my experience, and nothing is from Sarasota Opera — they don’t know I’m writing this (and hopefully, they’ll be pleased if they do ever come across it). Finally, what I do know of the production process comes from years of observation from the sidelines, from the role of a super, so some stuff in here could be just plain wrong; I’ll try to make it a point to underline where I know my knowledge is shaky, but there might be things I’m more sure about than I should be.

Let’s just dive in by recapping the operatic development process using software terms:

The product manager writes functional specs (the libretto)
The architect (composer) writes technical specs (the sheet music) based on the functional ones
Management chooses a reasonable release date
About a year before the release date, development begins on the infrastructure and wireframes (stage, sets, costumes), congruent to the functional and technical specs.
- The infrastructure may well be sourced from elsewhere, or built in-house — whatever makes the most financial and artistic sense
The main components (principal singers and stage management) are identified
With roughly six months to go, the technical lead (conductor) learns the technical specs (sheet music) backwards and forwards and begins work on the main components (the principal singers)
- The same as how, in software, the architect and the lead developer could be the same person so in opera, the composer and conductor could be the same person: Verdi conducted the first runs of all of his operas, and so have most composers. But after that first run, their operas are conducted just as well by other conductors.
The UX designer (director) begins fleshing out the UI (choreography)
Development begins on smaller components (auditions for smaller parts, chorus)
Support infrastructure is stood up (props, rehearsal rooms, living arrangements)
Management meticulously schedules acceptance testing (rehearsals), including bug fixing time.
A couple of months before release, major development is done (the choreography, principal parts, sets, and costumes are all largely in order), the infrastructure is in place, and developer testing begins (all cast members rehearse at home)
A month before release, developer testing is complete, and development is largely frozen: the infrastructure is ready, the entire cast is on site, and know their parts and music. Developer testing on the main components has been especially rigorous.
Acceptance testing begins:
1. The testing phase is the climax of the process. All hands are on deck, for very full days, for the duration.
2. It takes place in a lightweight mock environment (the off-stage rehearsal room) with mock props and costumes
3. The mock environment is designed to be easily reset and changed from one test to another, which is not the case for the production environment (the stage with sets)
4. The architect, UX designer, developers, and management are all present
5. Each workflow (scene) is thoroughly tested
6. The testing harness supports starting from any point in a workflow, stopping at any point, and resetting to any point, so that the entire workflow doesn’t have to be run every time, making it possible to easily test every individual feature
7. The testing harness supports various levels of integration testing, from interaction of only main components with mocked minor components, to full end-to-end testing
8. Project management keeps track of each test’s outcome against the specs and design
9. Project management files and tracks enhancement requests and bug reports (changes and corrections to choreography and singing) made by the developers and designers, who update specs and designs as needed
10. The tech lead and UX designer make tweaks as needed and file bug reports, which are worked on with high urgency
11. Once the tests are going acceptably well, testing moves from the mock environment and into a real one: the actual stage
12. More enhancements and fixes are made until the UX designer and developer are happy with the outcome
13. Beta users (coworkers, friends, early adopters) are brought in for final testing. There are very few, if any, surprises at this point.
The product is released on opening night
A point release or two may quickly follow, with minor changes (in the first couple of performances)

That should all be very familiar, but how does that differ from the process in most software shops? From my experience, it’s the beginning and the end: the design and the testing. Most shops focus on the middle: the development itself, with testing being a necessary evil, and design often being a quick drawing with some boxes and arrows, maybe just in someone’s head.

Don’t Focus on the Coding

The above process takes probably about 18 months, and the first half of it is all design. Main feature development takes about six months, and testing takes half of that again. So a full two-thirds of the process is design and testing — not development. On top of that, at the end of that six months of development, everything is already well-tested by the developers, with unit tests and rudimentary integration and functional tests. Which means that even less of that six months is actually spent on developing features; maybe as much as half that time. Counting that developer testing, we may be looking at nine months of design, three months of development, and six months of testing.

Design

At this point, you may be aghast at the idea of spending less than 20% of a release cycle coding, and 50% of it designing. The important thing to remember is that designing is programming. The difference is that it’s at a higher level, and it consumes almost all of the research time. It’s a more efficient, and more disciplined, approach than starting to code with only a vague plan, and changing direction as problems arise, pausing to learn new technologies, finding the right widget library, and then realizing that the protocol you started with doesn’t support one of your main features as you wrote it, which means going back to the drawing board.

That going back and re-coding, that’s what wastes a lot of time. That’s why the opera has so much design up-front and why a release date isn’t even chosen until the detailed design is complete, and thoroughly understood. And the opera is not alone, because every disciplined engineering profession does the same. I’ve never worked in civil engineering, but I’m pretty sure that every iron nail in a highway overpass is designed and placed before one worker arrives on site. A big design up front — not coming down a waterfall, but rather in a process that is flexible and agile — documented in great functional specs, is the hallmark of the timely and efficient building of anything.

When done well and thoroughly, it front-loads the vast majority of the variability. If you spend the first half of the cycle coming up with a great design, the last half should be an exercise in typing. The great screenwriter Aaron Sorkin said “You have to think about what you’re going to write before you write it”. Software works exactly the same way. The more specific and detailed your thinking, and the design document that comes out of that, the less surprises there will be in the development and testing phases.

This means the design should address gotchas head on: every technology used should be well-understood, it should be vetted to make sure it works like the architect thinks, and the design document should be as detailed as possible, with APIs, flowcharts, state machines and anything else that can reduce risk and variability in the second half of the cycle. Plus, that document should be very readable, and even entertaining, so that the variety of audiences that read it (devs, managers, QA, tech writers, etc) don’t fall asleep doing so.

If I’ve taken one thing away from my opera experience, is that it’s the important of a thorough design up front, in which literally every note is written before a singer is hired.

Testing

If there are two things I can take away from the opera, the second is definitely the outsized scope of testing. At the opera, testing is not only built into every part of the process — from design to development to release — but everyone is also laser-focused on it. Conductors play their music on the piano to make sure it doesn’t just sound good in their head. Singers practice for hours a day with coaches, who you can think of as the developers of singing. They essentially run unit tests all day long, making changes until the output (the voice) matches the spec that is the sheet music.

And once rehearsals start, everything falls in place, for the most part, with ease. There are always changes because a singer turned out to be taller than the director imagined, so he has to be placed further downstage; and three people in the chorus constantly put the emphasis on the wrong syllable of some Italian word they’ve never heard of, so the maestro has to explain Italian pronunciation yet again.

Enhancements and bugs are built into the acceptance testing phase, but they’re assumed to be minor. Easily changed and corrected, with relatively little effort from the developer. You don’t find out that the soprano can’t hit the high note at this stage, because she auditioned long before. You don’t find out that the set design is all wrong, because an intricate miniature replica was built first. If the main singer gets the flu, there’s a cover waiting to step in, having shadowed the singer at every rehearsal. Everything has been vetted, pre-tested, and every contingency addressed so that there are no show stoppers. Even without any changes at this phase, the opera would be good. The changes here are the little details that make it great: a flawless, amazing performance.

To get there, the testing has to happen in design and during development first. The acceptance testing has to involve all the roles in the production. And it has to be properly planned, with ample time scheduled for it, so that its success is the number one priority for everyone during that time.

Conclusion

By now, I’ve been to dozens of operas, many on opening nights, many in the audience and many backstage or on-stage, and I can count on one finger the number of major blunders I’ve experienced. It was about the fifth performance of a production of Turandot, when the king repeated the same line twice. People that weren’t paying attention to the Italian wouldn’t have even noticed, but someone else played the part the rest of the run.

I’ve seen many more small issues, like people dropping prop coins or papers, walking out the wrong exit, or forgetting to take a jacket off. But the lack of issues in general is astounding, to say nothing of the ability to release on time to the day, and on budget, year after year after year. All of that comes solely from the company’s ability to front-load risk, which then lets them plan the release with certainty, and devote ample time to testing and refactoring, so that the final product is an absolute gem.

Software & Opera, Part 2: The Operatic Development Process

January 28, 2021 by Gabriel

This is the second of a three-part series on opera and software. Part 1 explained why they’re related, this explains the process used to produce an opera, and the last part explores what can be applied to the software development process.

Before I go any further, some disclaimers are in order: I’ve never worked backstage anywhere else, so I don’t know how other opera houses operate — they could be exactly the same, or wildly different. Also, everything in this article comes from my experience, and nothing is from Sarasota Opera — they don’t know I’m writing this (and hopefully, they’ll be pleased if they do ever come across it). Finally, what I do know of the production process comes from years of observation from the sidelines, from the role of a super, so some stuff in here could be just plain wrong; I’ll try to make it a point to underline where I know my knowledge is shaky, but there might be things I’m more sure about than I should be.

Pages from an 1859 libretto for *Ernani*

The stuff that happens early on is what I’m least sure about, because I generally start working on an opera during off-stage rehearsals, which is essentially the “acceptance testing” phase. But from what I’ve gathered, this is what happens before then:

The libretto is written. This is like a movie script and contains the dialogue and stage direction. For most operas performed today, this was written long before your grandparents were born.
The libretto is set to music. The composer takes the dialogue (and the gaps therein) and creates music that sounds nice to people who like operas. Again, this has usually been done at some point in the 1800s, but even for new operas, it would be at least somewhat before anything else happens. And now you have an opera — at least, on paper.
The opera is slotted into a pre-existing Friday opening, about 18 months in the future. By the time one season starts, the next season’s roster of operas and their exact release dates have already been made public.
Set and costume design are started. This is one of the longest phases, because a set may have to be created from scratch, and sets are big and can get complex. They actually take up most of the backstage area. Renting them is an option, if the size and shape of the stage is pretty standard. Costumes also may have to be made — sewn in the opera’s costume shop — but sourcing ready-made ones is time consuming too, since an opera with a full chorus and a bunch of settings could easily require over 50 costumes. And sizing is a thing to deal with on top of it all.
About a year before opening, the principal singers and stage management are hired and contracted for the work, which actually starts some months later. There are usually about six principal singers and maybe a couple of more minor roles.
The conductor starts learning the music and hires the orchestra.
The director starts choreography design, figuring out what happens in each scene: where, when, and how people enter; what path they walk; how they act, what they physically do; and where, when, and how they exit the stage. Some of this is dictated by the libretto, but most is not.
A couple of months later, general auditions take place for the chorus, which is about two dozen people.
A few months before opening, props start to be created or sourced: swords, treasure chests, torches, faux violins. The set and costumes are done, but not tailored.
The rehearsal schedule is completed — for two full months of rehearsals. Since four operas are being produced at the same time, only parts of each opera are rehearsed in each session (usually one particular act or scene), and rooms and the stage have to be scheduled so that rehearsals can happen in parallel. Also, the chorus usually appears in all four operas, so the scheduling has to take into account that they can’t be in two places at once.
A couple of months before, the cast is all set and the various design work is mostly done. The cast starts rehearsing the music on their own.
About one month before, the cast arrives on site (they come from all over the country, and internationally) and rehearsals actually begin.

This is the point where I enter. By the time of my first rehearsal, the principal actors have been rehearsing for weeks, and the larger chorus for some days. Principals have something like 10x the stage time as the chorus, so they have a lot more to work on.

The rehearsals early on are held in a large rehearsal room instead of the stage, to minimize labor costs associated with setting the stage. Instead, the floor of the room is marked with tape outlines of the sets, with different colors indicating different scenes. So Act 1 might be in red tape and outline some stairs and a couch, while Act 2 might be in blue tape and outline the same stairs, plus two doors and a table with chairs. When you rehearse Act 2, you walk around the blue tape and ignore the red tape.

There are generally a lot of new people, so everyone gets a name tag in the beginning. In each rehearsal, in addition to the performers, the conductor is present, along with a pianist, the director, a stage manager, and two assistant stage managers: one for stage left, one for stage right. Principals all get cover singers, to put the bus factor at 2, and their covers are also there.

Since the choreography is already designed by now, the director tells everyone what’s going to happen in the scene. No one is in costume, except principals might wear something a drunk person might think is their costume, to get used to walking around and singing with, say with a sword or a heavy coat. The singers have already memorized their music, and performed it in front of a maestro and gotten notes on what to change.

An important thing to understand is that everything in an opera is cued by music, and the music is cued by the maestro. She moves her baton at a certain tempo, and all of the singers and orchestra musicians keep that tempo. When she stops, they stop and when she starts, they start. If they start to lead or lag her, she stops and yells at them. “Can everyone see me? Can you, Jeremy? Because if you can, why are you half a measure behind?” The conductor is essentially the system clock, for a multi-processor system. Or maybe an NTP server.

Because of this, the cast’s actions are also cued by the music and it follows that the director’s directions are usually given relative to some piece of music: “when Isabella gasps, you three move upstage, and you go put your hand on her shoulder. Then, on the beat after ‘da dada da dun’ everyone but the Don exits the stage. Ok, let’s take it from two bars past 62”. It’s amazing to me that the singers can start from any part of the entire opera, with a second’s notice.

Stage management keeps a giant binder with the sheet music for every role and marks where in it things are supposed to happen — like stage entrances and exits. After everyone verbally understands what’s supposed to happen, we run that part of the scene, with piano music. Here usually, someone omits doing something — walking somewhere, facing someone, fake laughing — something got forgotten or misunderstood in the space from the director’s mouth to the cast, so we reset and run again. Sometimes, the director, having seen it run with actual people, decides to change where people stand or face or who they fake banter with, so we reset and run again. Later, when we rehearse on stage with the actual set, sometimes things are tweaked even more. And if the singing is off, the maestro stops the music, yells admonishments, we reset and run again.

Once the director and maestro are happy with the way things are running, they layer in any additional people in another rehearsal. For example, sometimes we have rehearsals just with the supers, or the supers and chorus but not principals, for various scheduling reasons. And when everyone knows their parts well enough, they’re all brought in to the same rehearsals.

The off-stage rehearsals are generally splayed over three weeks, with each scene being rehearsed about three times, depending on the complexity. Once in a rare while, things might be going so poorly that they might add rehearsals; as an unpaid volunteer doing this for 20 hours a week on top of your day job, that’s what you really don’t want.

Finally, it’s about three weeks before opening, and we get to rehearse on-stage! There are only a handful of rehearsals left at this point, but most of them are of the entire opera, start to finish:

A couple of rehearsals with only the piano accompaniment still
A piano dress rehearsal — meaning still only the piano, but full costumes for everyone, though only principals get makeup
A rehearsal with the orchestra but no costumes
Finally two full dress rehearsals with the orchestra.
- These last two are run exactly as if they were live performances, with beta testing users being brought into the audience, in the form of friends, family, and big shot donors.

During these on-stage rehearsals, the lighting people are also testing the colors and intensities to make sure they create the proper environment and mood, the costume and makeup designers check to make sure everything looks good from the audience, and the director walks around the whole opera house to make sure various vantage points can all clearly see the important action.

For the last rehearsal, they generally bring in a couple of classes of middle or high school students, and again: they’re run exactly as they will be on opening night, with PA announcements, supertitles, intermissions, curtains, etc. — even the bows at the end are rehearsed. The only differences with respect to a real performance is that the conductor might still stop the music if things are going too wrongly, she gives notes to the orchestra at the beginning of each act, and the director hovers around the whole house looking for final tweaks to make.

After opening night, things are mostly on rails. The director might issue notes with small things the cast is doing wrong or she’d like to change, someone might need musical coaching if they’re too loud or soft or whatever, but by and large everything is set at that point, and it all just manifests like a clockwork for a dozen performances. That is actually the inflection point for when it gets really boring. After the jitters of opening night, it all becomes so routine that there’s not much excitement in it anymore — but that’s good, because then you can finally focus on the performance.

In the next and final part, we’re going to talk about how all of this applies to software development.

Next: Software & Opera, 33 1/3

Gabriel Jiva

Software Engineering

Author Archives: Gabriel

The Art of Interviewing

Lessons Learned on the Job Search

Anatomy of a Loop

What Worked at Each Stage

Resume

Recruiter Screen

Hiring Manager Screen

Behavioral Interview

Technical Interview

TL;DR

The 8 Engineers You Might Know

The Types

The Generalist

The Specialist

The Builder

The Conductor

The Architect

The Artisan

The Hacker

The Marshal

The Disengaged

Cheat Sheet

Methodology

On Engineering Consensus

DRY Code, WET Comms

The Best Testers Are Scientists

My Slack Tips

The Why

The How

Be The Lorax

Footnote

Software & Opera, Part 3: Design & Test

Don’t Focus on the Coding

Design

Testing

Conclusion

Software & Opera, Part 2: The Operatic Development Process