12 things I learned in my first year as a software engineer

“Fail. Learn. Grow.” — Anonymous

I started my first full time software engineer role at Mistplay a little over 3 years ago, and am now a Team Lead. Since then our engineering group has grown from 4 to 25+, our company from 20 to 150, we’ve been named the 16th fastest growing startup in North America, and we're continuing to hire massively across engineering and data teams here. I learned a lot in my first year as an engineer and would love to share again 2 years later. Here are my top takeaways.

12. Review, review, review

If you’re in between tasks or have time to spare, it’s a great idea to check out what pull requests (PRs) have been posted. You’ll learn how other people work and think, and pick up some best practices while you’re at it. Try to match the style of your company’s senior engineers, and ask questions about their code if you have them. It’s also a nice way to give back to your team by helping catch bugs and speed up the development process as a whole.

“The more that you read, the more things you will know.” — Dr. Seuss

11. Ask Google about best practices

Your code needs to work, but it also needs to be readable, maintainable, and bug-free. Sometimes a method will work functionally, but can cause a memory leak or a crash without proper care. If you’re solving a problem based on your own experience, or using a Stack Overflow solution from 2013, take a few moments to double-check it on Google. This will help you understand if it is actually a best practice solution, or if there are better alternatives.

“The important thing is to not stop questioning” — Albert Einstein

10. Don’t reinvent the wheel

In my first 3 months, I built a tool to do timezone conversions because it was needed for a task I was working on. Of course, this is a common problem that others have already solved. Since then, I now refer to Google to find packages to solve common problems. Using a reputable, well-maintained library when possible saves time and results in sounder, more concise code.

“Code reuse is the Holy Grail of Software Engineering.” — Douglas Crockford

9. Get to know people outside of your team

A great part of working at Mistplay is our weekly team lunches. We also have regular happy hours, game nights, and movie nights where people from all teams hang out. Although all these events are currently virtual, it’s an awesome way to meet people when living in a new city, and also makes working with people from other teams more enjoyable. Generally, it’s just been a great experience getting to know people across the company.

“If you can laugh together, you can work together.” — Robert Orben

8. Make project planning a collaborative process

Mistplay uses agile sprints for project planning, which means that we assign, work on, and review all tasks in two-week cycles. We also vote on how many “story points,” or how much effort, the tasks are worth. This ensures that everyone knows the full details of a project before tasks are assigned, and can provide input regarding how long each task is expected to take. Not only does this spark great discussions, but it also helps your team avoid underestimating workloads. Additionally, knowing details about other peoples’ tasks helps when reviewing PRs.

“Talent wins games, but teamwork and intelligence win championships.” — Michael Jordan

7. Keep your manager/project manager (PM) up to date about your timelines

It can be surprisingly challenging to estimate how long a project will take, especially if the scope changes after you start working on it. Once you start a task, keep estimating in your mind how much longer it will take. If you notice that it is much longer than what you planned for, talk to your manager.

“The single biggest problem in communication is the illusion that it has taken place.“ — George Bernard Shaw

6. Propose alternate ideas to your Product Manager (PM) and designer

Don’t be shy to share your ideas, especially if they could speed up a task or improve the final product. Consider what simplifications would make a given task faster, and talk to your PM about how significant the user impact from those changes would be. Any suggestions that would improve the final product are worth sharing. At a startup, there are only a few people reviewing designs before you implement them — so if the UX/UI feels off to you, go ahead and propose a change before you start.

“We are aware that we are doing something significant. We’re here at the beginning of it and we’re able to shape how it goes.” — Steve Jobs

5. Make short PRs

Bundling everything into one PR might seem like the fastest way to go, but it tends to be better to break things up wherever you can. It’s hard to review a long PR, which means that your reviewers will either start skimming or fixate on minor problems. Try to write clean, modular code, and PR it in small, logical batches. Your reviewers will thank you — and your code will get approved more quickly.

4. Become a master of testing

It’s no secret that testing can be painful — but it doesn’t have to be. For me, the answer to writing tests for our node.js backend was to unit test everything as much as possible, use a mocking library to make API and database calls (or really any function I want) return a consistent value, and then write a minimal set of integration tests to be sure that everything fits together. One key is to write modular unit testable code, so that this all becomes easy to do.

“I’ve known people who have not mastered their tools who are good programmers, but not a tool master who remained a mediocre programmer.” — Kent Beck

3. Get messy with debugging

It doesn’t matter if you’re investigating a bug or building a new feature: you should feel free to take apart the rest of the project to test what you’re working on. You can comment out authentication, disable fraud detection, and add || true to if statements you want to fall into. Deconstructing your code in this way can be much faster than tinkering with a database or user state.

“Move fast and break things.” — Mark Zuckerberg

2. Always. Test. Before. Refactoring

Like any startup that has been lucky enough to experience significant growth in a short period of time, some of our code that handled important functionality was written without tests. During my first year, I unwittingly made a breaking change during a refactor that passed the integration tests — because there weren’t any. A few days and $10,000 worth of damage later, the lesson became clear: always check for tests before refactoring, and add good tests if they are not already there.

“I’m not a great programmer; I’m just a good programmer with great habits” — Martin Fowler

1. Get others to review your ideas early

Before tackling a big feature, write a developer spec and ask a senior dev for feedback. The more detail you go into here, the better your final project will be. Writing a dev spec gives you a blueprint, so that when you’re coding, you don’t have to make decisions about logic or functionality — you can just write clean, modular, beautiful code.

Another benefit of writing a dev spec is that your senior dev can review your ideas and figure out bugs before they are even coded. Ultimately, you’ll end up with a much better final product than if you coded it one way first and then revised after getting PR comments about problems.

“You can use an eraser on the drafting table or a sledgehammer on the construction site” — Frank Lloyd Wright

Thanks for reading! If you are starting out in your career, I hope one or two of these tips will save you a headache!

Written by Ryan Kuck, Team Lead for Software Engineering at Mistplay