Blog

Art is practice. They are one and the same. You have to learn to love practice or you don't really love the art.

Music and programming share this. I cringe thinking of my first programs. But I wrote many many more and they got better.

The musical slang for this is "shedding". At first, you sound so bad, you're exiled to the woodshed. But eventually shedding is just a thing you do. It becomes part of your practice.

When Charlie Parker was starting, he asked if he could sit in on a jam session. It didn't go well. He lost track of the changes while soloing. The drummer threw a cymbal at him.

A year later, Parker showed up at the same club and asked to sit in again. A couple of the band members remembered him, taunted him. This time though, he "cut heads" – jazz slang for dominating musically.

What changed? Parker turned his humiliation into determination, determination to avenge himself through practice. He said later he practiced up to fifteen hours a day during that period.

If you're just starting out with programming, think of yourself in the shed. Don't worry about your programs being great, just keep 'em coming.

At first, practice can be painful. With the guitar, you have to build up literal callouses on your fingertips. Creating the habit of practicing daily can be difficult.

Eventually, the pain can turn into joy. I love this phrase: it's not that I have got to practice, I get to practice. I look forward to it as its own reward.

Parker's determination did not turn into devotion, a practice of gratitude. He lived what we'd today call a rock star lifestyle: booze and drugs, casual sex, and a nasty attitude. When he died at 35, estranged from almost all family and friends, the coroner estimated his age as 50.

Part of art is longevity. Parker's sidemen Miles Davis and Dizzy Gillespie both lived into their seventies and released dozens of albums. Although they both credit Parker as the innovator, they each earned much more recognition. And although they also had personal challenges, I'm sure they experienced a much greater amount of joy overall.

Negative motivations like revenge and money are valid, but only effective in the short term. To borrow a phrase from surfing, I believe the greatest artist is the one who has the greatest amount of enjoyment.

Turn "got" into "get" and learn to love the shed.

Quantum Mechanics has an interpretation which coined the phrase, "observation affects outcome". In QM, this interpretation leads to mysticism: the cat that is both alive and not-alive, the particles that aren't there until they're looked for.

However, taken quite literally, it has application and insight for everyday life.

Watching is not a passive activity. When the watcher receives information about the watched, both of them are changed forever.

Parents scar their children no matter what they do. Anyone can see the effect of absentee parents. But at the other extreme, overly involved, so-called "helicopter" parents can cripple a child equally.

Scars can't be avoided, because all parents are themselves children. Still learning.

In a video game, you can relive a life over and over to get it just right. In this life, the warmup is also the final. We have to make mistakes to explore the boundary between what works and what doesn't. The test limits the results.

Observation affects the outcome.

Telecommunication is excommunication.

Sometimes signals mean their opposite. It seems like communications technology should bring us together, but in practice it pulls us apart.

Telecommunication provides an illusion of closeness. Facebook is like "Friendship: The Video Game" – there's even a number to keep score with.

The first time I realized this, I was on the phone with my family on the West Coast. At the same time, someone was moving in next door. I realized I kept in closer touch with people hundreds or thousands of miles away than down the street.

The greatest human separation in history, our current pandemic lockdown, could only have been possible because of our telecommunication-enhanced isolation. Our economies have suffered, but as little as ten or fifteen years ago we would have been unable to avoid economic catastrophy.

The horse has kind of left the barn on this one. We've accepted technological isolation without fully understanding the effects on society. These shock waves are reshaping us.

But while you can't change the hand you've been dealt, you can change how you choose to play it. Listen, I work in tech, I carry a smartphone, I'm knee deep on social media. But I try to focus on how I can use them rather than letting them use me (pro tip: treat social media like a slot machine – once you see something good, "cash out" by signing off).

Isolation is inhumane, and telecommunication enables it. We're living in an inhumane age. Let's remember that as we struggle.

The most important part of beautiful code, formatting, adds no features or performance benefits.*

Just like a poem, programmers use whitespace to give code shape. Spaces, tabs and returns get used to shift code horizontally and vertically.

This shifting adds meaning to reading the code. Putting negative space around a value draws attention to it, like the border on a framed picture. Indenting code indicates a relationship of hierarchy, shows its dependency.

The computer ignores whitespace. In fact, readying a web app to deploy involves automatically removing all whitespace from the code. Yet it's so fundamental, an experienced programmer looking at unformatted code experiences immediate distaste and distrust.

The saying goes, "form follows function". Code has to work first. But just working isn't enough. It also has to be an object of beauty. The specific rules of the formatting don't matter much. They just need to be meaningful and consistent.

Spending time and attention on actions that don't add features is wasteful. Everyone's budget is eventually finite. No one can afford to be wasteful everywhere.

But being wasteful intentionally can be a gift, an offering, luxurious.

Making something beautiful requires choosing what to waste.

* EDIT: changed from "adds no measurable value" – formatted code has been proven to have lower bug density, easier refactoring, etc.

I wrote a piece earlier this week about the concept of "10x" in programming – the idea that some programmers are ten times more productive than the rest.

I got some pushback for the main statement I made: "10x programmers practice their art with ten times the love." I stand by this, but it does deserve more explanation.

There's a common misconception that programming is a science. It's not; it's an art. There's a huge technical component, for sure, but music shares this, and it's not a science.

It's meaningless to say one musician is "more productive" than another, because there are no appropriate measurements to compare. One singer might have a wider vocal range and produce more decibels at full volume, but we don't rank singers based on their numbers, as if they were athletes.

Think about a program you liked. It had quirks, but they were fine. Then the "big update" came out. It promised measurable improvement: better performance, more features.

The new version was worse. On paper, all the stats were better, but it no longer served its purpose as well. Your feeling towards it soured.

The true measurement of a program's success depends on how people feel about it. That's what makes programming an art.

Making something people like is not the same as giving them what they ask for. A good programmer has to understand human nature, and have the discipline to give people the right thing. Just like a good musician doesn't "flex" their technical capabilities for their own sake – they play what the communication requires.

This combination of soft skills has little to do with the mechanics of technology. Instead, it represents a form of devotion to the craft. I wrote earlier this week that software belongs to its users. Writing software – notice that verb, an art – is an act of service.

All of this, just to rephrase without the "L" word: 10x programmers are ten times as devoted to serving their users.

I stand by that statement as much as the first, but it's a boat load less catchy, isn't it?

“This program is absolutely terrible. Whoever wrote it should be ashamed of themselves.”

It was the early 2000s. I’d written a few programs, but this was one of the first intended for an audience larger than my immediate co-workers. So far, I’d rolled it out to several departments. The feedback up until this point had been a muted positivity, “good job” type stuff.

Many skills required to be a successful programmer also apply to everyday life, and handling criticism is a big one. It would be nice if everyone delivered their feedback in a tone of gentle, positive encouragement; but to paraphrase Ice-T from his metal band “Body Count”, I live in the real world, and sh ain’t like that here.

Separating the objective and actionable elements of feedback from the emotional and personal triggers makes a crucial difference in how you’re able to respond. Hostile, antagonistic feedback often still contains valuable information about the work.
Download the Medium app

Pro tip: it’s the work, not your work. You write a program, but it does not belong to you. Software belongs to its users.

The only thing more worthless than a program that no one uses is a program which people feel they have no choice but to use, which causes them frustration. As a programmer, you have a moral responsibility to create works which users enjoy (or at the absolute minimum, to reduce user suffering).

If your program has problems, users’ communication will reflect their frustration. In order to get the invaluable information about what’s wrong, you have to apply a mental filter: ignore the negative “noise” and focus only on the positive “signal”.

Here’s the filter that enables me: as a programmer, I provide a service. I want the programs I produce to be of the highest benefit to their users. The information I collect does not reflect on me personally, but on the feeling between the user and the program.

I thought for a long moment, considering the sick burns I could lay on this person by revealing I was the criticiz-ee. During that thought, I realized I was being paid a backhanded compliment: the hidden, incorrect assumption that a junior like me couldn’t possibly be the author. That even such a “terrible” program still must have come from someone older and more experienced.

“I’m sorry you feel that way. Can you give me some specifics? Maybe I can help to improve it.”

Making a decision about anything is an emotional process.

Even for a simple, fact-based decision, when you evaluate a possible answer, you give the thumbs up or down based on a feeling.

That feeling is confidence. You’re either highly confident the answer is correct, highly confident it’s not, or lacking confidence either way.

The confidence is supposed to be a direct reflection of knowledge, gained through experience. And usually those two things share a strong correlation, but correlation is not causation.

Confidence can be misplaced. You can feel certain you know something, and then find out you’re wrong.
Write on Medium

Physically, being tired or hungry can greatly affect the accuracy of your confidence. I still cringe when I think of one spectacularly incorrect answer I gave, late in the afternoon after a lousy night’s sleep.

Confidence can be misplaced for emotional reasons too. Admitting a rival is correct requires separating the feeling you have for them from the confidence you have in the answer.

To succeed at programming requires clarity of thought above all else. Both externally, clarity in code; and also internally, emotional clarity.

Unclear code allows bugs to fester. Unclear emotions allow actions to happen unconciously.

So why don’t we all pursue clarity all the time? Because it’s uncomfortable. It requires accepting a situation as it is, not as we’d like it to be.

Like many uncomfortable habits, eating your vegetables or getting exercise, there’s a tremendous reward to clarity.

Pay attention to your emotions to make better decisions.

Music and programming are both arts with a significant technical component. Having a teacher can be a great help with those challenges.

Ultimately though, all learning is self-learning. Even the greatest teachers can only help students to teach themselves.

We often think of "teaching" as something one person does to another: the teacher opens the student's head and pours the knowledge in.

In practice, it doesn't work this way. Instead, the teacher/student relationship resembles that of a traveler and a guide. The teacher leads the student along the path that's most likely to get them where they want to go with the least cost.

But how can the teacher take the student where they want to go, if they don't yet know?

I had the great fortune of having a great teacher demonstrate this for me.

When I started the guitar at 13, my parents said I had to take lessons. I went down to the music store, and they signed me up with this crusty old fellow. He wanted me to start by learning the names of the notes in "On Top of Old Smokey". I wasn't about that. My parents said okay, but, I had to find someone else.

I went back to the music store, and this time they put me with Mike Gross. First lesson, we made some small talk, then Mike asked: what kind of music do you like? I said Guns N' Roses, Metallica. He said how about AC/DC? Hell yeah, now we're getting somewhere.

In the first lesson, Mike showed me the chords to "Back In Black", and also the hot little riffs that tie the chords together. Then he showed me guitar tablature – a notation of where to put your fingers – and how to tune.

In the first hour, he gave me everything I needed to get hooked on the instrument forever.

I kept going back to see Mike because he would transcribe songs I brought in on tape. I know metal wasn't his bag, but he'd teach me anything without comment.

One day I asked why the same pattern kept showing up in all these solos and riffs. Mike said it was the pentatonic blues scale, and showed me how to move it up and down the neck in any key.

I was hooked again. The mathematical and geometric qualities of music theory were fascinating to me in the opposite way as school math and geometry. I ate up the circle of fifths, augmented and diminished, building chords out past 9ths into 11ths and 13ths.

More importantly, I could see how to manipulate the forms, how to create. The first time Mike got me hooked on the guitar, the second time on music.

I've been inspired by Mike while designing my Intro to Programming course. Mike let me wander and stumble into music theory on my own, unlike Old Smokey, who tried to make me start there.

The current state of programming instruction seems to want to force students to learn the scientific side of programming first, when students are really motivated by the art. People get excited about programming because they want to express themselves, to communicate with others.

No doubt: theory, technique and technology are super important in both music and programming. Teaching is not the same as music and programming though. Great practitioners are not always great teachers.

Teaching is a form of service where the teacher puts the desires of the student ahead of their own.

The programming community has a concept called "10x". This concept is somewhat controversial. Allegedly, some programmers are ten times more productive than others.

I say "allegedly" because the quantitative part of the claim can't be backed up.There's no universal, objective metric on which all programmers can be compared.

Many metrics exist, but they all have limitations. People used to talk about lines of code (LOC). Bill Gates had a sick burn for that one: "Measuring programming by LOC is like measuring airplanes based on weight." There's bug density, the number of bugs per LOC. Bugs can be distorted by those skilled at social manipulation (if I add some code, and that change exposes an unhandled case in lines you wrote, whose "fault" is it?). Agile has a concept called velocity, but it can't be compared across teams. And so forth.

I'm not claiming the concept is invalid. Everyone who's worked in the industry for a while has a "short list" of people they'd really like to work with again.

These are the 10xers. They're just not measurable quantitatively.

Sometimes 10xers are consensus builders and obstacle removers. They attend necessary meetings with the business management while other team members are cranking out LOCs. Sometimes they're mentors and cheerleaders, helping junior devs solve frustrating problems elegantly.

The people on my short list have a few things in common. They're focused on producing results, rather than getting credit or assigning blame. They practice intellectual humility – they know good ideas come from anywhere, so they treat everyone with respect regardless of their status. They share, because they know a rising tide lifts all boats. They value clarity and rigor above all else.

They're not necessarily technical prodigies. They have to know enough to Get Things Done, and they have to have a passion for learning and improving. Blazing technical skill is not a guarantee of 10x though. "Brilliant jerks" can be negative-xers: their toxic tendencies poison a team's code at a greater rate than if they weren't there.

There's a short way to say all this: programming is an art more than a science. 10x programmers practice their art with ten times the love.

You'll never be a truly great programmer without love in your heart.

Here's a lighthearted secret, my favorite question to ask people:

What's your earliest memory of hearing music?

Not your first album or concert, but the first time you remember hearing anything.

The question fascinates me because it's casual, on the level of a party icebreaker. And yet, it's hella personal. You get a fleeting glimpse into another human's psyche. People almost always answer with not just the literal information, but also the circumstances, the surroundings.

The other thing that fascinates me is how often people turn it around, and ask it back at me.

Last year, I went to see the Messthetics, a punk-jazz fusion band. The bassist and drummer are Joe Lally and Brendan Canty, from the legendary indie/post punk band Fugazi.

After their set, the crowd went nuts, and they came back for an encore… except the guitarist, Anthony Pirog, had gone to the bathroom. Brendan got on the mic, thanked the crowd, made some remarks, and then there was an awkward silence.

"Does anyone have any questions?" he asked. I didn't hesitate for a second before shouting out my favorite.

He was tickled. He talked about his dad, a jazz guy, his memory of LPs of all the classic big band stuff, Count Basie, Ellington.

"What about you?" he shot back.

My grandma had an 8-track player in her car with two cartridges: The Mills Brothers and Willie Nelson. But we never listened to Willie. I remember driving from the Pacific coast, past Grays Harbor, up into the Olympic Rain Forest, bathed in the luxurious harmonies of "Besame Mucho" and "Moon River".

What about you?