Hot take: Software engineers should job hop as much as they can during the first five years of their career.
Now I don’t mean that you should change jobs every three months, but I do mean that you will learn a lot more working at a few different companies over the course of five years than you will working at only one.
You should also seek companies that will allow you to grow through internal promotions and stretch assignments. Doing the same thing over and over may make you a specialist in a particular area, but it can easily lead to stagnation if you’re not careful.
When you feel that you’ve outgrown your current company, don’t hesitate to leave. Seek internal opportunities and make your career aspirations known to your manager. But if it becomes clear that there is a misalignment between your goals for your career and your manager’s goals for your career, look elsewhere.
Optimize your career for growth.
I’ve followed this strategy throughout my career, and it’s fun to reflect back on each of my previous roles and what I learned.
I began my career eight years ago at Qualtrics as a product specialist doing tech support. During this time I learned how to be a great troubleshooter. I learned how to solve problems, how to think through issues, and how to find creative workarounds.
Through over 10,000 client interactions, I learned how to write well and how to communicate effectively. I learned how to train and teach and present well. I frequently ran client webinars and training sessions. It was during my first year here that I was introduced to web development.
I had a brief stint on our design team helping to create client’s survey themes. Nothing too fancy here, just including clients’ brand logos, fonts, and colors in templates they would use for their surveys, but it was a great introduction to HTML and CSS. I began to cultivate an appreciation for what makes a great design.
Shortly after that I moved over to our professional services team as a frontend developer working on one-off client requests. These projects lasted anywhere from two days to several months. The variety of the work was astounding.
During this time I learned how to recognize customers’ needs and translate those requirements into code. I learned to look beyond what the customer originally asks for and to dig deep to understand what problem they’re really trying to solve. Oftentimes there is a better or simpler solution to a customer’s problem than they think, and it was up to me to provide that insight.
I learned that simultaneously managing sales work and dev work is an impossible task and that there’s a reason why we specialize in our own fields. I also learned that I enjoy solving technical problems a lot more than I enjoy negotiating pricing or nitpicking legal terms.
After a couple years on our professional services team, I began looking for an internal transfer to a non-customer-facing software engineering role. When it became apparent that this would not be a likely possibility at Qualtrics, I started looking elsewhere. It’s not worth it to stay in a role that doesn’t align with your career aspirations, no matter how great the company is.
And so, after three and a half memorable years at Qualtrics, I left to join Younique.
I started at Younique as a UI developer and left Younique as a senior UI developer. My time here was filled with growth opportunities as well as a healthy amount of culture shock.
The thing about your second job is that the company culture can be very different from your first company’s culture. That’s also the benefit of working at several different companies. At your first company, you don’t know anything different. You don’t really have a feel for what practices are healthy or effective and what practices are toxic or ineffective. At your second company is where you really begin to gain that perspective.
At Younique I learned to work in a team. My professional services work at Qualtrics was very siloed with individual projects, but at Younique I was in an actual development team practicing Agile methodologies using the Scrum framework.
I learned to work in a large codebase, some of it very much what you would consider “legacy code.” I learned Git strategies and release and deployment strategies. I learned React, Babel, Webpack, ES6+, and a variety of other web development tools. I learned how to write tests for my code.
Younique was the first company to send me to conferences. They were also the first company that gave me the opportunity to present internal engineering trainings to the rest of the organization. They invested in my growth, and it paid off well, both for them and for me.
I learned a lot about informal leadership and how to influence engineering decisions without direct authority. I also learned that sometimes you get overruled, even when you deeply disagree with the decisions being made.
After a year and a half, I decided to leave Younique. I greatly enjoyed the people that I worked with, but I began to feel a sense that the engineering principles I had internalized and grew to love were not equally valued by the company culture.
There was a reason for this too. Younique is an e-commerce company, so the software we were building was not the product. The software was simply the means by which the product could be sold. The result of this business orientation is that engineering standards are not the main focus of the company.
Automated testing was not highly valued, and neither was accessibility. Some architectural decisions seems rushed and not very well thought through. Project planning was a nightmare with endless last-minute changes from marketing that left the engineering department working late hours to accommodate these requests.
I was comfortable at Younique, but I wanted to be back in the tech world where software was the product. I wanted to be in a company culture with strong engineering values and high standards. In short, I wanted to find a company culture that more closely aligned with my internal standards.
And so, I left Younique to join Instructure as a software engineer.
At Instructure I learned software engineering best practices. I learned what an organization looks like that values quality, testing, and accessibility. I worked with a lot of smart people that were far more senior than I was. I participated in our architecture council and helped drive decisions that impacted the entire codebase.
I deepened my understanding of the frontend ecosystem and toolchain, including Webpack, Rollup, Storybook, code formatters, code linters, change logs, and release tools. I learned how to build and maintain a design system. I learned the importance of keeping dependencies up to date. I began working with microfrontends.
I learned how to navigate relationships with teammates that were remote contractors from other cultures. I continued presenting in engineering training meetings and “lunch and learns.” I had my first real mentoring opportunity with an intern.
Incidentally, it was near the end of my time at Instructure that I started writing.
I left Instructure after one year, much sooner than I had originally planned. The company was going through a rough acquisition by a private equity firm, and there were several rounds of layoffs. I survived the layoffs, but most of my team was gone. The camaraderie and sense of belonging was gone. The uncertainty of what would happen next was palpable. I needed more stability in my life, so I found a new job.
My next adventure was at Workfront as a senior software engineer. It was at Workfront that I had the opportunity to apply the lessons I’d learned at my last three companies. Workfront provided me with many amazing leadership opportunities, both formal and informal.
My time at Workfront gave me a chance to help improve a less-than-ideal company culture fraught with poor engineering practices. Bugs were rampant. Test coverage was low. Integration tests were flaky. The app was not accessible. Junior team members needed direction.
During my first year there I helped the engineering organization institute a practice of “zero defect” to reduce the mountain of bugs. I improved our test coverage. I beefed up our design system. I fixed accessibility issues. I implemented code review checklists and best practices. I organized and improved our documentation. I trained my team in weekly staff meetings. I trained every other engineering team through accessibility workshops over the course of several months.
I had the privilege of participating in dozens of interviews and hiring decisions. I had interviewed a few candidates at Younique and Instructure, but it was at Workfront that I really began to enjoy and appreciate the interview process.
After a year at Workfront, we were acquired by Adobe.
At Adobe, I’m a senior software engineer and tech lead, and a year and a half after the acquisition, I’m still here and loving it! At this point in my career, I’m still optimizing for leadership growth opportunities.
I’ve been leading our accessibility initiative for the Workfront product for the last year and a half. I interviewed, hired, and am leading a new accessibility team that I’m still working with today.
I’ve learned how to drive initiatives that involve not just my team or portfolio but the entire engineering department. I’ve learned what it takes to stand up a new team. I’ve learned what qualities to look for in software engineers during interviews. I’ve learned the hard way that not every hire is a good hire. I’ve learned the importance of good onboarding documentation. I’ve learned how to scale best practices that I’ve learned so that dozens of other engineers can follow those same standards.
Adobe is a wonderful company full of seemingly boundless opportunities for growth. So, I’m still here! For now…
Optimize your career for growth. You’ll be happy that you did.