Five Years Into My Career

This one is going to be pretty straightforward. I am now five years into my career as a software engineer, and there are some lessons I have learned that I think could benefit others who are entering this field or are only a few years in.

My Background

Before we go further into some of the lessons I've learned, I want to bring you up to speed on how I got here. I have been playing video games and building computers since I was seven or eight years old. I took my first coding class in high school, a semester class learning Java, I believe. When I got to college, I couldn't decide what I wanted to do and ended up graduating with a degree in business administration. A couple of years into the job force, I missed coding and thought I'd give that a shot since I wasn't super into my data entry job at a flooring company. I didn't have the ability at that time to go back to college for a computer science degree, so I went the route of a twenty-four-week coding bootcamp. Over the course of those weeks, I gained a working understanding of how to create websites that I would describe, looking back, as the bare minimum.

I spent the next year or so trying to teach myself the things that the bootcamp did not. They taught me how, but we didn't have the time to learn why. Seven months after I graduated from the bootcamp, I got my first job as a software engineer, working at a company local to Kansas City. My daily work involved using HTML, CSS, and JavaScript to build small improvements to our external website. I worked under a senior engineer, alongside a small team of five. I continued to try to learn and grow as I went, but I got comfortable quickly with what I was doing. This leads to the first of the lessons I have learned in my five years as a developer.

The Why Actually Matters

The first lesson I want to discuss is that the why actually matters. I was comfortable in my first two years just knowing that I knew how to build a website. I knew how to make it look good. I knew how to make it do stuff and how to allow users to interact with my websites. I knew that if I copied in some code, I could connect my website to a database. But as I grew more comfortable with how I could accomplish these things, I realized that I didn't know why my code did certain things. I didn't know how the internet worked or what JavaScript was doing under the hood. I didn't understand what happened when people landed on my website. I knew what they'd see and what they'd be able to do, but I did not know what was actually happening. Upon this realization, I came to the decision that I didn't care. I didn't care that I didn't understand why. I knew how, and that was enough to get me a good job to pay the bills.

Ignorance was bliss, but it was short-lived. As I got further into different languages, joined different communities, and took in different content in the programming realm, I realized quickly that at my current trajectory, my skills and abilities were permanently capped by my lack of understanding of why. I learned that eventually, the why and the how to do certain things were tied closely together. This was a hard lesson, but I realized that at that moment in time, I was a bad programmer. But that's okay because everybody is bad when they start. But I was capping my growth by refusing to dive into the why. In order to get good, you have to realize first that you are bad. And that's why this lesson was so vital to learn. So I started learning why. Instead of watching tutorial videos only, I started reading documentation. Instead of only copying and pasting, I started writing stuff on my own, failing and growing the whole way. Instead of thinking that the understanding of data structures and algorithms was not relevant to actually doing the job, I started pursuing an understanding of computer science.

I still have a long way to go. I still have understanding to build up. But I'm better today than I was yesterday. I know more about the why now than I did before, and that has made me a better programmer. Turns out, understanding how a computer handles memory does, in fact, allow you to create better software.

New Does Not Mean Best

The second lesson is that new stuff is not always better. Now, this one can be applied outside of software and our jobs, but I'm going to stick to that context to the best of my ability.

I have struggled my whole adult life with always needing the new thing. I needed the new MacBook, the new iPhone, the new TV, the new car. And that consumeristic attitude bled into my programming. Every couple of hours, a new JavaScript framework comes out. And I would rewrite apps and sites in the new frameworks because it was shiny and new and better. And sometimes, new stuff is just fundamentally better. But I turned into the guy that's always changing my toolsets to use the newest stuff. Because new is always better. Except, it's not. Us web devs are now realizing that client-side heavy single-page applications are not actually always what is best. Sometimes, instead of using React and Redux, several different libraries, and a few UI plugins, we can actually just serve HTML with a simple node server. Now, depending on what you're doing, the full framework solution is needed. But if we always use what's new just for the sake of it, we are going to have a ton of bloated, over-engineered websites that destroy the experience of the user.

The lesson is when new things come out, we should try them. Install the new tool, download the new language, create a todo app with the new framework. Explore the new things, and to call back to the first lesson, maybe even dig into what makes the thing work. But then, make a decision on whether or not to bring that new thing into your toolset based on parameters outside of just the fact that it's new. Decide on those parameters for yourself. Maybe it's speed, memory usage, developer experience. Just don't let your deciding factor be how new something is. Because you can make the same great CLI tool coding on a 10-year-old laptop running Arch Linux that you can on a brand new M3 MacBook Pro. You can make a great personal website using React. But you can make a great personal website using HTMX and Go.

The summary of this lesson is to bring in more parameters to your decision-making on a tool or language than just how new and fancy it is. Because sometimes, Neovim can write your software just as well as VSCode with 234 plugins.

In Conclusion

This got longer than I was expecting, so I'm going to put a few more lessons I've learned into a second post. I hope that these lessons benefited someone.

To the person just learning how to code - it's okay to not know everything. Everyone starts knowing nothing. Just write some code, and understand a little more today than you did yesterday. Enjoy the journey.

To the people who are a few years in - If you're like me, and somewhere between your first lines of code and now, you got complacent and stopped learning, don't feel bad. If you are okay where you are, that's alright. Enjoy the space, and make yourself some good cash. But if you're realizing you want to dig deeper, go after it! Go figure out some things you don't actually know, and learn something.

To the people that have more experience than me - I'd appreciate your input. If you can give advice and criticism without being rude or gatekeeping, please give me that advice. I have so much to learn, and I am always open to those who are paving the path ahead of me sending some wisdom my way.

Thanks for reading!