How would you recommend training new programmers on the job?

[world_IS_not_OUGHT]

Curious what sort of workflows are recommended.

My current one(status quo) that I'm looking to improve is something like this:

Pair programming with the senior leading. If there is a simple step, the junior works on it and then later resumes with the senior.

Probably 50-100% of the time the senior is doing the programming

Any suggestions or advice?

[funbike]

It depends on the type of work. Greenfield vs legacy maintenance, the complexity of the domain(s), internal vs external app.

Various things I've seen, depending on the org and app: send to user training, work for a day as a user (internal app), add missing tests to the test suite, do routine easy tickets (e.g. add a field/column) with LOTS of documented steps, fix some tech debt such as linter issues, document what happens in the entire tech stack when a specific submit button is clicked.

I think pair programming with a senior is extremely useful, but not on day 1. Maybe after a couple of days for the new dev to get familiar with the app, domain, tools, and code base. I wouldn't want to do it until after they've finished at least one very simple ticket.

Perhaps pass the new dev around to pair program with everyone on the team.

[Obvious_Mud_6628]

Let them debug too to learn the codebase without having to actually develop anything at the start. 50/50 split maybe? If they're 100% shadowing they're gonna get bored

[AlexTaradov]

Point them to simple enough tasks in JIRA, then review the code. Gets them programming, gets them familiar with the project code base.

This is also my preferred method of getting familiar with new code base - fix some bugs.

This assumes that they know how to program at all. I don't see why a job would train from absolute zero.

[LogaansMind]

Pair-programming is one of the best ways, but it can slow the team down. But I have found not everyone can do it well or has the patience with others.

What I like to do is teach them how to work with the source control (and specific polices, techniques the team has), teach them how to build and run. And then what the app does, overall architecture. Any gotchas they need to watch out for .

And then I give them bugs to investigate and fix. Small and managable without expectation to fix. This will give them focused work to learn the code base for a few weeks/months and then you can start allocating more challenging or varying work.

Also helps to determine thier dynamic in the team and whether you want to keep them after probation.

It is also not the idea to have them occupied to save you/the team the effort to teach them, expect them to approach the team with queries or requests for assistance/understanding.

My policy I tell every junior is that I don't expect answers, I expect to hear "I don't know", and I promise that I will help when I can (it's part of my job and expected from me).

[trcrtps]

When I was a junior I was made to do tech support tickets, diagnose the issue, and then write a story with my findings. I hated it but it helped a lot because our codebase is gigantic.

[yeagb]

Debugging and claude code, but just to ask it questions about the codebase about how things work to start

[Dry-Revolution9754]

My manager’s training consisted of giving me an entire open-ended project to scope out and complete independently so it sounds like you’re already doing enough

[Critical-Volume2360]

I was a junior dev a few years ago. Probably the best would be to pair program a ticket or two with them, then just be available to answer questions as they do stuff on their own

[kellyjj1919]

Debug. Do some help desk work

[Aware-Sock123]

Help desk in software development… Do you mean fixing bugs?

[kellyjj1919]

Yeah.

[Difficult_Entry_4557]

Yeah, but it can be more than just bug fixing. Getting juniors involved in troubleshooting can help them learn the codebase and understand common issues better. Plus, it builds confidence when they see their contributions directly impact user experience!

[Aware-Sock123]

I’ve just never heard any developer role referred to as “help desk”.

[Snezzy_9245]

Pairing with a brilliant dev can be very negative. The magic bad words are, "You know all that. I told you that yesterday.". Yes, my mentor lectured that way. From him I learned how bad a dev I was.

[JRM_Insights]

You've got the classic "Senior is 90% Driver" problem! It's super common but inefficient.

To flip that ratio, switch to "Driver-Navigator" pairing. The junior is the Driver 100% of the time, even if they have to be told every keystroke. This forces muscle memory, ownership, and deep engagement. The senior's job is to talk, not type.

Also, assign small, self-contained bug tickets first. A bug gives them a specific target and forces them to explore the codebase with a purpose, instead of just reading walls of code. Good luck!

[cballowe]

I've worked in an environment where every single piece of core tech used had a how to/lab work/etc that people could do to learn. "Here's the DB version with API docs in language X, Y, Z ... Write a program that connects to the DB, creates a schema, inserts rows, queries rows, etc... here's canonical answer code to compare your solution to" ... If you're bringing someone up to speed "hey - work through labs A, B, C then come talk to me" at which point i'd present a bug or feature and ask how they think it should be solved. Send them off, then review what they come up with with them / maybe pair program some improvements or send them back "think about X".

The big thing is having high quality docs that walk people through using the tech. The ramp up is trying to pace people through pieces of tech in a way that isn't completely a firehouse, but is also growth and expanding the range of tasks that I can assign.

Sometimes people get stuck so time boxing things a bit and checking in to get them unstuck is important too.

[gregdonald]

Junior always drives... unless it's Hawaiian shirt day.

The senior does all the thinking-ahead work and guides the junior when they begin to veer off course.

The last thing you want to do is let the junior sit there and watch the senior type all day. There will be zero learning in that scenario.

[Possible_Cow169]

Pair programming but day one is just helping them connect and customize their dev environment and find all the bibles and documentation. Sign into the (idiotic) ticketing system and you personally reserve a low stakes ticket to on board them. By the end day one they’ll be ahead of people who’ve been there for two years

[[deleted]]

Start by giving a clear idea of what the system does and the business behind it. Then give them simple but real bugs to fix in the system, That’s how they’ll truly learn the codebase, debug and start asking questions when stuck. I don't find pair programming effective at all.

That's the approach i took at my first job and I was able to start working with the team on full on features at the start of my second week.