Help me understand this problem better: Effectively ramping up new developers onto a project?
The software world is fast paced, and most development projects are seemingly run at breakneck speed.
As someone who often plays the tech lead role, I'm regularly the person who needs to make sure a robust solution is shipped while simultaneously playing a skills guidance councillor role for new/junior devs (Sometimes unwillingly)
This creates a catch-22 situation:
-
If I spend too much time on code reviews and mentoring and teaching, the project delivery suffers because nobody is busy writing the actual project code. Of course, eventually, once the junior team members get up to speed, the hope is that pace will pick up.
-
If I ignore the skills development aspect and just get the job done, then the junior devs don't add much value to the project and just cause frustrations.
Neither of the above are ideal scenarios, and the nature of the project will determine which way you'll lean.
My view is that the real solution is to leverage the gazillion existing learning resource on the web (tutorials, Youtube channels, Udemy courses, etc). So instead of personally sitting with each team member, I rather assemble a learning path for them. So if the project is predominantly an Angular based solution with a SpringBoot backend (for example), I'll spend some time searching the web for useful resources in those two technologies and get the juniors to work through it on their own time.
The problem is not totally solved through, because:
-
There simply is too much content available, and in the world of developer frameworks and tools, the content becomes stale very quickly. We need to have a reliable way to index the available content by topic and allow us to sort by relevance.
-
People don't know what they don't know. This results in people attempting to learn technology X while they don't yet have a proper grasp of Y, and Z, both of which are critical prerequisites to understanding X. This is possibly the main cause of Tutorial Hell
So I want to figure out how to solve this dilemma. In big tech companies they have huge internship programs and learning initiatives, but in smaller companies and start-ups this is not a reality. Often the CTO also runs the internship program :)
I'm curious to hear other people's thoughts and opinions.
Pair programming is the fastest way of knowledge sharing I know of. A lot of companies resist it but I think the ROI is positive in many, many cases. It doesn't have to be every day, either. Even pair programming two days a week is a huge benefit.
This is actually the one thing I miss most from working at a large startup.
The business unit I’m in at VMware pairs almost 100% of the time. We’re probably 4000 or so people across multiple roles. Productivity is crazy high and the on boarding time is reduced significantly.
before you jump into pair programming..
talk with your current dev team.. do a pizza/whatever.. and toss the ideas around.. you might actually do this with as many devs as you can.. keep it short, to the point.. you really want to nail down a short/quick process that you can test not only with your team, but with others as well.
if however, you only have a few devs.. well, you're going to have to be creative/flexible.
if you have a new/jr dev.. tossing that person to code is probably not quite cool... learning curve can be a pain. doing pair programming at this point probably isn't that good either from a productivity standpoint. you might have the jr dev do a combination of "testing", or generating testing scenarios if you do that, as well as a bit of pair programming.
if you have multiple sr devs.. let the jr dev go between a few of the sr devs..
you're prob not going to get jr devs spending a great deal of their own time on your company's work.
on the other hand, 90% of the places i've been involved in usually had devs working way more than 40-50 hr weeks anyway..
good luck
Thanks for the response, really appreciate
I'm not going to exactly dictate an answer to your problems, but I'll share the approach I have followed in the past. Mind you, most of my career I have been working alone (+-5 years), and there have only been mere months I was able to work/lead a small team of 2 to 3 people. In the meantime however it was expected of me to deliver the results of a team.
This is absolutely the first goal when collaborating; keep things as simple as potentially possible. Actively invest in simplicity. One might think time spending refactoring and optimizing is not time well spent. Think again. Small bugs which are workable eat valuable time from future developments. Refactor often as it will enable you to move quicker in the future. Identify time eaters such as manual deployment and testing. Automate it, even when it would take weeks of work (which means it has been postponed way too long already and the best time is now).
Second to clarity is to share a mental model with your peers. Take some time to explain the system as a whole. The different components, how they interact together and what their responsibilities are. If this is difficult to do due to the complexity, refer to the previous paragraph. This mental model will make it easier to reason about the system, and prevent one to think only in the context of "the one page I need to change some javascript on".
Talk a lot. Not only during stands up (if you do those), but during the day. Informal conversations are the best way to get to know what someone is up to. Share ideas, share the global vision on the project, share what you're working on. If a tricky issue comes up in one of these conversations, do not hesitate to pair up together. Having to pairs of eyes on a single problem usually improves the quality of the end result. Pairing up also opens up a great possibility for knowledge exchange, and for me this is one of the most important moments when mentoring someone as I am partly able to show the way I solve problems, and help them solve things too. Besides that, talk usually diverges towards upcoming issues, and I'd be able to share my view on the way those problems can be tackled. Whether they follow this advice or not is totally up to them however.
This way I'm able to organize a small team in a very informal way. Newcomers gradually start to have a bigger and bigger impact on the result, and can learn at their own pace, while being guided through the material they are working with.
Personally I do have the benefit I do not have to adhere to issues, a certan number of storypoints, or have to follow a fixed roadmap. Together with the team we're determining from moment to moment what the best way would be to progress. Note that I do actually share a long term vision, so that everyone is in the loop on the "end result". The bliss of innovative product development :)
Much appreciated Corstian, always handy to learn other people's experiences
Pair programming and mentoring, in-depth code reviews are indeed resource hungry activities.
A product/project can only take on so many juniors before their "discount" begins to actually cost MORE then having hired more senior devs. But it's a balance.
Also i've given my own devs articles to read, and depending on the dev, they either read them or don't.
React docs, MDN on websockets, react hooks, react context state managment pattern, in all fairness, it takes time to learn this if you are very new.
Also some devs consider "their own time", the companies time, and won't engage with material on weekends.
On the flip side, some more senior devs will spend more time then they need commenting on more junior peoples code + mentoring when it isn't really needed, since that area of the code is not super critical at all.
I feel regardless, we all get what we pay for, and we should determine it at interview time how the decision affects time resource allocation around a project.
Also a lot of companies promise "mentorship" and it is rarely a reality, understandably, it just takes too much time in most cases.
Tx Coneo, w.r.t. your comment re "Mentorship": This is really where I'm heading - I'd like to put something together that solves my problem but potentially also at scale. Almost like an enterprise-level code mentorship programme.