I called it a side-project because it started out as something I was working on in my own personal time. I did tell my manager I was working on it and showed him progress from beginning until the end. After he approved, he told me to create a document explaining how it works and how it solves our problem, and this document was used to explain to upper management why it needs to be prioritized in the following quarter (and it ultimately was). So it was very possible that we may have had higher priorities and we wouldn't be working on it all. We also threw away that prototype and we're building it from scratch to a production-level as a team.\
\
I believe the root of your question is centered around learning and growth. Working on side-projects is a means to learning and growth, and it's definitely worth investing in that outside of your work. I know plenty of very senior engineers that have been experimenting with LLMs just to get experience with it. Eventually this learning and growth is expected of you the more senior you get.\
But would it help if you devoted that same time to work-projects instead? It depends, as not every project may bring about the impact you're seeking (nor will they induce growth/learning). It's best to ask your manager/mentor about specific projects. If you're looking for a rule though, I would definitely prioritize learning and increasing your skills on a weekend.

Lead Software Engineer at Vista

Atif Mansoor

It depends on what kind of "side-project" you are talking about:

1. A product or service that you will launch and get strangers to use. 
2. A project simply for working on new technologies and skills.

For the first type of project, unless you're already working with A/B tests (experiments) in a frontend or fullstack role, this can be a great learning experience when it comes to discovery, experimentation and rapid prototyping. The industry is trending towards engineers being more product-focused (google "missionary vs. mercenary engineer"). \
For the second type of project, there is still value in developing prototypes that build your knowledge and skills, even if they never see the light of day.  In my case, I was primarily a backend engineer and I worked on a side-project in React. It started out with a Udemy course, I built out a bunch of features and I had the intention to launch it one day, but I never did. Despite that, it helped me a lot in transitioning from a backend team to a frontend team at Microsoft, as I was able to hit the ground running. I was at a mid-level position (level 62) at the time. \
\
If you're trying to get promoted, your side-projects should actually be centered around helping your product or team. Recently, I created a prototype for an internal tool that solves a business problem of ours. I presented it to my manager a month ago, and now we're actively working on it (albeit a scaled-down version within a short time-frame). A project like this will certainly help build your case for promotion.\
\
I agree with you about not having a side-projects section in your resume after having experience. There's no reason to include that unless you launched it and have customers.

Having worked at Amazon and Microsoft, I can tell you that even after you accept the offer, the challenge of growing and making an impact is the real struggle. At Big Tech, you have the opportunity for fast growth, but it's not guaranteed, and you will be competing with very talented people on getting high-visibility projects.

These types of firms will always be around. If you're unemployed, focus on building a side-project (specifically focusing on UX and Product skills; I would recommend reading "Inspired" by Marty Cagan). Use what you know to show what your potential.

When you land a job at a smaller firm, focus on getting high-visibility projects. I left Microsoft to do just that.

I want to comment on your thought that fulfillment is tied to career growth. That's true to an extent; if someone is passionate about their product/service, they are more likely to drive results and make a business impact.

On the other hand, it may be "boring" things that actually cause you to grow and level-up. "Engineering excellence" is a good example: writing documentation, improving on-call experience, finding gaps in processes, reducing tech-debt and so on. Especially at a senior level, you will not achieve growth simply by completing the tasks assigned to you. You need to be pro-active in finding gaps  and problems, getting buy-in from the team, and executing on that. These can often be tasks that people find "boring" or "unfulfilling".