Does Mastery Still Matter?

A collection of stories and memories from Jerry Seinfeld, Jiro Ono, and Krasimir Dimovski that show the importance of mastery in a post-LLM world.

My childhood dream was to be a painter.

I was right-brained enough to appreciate beauty, but not enough to be good at creating it. I just didn’t have the hand for it despite my best efforts. But even though I didn’t manage to become an artist, I learned to appreciate those who did.

Not only because of the beauty of their work, but because of the skill behind it. Mastery shows commitment, it shows strength of character, and persistence. I knew how difficult it was to draw a cube lit from one side, so I could only imagine how much time and effort it took to draw the Mona Lisa.

This need to be good at what I do still hasn’t let go of me.

How I Stopped Being Clever

I spent my first few years as an engineer in the part of the software world where mastery was lower on Maslow’s hierarchy of needs. Web agencies and startups taught me to be pragmatic, but they didn’t show me the beauty of building software.

Craftsmanship had a pretty low ceiling in that environment.

So I spent my free time devouring technical books and blogs. Looking back, a big chunk of that time was wasted on knowledge that was not only impractical but downright harmful for my engineering skills, but one book series I enjoyed was Kyle Simpson’s You Don’t Know JavaScript.

I’ve read them all cover-to-cover more than once.

To me, mastery was equal to knowledge, and the more I learned, the more I wanted to display it. I’d use every tool, shortcut, and obscure behavior of the language to build things because I wanted to show how much I know. I exploited JavaScript to its limits.

It wasn’t an ego thing. I had spent countless hours acquiring this obscure knowledge, and not using it seemed like a cardinal sin.

A few years later, I got a job as a front-end developer at a company that was developing its own cybersecurity product.

Around that time, I developed the habit of using the + operator to typecast variables to a number because it required fewer characters than calling a function. Just put a + before the name of the variable, and JS will treat it as a unary operator and attempt to convert it to a number.

const num = “123”
+num // returns 123 (number)

I thought that saving a few characters was a nice touch. Our lead engineer didn’t appreciate it, though:

“Every time I see you doing this, I feel like I’m getting an aneurysm.”

I got a nice roast every time I submitted one of my trick-filled PRs, and I slowly found out that craftsmanship and mastery are not about tricks and shortcuts.

It was the first time I worked in an environment that valued something other than correctness and speed. My typecasting saved a few characters, but it lacked an important value of good software. Readability.

It required the reader to know that specific behavior, or they’d sit wondering what this + is doing there. Use a few more tricks like these, and you might as well start leaving footnotes in each file.

That Pesky Subjectivity

Many engineers work in environments that don’t reward craftsmanship, only speed of execution. And when you’re rewarded for the result, you start believing that this is the only signal for improvement.

Your manager is happy you met a deadline, and you get a nice salary bump during the next promotion cycle. Surely, this is a sign that you’re growing and improving.

But there are two ways to judge code - correctness and craftsmanship. The former you can measure objectively, the latter is inherently subjective. Like most other crafts, true mastery lies in that subjective territory where things aren’t simply black and white.

Now, this was a big problem for me.

It either works or it doesn’t. You’re either shipping or you’re not. What’s there to talk about?

Since there is no other benchmark for improvement, we equate mastery with only correctness and speed.

Mastery in Well-Built Software

Writing code and building software are two different skills. I’ve seen absolute code virtuosos who can’t make a meaningful trade-off or design decision for their life.

Being able to write in a way that makes your code understandable by both the machine and the person behind the keyboard is something I deeply admire. But in the last couple of years, I can’t help but notice that this aspect of the craft is no longer that highly praised. In a post-LLM world, correctness and speed have triumphed over mastery.

Maybe speed more than anything else.

I remember when job postings emphasized how much the company valued its code quality. Go sift through a few startup listings and count how many times the words speed and shipping are used now.

These are the only things the 996 culture values.

In the post-LLM world, where thousands of lines of code per day are the norm, you can’t give that detailed review to every single one of them. You can’t root out the usage of the + operator for typecasting.

If You’re Efficient, You’re Doing It the Wrong Way

When I discuss this with other engineers, they’re quick to tell me that there are tools to ensure this quality. There are settings, rules, and automated reviews. You just need to create the proper system, and the agents will follow it.

But to give you a proper answer to how I feel about this, I need to share a quote from Jerry Seinfeld.

“If you’re efficient, you’re doing it the wrong way. The right way is the hard way. The show was successful because I micromanaged it—every word, every line, every take, every edit, every casting. That’s my way of life.” — Jerry Seinfeld

Quality can’t be automated. I’ve tried. The industry’s been trying since forever. You can get up to good enough, but not to perfect. You are chasing efficiency, not mastery. If you’re trying to make things faster, you’re chasing scale, not a good result.

I can’t realistically tell people not to use LLMs and write artisan code by hand.

Every craftsman uses tools. But the instructions you give to the LLM and what you do with the code it generates is where mastery is shown. Whether you tell it to build a module and expose specific functions for its public-facing API, or you just give it a business requirement and pray to the machine spirit.

Basically, how hard you micromanage it.

The fallacy of the amateur is in thinking that the tool creates the skill, when actually having the skill allows you to make use of that tool effectively. Learning to use an agent effectively is much simpler than gaining the underlying knowledge and forming a taste for what good software looks like.

I’m not saying this as an excuse to stay small, to be slow, and to ponder details for days without shipping anything.

Speed comes with skill and taste. Seinfeld’s viewers enjoyed a new episode every week. You can ship software without sacrificing mastery.

The Subconscious Pursuit of Mastery

A friend of mine has been working on software that finds mentions for companies on social media and news websites.

He’s been at it for years, and what started as a software for PR companies turned into an obsession over efficient storage, search algorithms, and non-stop performance improvements.

When he tells me about his work, he doesn’t talk about revenue and projections, but about the next technical challenge he’s overcome.

He’s chasing mastery, not making a business.

It’s just a lot easier to work on your craft in solitude. That’s why it’s more visible in traditional art - paintings, and books are not made by a working group that has to compromise in order to make someone happy.

How is This Even a Question?

A few years ago, I saw the documentary Jiro Dreams of Sushi. It’s about a famous sushi chef who has devoted his entire life to mastering his craft. He was 85 in the documentary, and he said he still has a lot to learn.

Jiro is world-famous, and even a slightly business-savvy person would tell you he could’ve trained a bunch of chefs and opened a chain of restaurants that could be making money without him having to sweat over every slice of tuna.

But this means that he’d be thinking about scale, not quality. About wages, not the pans.

Instead, he has only ten seats in his restaurant, his son goes to the market to hand-pick the fish, his apprentices spend years just beating eggs, and he’s in the restaurant every day.

Jiro values his work.

I don’t think he gets up in the morning wondering if his mastery is still relevant in a world of fast food and takeaway.

Can you imagine going up to him and asking him if he thinks his mastery still matters? I’m not sure if he’ll even understand the question.

Mastery Does Not Matter (To Most People)

This leads me to the most important point of this write-up - mastery has never been on the general populace’s list of interests or aspirations.

I was in my late twenties when my father-in-law took me to see Carmen, and some time in the second act, he asked me what I thought of it. I answered that I’m not sure if I really liked it.

“You don’t like it, you learn to appreciate it”

This changed how I viewed the opera’s second act.

Most people won’t wait half a year for a spot in Jiro’s restaurant. They won’t go to a philharmonic concert. The same goes for software, and this Dijkstra quote rings in my head every time I have to work on an over-engineered project:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” ― Edsger Wybe Dijkstra

Some codebases are pompous, built without taste, and that is visible in the complexity they’re drowned in. So the question I started this write-up with is fundamentally flawed.

Mastery doesn’t matter to most. But it should matter to you.

Mastery is Hidden in the Layers

I recently went to a literature festival and spoke to the author Krasimir Dimovski. He said that every work of art has layers, and each layer is appreciated by a subset of people.

The outermost layer of his latest novel is a thriller that anyone can understand. It’s an easy-to-read page-turner. But in the inner layers, he touches on education, love, and morals. Fewer people will look into these. Then the innermost layer is where he works with the language, where he shows what an incredible wordsmith he is. Now this will be appreciated only by the handful of people who truly appreciate literature.

People only see outwards from the layer they’re on, so they can read a novel whose deeper ideas go completely over their heads.

Mastery is in respecting these layers.

Many people buy a car for its color, some look into its extras and capabilities, but a mechanic will appreciate its engine.

The mantra that customers don’t care about code quality has been repeated time and time again to justify speed. And it’s true - users don’t care about what’s inside the software they’re using. But you should care. Users appreciate the outer layer. Your fellow engineers will appreciate the inner.

And you, as the creator, can take pleasure in crafting something like this.

The Gap

The pursuit of mastery starts with an insane amount of struggle and a feeling of incompetence.

“Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.” ― Ira Glass

This is where a lot of people quit, in the gap. They see beauty, they appreciate it, but because creating it takes time, they give up.

Maybe that’s why I gave up painting in the first place.

But if you don’t feed that desire to create, it will devolve into cynicism and despair. It’s like still water - it turns into a swamp. But if you have that need, that deep desire to make things, it only needs to matter to you.

Like Dimovski, you’ll find a layer to express your mastery even if it’s somewhere deep inside the codebase.