Matt Van Itallie for This is Learning

Posted on Jul 24, 2022

Code is a craft, not a competition – and why it matters.

****Writer’s Note: I am honored to be publishing this piece with This is Learning.

This is Learning is a community that shares my values: a love of coding, a belief in continuous learning and growth, and a commitment to collaboration – these are some of the best elements of the global community of developers and what we aim for at Sema.

I got to know This is Learning through a fabulous podcast about Code Reviews with Jay Bell earlier this year– check it out. I have all the time in the world to talk about mentoring and growing devs’ knowledge with people who care deeply about it too like Jay.

Finally, I am humbled to be here because I couldn’t ask for a better example of a person who represents the best of coding, a Co-Founder of This is Learning, Santosh Yadav. Santosh’s own story makes him an exemplar that coding is a path to incredible opportunities, including GitHub’s first Star in India – if you do the work. And having achieved this status, he has made it his priority to give back to others.

Now, on with the show…

Introduction.

Over the last two years, I have interviewed more than 1000 developers about their work:

what they love about coding,
what they’d want to improve, and
what blockers are getting in their way of achieving their personal and professional goals.

My goal was to get input on next-generation tooling that could make a positive difference, whether they were working on Open Source or private projects, from minor to giant teams.

More than any specific feature or need, the most important thing I learned was a metaphor:

Code is a craft, not a competition.

I wanted to share my thinking with you and get your feedback.

Part 1 what is a craft?

Part 2 is coding a craft?

Part 3 if coding is a craft, and I believe it is, what are some of the implications for software tooling to support that craft?

Let’s delve into it.

Part 1: What is a craft?

When Engineers started talking to me about craft-like elements of their work, I did some background reading on the history and nature of the craft.

My favorite source was Peter Korn’s “Why We Make Things and Why It Matters: the Education of a Craftsman.” It’s a biography of a master woodworker, but the first third begins with a discussion of crafts vs. arts vs. other vocations.

From this book and other sources and conversations, here is my distillation of what a craft is.

First, A craft is a skill that improves with knowledge and wisdom.

As the old adage goes, knowledge is not the same as wisdom.

Knowledge is information in its rawest form — domain-specific facts, methodology-specific facts, and guiding principles.

Wisdom, on the other hand, demands insight. It is the judgment to apply knowledge to specific contexts to pick a correct approach or approach with the highest likelihood of achieving the desired goals.

When a craftsperson possesses greater knowledge and wisdom, their ability to create a quality finished product increases. So how does this growth happen?

Both knowledge and wisdom can be self-discovered, passed on through codified sources, or taught. However, as with any skill, high-quality teaching is the best way to accelerate skill adoption.

Here’s where things get interesting. Though Knowledge is important, it can’t do much on its own — in fact, it’s something that seems more valuable than it is. In isolation, it can be just rote memorization or facts lacking critical context that’s needed to apply in a useful way.

When it’s combined with and refined into Wisdom, Knowledge begins to pay dividends. Wisdom is applied Knowledge - used to chart a course with the highest likelihood of achieving what one set out to do.

Wisdom generally can’t be memorized. Instead, it’s forged in the crucible of experience and repeated mistakes. When someone developing a craft is nurtured with high-quality teaching, the acquisition of Wisdom is again greatly accelerated, and so is their ability to create a quality finished product.

Second, the craftsperson derives pleasure from doing the work for its own sake.

Important to the definition of craft is autotelism: the principle that pleasure comes from the work itself, intrinsically, separate from any external purposes or goals.

This doesn’t mean crafts don’t generate external benefits – compensation, critical recognition, or the delight from users appreciating a creation. But as Korn writes “there is great satisfaction to be found in work that engages one as an end in itself.”

Third, working on a craft can generate flow state, when a creator is totally engrossed.

The very smart, and very hard to pronounce, sociologist Mihaly Csikszentmihaly identified nine components of generating flow:

There are clear goals every step of the way.
There is immediate feedback to one’s actions.
There is a balance between challenges and skills.
Action and awareness are merged.
Distractions are excluded from consciousness.
There is no worry of failure.
Self-consciousness disappears.
The sense of time becomes distorted.
The activity becomes an end in itself (autoelic).

Working on one’s craft can generate this flow state.

Fourth, the finished craft has to work.

This is the single biggest difference between art and a craft. For a craftsperson, unlike an artist, ultimately, the item being produced has to function and provide utility to a user. As Korn says about woodworking:

“The craftsman does not have the luxury of ambiguity. Soon enough his beliefs are subject to the test of the real. Either the chisel is sharp enough to pare wood effectively or it isn’t. … The sturdiness of a table and the comfort of a chair are immediately apparent to any observer.”

This standard of “does it work in reality,” while harder to achieve, ultimately leads to more satisfaction:

“The satisfactions of manifesting oneself concretely in the world through manual competence have been known to make a [person] quiet and easy. They seem to relive [them] of the felt need to offer chattering interpretations of [themselves]... [they] can simply point: the building stands, the car now runs…. Craftsmanship must reckon with the infallible judgment of reality, where one’s failures or shortcomings cannot be interpreted away.”

He wrote it about woodworking, but it reminds me of every intense conversation I've had with devs before, during and after building a feature or driving down tech debt.

Part 2: Is coding a craft?

I believe that code meets this definition of a craft. To investigate, let’s compare the activity of writing code against the four tenets I outlined previously.

A craft is a skill that improves with knowledge and wisdom.

Coding most certainly involves the collection and synthesis of information:

Domain-specific facts e.g. making a project GPDR-compliant,
Methodology-specific facts, e.g. database structures, algorithm optimization and style conventions
Guiding principles: both for the individual (understandable code is a priority), and for the team (code reviews are a priority)

And coders develop wisdom the longer they code. The biggest difference between Beginner, Advanced Beginner, Intermediate, Advanced, and Expert coders is the ability to apply wisdom to the coding situation at hand.

In the world of coding:
Knowledge can be thought of as the skill necessary to solve a certain problem through code
Judgment would include whether to build the solution vs. use a third party library

Coding knowledge and wisdom can indeed be self-discovered, passed on through codified sources, or taught.

While it is possible to become an “Advanced Beginner” developer through self-discovery or research, the practice of teaching accelerates this process and unlocks far greater maturity.

For coding, “teaching” can include informal Q&A, code reviews, mentorship, and classroom coursework (if it’s relevant and involves true back and forth between a student and teacher).

When teaching, a developer also engages in the learning process. It allows them to absorb the mistakes made and lessons learned from multiple people and angles. They can learn to communicate with various skill and competence levels.

The craftsperson derives pleasure from doing the work for its own sake.

Important to the definition of craft is autotelism: the principle that the pleasure comes from the work itself, separate from any external purposes or goals.

This is a fundamental guiding force for almost every developer I talked to.

Yes, of course, some coders see their work as a 9-5 job. Many appreciate that it is an unquestionably great career when measured by compensation, flexibility, and autonomy.

In addition, almost all engineers are thrilled to see the code they’ve written used in action, helping their organization (or if they’re lucky, the world) be more successful.

But at the heart of most engineers I spoke with, having code simply work successfully is immensely satisfying, regardless of any other factors.

At the heart of code quality is a deep passion for the code to work, and work in the right way. This speaks to engineers' devotion to their craft — a devotion to producing a workable outcome and an elegant solution with enduring value. It evokes mindfulness and appreciation for the process and propels them to explore ways to improve it.

Working on a craft can generate flow state, when a creator is totally engrossed.

Coding in the right environment – which of course, is not 100% of environments! – can lead to the flow state:

There are clear goals every step of the way: Functional and non-functional requirements join themselves in code written in a flow state.
There is immediate feedback to one’s actions: The code compiles, or it doesn’t, it runs, or it doesn’t, it passes tests, or it doesn’t.
There is a balance between challenges and skills: Engineers can keep working on harder and more complex technical challenges in higher performing coding teams. An Engineer might get a consistent quantity of constructive feedback in their code reviews because they are enabled to keep pushing themselves beyond what they already knew.
Action and awareness are merged: Yes!
Distractions are excluded from consciousness: Many a teammate has wondered why a Slack message has gone unanswered during the first half of a day. A mind engrossed in the complexities of a challenging problem being solved well has no time for interruptions or context switching.
There is no worry of failure: Yes, Business / Sales / Finance pressures do intrude, but when a dev can be focused on the task at hand, they have moments of energy and clarity without fear.
Self-consciousness disappears. Coders get lost in the work and can code without eating, sleeping or any other need.
The sense of time becomes distorted: I’ve heard stories from hundreds of engineers losing track of time and completing just ONE more feature, or optimizing just ONE more method.
The activity becomes an end in itself (autotelic): Timelines are an unavoidable real part of commercial software development, but flow is not generated by the prodding of a scrum master or the pressure of deadlines.

The finished craft has to work.

To figure out something magical in code can be a delightful feeling, but for almost all coders what matters is what happens when the code is used. Ultimately, the code needs to work.

For the coder, “working” means “does it compile,” but it also means “does it work for users” and “does it work to the level of my team’s standards at this particular moment (since the tradeoff of scrappiness and excellence varies over time).”

What it means to treat code as a craft, and not a competition - and how to enable it.

If we’ve done our job, you know what’s coming next: the implications of treating code as the craft it is.

We are persuaded that code is a craft – which means that engineering teams and their supporting tools and systems need to be set up to support creating code as a craft, not a competition.

No doubt you can think of many examples of where devs and dev teams were not treated in this way– rewarding or measuring lines of code created is our favorite, worst example.

We believe any engineering manager or organization with developers should want to facilitate the flow state of craft from the folks developing for them.

Here’s some guidance on what that looks like.

Because craft relies on knowledge, tools that put expertise at the fingertips at developers are incredibly important.

That’s why Stack Overflow has been one of the most revolutionary tools for developer flow in the last decade.

Resist the dogma of velocity at all costs.

Instead, be methodical about identifying and removing blockers to flow. Blameless, inclusive retrospectives, and continuous testing to find better methods for dev flow, are essential.

Feedback methods, particularly code reviews, mentoring, and paired programming, are essential to transfer knowledge and develop wisdom.

The most important measurement of code quality is the subjective assessment of engineers with knowledge and judgment. Linters have their place… but the truth is what other craftspeople say.

Metrics about coders shared without permission are dangerous. The choices that coders make every minute, hour, day can not be reduced to a robot’s review of your code. And stay far, far away from measures like LOC / day.

Finally– coding exercises during interviews need to be handled very carefully. The best way to understand how a coder works is by observing their past performance, or coding/problem solving under conditions similar to what they’ll face while working. Reviewing the details of their previous work– a true portfolio, not just the front end– can help here.

Conclusion.

I hope this piece persuades you, and it gives you ideas to help support the craft of coding in your own organization.

But if you’re not persuaded, I really hope you weigh in and help make these ideas better. A true joy for me of the community of coders is a deep belief in the power of ideas, and a willingness to jump in to improve things– whether’s it's twitter or reddit posts, articles or, of course, the code.

In the weeks ahead, my company will be announcing the next generation of our free developer tool, a GitHub add-on to help engineers connect, get hired, and get promoted.

We have done our best to build it based on these principles we discovered... but of course we know the first version will only be the beginning of the journey. Building something with excellence never ends.

Here’s to the wonderful global community of coders and, yes, to the craft of code.