The Day I Became A Software Engineer

I’ve used software almost all my life. A single mindset shift changed my entire attitude to software. It turned me from a software user into a software engineer. It took me 30 years. I’d like to share that day with you.

When I was 10, I was playing Space Cadet Pinball and Mario Teaches Typing on the shared family computer. I became a software user. Not a software engineer.

When I was 14, my entire friend group found ICQ. I discovered MUDs and spent way too much time online. I became an Internet user. Not a software engineer.

When I was 18, I helped run battalion logistics in the Army. My unit tracked everything in Excel, and it became my job to output accurate monthly reports and forecasts. I become a business software user. Writing Excel formulas now! Still not a software engineer.

When I was 22, I learned statistics and finance in college. I also ran a student investment fund. My classes used R/S-PLUS, MATLAB, and yes, Excel with a little VBA. I became an academic software user. Writing code for class! But still not a software engineer.

When I was 26, I helped trade billions of dollars’ worth of interest rate swaps, currency derivatives, and eventually stocks. The bank/fund I worked at had software engineers, but they were too busy for little old me. So I had to learn Haskell/Mu, F# and Python to write the stuff I needed. Nothing amazing, mind you, just enough to get by. But I became a quantitative trader. Managing money with code! Yet still not a software engineer.

When I was 30, I burned out of finance, and took a year to decide to learn to code for real. I spent a year completing FreeCodeCamp and Fullstack Academy and got my first dev job at corporate venture. My job title literally said “Software Engineer”! But I was still not a software engineer.

I spent ~30 years as a software user. For 30 years, I would try to do things with software. When I ran into a problem, I looked through support forums. I asked colleagues. I (sometimes) read the manual. If I found nothing, I was done. It wasn’t possible. Next tool, next task, sorry boss. You’ll have to get a Real Software Engineer to figure this out.

I had this mindset even through learning to code. First I was told what to code and how to code, by professors and bosses. FreeCodeCamp did the same thing: write this line here, see that result. It was particularly acute with MeteorJS - if an Atmosphere package didn’t exist, it couldn’t be done. You’ll have to get a Real Software Engineer to build it.

It persisted when I learned React. If I wanted to do X, I would search for “How to Do X with React”. Google wanted me to believe that my problems would be solved if I could type in the magic incantations to summon the right blogpost. That I could ask stupid questions like “What’s the Best __?” absent any context. If something didn’t work, I’d file an issue and wait for the maintainer to fix it. I’d find someone’s hacky workaround, paste it in to my code, and if it works, happily carry on. It’ll be fixed eventually by someone who knows what they’re doing.

I knew how to write tests, but I didn’t believe in them. You could say I wrote tests performatively - on demand, because someone said it was a good idea, because some interviewer was watching, because some user asked for it. In a way, it just mirrored my own attitude to my own code. I knew how to write code, but I just didn’t believe mine was worth anything.

I turned 34 last week. Things are different now.

I don’t recall the exact day I decided to stop being afraid of node_modules. It must have been around June 2018. I had a bug, docs were out of date, and no help was forthcoming. I’d peeked in there before, but it always looked like a mess of junk. But I opened it up, guessed the right place, put in a few console.logs… and figured it out!

I knew the objectively correct answer, because I was looking at the running source code. I could give a solution to my own issue, and contribute a fix. I could make a judgment call on whether this code was adding value. I could apply local fixes, or fork it altogether. I appreciated the separation between app and framework, between developer and platform, between “antipattern” or “best practice” - but equally could make up my own mind whether I agreed with it, once I understood how it worked.

I found I could do this again, and again. It’d be frustrating at times, and I lacked a lot of fundamental knowledge where I’d get stuck. But it worked more often than not. I stopped passing the buck. Taking responsibility for my own code. Thinking for myself. Learning about tradeoffs, and making them. Becoming that person other developers go to when they need help. Writing those docs and blogposts they look for on Google. Always improving my knowledge of how things fundamentally work, by sharing it.

Everything is just layers of abstraction. Made by humans just like me. If I run into a problem, I can search for help. I can write it up. I can View Source. Think through First Principles. I use git for version control and tests to hold the line. With enough time, effort, and mentors, no problem is intractable.

Now I am a software engineer.