Software Engineer
Grad School and the Slow March to Senior
June 09, 2021

2020. Let's not do that again.

It's been a wild run. I've worked in software for over three years now, for two companies doing wildly different things. 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 frontend developer, and decided to jump a little earlier back to school, convinced that there was more to learn. I loved the magic of computers, of having them do thousands of things a second,

I ended up pursuing my Master's to help with the elusive imposter syndrome, and got in at Northeastern here in Boston. It's a top 50 school apparently, but I had never heard of it before moving to the Northeast. But so far, I am enjoying my classes, and some brilliant people both teach and attend here, so overall it was a good move.

It did make me realize a few things however, as I work with folks of differing professional experiences, from those who have only been students, to those older than me who are mid-thirties and are looking to expand their professional horizons a bit, or even making the swap in to software for the first time.


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 write this down.)

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! There are times to admit you need an expert, and there are times where you are expected to grow into being that expert, and of the two, most often it's option B that is looked for.

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. Start to finish, the entire interview process took a single hour. No technical, just a brief history. A problem was laid down, and I said I could do it.

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 feels like it was 2018 when I started playing with rust, I blinked, and now it's a language supported on AWS and I will be interning there in the summer of 2022. 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 26 year old trying to, please, free that memory leak in C so that they can go to bed.

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.

So this is my life for a while. Juggling school and work. A wife and two cats, and it's a good life. I'm excited to see what comes next, even if I've had to put some of my friendships and pet projects on hold for a while. My blog sits on a pretty obscure corner of the net, and maybe has 30 or 40 visitors a day, mostly for some of my niche solutions (looking at you, gatsby and raygun), so it's a bit sad that I haven't added anything since last November.

But 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?