new years reflections

While I consumed a great deal of internet advice throughout my first year as a software engineer, I don’t think that anything could of prepared me. It was full of very high peaks as well as valleys where I questioned my role in the industry. Despite the challenges, there’s nothing really that compares to the rush when something you’ve built solves a problem, and I’m so glad to be here. As an exercise in reflection, I thought I’d jot down a few more internet advice points that I learned along the way.

You will need to get comfortable with your brain feeling like the jello that it is.

During my first year of programming full-time, I learned an entirely new backend programming language, and have started learning the patterns of software engineering. There were times that I would go home, and I felt my brain pulsing underneath my skull like a TV set to static.

I felt like I was too stupid to get the concept I was learning because it didn’t come immediately.

But whatever its been that I’ve not understood immediately, whether it be interfaces, or HTTP handlers, I’ve found that it just needs a moment to simmer before I’m able to use the concept with confidence. I’m more prepared to feel like this without getting down on myself: maybe later on in my career, there will be less volume of new material, and I’ll have the pathways better set up in my brain to gain the new information with confidence more quickly. But if there are concepts that don’t hurt your skull every once in a while, that probably means you’re not learning as much as you did before.

People care much more about what you’re excited to be working on than your credentials.

Coming from University, I was taught that what degree you hold, and what position your name is in in the author attributions were what people were interested in. Oh you have a masters rather than a bachelors? Impressive. I’ve found that in tech that this isn’t the case. When entering social situations, don’t be insecure due to your biology degree or not having a computer until you were sixteen, because they want to hear about what you’re currently doing, or want to know more about.

Being a junior engineer has advantages.

When you’re a junior engineer, people expect you not to know things. Use the opportunity to leverage your lack of time in the field and learn to ask extremely good questions. Being obviously inexperienced shields you somewhat from the people who think questions are a sign of weakness (or even worse: an attack on their knowledge), and also frees you to ask more questions now, so you’re not left wondering with holes in your knowledge later on in your career. Asking extremely pointed, direct questions is critical to perform on a team, for your technical growth, and also communicates that you are involved and understand the task.

Senior Engineers are extremely good at guessing.

In a previous life while I was in college for structural engineering, my professors would sometimes pick a coefficient for, say, friction, and continue on with the problem in a way where the correct variable for coefficient was critical for the equation to behave in a certain way. This was confusing to me, and I would ask how they knew that number would work. They seemed to just pull this out of the sky. It turns out that if you do something enough times, you develop what’s called engineering intuition. Sometimes I would have to develop this for long structural design tests, because the time was too short to make the wrong call – you had a gut feeling for a decision, and you don’t quite know why you choose it at the time. The same holds true for software engineering, because sometimes the problem is too big to really think about in a linear fashion, but you have a feeling that something may work. This doesn’t work out so well as a junior engineer. Sometimes you run around in circles for hours until you finally put the pieces together. The neural pathways that you build as an software engineer throughout your career are mission critical in a way I don’t think gets enough press.

The people who take themselves too seriously don’t know as much as the people who are able to admit ignorance.

One of my friends was studying for his qualifying exams to get into a PhD program a while ago, and it was expressly agreed that he would get to a problem while at a board in front of several distinguished professors, and it would be expected that he would be able to determine that the solution couldn’t be reached with the given information, or that his knowledge was too limited to make an educated conclusion. They teach this because it’s extremely dangerous when someone cannot admit limited knowledge because of the potential effects on a project if their incorrect assumption is treated as the final truth, or limited questioning leads to errors.

When I first entered the industry, I assumed the people who postured the most and used the “correct” terms and acronyms that I didn’t know were leagues above where I was, and it would take years to get to that place. In reality, they’re hiding behind key terms in front of people they don’t know because they’re afraid to look directly at what they don’t know. It’s really just imposter syndrome behind a mask.

Not all of the tech community takes themselves too seriously.

An aspect that I was delighted to learn about the community is that there are many engineers and designers who are able to make fun of themselves, and the industry at large while also achieving high-ranking positions. There’s a certain expectation as a junior engineer entering the industry that you have to be extremely intense and opinionated. I’ve never been very good at overselling myself or “posturing” to appear like I am some sort of technical wizard. I love to write code, and I love that there are self-aware people that wear Allbirds but laugh at themselves all the same.