Skip to main content

Show Your Work!

This book by Austin Kleon was an unexpected one, both because it wasn't on my reading list and because it kept getting better as it went on, exceeding my expectations.
I read it in a completely different way compared to the others: in the meantime I was building a piece of software, Veil, aimed at solving every problem I'd had with the dark readers I used in the past for my eBooks. I improved the program as I noticed errors or got ideas while reading.
It was extremely rewarding to be able to switch between activities whenever I wanted, a bit like I do with coding and design.

I also analyzed some key excerpts from the book with the help of AI, having them reframed for my future job as a UX Engineer, especially the last section which covers things I haven't experienced yet.
That copy-and-paste was one of the main problems with the dark readers I used: one would paste one word per line, another wouldn't put spaces in properly.
The biggest issue, glaringly obvious with Refactoring UI where there were tons of images, was that all of them blindly inverted the images too, including pages that were already dark, which turned white. With Veil I solved all of this.
But there will be a dedicated readme for that; I couldn't hold back the excitement.
Let's talk about the book.

Scenius​

The myth of the lone genius frames creativity as an antisocial act: the lightbulb goes on, the genius locks themselves in the studio, the masterpiece is released to the world.
The rest of us are left to just watch.
Musician Brian Eno proposes an alternative model he calls scenius: great ideas often emerge from an entire ecology of talents: artists, curators, and thinkers who support one another, look at each other's work, copy and steal ideas.
It's a bit like what happens in Midnight in Paris: there was that woman who analyzed books and paintings, gave feedback, held together people from different fields.
Picasso and Hemingway in the same place wasn't a coincidence.

Amateurs​

Austin argues that sometimes amateurs have more to teach us than experts, quoting C. S. Lewis:

"It often happens that two schoolboys can solve difficulties in their work for one another better than the master can.
The fellow-pupil can help more than the master because he knows less.
The difficulty we want him to explain is one he has recently met.
The expert met it so long ago that he has forgotten."

I wasn't convinced. I read it more as motivational encouragement for beginners, a category I belong to, than as an absolute truth.
That said, I do think the part about beginner innovation is correct: in 6 years of going to the gym I've learned exactly what to avoid and what not to, and the innovation I can bring to it now I'd call controlled, meaning within the boundaries of the guidelines I've absorbed from the resources I studied and the direct, hands-on experience I've built up over time.

In my view it's not just a matter of knowing more or knowing less.
It's also a matter of being in love.
At the beginning you're willing to experiment not just because you have fewer constraints, but also because you're genuinely in love with the subject.

The most direct counter-example I've lived through is Calcola Turno: after tackling HTML, CSS, and JS on this path, in the second version I implemented features I didn't even know existed in the first.
I realized that the more dots you have, the more you can connect them. I believe that if a beginner surpasses an expert, it's because they have talent, not because being a beginner is a structural advantage.

Chain-smoking​

The title doesn't refer to cigarettes literally, but to the gesture: lighting the next one before finishing the last.
The mistake Austin talks about, one many people make, can be summed up in the following process:

  1. Finish a project
  2. Stop
  3. Wait for feedback (applause or criticism)
  4. Worry about the future
  5. Try to start from scratch, with inertia working against you

I discovered that the Next sections I put at the end of most projects represent this exact principle.

There's a dark side, though, if you take chain-smoking too literally.
Rest, as in completely disconnecting, is maintenance for your body, and sometimes you come back better than before.
I can say this with more certainty about the gym, where the way to break through a plateau has always been, paradoxically, to take a break for a few days.
And Austin says it right after, in the following chapter.

Flow and Stock​

One of the concepts that struck me the most, because I didn't know they had a name, is the distinction between how we produce and how we archive:

  • Flow is the stream. To give a practical example, it's the Path section of this site, where I document the journey as it progresses
  • Stock is what remains: the Vademecum, an aggregate of concepts collected during projects, the explanations that made me understand those concepts, jotted down while studying.

Vampires​

These are toxic people or situations that leave you feeling worse after dealing with them. For example, the Product Manager who calls two-hour meetings with no agenda and leaves you drained, the Senior Developer who instead of explaining a concept makes you feel stupid for asking, the client who calls at 7 PM on a Friday to change a color.

Brancusi's lesson is cited: it doesn't matter how "brilliant" Picasso is. If interacting with him drains the energy you need to work, you have to cut ties or put up barriers.
The gist is: don't let your creativity be squeezed dry by others.

The same applies to tasks:

  • Do you feel drained fixing bugs on obsolete browsers? That's a vampire task
  • Do you feel energized after prototyping a complex micro-interaction? That's positive energy

Using this test to guide your specialization is more honest than chasing what "looks good on a résumé."

Identity​

Kleon writes that the only way to find your voice is to use it. It's not about building it from nothing; it's already inside you. I've experienced this firsthand, but replacing "voice" with "personality."

Once that voice exists, the danger doesn't come so much from external "trolls" as from impostor syndrome.
Reframing the concept for my context: when someone says "your code is spaghetti" or "you're not a real engineer if you copy-paste," it hurts only if you already think you're not good enough.
The external troll uses a megaphone to amplify the mean voice already in your head: recognizing this doesn't neutralize it, but it does cut it down to size.

There's a subtler threat, though, which Kleon calls the success trap.
Neil Gaiman tells the story of waking up one day and realizing he had become someone who answered emails for a living and wrote as a hobby.
It's the fate of anyone who becomes so good at something that they're consumed by the requests that skill generates, and they stop doing the thing that made them visible in the first place.

Boolean Yes/No Algorithm​

The concept I'll carry with me the most into the future. It's brutal and crystal clear:

  • If an opportunity lets you do more of the work you want to do, say yes
  • If an opportunity means more money but less of the work you want to do, say no

The project pays little but lets you use that technology you want to learn? Yes. The project pays a lot but locks you into legacy code for 12 months? No, you're selling the future, not the present. That said, not everyone can afford this luxury, certainly not me either, when I formally start this career.

Begin Again, Not Start Over​

Kleon quotes Alain de Botton:

"Anyone who isn't embarrassed of who they were last year probably isn't learning enough."

Many people fear change because they think it means throwing away years of experience.
The semantic distinction he draws is very interesting:

  • Start Over: going back to zero, total loss
  • Begin Again: a new start, but with all the knowledge you've acquired

You never truly start from zero.
I wonder if this is a bit like what happened with the gym: 6 years in which I accumulated concepts that turned out to be useful in completely different contexts, like the 70% rule, active rest, controlled innovation.
Just as it happened with the factory, which taught me the ability to put the user at the center (Center). The takeaway is that your baggage transfers even when the context changes, just as Steve Jobs told in his famous Stanford speech, explaining how he connected the dots thanks to the calligraphy course he took in college.

Next: Reading this book happened entirely inside the prototype I mentioned at the beginning.
Read, notice a problem, fix it, start reading again.
The most immediate development cycle I've ever experienced (after Center).
The project is called Veil and it's the next readme.