The blog is explicitly aimed at new developers. For them, I think working alone is a really tough spot, because they're going to have a hard time learning on their own, they won't have anyone to bounce ideas off of regularly, and they won't have someone at work to mentor them.
For developers later in their career, I think your advice is spot on. I remember lying on the ground struggling to solve one of the hardest problems I've ever tried to solve (as co-founder of a startup) and I'm proud of that solution. Having someone there would have helped, but wasn't required and probably wouldn't have helped me grow as much.
I've been a professional developer for about 5 years, and I've never seen great professional mentorship. In my experience, one should plan on working alone, and look & hope for good mentorship. For my first job, I was lucky to get a single offer, and that meant I didn't have much of a choice in what kind of learning & earning potential I had.
In my career, I've had a handful of occasions where someone mentored me. When they do, you can learn very, very rapidly.
But as good and valuable as that is, I think everyone needs the experience of solving multiple, hard problems mostly using books and the Google machine. You can never be senior until you can solve hard problems without someone holding your hand.
You are lucky if you get to bounce ideas off of someone. The relationship you describe doesn't exist between peers and reminds me of a teacher student relationship.
That's the classic example but doesn't apply because in a teacher student relationship there is a level of trust and control with each person at a different level.
If you find someone to mentor you in programming and they are on your team at work you are more like peers. Equal and in some cases the mentor becomes the mentee when another subject is in focus.
It depends a lot on the person and how they prefer to learn.
For people who are very analytical and self-motivated, i think it's fine to suggest reading books fairly early on in their development and just be there to answer questions or indicate how those theories are applied in the company's processes and tooling.
In this case the challenge is more around finding a book to suggest that suits the work. Coaching can end up being more around where to focus or how to skill up on one topic at a time.
Some people find it tough to digest knowledge in written form. In my workplaces this is often compounded by many good tech resources only being available in English and many developers not being native English speakers.
In these cases i have found it helps to start with pair programming (best case) or detailed code review (at minimum). After each "learning session" you can then provide links to references (book, article etc) for more info or background on the comments. This helps contextualize the theory upfront and shows the value of the source.
Sometimes when a certain source is referenced frequently, people take the initiative to read it to better understand the fundamentals for future work. Sometimes they don't.
That's where management comes in, i think. Regardless of whether a person chooses to learn with a book or some other source, at some point they are going to have to be able to solve challenging problems on their own. Managers are able to facilitate growth by allocating tasks that are at the right level of complexity for the dev.
I think the point is that it's not the job of a mentor to step in and solve the mentee's task, but to provide support and explain what sort of techniques and resources may be helpful to solve it. It's still up to the mentee to do the work.
Thank you for the detailed answer. I know this is somewhere I still have a long way I could improve so it's definitely interesting to get another's thoughts.
I think there's some confusion in this thread: yes, all programmers should develop their ability to solve problems alone. But new programmers should definitely avoid accepting a position where they would be the only programmer, if at all possible. If you get such an offer and are worried it's the only offer you'll get, I think you should bank on that being wrong and stick it out and wait for an offer with an actual team.
You have to bring it up when you're interviewing, and get in deep. Tell the technical interviewers what you want to get better at and be honest and be prepared to say no to good offers that aren't going to nurture your skill set. Ask about how they do code reviews, what professional development they offer, how often they pair program, do they do tdd or just make it work as fast as possible to appease the business, how the team has helped each other to grow and whatever else feels important to you
I've mentored people and gotten decent feedback on that. If that's what you're missing, move around. See if there's someone internally to get what you need, else jump ship for a new employer. Also, mentoring is mutually beneficial. As a mentor I get someone I can trust to do things in a particular way. Value for the mentee was already implied.
I’ve seen quite a lot of different teams and I have a side gig as an external examiner for CS students, and I’m not sure the real world really fits with your idea of a “high performance mentoring team”, because no one frankly seem to have a clue.
Most senior developers and teams have made choices and they’ll be able to tell you what works and doesn’t work in their shop, but that’s often not universal or even good advice for new developers.
I think the hype around kubernetes is the perfect example of how terrible experienced developers are at making decisions. I’ve seen more teams fail at it than succeed, and none of those teams, even the ones who succeeded actually needed it because their max-load didn’t ever even require them to have a load-balancer. Yet, I’ve yet to find any senior team who was sound enough to realise that they aren’t Netflix.
You won’t really get good mentorship from that. It’ll just feel like that because they are less insecure, but in reality, people aren’t actually very good.
I think the exception is if you make it into something really high end R&D, but chances are you’re already better than 99% of us if you do.
I think once you reach the point of docker-or-not you're probably beyond simple one-directional mentoring. At that point you've earned your opinion.
Mentoring is however wildly effective at helping people get to grips with tools. As an example learning django isn't particularly hard, it has a great tutorial, but I wouldn't be surprised if a junior programmer with no web framework experience would learn it twice as fast if given someone that'll answer their questions promptly.
I've never been a full-time developer, but I find that a lot of the passion around remote/distributed work often misses something for people starting out.
Communication systems were a lot different when I started in the tech world. But it's really really hard for me to imagine starting out in a world where I was sitting in my apartment all day. Remote doesn't mean working alone of course. But I would certainly have found the relative isolation difficult even given today's messaging and videocon apps.
The blog is explicitly aimed at new developers. For them, I think working alone is a really tough spot, because they're going to have a hard time learning on their own, they won't have anyone to bounce ideas off of regularly, and they won't have someone at work to mentor them.
For developers later in their career, I think your advice is spot on. I remember lying on the ground struggling to solve one of the hardest problems I've ever tried to solve (as co-founder of a startup) and I'm proud of that solution. Having someone there would have helped, but wasn't required and probably wouldn't have helped me grow as much.