2020. Let’s not do that again

It’s been a wild run. After growing my hair out at the start of the quarantine, it now reaches mid-back, and the end is finally in sight.

I left my last job, and was introduced to the market for the first time. (Imagine my surprise as to when I realized that interviewing was an actual skill that needed to be learned!)

I wrestled with imposter syndrome after several years of being a successful developer, and decided to jump a little earlier back to school, convinced that there was more to learn.

The pandemic wiped out the need to take the GRE, and while I hadn’t been concerned about that (Thank you, double major in STEM and a social science), it was one less hurdle to jump whenever that time came. So I took the leap, applied to Northeastern University, and got in to a good school. The people are very friendly, the professors are by and large very knowledgeable and talented, and the campus is great, if a bit nostalgic by this point now that I’m reaching the later stages of my 20’s. It certainly deserves it’s slot as one of the best Comp Sci schools, and overall, I’m happy I took the leap.

It did make me realize a few things however.

like…

Everybody is faking it until they make it.

And if there is anything reassuring about this year, it’s that.

Because software is hard. It is.

It’s hard to get started, when you have absolutely no idea on the tools that exist, so everything is a monumental task. Then it’s hard to get the design patterns down. There’s 15 or so popular ones, with their own trade-offs, but you know, learning those trade-offs take experience, and experience requires using them when you likely haven’t before (which, see before, is hard). And after all that, it’s hard to optimize. I once wrote an answer to a leetcode problem, and I was so proud of myself that I figured out the tricky solution in under five minutes, only to realize, that my N^2 solution absolutely shattered when handled an input with a length of 5000 items.

And then above it all, I believe that programmers are the ones who are expected to have that quick solution. That breadth of knowledge. And in a realm of layers upon layers of abstraction, that takes time to learn.

So what do programmers do? What can we do? (Spoiler alert, it’s kind of faux paus to actually publish this out loud.)

We fake it.

That’s right. We absolutely fake it until we make it, for years, while we build up those skills. Because nobody want’s the engineer to walk in and be given a problem to solve, and everybody looks to him, and then they say, “Well gee, I rightly don’t know. This is beyond my abilities.” Could you imagine? Of course it’s a difficult job! That’s why they hired you!

I recently had the delightful experience with starting to work for a start-up, and was brought on by the CTO, a man who had been programming since 1960. 1960. He asked if I was interested, we shared stories, and then he asked me to draft up a portion of the software I would be writing for them, using python to write for windows. Something I had never done, but thought I could do. And he nodded, and told me to tell him when I had an update.

I think that’s why I like this job so much. This is a man who used to write assembly for a living. He has actual war stories of writing software for things I couldn’t imagine doing. And that’s ok. Because I’m working now in languages that weren’t invented until 20 years after he started working professionally. What a blessing, to be doing dynamic work in an industry that didn’t exist 100 years ago. There is the joke that every time a developer sneezes, a new JavaScript framework is released. And I think that’s really neat.

The entire field is moving so quickly. Yesterday was 2018 when I started playing with rust, I blinked, and now it’s a language supported on AWS. Everyone is just holding on by their nails, and when someone asks them a question that they have no idea for, they go out and solve it. Fake it until you make it is not just the industry motto, it’s pretty much the golden standard. It sounds bad on the surface, but the actual reality is that without the first part, I’m not sure if we would be anywhere close to where we are today.

I bring this up, because now I’ve had the chance to go back and work alongside other students again, and a lot of them don’t have the same actual work experience that I do. And it’s been a lot of fun watching them learn, and struggle, and fight through the same hurdles that I now realize that nearly all developers go through, whether that is a 13 year old who is learning basic for the first time, or a 21 year old trying to, please, free that memory leak in C so that they can go to bed, or the 30 year old who is pushing to finish a major feature for an entire platform.

We all go through the same things. Learn the language a bit. Learn the tools a bit later. And then, and this might just be the hardest part, to actually build dynamic, useful tools with those skills. A person might be taught how to swing a hammer and put up a door, but it is entirely a different beast to building a house.

There is more to learn, and I’m excited to go out and find it.

One last note. Exiting VIM isn’t that hard. Escape. Shift colon. wq. enter. Why has everyone made such a big deal out of this?