It's about the curry
I got invited to speak at Monkigras 2018, a superb conference on software, technology and craft. This year’s theme was “Sustaining Craft”. I wrote and delivered It’s about the curry - you’ll find a (close enough) transcript below.
Hi, I’m Ricardo J. Méndez.
I’m a software engineer by training. I’ve been running teams for about 20 years. I’ve been running my own business for over 10 years, where I sometimes build teams from scratch, sometimes embedded myself on a company’s team, sometimes a mix of both.
This means I can easily end up working with 2-3 teams a year. I’ve had ample opportunity to see how things play out, across the spectrum - from teams that say they care about craft but do little about it, to teams where it’s not even a topic but they excel at it.
What I’ve found
There’s this dissonance where if you ask people about craft, everyone will say it’s a good thing, but at the same time:
1) Can’t describe what it means for them, and
2) When they can, it’s some high and lofty artistry-focused definition.
Nobody likes to think that they’re the assembly line piece that a soulless plutocrat hasn’t yet figured out how to replace, and craft sort of sounds like a good way of avoiding getting Mechanical Turked.
But often we don’t reach for its potential, in the rush to get the job done. We hit a minor snag and all these noble but fuzzy ideals go out the window.
Most definitions are about doing everything by hand, about skill, about quality, or going about things the traditional way.
Yeah. That’s nice. But it’s also too high-faluting.
From what I’ve seen, these high expectations are what keeps most people from just doing small things that could make their work better.
For me, it’s straightforward.
Craft is about consistently avoiding shortcuts - even shortcuts others might consider practical - because you expect to get a better result.
Let me tell you a story, and after, I’ll talk about what I’ve found makes craft easier to sustain within a team.
A few years ago my wife and I were in Tokyo with her sister for the winter Comiket.
(Because we are gigantic nerds and Japan is our happy place - we go there when we can).
When we’re in a city, we get out of the hotel early, then walk around as much as we can. We can end up walking 20+ km in a day.
So this particular day we didn’t have breakfast, because the sushi place we wanted to go to had a five-hour queue.
After wandering around, trying to find the restaurant, and finally deciding we weren’t going to get in before the end-times, we just went straight to this huge park we wanted to visit and spent a good chunk of the day there.
By four in the afternoon, when hit Shin Ju Ku station, we haven’t had anything but matcha all day. We’re starving.
Now, there’s lots of “quick lunch” places inside the larger metro stations.
They are simple hole-in-the-wall kind of places. They don’t feel like a restaurant - it’s less fancy than a stationary food cart.
They are so bare bones that most don’t even have anyone to take your money. You have to get a ticket from a vending machine. Many don’t even have images on them - you have to look at the kanji, do some pattern matching, maybe narrow it down by price. Then you put in your coins, out comes your ticket, you go in, you hand it over… and eventually you get your food.
That’s how impersonal it feels. It’s the last kind of place you expect to find an example of good craft at.
There’s this thing they do, where they have wax models of the food on the window. One of these catches our eye and our mouths just start watering. We just fixate on this plate right here.
Pork cutlet, bit of salad, sausage, korokke (this little potato croquette that my wife loves), curry, corn, this pork bit over here… It’s a heart attack on a plate, but since we’ve been exercising, we don’t mind.
We figure “it ain’t going to be like that, not for 800 Yen, but who cares, we’re hungry”.
We go in, and a woman takes our ticket, then we sit around with our tea, waiting for the food to come out.
We can see into the kitchen where some young guy is preparing the plate, and he’s taking his time arranging things around it. We’re hungry, so all three of us are staring daggers into him doing his thing, hoping he hurries the hell up.
Then then he calls out and the woman who’d taken our ticket brings out the food.
And all three plates come out perfectly arranged. This gorgeous, mouth-watering work of art.
(Or at least that’s what it felt like - hey, I was hungry)
Funny thing is, I don’t remember what it tasted like, but I vividly remember he’d set it up to look exactly like the model.
And that made a light bulb go on.
You see, for a while there, it seemed like I couldn’t walk into a talk about craft without people bringing up Jiro Dreams of Sushi.
It’s about this old chef, Jiro Ono, who has been making sushi for more than sixty years, and runs this little restaurant where you have to make a reservation for months before you visit.
Great documentary, sure, but it might as well be the “survivor bias” of craft.
It’s about someone who devoted himself to a single style of cuisine, for decades, and eventually got world-wide recognition.
That’s nice. Everyone dreams of doing their best work at the equivalent of a 3-Michelin-star restaurant.
But that’s an end state, not a process.
I don’t care about how people work when they land the ideal gig on the best possible place.
It’s more relevant how to act if where you’re working at is on the un-glamorous end of the spectrum.
How can you sustain a craft when you’re working on what can feel like the tech equivalent of a hole-in-the-wall subway station curry joint?
Which reminded me of something David Cronenberg said:
“Most people have too exalted an idea of what art must be to connect their own impulses to create with delivering themselves.”
And I think this is what trips us about software craft sometimes.
Everybody sees the end result. We expect to come up with the perfect work of art, or at least close enough to some imaginary standard, right out the door.
While we may know that’s not possible, we don’t think about setting things up for incremental improvement. We disregard the process.
So let’s talk about what I’ve found with my teams that we can do to help sustain a certain level of craft, without expecting to be the three-star Michelin restaurant from the start.
Find allies who share your aesthetic.
Yes, this is about aesthetics. And yes, it’s a big one.
In order to do something in the long run, and to enjoy doing it, you have got to like what you’re building.
Everybody can tolerate doing something ugly, for a while. Crunch time, shoddy processes, unnecessary fires. But that’s no way to build something to last.
Ugliness leads to churn.
Even the language that we use to describe something that resonates with us, a solution that feel just right, is about beauty.
- “Wow, that’s nice”
- “I found a beautiful fix for this case”
- “You should see how well this all fits together”
Aesthetic choices affect platform and system design.
Hell, working with people who share your aesthetics will make it a lot easier to agree on what it is you’re building in the first place.
And keep in mind allies are not necessarily co-workers, or team mates.
Allies can be people in the company who help you sell your approach; a boss who gives you the space to grow your craft; a mentor whose questions help you find your style; someone from the community, who gives you an opinion or points you in the right direction.
You need people who support you when you are unsure about a decision, or who tell you when you are making a boneheaded move, or who have different blind spots.
People whose judgement you can trust.
I’ve found that when team members trust someone’s aesthetic choices for a system, even if they wouldn’t describe it in those terms, they are a lot more likely to trust this person’s judgement.
Shared aesthetics make jamming a lot easier
There’s this myth that a good team is like a finely-tuned orchestra. It’s not. An orchestra has it easy.
Orchestras and bands have a score to play. Someone composed it in advance. It will play similarly every time, barring stylistic choices by the conductor.
A lot of it is about practicing, and doing your bit, and hoping everyone else’s timing is right.
Software development? It’s a lot more like a jazz jamming session.
The members show up, and have a basic set of skills, but they’re not going to apply them in the same way every session.
All too often, you’re going to need to improvise, and for this improvisation to work, you need to know your fellow players.
Sometimes your group members are going to fumble, and it’ll be up to you to pick up and make sure that the bum phrase they played fits into the whole thing.
Sometimes they’ll need to do the same for you.
Not everyone can be in the front, going nuts, all the time. Enjoying the aesthetics of what you’re creating makes even a supporting role rewarding.
It helps increase the willingness to put aside the individuals’s own temporary, show-boating interests to ensure that whatever you are building is better in the end.
When choosing who to jam with, keep in mind that diversity is going to play a big part on coming up with interesting results.
You don’t want a band that is 95% tubas.
And if you’re running a team? You’re not a conductor. You’re a stage hand. You’re a roadie.
Your job is to make sure they have everything necessary to play and then get the hell out of their way.
Forget the Steve Jobs movie rubbish about “musicians play the instruments, I play the orchestra”.
It’s not your band. They don’t work for you, you work for them.
Shortcuts are tempting
As part of this, given all this jamming and improvisation, we need to do one key thing.
We need to put ourselves in a situation where doing the right thing is the easier choice.
Build habits so that things become autonomic, like putting on the seat belt before you turn on the car.
You’ll need to figure out which things work for your case.
Might be a weekly WTF where you discuss what you screwed up, and how to never do that again.
Might be giving everybody Fridays off so they can learn and train, even if you’re against a deadline.
We repeat things, and we train, to build habit. That way, when we hit crunch time, we can default to best practices.
I saw a tweet a few days ago which said that best practices start with good people.
That misses the entire point of best practices! They are there as support when you’re not at your best. They help even when you slept too little, have a terrible cold, and your brain refuses to come on.
That’s also why you need allies who share your aesthetics. They’re part of the support structure. They are there to raise a finger and go “ein moment bitte!“ when you’re about to do something lazy and ugly that will bite you all down the road.
Patience and a tolerance for past mistakes
Because you’re going to have to live with your choices. Any improvement will directly correlate with how much you can tolerate cringing at your past work.
I still code. And I assure you that the line about how there’s no code more hideous than the one you wrote six months ago is absolutely true.
And worse, that never goes away. Not as long as you are learning.
There’s two ways in which allies help here.
Allies give you perspective, especially if they have more experience.
Allies challenge you, when you’re hesitant to try something because you feel you might fail at it. There can be no growth without exertion.
And you will be exerting yourself.
Getting better at anything is tiring. It’ll be a constant fight against your own desire to give up.
This is why you need to set things up so that it’s easier for your team to do the right thing.
This is also why you need to pick the right allies to work with. You’ll have enough stress as it is.
The wrong people? The wrong people will turn your entire day into table-flipping o’clock.
Crafting is about shaping the result. Shaping requires agency, the capacity to act and determine your own fate.
So you might be thinking “oh, that’s all fine and dandy if you’re doing your own thing, but I have a boss”.
Which is perfectly valid.
You’re going to need to find a place where people see the value you provide.
Having agency will require some negotiation. There can be no negotiation if the other side sees you as a cog - at best, you’re arguing about replacement costs.
Now, don’t misunderstand what I said about aesthetics. Craft is not about artistry, or creating something just for creation’s sake.
It’s much more about consistency and putting in the work.
You and your team, getting your heads down and focusing on what you need to achieve. No matter where you all are in the organization.
Remember that the guy arranging these plates day after day so that they look exactly like the model in the window is the cook at a hole-in-the-wall place. This is not the Chief Curry Officer, imposing his glorious craft vision from up on high.
This is someone just getting on with the job.
Don’t let the madness get lost in the method.
And still, with all this structure, you can’t let the madness get lost in the method.
You need to bring something from yourself.
It’s easy to just follow existing frameworks, a set of rules that someone else came up with, without questioning if they apply.
The end result will be dull. It’ll be the same thing as everybody else is doing.
Frameworks are training wheels for the mind.
They’re useful when you’re getting started, or as a reference point, but can be constraining once you’re ready to start going your own way.
We should keep asking ourselves if hewing closely to the framework buys us something, and where we could be better off by stepping away.
Frameworks are other people’s choices. It pays to examine if we’re also happy with other people’s trade-offs.
A certain disregard
Maybe you noticed that this advice on questioning frameworks can be at odds with what I said about best practices.
If so, good. You need a certain disregard for authority.
It doesn’t matter if other people are criticizing or providing advice or praising. Make sure whatever they are saying is in line with your aesthetics.
Remember that whatever experience they have, whomever they are, they aren’t you.
(And that includes me)