"This unplanned experience taught me that if you care about people they will care back, and with just a little bit of encouragement most people will eagerly learn what you need them to know."

Brooke Allen reminding us that there is a vastly better way to learn, to hire, and to build:

https://brookeallen.com/2014/06/14/how-my-life-was-changed-by-caring-about-the-people-i-did-not-hire/

“Because I’ve been lucky enough to work in environments that allow people to really flourish, I’ve seen a lot of people go from unremarkable to amazing … most companies invest pretty much nothing in helping people.” —the awesome Dan Luu.

http://danluu.com/hiring-lemons/

(I *know* this is true, I’ve seen it happen—in others and myself—though now it’s obvious that my Asian tech man privilege meant people were comfortable investing in me.)

I've been thinking a lot about this after finishing Anders Ericsson’s *Peak*, about his research on expert performers (think star soloists, athletes, chessmasters, surgeons, pilots) and how to train them. Ericsson’s team coined the phrase “deliberate practice” to delineate the kind of practice that results in constant improvement of skills (via finding and strengthening mental representations) from ineffective practice, but the key point I’m stuck on is how we CAN’T measure coders’ performance.

The performers Ericsson’s team studies all have either a quantitative criterion for expertise (e.g., chess, sprinting) or well-established qualitative judges (ballet, violin), and deliberate practice for a new field can only be discussed after its criterion is elucidated—practicing without being able to answer “Am I getting better?” is just wishful thinking, and it’s where we are with #programming. HackerRank’s awfulness shows us just how far we are from any kind of clarity on these issues 😟.

Dan Luu in http://danluu.com/hiring-lemons/ is spot on: it’s freaking hard to recognize good coders, and, what's even more damning, some in our industry don't believe that. How on earth can we train, or hire, in such a miserable situation?

Steve Yegge acknowledged these problems, years *before* Ericsson’s book was published 🙃:

"In Bob's view of the world, there are essentially three programmer skill levels: folks learning how to program, folks like Bob who know how to program, and the inevitable whizzes … Bob has no incentive whatsoever to try to improve his skills."

https://sites.google.com/site/steveyegge2/being-the-averagest

This is 2004-vintage Yegge, as loquacious as ever, but the essay describes our industry's corrosive attitudes perfectly. Nothing’s changed.

"Obviously Bob can't compete with people who were kid geniuses, and he shouldn't exert himself unduly on their account. Bob knows everything he needs to know about actual programming. As far as Bob is concerned, he's a programmer, and that's all there is to it. Bob realizes there are technologies, data structures, algorithms and techniques that he knows little to nothing about. But that's OK. He doesn't know them because he doesn't need them for his job." —Steve Yegge, ibid.

Yegge, more than a decade before Ericsson's *Peak*, also foreshadows the deliberate practice difference:

"Most programmers have only a vague notion of how competent they are at what they do for a living … programmers usually are learning new things on the job, but their self-directed study is typically just reinforcing what they're already comfortable with … People stay in their comfort zones."

(Yes I'm still talking about https://sites.google.com/site/steveyegge2/being-the-averagest)

As if that wasn't enough, Yegge was working out a solution, fourteen years ago:

"my primary interest [in] developer training: … Once you get someone to realize that the sum of their skills is about as effective as punch cards and paper-tape, compared to how effective they could be…, the rest is easy. You give 'em some books and set 'em loose. Programmers are a pretty smart bunch, you know, once the blinders are off."

This isn't coder quality criterion, but it does give us a way to improve.

I wrote to Steve Yegge and asked him what books 📚 are good to pull yourself and others out of “the comfy vortex of the Bob Paradox” and he was kind enough to mention:
- algorithms via Skiena's *The Algorithm Design Manual*;
- concurrency, and he asked me for a replacement for Lea’s language-agnostic *Concurrent Programming in Java* ☺️;
- college math needed to understand…
- all the data science and data engineering hot goodness.

Thanks Steve! Tomorrow is #library day.