> I ended up coding 98% of it

Stop doing that.

If you are trying to get a new team to take over your part of your coding work, you need to let go. Talk them through how you would do it, let them then give it a try... and then accept how they actually do it (as long as it works). When one person does all the work, it ends up being written in just the way that one person understands it and likes it. Which often leads to a lack of acceptance that different devs will accomplish the same task in different ways, and the original coder falls into this habit of "That isn't how I would have coded it, so it must be wrong."

Maybe I'm getting the wrong impression. Maybe you really are brilliant and 100% correct and you have hired nothing but duds. But... the odds are against that.

In the first one or two weeks of their training, I recommend implementing pair programming. Pairing your junior developers with more experienced developers or you. One actively coding while the other provides guidance and support, then switch places. This hands-on collaboration can accelerate a lot the learning process.

After that, the best place to continue learning is on code reviews in PRs. As @half0wl mentioned, it's importat to do it in both directions: you review their code, they review your code. This feedback loop will help your junior developers learn best practices and gain a better understanding of the codebase.

To facilitate these code review conversations, I recommend utilizing a tool like Pullpo.io (https://pullpo.io/products/channels), It allows you to have more enriching code reviews quickly on Slack, without wasting much time and being able to merge the PR sooner.

That said, learning curves can vary for individuals, and it's crucial to foster an environment of continuous learning and growth. But if after two years they can't keep up, i think it may not be the right person

Disclaimer that you work there would be appreciated

How are you "training" them? It's important to drill down into what they're struggling with before you throw resources at them.

I've found that code reviews are the best way to mentor and transfer knowledge. And it goes both ways: you review their code, they review your code. When I'm explicitly training someone, I get them to review my code and I occasionally throw in some minor curveballs that I expect them to pick up on in the first few rounds (e.g. obviously incorrect conditionals, some convoluted loop, leaky interfaces, etc.) If they stamp the PR without picking up on those items, I highlight it using a "do you think this is correct/is there a better way for us to do this" line of questioning. 5-10 or so PRs later, they become the first to spot those issues :-)

Thanks for sharing how you code reviews with your juniors! You're definitely more patient than me in that respect. I'll try that out.

Our training program mostly revolves around teaching them the fundamentals, where I give them some specs & resources, and once they code that, I give a code review: - They learned how to build some CLIs programs, where they make small clones of cat, find, grep, and cut. - They learned how to build some basic data structures such as linked lists and some sorting algorithms. - They learned some OOP by creating a CLI employee management system - Also some Network Programming by replicating the core features of the rack gem, and building their own web framework from scratch - They then take their hand-rolled frameworks, and they build the web version of the employee management system and ship it to heroku - Other projects also include some common tasks in the company, such as creating their own authentication system. - Lastly, they build their own design system using BEM CSS (a designer hands them a figma file, and they follow our internal CSS template / variables)

All of the above projects include code reviews, and the hope is that they learn how to become independent programmers & be able to contribute to any code, whether internal or open source. The goal is mastery of fundamentals.

I am not sure if I am too demanding -- our sprint is about 1.5 months long (0.5 months are for QA), but the expectation of that sprint is to ship one or a few features (e.g. a share button for a CRM for example).

Lol. Aren’t you afraid you’re going to forget about those bugs and merge them in?

You'd probably branch off a previous feature branch, introduce the bugs then do a mock PR that doesn't get merged, maybe even against a copy of the dev branch in case of accidents.

1. Have a title. It is most helpful to have some authority, even if completely superficial. This will empower you to set the direction for the learning and prevent the learner arm wrestling you when things get tough or when or defy popularity.

2. Be a leader. Listen to their concerns (really listen). Simultaneously be firm, direct, and honest. Don't let their insecurity drive the train. If you are in charge then be in charge, because you are trying to help improve them.

3. Set left and right limits. This is best done with automation, because the automation will either be without bias or at least equivalent to everybody. Automation can be test automation, compile checks, lint checks, and even vanity checks. Vanity (code style) is highly subjective and should only be applied via static analysis.

4. Document. Write down the learner's current learning and progress at each mentoring. That documentation will be used as positive evidence of their growth and progress for their manager evaluations.

5. Keep them accountable. Impose some minor amount of ownership and liability onto the learner. This will impose the need for the learned material. Simultaneously reassure the learner that this is a friendly environment with minor tolerance for failure. If it really is a safe environment then you as a manager have taken additional steps to increase internal automation to mitigate away as much risk as possible.

---

If after a good training structure the material is not sinking in one of two things are happening:

1) You are a bad teacher, probably due to your own biases. You have likely redefined reality in a way that reaffirms your own strength and fail to see the difference.

2) The current work is either not of interest to the junior or the junior is not intelligent enough. That is why you document at each mentoring for trajectory.

In my experience most of these training failures occur from the trainer not seriously taking ownership of the training (absence of leadership) and a complete failure to identify internal risks. When internal risk is high nobody cares about what you care about.

Well , it just mean that they are not meant for that field if they are really bad in it. Try asking them what they like to do and maybe try guiding them to change their line of work to their line of intrest

It's illegal to suggest people to consider a different career path in our country. We unfortunately will be held liable for "encouraged" or "guided" termination.

What a nice way to say "get them fired"

So far the number one thing I've found is keeping tasks appropriate in size. Huge PRs are going to necessitate lots of comments and changes, which is discouraging to a junior who has just spent a lot of time figuring out how to do something. You want to keep PRs small so tasks are doable and mistakes are catchable.

So 1) make sure you split big tickets into small tasks. 2) I encourage juniors to split largish tasks into multiple PRs.

It's important to provide mentorship and guidance tailored to their specific needs. Encouraging them to work on real-world projects, providing constructive feedback, and offering opportunities for skill-building through workshops or collaborative coding sessions can accelerate their growth and confidence.

How much experience does your junior dev have? Do they have a CS degree and have they done internships before? I am in college and looking at my peers, I can tell you that just having a degree does not mean they can code.

Maybe a controversial answer, but tell the junior dev to use ChatGPT.

Please be cautious with this approach. Good juniors will benefit from this. But the bad devs and students I worked with just copied code from others without understanding or learning from it. You might just introduce an unreliable middleman between yourself and the LLM this way, benefitting nobody.

Good point. ChatGPT should be used strategically

GPT or Copilot

Take this comment with a massive pinch of salt as I'm not a dev, just a sysadmin who does some scripting, and I've learned a ton already from asking ChatGPT to "refactor this function".

One of my colleagues had paid for Copilot out of his own pocket, and the guy went from having never touched Python to writing functional applications in a few weeks.

Note that the copilot doesn't help with anything non-code that you don't ask it. For example, I asked my colleague why he doesn't use venv, and it was because he'd never heard of it. He certainly isn't using version control either! On the other hand, his documentation is great because copilot helps write that as you go.

I'm curious how Copilot and ChatGPT affect learning. Do they help people develop a good understanding of coding by getting them moving quickly and teaching them good practices? Or do they just let folks patch together chunks of code that work as a whole although they don't really understand why? Or perhaps the reality is somewhere in between?

Honestly I think it will be game changing for education (if people use it for learning). You get initial info from it then you say "simplify that further" or "expand on that". Like having a personal tutor who is a PhD in 1000 subjects,just answering all your dumb questions 24x7

Both have CS degrees but from what I would say are "mid-tier" universities.

After they completed training, I gave them both Copilot and our internal ChatGPT (which uses the API). I did notice some speed improvement but still not to the pace & standard that I expect.

Have you ever asked them if they are running into problems, and if yes which ones?

It probably all starts right there.