One Year, Ten Times

I’ve heard this thought in many places, in many forms:

You might have ten years of experience, or you might have one year of experience repeated ten times.

It’s a pithy way of saying that spending a long time doing something doesn’t necessarily mean you’re very good at it.

Reps without evaluation don’t lead to improvement. Practice doesn’t make perfect, necessarily. Practice makes permanent. In order for practice to make us more perfect, we have to practice with better form. When we don’t have good form, we have to look at the difference between where we are and where we could be, take a look at the gap, then cross it.

We cross the gap by practicing with better form than what feels natural to us. Usually, that feels wrong. Uncomfortable. But we grow into it.

Here’s something I suspect: You grow into a work environment in 2-3 years. You figure out that work in that timeframe. And then if you stick around longer than that (barring substantial challenge via new roles or goals) your growth plateaus. You get comfortable. You start coasting. And your experience coasting isn’t nearly as valuable.

Sure, you figured out that stack and that codebase and that team and org and that product. How do I know you can hack it in my world?

And that’s how decades of experience can effectively be a fraction of what they might look like on paper.

The Most Toxic Team Member

“The Foole doth thinke he is wise, but the wiseman knowes himselfe to be a Foole” – Shakespeare

The most toxic person to your team or organization is someone who has stopped learning. Someone who thinks he has learned all he needs. Someone who thinks he’s an expert.

Such a person will not only not take in new information, he will often actively defend himself against new information. Such a person will not listen. His priorities and incentives will not be aligned with those of the organization. The organization needs to learn and needs its people to learn.

But I Already Did That

I wrote a while back about questions to ask of potential employers in interviews. I was mostly pleased with how it turned out. A friend told me he liked it, too. That felt good.

Since then, I’ve seen several articles on the same topic getting attention. (Much more attention.)

It makes me jealous.

But should it?

Why did I write about it? Did I accomplish my goal in writing about it? Don’t I often say that much of the benefit I get from writing is from how it helps organize my thoughts? Do I need to be the single source of expertise on this topic? Wasn’t it just my opinion that I was publishing? Can’t I get something out of each and every other article I see on this topic?

Small Commits

Large commits are great when you don’t want people to really review your code. As commits get larger, they start to become difficult for a reviewer to load into their brain. To review a large commit, you have to do a full, deep context switch. You have to set aside time. If you get interrupted, you lose some context and have to get it back. It’s hard work.

When you make a small commit, on the other hand, the change you’re making to the code is small, by definition. And because the change is small, it’s easy for someone else to look at it and evaluate it. You get a good review, an actual review.

Small commits make life a little saner when merge conflicts come up, too.

Highlights

Lately I’ve been reviewing my highlights from non-fiction Kindle books I read years ago.

I can often review a whole book in 15 minutes and find something that feels fresh and useful today. (Assuming past-Josh noticed some interesting stuff. He wasn’t always the brightest bulb in the box.)

So not only are highlights a good tool for focusing as you read and reviewing when you’re done; they can make a very good precis for future-you when you’ve inevitably forgotten half of what you hoped to absorb from a text.

A Different Room

It’s an old line: “When you’re the smartest person in the room, find a different room.”

I get it. You can learn a lot from people who know more than you about the work. But let’s think a little deeper about this.

Yes, when you work with folks who’re better than you at something, they can bring your game up. And the reverse is scary: the notion that working with people who’re less good than you might bring your game down.

But also: When you work with people who are not as good as you, maybe you’ll bring them up. And when you work with people who’re better than you, maybe you’ll bring them down.

Editing

“Try to leave out the part that readers tend to skip.” – Elmore Leonard

If you’re writing for other people to read, the activity you should be doing more than anything else is editing.

Editing is crafting.

When I edit, I consider how my thoughts will come across as someone else reads them. Things go away. They move around. Words get replaced. Specifics turn into generalizations, or vice versa. Examples turn into principles or patterns, or vice versa. “I” turns into “you”, or vice versa. Every word should have a purpose. Any that doesn’t should be tossed.

When I edit, I ask questions. What if the reader already knows this? Will repeating it be boring? What if the reader doesn’t know this? Will nixing it be confusing? Who is my likely reader, anyway? What’s my goal here? Is this a tangent? But is it relevant? Is this funny? Should it be? Where should I start? Where should I stop?

When I don’t edit, I regret it. I feel good when a thousand-word post just comes right out, but whenever I publish one of those without at least sleeping on it, I come back and find a thing or two I should probably have tweaked.

Convenience Vs Control

iOS wants control. When you give iOS control, it does a pretty good job, and you get convenience. But your options are constrained, to some degree. Some people bristle at this. Some outright hate it.

Android wants you to have control. You get way more options. Lots more knobs to fiddle with. But when you have a lot of control, you have to spend time and energy learning to use the control.

I’m an iOS user, squarely in the “don’t make me think” camp when it comes to my mobile device OS. But not in all things. For instance, I often prefer to pay the considerable time and effort cost of cooking from scratch so that I can control what’s in my food, as opposed to zapping frozen convenience foods full of things I maybe don’t want (and maybe can’t pronounce).

Generally, I think a balance can be struck. Too much control probably leads to diminishing returns on your time and effort. Too little control might mean you miss out on the low-hanging fruit — cheap and easy ways to make your life better.

When Do You Know Enough To Teach?

Q: When do you have enough experience with a thing to go out and share that you’ve learned with the world?

A: As soon as you have any experience.

(But it might be a good idea to anticipate doing some learning in the process.)

Paycheck To Paycheck

When you live paycheck to paycheck, a little bit of turbulence can have big effects. You can’t afford to miss a single check. That makes you dependent. It limits your freedom.

Not living paycheck to paycheck means resilience. You’re not afraid of losing a particular job. You can survive it. This helps with negotiating. It means you’re more likely to speak your mind. You’re less willing to do dumb things because someone in authority is being stupid. You can say “no”, leave and go find a new thing. You have time, flexibility, independence.

There’s no decoupling your job from your career when you need that next check.