Flashover

“Don’t try to create and analyze at the same time. They're different processes.”

That’s the eighth rule from composer John Cage’s 10 rules for students and teachers.

In similar fashion, software engineer Kent Beck has his metaphor of the two hats: you should either add function or refactor. When you wear the refactoring hat, you preserve observable behavior. When you add function, you extend or break this behavior. You rebuild or you restructure.

Cage and Beck’s main point isn’t the dualism of discovery and editing. Their argument is that you will forget this duality in your day to day work. At least that's probably why Cage decided to include the idea in his 10 rules and Beck constructed a metaphor instead of a simple principle.

When you forget that create and analyze are different processes you end up spinning your wheels. You try to be an artist and an editor at the same time. You end up second guessing your every step.

Write. Edit. Write. Edit.

Extend. Refactor. Extend. Refactor.

Create. Analyze. Create. Analyze.

Try to replace those dots with an ampersand and you’re exposing yourself to more context switching than you actually have to.

***

PS. If you want to try turning Beck’s metaphor into a habit, consider reading my post "Using TDD as a Mind Hack" from last year.

You're doing well whenever you can say to yourself that you put in a fair day's work. To ask yourself if I'm content with what I accomplished today, and then come back with a confident answer of "yes", is to say that today I can stand proudly behind my work: I did what I promised myself and others. I didn't waste mine or other people's time. I stayed on top of everything important.

You are probably not able to define a fair day's work but I'm pretty sure you know it when you see it. Fair is sustainable. Fair is calm. Fair is not stretch. Fair is not perfect.

You can have people find out that you're not perfect and still put in a fair day's work. But it's not easy to set your mind at rest if today you let someone down, if you got caught in busywork, or if you're constantly afraid that something is going to fall through the cracks.

It's going to be much easier to avoid these things from happening if you stop overpromising, if you allow yourself to fail, if you don't work long hours for the sake of appearances, and if you learn how to stop thinking about work during your non-work time.

"Did I put in a fair day's work" might be the best question you can ask yourself today before leaving the office.

A digital transformation project falls flat. Your company doesn't reach this year's growth target. You're just not able to improve the profit margin despite your best efforts.

Why?

When your company encounters strategic failure, what are the questions people inside your organization ask themselves? What questions are followed by the question of "how can we do better next time?"

• Do we need to get better at modeling our environment and planning our steps? Should we get better at understanding strengths, weaknesses, opportunities, and threats? Or is it that we have the understanding, but we don't know how to connect the dots?
• Do we need to get better at analyzing economic facts? Did we misinterpret the data?
• Do we lack critical resources and capabilities? Did we try to bite off more than we can chew?
• Does our CEO lack vision? Was she not able to guide us?
• Do we need to get better at learning? Instead of trying to plan our steps better, should we make smaller steps and perhaps plan fewer steps ahead?
• Are we not democratic? Did we have too little debate and too few people involved?
• Do we need to change our culture? Did our beliefs and values prevent us from reaching our goals?
• Have we picked the wrong time to have a company in this industry? Did we do the best we can despite the lousy market?

These questions are not neutral. There are assumptions baked into them. When you ask if your CEO has vision or not, you also posit the idea that CEOs should be visionary leaders (instead of generous leaders, for example).

These questions also affect outcomes. Discussions that start with the question of "how can we get better at analyzing financial data?" are different from discussions that start with "how important is financial data for our business?"

It doesn't take long for people to jump from "should we get better at X?" to "how can we get better at X?" especially if the question is voiced out by a high status person.

Questions can be more revealing than answers and more influential than memos. Maybe you can fix your problems by fixing your questions.

It's Wednesday night and Yvette Pasqua, CTO of Meetup, is packing her carry-on luggage in her New York apartment. She's leaving the city for two days.

It's nice to get a break from New York. But right now, there would be a little more calm in her life if she wouldn't have had to squeeze her work week into three days. It's also a shame that she has to cancel the dinner with her friends on Friday because of this trip.

Early Thursday morning, she takes the taxi to the airport. Pasqua had to wake up a little earlier than she's used to. But she's not feeling terribly groggy. She knows she's going to miss opportunities to communicate, listen, and empathize by not being present at the office. But she also knows that this trip is an important learning opportunity.

Pasqua is coming to see you. She's coming to your office for two days to learn about leading engineering teams. She's constantly thinking if her engineering resources are focused on the right things and how to get better at execution and delivery. Pasqua is highly experienced and skilled at this stuff. But she also believes that you are still able to teach her something.

Year ago, Pasqua and Meetup became one of your clients. Back then she wouldn't have made this trip. Of course no such invitation was made since neither you nor Pasqua thought that a trip like this would be worth her time.

Year ago and same as now, you were great at what you do. You had solid client references, you delivered quality work, and you kept your promises. Meetup made a smart choice signing a deal with you. But despite you being able to proudly stand behind your work, you also knew that CTOs of your biggest customers wouldn't have come to your office to learn about technology.

However, something changed during the past 12 months.

You now have the confidence to make an invitation like this and people are willing to accept it. Pasqua is willing to go through both the personal and professional hassle of the trip. She thinks she can learn from you.

How did you end up here? What is it about your company that makes experienced people look at your work and content, and think they should give their attention to you?

In his podcast Revisionist History, Malcolm Gladwell does two episodes inspired by William Henderson's paper The Lsat, Law School Exams and Meritocracy: The Surprising and Undertheorized Role of Test-Taking Speed. Those two episodes opened my eyes to how we constantly judge people on false merit and how our society often has a bias toward people with good test-taking speed. It's a great listen; you should check it out.

Henderson and Gladwell focus on the world of law. But in this post I'm going to discuss their idea from the perspective of programming.

Who's the better chess player?

Here is Gladwell's argument in a nutshell: We constantly measure people's reasoning ability with time pressured tests. We use those tests to decide for example who is accepted to high-ranking universities. However, science says that test-taking speed does not correlate with reasoning ability. Time pressured tests measure the speed of our reasoning ability, not the actual quality of it.

Gladwell divides people into two categories based on test-taking speed: tortoises and hares. Tortoises need their time to figure out solutions and answers while hares are fast thinkers. And just like in the fable of the tortoise and the hare, tortoises triumph over hares when the game is not about speed. For example, Henderson found out that law students who don't do so great in time constrained tests, are still able to get solid A's from take-home exams and papers.

You can see this same pattern in the world of chess. Chess games have a time limit. This is so that the games wouldn't go on forever and end up in ties. However, the time limits are not always the same: Classical chess games start from 90 minutes per side for the first 40 moves. In blitz chess, each player gets 10 minutes or less for all their moves.

Chess player Fabiano Caruana is ranked 2nd in the world. His peer Hikaru Nakamura is eleven ranks below him at 13th. However, these rankings are based on classical chess games. In blitz, Caruana wouldn't stand a chance against Nakamura. Nakamura dominates in the world of speed chess. Caruana's strength is his calculation skills while Nakamura's strength is his pattern recognition skills. When you decrease the play time, pattern recognition skills give you a greater advantage as a player.

So who is actually the better chess player? Nakamura or Caruana? We have the official ranking to answer this question. But if the organization in charge of the ranking would decide to decrease play time dramatically, the ranking would look something completely different. Great chess players are great in different ways. The official ranking is just one side of the story.

Why is someone a great programmer?

Think about your colleagues' and your own personal strengths and weaknesses. Think about Nakamura and Caruana. Think about the fact that test-taking speed doesn't correlate with reasoning ability. Are you able to agree with the following statements:

• Great developers have great reasoning ability
• However, your learning speed doesn't correlate with your reasoning ability
• ...your delivery speed doesn't correlate with your reasoning ability
• ...your ability to succeed in whiteboard interviews doesn't correlate with your reasoning ability

Even if you agree with those statements, you probably also make conclusions like these (consciously or unconsciously):

• Because person A learned C++ in a month, she's a better programmer than person B who spent 6 months learning the language
• Because person A delivers features faster than person B, she's the better programmer in our team
• Because person A nailed our whiteboard interview, she's the best candidate and therefore the best programmer we can hire

It's likely that inside your team and your organization, there is a bias toward tortoises or hares. It can be that because of your interview process, you end up hiring more hares or tortoises. Because of the way delivered work gets highlighted and successes celebrated inside your organization, you might be promoting either more hares or tortoises.

It's also possible that there isn't anything wrong with your biases. If you need hares, by all means hire hares. If you need tortoises, hire tortoises.

But what if you haven't thought about whether the work you have set out to do is meant for hares or tortoises. What is the version of the fable people tell themselves inside your organization? In the minds of people, is the winner the hare or the tortoise? And if you look at the facts objectively, does their version of the story match with reality?

My interview story

A little more than a year ago, I was interviewing for a job. I was asked to take a couple of online tests to measure my reasoning abilities. The tests had such strict time constraints that most people weren't able to finish all the questions in time. You had to mark your answers fast and not second-guess anything.

I took the tests and I scored fairly well (not amazing but also not bad). Based on the results, I thought that the tests suggested that I'm smart. But in fact, all I had managed to prove anyone is that I have pretty good test-taking speed. I, and the interviewers, falsely thought that the tests said anything truly meaningful about my reasoning ability.

By the way, just so you don't think I'm trying to do a humblebrag with this story, let me drill my point into you by quoting Henderson's paper: "it is widely acknowledged that test-taking speed and reasoning ability are separate abilities with little or no correlation to each other." Just because you're fast, doesn't mean you're smart, and vice versa.

I actually don't know if I would have been hired. I dropped out of the interview process. I figured that the job required much more contemplation and deep reflection that I had the patience for. It was work meant for a tortoise and I was a hare.

Sadly, the company had forgotten the lesson of the fable. They were betting on the hares of the world.