Wait. Who am I?

Don’t worry, not gonna bury the lede.

I’m just a guy, effecting a career change. Writer to software developer. Not an uncommon transition, from what I can tell.

I’ve had to do a lot of work to pull this job switch off. Learning how to code is just a part of it.

Another part — and I think, an important one — is assuming a new identity. How do I start to think of myself as a “programmer”, instead of a “writer”?

Maybe that sounds fuzzy-wuzzy, or trivial, or vague to you. I would have agreed with you when I first started out. Nine months in, I don’t think so anymore!

Quite a few moments in my career-transition process were way harder than they needed to be, just because I was uncomfortable thinking of myself as a programmer guy:

Processing frustration

Frustration is an essential part of any meaningful work. A solid self-identity, one that lines up with what you’re trying to do, can be the difference between overcoming that frustration, and succumbing to it.

When I, as ‘Writer Matt’, had problems with my day-job as a content writer, it was easy to find my way around them.

Okay, so this piece isn’t gelling quite like you want. It’s okay. You got this. Take a break and come back to it in a little while. You’ll figure out what to do.

Contrast that response with how I met my coding problems. When Writer Matt hit a nasty bug, it felt borderline catastrophic. The stories I told myself about these (pretty minor, in retrospect) failures were both cruel and untrue.

You don’t get this stuff, Matt. And you’ll never get it. You’re not a programmer! You’re a right-brained, wooly-headed, artsy-fartsy, absent-minded, writer. Disgusting!

Not good for my emotional wellebing, or my performance.

As I’ve spent more time coding, I gradually learned to take a healthier attitude toward my mistakes.

But yeesh, that self-flagellation was painful.

Accepting ‘limitations’

Independently learning to code is the ultimate greenfield problem.

What should you focus on as a learner? What should you do with your skills?

If you have no teacher, nobody’s answering those questions for you. You have to do it for yourself.

And because I wasn’t thinking of myself as a programmer, I came up with really constrained, restrictive answers.

Build my own projects? Naaaah, I’m not a programmer. I’ll just follow this FreeCodeCamp tutorial.

Make a new portfolio? I’ll stick to WordPress, thank you!

At every opportunity, I shied away from potential challenges, because I didn’t think I was “ready.”

I can’t even articulate what I was afraid of. What are the stakes of failure, on an amateur, DIY software project? That it won’t work? That you’ll get frustrated? Who cares!

Now I know that there is no “ready”, before you get to work on something. The only way you get “ready” it to jump in.

Shrinking away

I used to be a remorseless copy + paster.

Any problem I faced, my first step was to visit Stack Overflow, and see if someone had solved it for me. Copy + paste = done.

It left me with projects that I’d “built”, but didn’t understand. The pasted code was opaque to me. If it broke, I couldn’t fix it.

That’s no way to get better at software.

I realized my Get Confused –> Visit Stack Overflow methodology wasn’t an approach to problem-solving — it was an approach to avoid problem solving.

It was flinching. A way to disengage with what was in front of me.

A little change made this better.

These days, when I run into an issue, instead of jumping right to Stack Overflow (or whatever else Google spits up at me), I make documentation my first port-of-call.

It’s a small thing, but it has revolutionized the way I work.

Reading the documentation means I grok the tools I’m working with, I write my own code, and I know how to fix it, and how modify when circumstances change.

It also means I enjoy the process a lot more.

Which is ultimately what a programmer does, right?