My Journey to Become a Staff Software Engineer

This week, I begin my new position at Widen as a staff software engineer with a focus on JavaScript engineering and developer experience. As I reflected on my career journey and what I learned to make it to this point, I wanted to share my journey and learnings to help other developers advance their careers and become better software engineers. In this article, I’ll outline the 9 most important lessons I learned in the last 5 years I’ve spent as a software engineer.

Try things out

One of the best ways to learn something is just trying it out to see what you learn. So much of what I have learned is a result of experimenting with new languages and frameworks; trying new ways of architecting applications; and taking inspiration from other developers and applying it to your own projects. The key here is “trying”. You can learn so much if you give things a try, even if you decide you didn’t like it and you throw it away. I’ve started so many projects and never completed them because completing them wasn’t the point, rather I was having fun trying new approaches to problems that I’ve solved many times to see if I can find a better way.

Read documentation

It often shocks me how often I see engineers asking questions or failing to understand concepts when there are so many amazing sources of documentation that clearly explain these things. You can learn so much by reading documentation, even if you aren’t looking for a specific answer to a question. In fact, this is where some of the best learnings come as you discover better ways of doing something that you may not have known were possible!

Now, I know what you are thinking, reading documentation sounds boring. That can certainly be the case, so set yourself small and attainable goals so you don’t burn out from reading too much documentation. For the past year, I’ve set a goal to read one page of documentation (or 5 minutes worth) every workday. Five minutes is such a small commitment, but you’d be surprised how much documentation you can read in a year when you do it every day!

Get good at Google

This might sound silly, especially when many companies (including mine) don’t allow using Google during coding interviews, but learning how to research problems is a very important skill to becoming a more effective engineer. I frequently see junior-level developers who when faced with a problem they can’t figure out, will quickly go to a more experienced engineer to ask why their code isn’t working.

While I always encourage reaching out to more experienced developers for help, overusing those resources can do two things. First, it limits the learning potential as getting a quick answer is quickly forgotten while taking the time to research a problem is often better retained. Second, if you overload senior engineers with questions, they will eventually get frustrated that you aren’t taking the time yourself to research the issue. Senior engineers want to see junior engineers grow, and learning how to research and discover solutions is one of the foremost ways you can do this.

To be clear, I’m not suggesting that you don’t ask any questions to senior engineers, rather I’m suggesting to spend more time learning and researching on your own before you ask questions. There will always be those tough questions that you just can’t figure out, and that’s a great time to get some help from a more experienced engineer. Eventually, when you become the senior engineer, people will be asking you questions and you may no longer have a more senior engineer to lean on, so practice these skills now!

Teach what you learn

As you learn and grow as a software engineer, one of the best ways to reinforce and deepen your knowledge is by teaching others what you have learned. This is not anything new that other people haven’t already figured out, but it certainly is true. When I am preparing to teach a concept, even if it is a simple Slack message to my teammates, it introduces an opportunity for me to ensure my knowledge of the subject is complete and accurate. The last thing I want to do is make and spread false claims or information, so as a result teaching becomes an opportunity to ensure my knowledge is accurate, which often brings with it new information I may not have known before.

Keep in mind, teaching doesn’t need to be a lecture in front of your whole engineering department at work. In fact, it doesn’t even have to be a speech, it can be a simple Slack message with a new tip you learned or a mention of a more efficient process on a Zoom call. These methods of teaching require far less preparation while still resulting in deepening your knowledge and helping your coworkers to also improve their skills.

Relentlessly improve efficiency

As you advance to higher levels of software engineering, you will solve more complex problems that require more time and mental energy. As you do, you will be limited by two factors: how quickly you can develop solutions to these problems and how quickly you can implement these solutions. Improving the efficiency of developing solutions generally comes with time and experience making it more difficult to artificially speed up, but the opposite is true of improving the efficiency of implementing solutions.

While certainly not the only factor in efficiency, how you type and your typing speed are important factors to efficiency. While software engineers do not simply type for 8 hours straight every day, we do type a lot, so improving your typing skills will have a positive impact on your overall efficiency. Not only that, but if you improve not only your typing speed but also your typing method you will find yourself wasting less mental energy thinking about typing, and instead you can use that energy to think about the problem you are trying to solve.

There are so many other ways to improve efficiency, but rather than making this section huge, here are some of my top tips.

Learn keyboard shortcuts to reduce time wasted moving between your mouse and keyboard.
Prefer CLIs over GUIs. While GUIs are nicer to look at and use, CLIs are often more efficient. For example, with some configuration, I can manage my Git repositories far quicker via the command line than I can via VS Code’s built-in Git client.
Automate as much as you can. Setup a GitHub action to automatically update dependencies every other week, create lint rules to enforce coding standards, or create recurring reminders of common tasks. Anything you can do to reduce what you have to remember and do will improve your efficiency.
For macOS users, replace Spotlight with Raycast or Alfred which both provide more functionality and offer means of customizing with extensions or workflows to automate common tasks.

Chase your passion

The world of software engineering is vast and varied. You can dive into low-level programming with Rust and C, data science with Python and R, web application development with JavaScript and TypeScript, and so many more areas. Due to the wide breadth of the space, it is not feasible to truly excel in every area and so it is important to specialize in a subset of the overall field based on what you are passionate about. For me, that is web JavaScript engineering and developer experience, but what is it for you?

As you grow, explore different areas to find where your passion lies so you can hone your skills and find more enjoyment in what you do every day. Don’t just pick the most loved language on the StackOverflow annual survey or the language that pays the most, find what you love doing, and do that. If possible, use time outside of work to build side projects either to explore new technologies or deepen your knowledge of existing technologies you use.

Stay humble

The more experience you get as a software engineer, the easier it will become to be prideful of your knowledge, position, experience, salary, you name it. Fight this and stay humble. Pride will not only cause you to lose respect from your coworkers, which is vitally important as a senior engineer and a leader, but it will also stunt your continued growth and learning. If you think you have it all figured out and know everything you need to know, you will stop learning and stagnate at your current level of knowledge. However, if you remain humble, and remember that not only do you have much to learn but also that every one of your coworkers, regardless of seniority, can teach you something, you will unlock the door to continued growth and learning.

Embrace your team’s norms

Since starting at Widen 3 years ago, I have moved around to different teams quite a bit. During some of the earlier transitions, I had a tendency to come to the team making all sorts of suggestions based on “what I did on my other team” or “what I did at my last job”. While suggestions like this are not necessarily bad, they make it significantly more difficult to build respect with your team as they see your suggestions as a challenge to how they work, what they have built, etc. This can cause others on the team to quickly become defensive rather than being open to your ideas.

What I’ve found to be much more effective is to embrace the norms of a team when joining them. This allows you to more easily see why they do what they do including the benefits of their process and approaches. As you embrace your team’s norms, you will gain their respect far quicker which in turn will give you the ability to suggest improvements that will likely be taken much better by your team. Not only that, but often you will find that some of the things that were so important when you first joined might not be as important as you think after spending a little time on your new team.

Challenge the status quo

The final lesson I’ll share in this article is to challenge the status quo. Being a highly effective software engineer involves challenging processes and decisions rather than blindly following the direction set by others. While this may sound contrary to my last point and very rebellious, when done properly, it can have a great positive impact. The key is knowing what to challenge. For example, at my work, UX decisions are something I often challenge. Asking why a design was created the way it was, suggesting simpler alternatives, or explaining technical reasons why a design should be reviewed. Be careful though, as your goal should not be to challenge for the sake of challenge, rather your goal should be to make the best possible software for your customers. If you are careful in how you challenge the status quo, you will likely find that others on your team appreciate your challenges and feedback.

Thanks for reading! I hope you have found this article helpful and if you have any comments, feel free to share them with me on Twitter or GitHub!