Mentorship has probably become one of the most heard-online buzzwords when it comes to coding. Juniors seek out mentorship for their jobs; Seniors are judged on their ability to mentor others.
But why is there so much emphasis on mentorship, and what exactly does it mean?
I’ve personally seen it have various meanings, often as a substitute for onboarding, coaching, or helping.
In my personal view, mentorship is a learning-based relationship between a person who has the experience and someone who is willing to learn.
In the last years, I’ve found myself mentoring more than 30 students not just on learning code, but on how to hone their learning abilities, and to get hands-on experience within the career they wish to reach.
But how does all of this typically start?
Well, my students usually come to me with one simple desire: to build something on the internet and develop their skills or assemble their portfolio, aiming to get a job in the industry.
Many people shy away from coding because they think they are not logical / smart enough. Logical thinking can be taught and it is actually a very simple process of breaking down any process into steps.
So, what are the benefits of hiring a mentor to learn to code, when you could just get on any website and hire someone to do the job for you?
Nowadays, with the current technologies and global markets available at your disposal, finding a developer is easier than ever, and the costs have never been so low.
I’ve seen them taking this approach countless times: coming to me asking for mentorship, after having wasted thousands on freelancers, just to get a half-assed product delivered that they don’t know how to run, let alone upgrade.
What does this tell us? Knowledge is forever, code is… well, not.
Code is not meant to be forever, but it’s meant to be continuously rewritten and upgraded, which is something you can do by hiring a developer.
To put it succinctly, I’ve made a simple illustration rawly highlighting the amount of money and time you would spend through the whole process of looking for a developer, from ideation to implementation of your desired project.
Note: the numbers would easily x2 if I prepared a very detailed analysis on the required amount of time and without taking into account your hard-earned dollars spent through the whole process.
If you’ve read this far, you too probably have wanted to see your dream project come to life, and now that you have chosen to learn how to do it, instead of paying someone else to do it for you...
Congrats! You’re already on the right track!
Let’s analyze this matter more closely: why, on all levels, hiring a mentor (and investing in your knowledge) is substantially more beneficial than simply paying someone to do it for you.
1. Forward-Looking Efficiency Vs. Short-Term Gratification
Hiring a developer is a good idea if your strong suit is NOT product development, or you don’t prioritize being self-sufficient. This could be the case of a team-wide startup or project where you already have a co-founder with technical expertise.
If that doesn’t describe your situation, and you’re alone without any kind of technical knowledge, you’re forced to find an individual or team to place the fate of your project in or take matters into your own hands.
2. Before Paying a Developer, You Need to Know What You’re Going to Build – and That’s Something Only a Mentor Can Teach You
The art of breaking down your project into smaller actionable steps is something that exclusively comes with experience.
This is where a mentor can play an important role, guiding you throughout the process of mapping out all necessary steps for smooth execution.
3. Assuming You Were Able to Provide a Decent Product Description to Your Developer, They Still Might Not Deliver What You Expect.
This misalignment between expectation and reality comes from a lack of technical knowledge and understanding of how things work under the hood.
It’s critical for you to understand how the engines work while building your dream car. Again, a mentor can help you approach this much more efficiently.
4. Let’s Get Highly Optimistic: All Goes Well, the Product Was Well Described and / or Well Developed (Trust Me, You Got Lucky). Now There is a Big Issue Waiting for You Around the Corner.
How are you supposed to run a business based on a product you didn’t build yourself and/or don’t have enough knowledge of?
The question here is how much do you value your knowledge vs. your time?
Would you buy a Ferrari without a driver’s license?
Previously published here.