Notes from Laurie Voss’ “Stuff everybody knows (except you)” talk from Tampa Bay Startup Week, part 1 : Global Nerdy

For those who missed npm COO Laurie Voss’ excellent talk at Tampa Bay Startup Week, Stuff Everybody Knows (except you), I took notes. Regular readers of this blog will know that when I take notes, I really take notes.

Laurie’s presentation ran for 1 hour and 48 minutes, not counting the Q&A session, so my notes will come in installments. Here’s the first one…

The images are a mix of Laurie’s slides, with some selections of my own.

Intro

This is the 28th time I’ve given this talk
If you’re a web developer, this talk is for you!
I’m the COO of npm (which involves lots of yelling at lawyers and accountants), but what I really am is a web developer
I started web development at 16, and I’ve been doing it for 22 years
The purpose of this talk is to fill a gap that exists when talking about web development, especially with new developers
We always talk about the new, exciting stuff
However, there’s stuff from 20 years ago that we agreed was a good idea, and that we still agree is a good idea, and if you’ve been developing since then, you internalized that stuff. If you’ve been around that long, you just know it.
How do you know that stuff if you just started three years ago?
This talk is about all that stuff that we agreed was good, true and evergreen 20 years ago, and you should still know.
The reason that this talk is called Stuff that Everyone Knows (Except You), because no one probably told you this stuff.
Two hours is a long time, but not long enough to be a complete tutorial. It’s an index of things you should look up.

A disclaimer: This is a ton of opinions, glued together and presented as facts. I have reasons and experience that leads me to think these things.
It’s been refined over 27 versions – stuff that didn’t land got excised.
Keep in mind that I could still be wrong. That brings us to…

You know nothing

There’s something called the Dunning-Kruger effect.
Dunning and Kruger studied how good people were at stuff vs. how good they thought they were at stuff vs. how good they thought other people were at stuff.
They gave people basic tasks that were easily to quantify by performance and discovered interesting things about the people in the top and bottom quartiles:
The top quartile were great at what they did, but they think they’re about average.
The top quartile are susceptible to Impostor syndrome, and it makes them vulnerable to arrogant jerks, especially people whose arrogance comes from prejudice.

Impostor syndrome lets white guys run roughshod over the rest of us.
The bottom quartile is “the really dangerous shit”. They’re terrible at stuff, but don’t know it. They also think they’re above average.
They’re also terrible at estimating how good other people are. They don’t overestimate or underestimate; they’re just random number generators.
They’re like that because they have no idea what good and bad look like:
- If they knew what bad looked like, they’d know they were bad.
- If they knew what good looked like, they’d know how to get better.
- They’re the kind who set the cake on fire, look at it, and go “I guess that’s baking.”
The real problem is that they don’t improve until a neutral outsider says “That’s bad. Let me help.”
Things like boot camps and conferences help you emerge from bottom quartile.
You know you’ve emerged from the bottom quartile and realize “I’m so dumb! There’s so much stuff I don’t know!”

The problem is that if you think you’re pretty good, you’re either pretty good — or the worst, unless you can find a good outside impartial observer.
It’s very hard to find a good impartial observer.
In general, when estimating your skill, be humble, but don’t take any shit.

Automate everything

Tasks that take a small amount of time but do often will eat up surprisingly gigantic chunks your life.
This was brought to my attention by this xkcd comic…

…but Randall Munroe, who writes xkcd, doesn’t have a real job, so he doesn’t know how real jobs work.
This is my version, which is based on an actual working day over the course of a year:

Think of a task that you do every day, and suppose it take you an hour a day. If you’re a programmer or information worker today, that task is probably typing — you probably spend 8 hours a day doing that.
If you type at 30 words per minute (the speed of a beginning typist) and speed it up to 40 words per minute, you’ll save an hour a day. Over the course of a year that savings becomes 1.5 months.
If you had a startup that got a bunch of money that made up 12 months of runway and you were a slow typist, you could spend the first month doing nothing but taking typing classes, and you’d still be better off, because the resulting time savings from being able to type faster would give you two weeks more runway.

Master the Unix command line — you have to live there; it’s where we deploy web sites. You have to be great at the command line; it can’t be someplace you go because you have to.
You have to know how bash and grep work, and if you can, learn how find, sed, and awk and all those other weird utilities work. Those are where you save time, where you put together little five-line scripts that take you from a 15-second task to a 1-second one.
There’s this myth of the 10x programmer — there’s no such thing. Everyone programs at the same speed; what a 10x programmer is someone who does only programming by automating away everything else in their job. They appear more productive.

Pick a text editor and master it

It doesn’t really matter which text editor you use: pick one and become really, really good at it.
IDEs are fine; don’t listen to people who tell you that vim is the only way.
Don’t switch editors all the time, and don’t remap your keyboard to Dvorak. The act of switching is what will destroy your productivity.
The people who are astonishingly productive at vim are like that because they’ve been programming in it for 30 years, even though vim is one of the worst pieces of software we’ve ever put together.

Version control: git or GTFO

There are lots of version control systems out there, but git’s the only one that matters.
git is how software is made these days. It’s how we collaborate, test, debug, and deploy.
You need effortless comfort with git as you do with typing. You need to be able to branch, merge, squash, and do all the weird things that people do with it.

Also in this series

Part 2