5 Lessons from 3 Years as a Software Engineer

I’ve been working in the tech industry for over three years now, and every so often I find myself reflecting on a strech of time, usually a difficult one. More often than not, these reflections give way to a principle or idea, something that I can see with hindsight and apply to my life or career in the future.

Typically I end up talking about these principles when I meet bootcamp students or new developers. They’re typically full of questions about how to approach the job hunt, learning and career in general. Here are what I consider to be the five most important things I’ve learned during the beginning stages of my career.

1. Lean into Discomfort

Learning to code is uncomfortable, and coding for your job is probably even more uncomfortable. Clients, sprints, budgets, production outages…the list goes on. There are a lot of things about being a professional programmer that could be considered stressful.

However, without fail, the times I’ve grown the most as an engineer have been when I’ve been under the most pressure. For example, take earlier this year. I was new in my job and the sole front-end developer on my project. In addition, I was learning to develop using a React/Redux boilerplate, and I had never used Redux before (more on that below).

Needless to say, I felt a ton of pressure. I wanted to deliver a successful project and make a good impression on my colleagues. But, bit by bit, I figured it out. I figured out the things I didn’t know how to do (and there were many) by looking them up, by fiddling around with the code, or by asking colleagues. I struggled, but I succeded. And more importantly, I learned. I learned more in that strech—because of the presure—than I ever had before in a similar time period. As such, I now seek out opportunities to be uncomfortable, because that’s where the real growth happens.

2. Don’t Pigeonhole Yourself

I’ve been in several jobs where my “official” responsibilites didn’t entail areas that I wanted to work in (the backend, for example), so I didn’t think I’d ever get to do them. A former boss challenged my understanding of how this works when he told me, “If you want to be fullstack, then just start calling yourself fullstack.”

A lot of job performance comes down to confidence, and confidence is largely a function of your mentality. If you’re telling yourself “I’m just a front-end developer, I couldn’t possibly do backend,” that will probably be true. I grew up playing tennis, and in tennis if you don’t believe you can win, you probably won’t.

The wisdom of what my boss told me is that if you believe you are something (or can do something), you’re much more likely to become or do that thing. In development, after learning the foundational patterns of a domain (more on that below) the rest of the work often comes down to implementation details. Don’t put yourself in a box if it’s not a box that you want to stay in.

3. Change Jobs (if need be)

My first job was not ideal. Many first jobs are not ideal. It’s a reality of the tech industry (and probably many fields) that the first job is the hardest to get. You’re untested, unproven. As such, there are fewer options.

My first job was for a municipal government. Sixty percent of my time went to maintaining a large Drupal-based intranet site, and the rest to developing random one-off apps with my preferred front-end technologies. Though I took the job with a lot of gratitude and optimism (and am still grateful I had the opportunity), it turned out to be a bit slower-moving than I’d hoped for. (No surprise for anyone that’s familiar with government.)

I was also aware that mentorship and learning from others was going to be a big part of getting better. However, in my first job, it was just me and one other developer, and we were largely siloed in our work. In addition, I wasn’t in love with the tech stack. After a while, it became clear that it was time to leave.

Since the first job is hardest to get, it was much easier to get the next. Most people also find switching jobs to be a good opportunity to negotiate a higher salary. This change worked in my favor, as I went to a company that was more my vibe and at which I could learn from other, more experienced developers. Every time I’ve moved jobs, it’s turned out to have been the right call. Use wisdom, but don’t be afraid to switch jobs.

4. Avoid Mountain-Making / It’s All Patterns

As previously mentioned, I had to learn Redux on the job. And, boy, was I scared to do so.

I had made Redux this big, scary thing in my mind—‘actions, reducers, oh no!’ As a result, I never really got started learning it, and having to do it for work was a great catalyst for finally doing so. But here’s the thing: once I got into it, I realized it wasn’t that big of a deal. This tool that I had made out to be so scary was actually fairly simple.

I’ve had this experience repeated in many other languages, tools and libraries that I’ve learned. Usually, there’s a core set of techniques, rules or patterns and then everything else builds on those. My mantra has become “it’s all patterns.” And once you learn to recognize those patterns, the rest becomes much easier.

Given this experience, I’ve tried to remind myself (though I still struggle with it) that whatever tool I’m intimiated by likely isn’t as scary as I think. I just need to lean into discomfort and learn the basic patterns. My confidence in self-teaching has grown significantly thanks to this discovery.

5. Build Projects (that you care about)

In my last post, I described the careers of two Nobel-prize winning scientists, and how their careers helped me model my approach to side projects. Side projects are a great way to learn, but I think they’re most effective when you’re building something because you want to see it exist in the world, not because you’re trying to check a box or impress a potential employer. Using your spare time to build projects isn’t nearly as fun if you’re only building out of obligation.

Seeing people actually use my software has proven to be an incredible motivation. I think that true motivation encourages you to push through the blockers of getting stuck, not knowing, or having to put in hours outside of work. This is a virtuous circle that helps you to learn more and build even more ambitious projects. That said, in my opinion it all starts with the proper motivation.

Don’t build projects if you don’t want to. But think of how cool it’ll be when you’ve produced something that’s solving real problems in the world.