Learning New Skills as a Developer By Building Your Side-Project

Since 2018 I've been involved in building close to a dozen products. Most of them I've shut down, some of them I've sold to others – and some are still alive! I credit a lot to this time – I believe these products are a major factor in my personal and professional development.

This year, MentorCruise had its second birthday. MentorCruise is a marketplace for tech mentorship – so things like coding, marketing, design and product management – for folks looking to learn a new skill or making a change in their careers.

Initially, it all started because I was eager to find a new mentor after I wrapped up my Udacity studies. I was enrolled as an alumni mentor and felt how the offer always got skewed more towards being mentor unfriendly. We got from being paid on a monthly per-mentor basis to being paid per-message. We needed to stay online to get requests and lost fixed access to our mentees. Finally, the payments got cut. No matter your experience, you were earning the same.

I started MentorCruise as a way to combat this imbalance – providing a way for mentees to find a mentor unrelated to studies, and for mentors to get fair compensation. Today, we have 5,000 registered mentees and about 350 mentors.

A lot of developers are not used to making decisions that impact users directly. You'd usually get your requirements from a project or product manager, and he gets that from a customer or doing user interviews – your job is to make it work, fast and efficiently.

By doing so, you're missing the view from the customer directly. That may not be something you'd want to have, but if you suffer from ever-so-often changing requirements and 180-degree changes to the specs, it's a skill that would be useful to possess.

If you are building your own product, there is no project manager sitting in-between you and your customers. You are responsible for understanding what their struggles are, and deciding how you want to solve it. That seems easy, but rarely ever is. Customers love to describe their struggles as new features, and you need to use that information to decrypt their real struggles.

This might sound familiar to you: What happens often if you have a long chain of feedback is that a project manager comes back to you, and tells you to make that sidebar hide-able. After all, that's what the customer wishes, right?

In this scenario, you would be the professional with UX knowledge, though. If you'd know about the underlying problem, you could propose a better solution from the start. Without that, you might end up implementing the same thing twice.

Oh, how we fellow devs despise marketing. Ads are taking over our screens, you can't walk anywhere without being sold to, self-proclaimed expert marketers are pushing e-books down your throat left and right. I get it. That's not what this is about.

Building your own product, you will have to do marketing in some way or another. "We'll build something great and they'll come" is a great mindset – unless they don't come, which they most often don't.

Marketing doesn't have to be that complex, ebook-down-your-throat Facebook ad debacle that everyone expects it to be. If you've ever looked up how to deploy a Node.js app on a Ubuntu server, you probably looked at DigitalOcean's marketing. If you ever browse Dev Twitter, you've probably seen the Tailwind guys post about their latest designs – that's marketing too, and if you've ever browsed certain Subreddits or looked at Show HN launches, yeah, that's marketing too.

The gist is, Marketing doesn't have to be annoying or cheap. If you write a really good article about your own learnings, that's marketing. If you know how to pitch your product to others on Reddit without sounding obnoxious, that's marketing as well. And finally, that won't only help with getting your products to the public, but marketing yourself in interviews, to potential partners or contracts as well.

Well, this is kind of an obvious one – if you build a product, you'll learn how to... build a product, but not only that!

If you are building a product today, you'll probably do so on the side of a day job that actually puts some money in your pockets. You'll work on evenings, weekends, whenever you have a day off or some time for it, that's hard.

That also means you won't spend a lot of time trying to get that one new piece of tech running. There's no time to set up another pre-commit hook when you could be pushing out features, and there's no time for a nice refactoring when there are still bugs hunting you.

Building a product on the side is first and foremost a challenge of prioritization. If you have one hour to make the most impact you can on your users, is porting your app to TypeScript really the way to go?

There's plenty of stuff you shouldn't take with you into your day job – being ruthless about technical debt is one of them, and you should probably still write your docs and tests, even if it isn't a ton of public impact – but when it comes to prioritizing what really matters and working under pressure, your own product is what's needed.

Once you go down this rabbit hole, you'll feel that not a lot of the job revolves around coding anymore. You'll fix a bug here and there, work on a new feature, but if you want to make real progress, you'll spend way more time writing blog posts, monitoring communities and social media to see what people say, feeding your social channels and making sure everything is smooth.

At some point, and that's highly depending on your financial situation and if your project makes revenue, you might even be tempted to outsource.

In the history of MentorCruise, I've had four people help me: A first programmer who spent some time setting up tests and fixtures for me – something I really didn't have the time or energy for, a copywriter who helped me express my thoughts more accurately, a designer who worked with me on a lot of redesigns, and now lastly a writer, who is producing content for my blog.

If you didn't have the experience of leading a small team so far, this is your chance! You'll jump right into the most difficult stage of trying to make communication work online, part-time, across timezones and language barriers – it's a ton of fun.

If you come out of this successfully, you'll have no issue guiding and mentoring other devs in your company.

Finally, there's customer support. Unfortunately (and I mean that), not a lot of devs ever get to experience this in full. My first experience with "customer support" was extremely bad. I was in my first dev job and the customer I worked for had a direct line to me. Angry calls, day in and day out, and not a lot I could do. In the end, I got passive. I quite frankly didn't want them to call me ever again. At some point they didn't, the contract was gone.

If you ever get any traction with your product, you'll have the experience of doing customer support for your users. You'll get e-mails about lost log-ins, failed payments, confusing questions, sometimes even the angry all-caps e-mail. You'll learn how to understand these struggles, solve them, get back to people and overall show a lot of empathy, even if you don't want to (you don't really have a choice). I strongly believe that this not only shapes the view you have of your own customers but also whenever you get another confusing or unnecessary request in your day job.

I think there are a lot more positives about building your own product, but these are some of the skills I feel like I have picked up that really helped me in my day jobs as well.

Let me know if you ever want to get into building your own products, would love to hear about them!