So, in some ways this reminds me of the care and feeding of interns. My philosophy on that is basically:

• Don’t give them “opinion” projects. Things like “compare these two frameworks” are just busywork, because they generally don’t have the experience to say anything of substance that you can’t read off of a blog somewhere. Further, they probably aren’t immersed enough in the bullshit business requirements of your environment to make really good analyses.
• Give them clear deliverables. Every project they get should have a clear GO/NO-GO completion criteria. There should be an easily-testable (automatically or manually) way of verifying that their work is done, if for no other reason than to give them immediate feedback on their progress.
• Never put them in the critical path of a project. They aren’t paid enough to justify the stress or responsibility associated with that, and the crazy bizarre shit they may come up with will become heinous legacy code overnight.
• Give them housecleaning tasks. Building on the above two points, doing things like making deployments easier, setting up CI, or writing isolated reports for business are all great things for them to do: useful to the team, easy to gauge progress on, and unimportant if they fuck up.
• Be constantly asking questions about how they approach things, even if they’re doing it right. Interns (and junior engineers) need to learn, and to learn they need introspection. Introspection is easiest if somebody external is asking you to explain your thought process and give constructive pushback.

Of course, there is another school of thought (which has its benefits) which goes:

• Use juniors to do the hard and backbreaking work of building a company. As Stalin showed us, nobody is too underskilled to be fed to the front-lines. They don’t know how bad things are, so they’ll keep working.
• Use a few senior devs (commisars?) to keep them pushing in the right directions and not retreating. Pay these devs well, since their job is basically to prevent the impressionistic juniors from thinking too critically about why they’re rebuilding the frontend for the third total redesign in three weeks.
• If things get bad, start farming the juniors out to other departments to help fight fires (and there will be fires). Be wary of juniors that realize they have cross-disciplinary skills, because they can disrupt management and start requesting more money. Fire them or promote them.
• Use your juniors to recruit from their schools so you have a continual stream of warm bodies.

EDIT: I obviously don’t support the second operating model, but a lot of people have had success with it.

As an aside, I never get why writing documentation is considered a good job for a junior. It took me probably about 15 years to become good at it, and I still feel I have much room for improvement. Good documentation requires not only understanding things to the deep level but also enough empathy to put yourself in your reader’s shoes and explain in a way so they understand it.

I was in this situation at previous work.

The code base we were working on was a core banking system composing of about 2 mln SLoC of PL/SQL and an additional 1 mln SLoC in Oracle Forms & Reports. No unit tests and spaghetti code in a lot of places. The development process was often described by my colleagues as ‘powdering the dead’. I was a team lead and was pushing to introduce unit testing, documentation and refactoring to improve the situation a bit. They didn’t want to give me a budget to do this with my team but they did start sending interns my way. Here is what the first one did and the others continued.

1. I attempted testing stored procedures before using Python, so I scheduled a single day and showed him my off work project that had unit tests written in python and running against a database, measuring code coverage etc.

2. Picked the most error prone part of the code, that everyone was afraid to touch. There were only 2 people that knew that part of the system. I took the intern to one of those guys to break the ice, let them meet each other and gave a heads up that he will have questions about that code in the following weeks.

3. Asked him to start writing tests for that part of the code and documenting what he learns about it (plus the process itself and his internship). Told him that if he gets stuck he goes to me and if I can’t help then we (or him alone) go to the expert.

In those 2 months he got one of the biggest spaghetti function (15k SLoC) quite well tested, uncovered bugs and even did small refactors that the expert asked for and guided. Additionally it got properly documented and I got a powerpoint presentation from him that I arranged for him to show to my upper management in person.

The outcome was:

1. That was the first ever internship that ended up with the student getting an additional payment bonus for how well he did (management loved his presentation).
2. I got an OK and an initially small budget to start incorporating unit tests in normal development.
3. The team was more eager to do testing, when they saw that it can be done by an intern with no experience with little help on one of the hardest parts of the system.
4. The student was super happy to do something that was actually very critical for long term development (most of our development budget was being eaten up by maintenance and technical debt).

Before getting any new intern (I had 6 after that guy) I did a meeting with my team as I learned that having an ‘off the budget’ person to help was the best way to actually fix pet peeves that experts in an area knew about but never had time to address.

• Writing test cases. During initial stage of my junior developer job, i learned a lot by testing the software product my company develops. I wrote test cases which includes on how a particular feature works, how it should work etc. The requirement for this is that i need to find out whether already a document exits? whether it is up to date? or i should update the document. And i have to interact with the testing team to know how to test and other teams which my module interacts. By testing i learned whether it was working the way it is intended? how it works? etc.

• Read code. When something doesn’t work, i was always told to read the code. Since the code base is old, it doesn’t have much document on how things work and even if it has, they will be different from what the code does. So whenever something doesn’t work, my first step would be reading the code. I also developed a habit of reading code daily, so that whenever the code compiles (it would take 20mins), i would choose some module and start reading the code. By reading code, i have found more bugs in the code that would require difficult steps for the issue to happen.

• Document what you do. Because many times i need to solve the same/similar problem. I don’t want to waste time solving it multiple times. Documenting what issue you faced, the root cause, the fix and how much time you spent on the issue will be very useful.

I’d pair program with them. Seemed to work out alright in the past.

Keeping the codebase well tested and documented would definitely be their main task. Having them write utility scripts could be a good idea as well.

With time you would sometimes switch positions with them. Have them write a feature and you document / test it.

Other crafts have this somewhat figured out, so it doesn’t hurt to look for them for inspiration. Apprentice woodworkers were tasked initially with setup work (planing boards flat and the like), and then with easy finishing work (simple sanding tasks, say), and with progressively more challenging parts of a build from there.

A lot of feature and bugfix work in a codebase involves a combination of “heavy lifting” and “straightforward setup & polish” work. You can productively use an assistant’s time by taking on the heavy lifting portions of feature implementation or a bug fix, and then handing it over to them to do the easy parts that get it the rest of the way towards done. At first this is going to involve you essentially spelling out how to do the easy 20% (You’re going to need to write a test in this file, called this, that tests for this in this way and fails, so that I have a regression test to check my work against. When I’ve got this passing, I will have put the elements on the page, you just need to style them to appear where they should. Here’s some links to how that is done), but you’ll quickly be able to dial that back, and eventually ease them backwards into taking on progressively more of the hard 80%. Walk them through how you approached the heavy lifting portion of each task on a whiteboard at a fairly high level, but leave them to walk through your code on their own. If you directly walk them through the codebase, they’ll take longer to develop the critical skill of reading and understanding someone else’s code.

This avoids giving them synthetic busywork that they’re not equipped to do well (fresh bootcamp grads are not going to be able to research and report on code in a way you find useful. If you give people tasks they’re not equipped to succeed at, that’s bad for them and reflects poorly on you), lets them feel like they’re making visible, real contributions, and lets them learn from the commits they’re inheriting from you.

Don’t give them complete vertical features or QoL projects to handle on their own. Left to their own devices, juniors will approach things in bizarre ways they aren’t equipped to recognize the shortcomings of, and without constant guidance they’re apt to internalize those approaches and turn into “10 years of 1 year of experience” programmers.

I think refactoring would be a good task, because it helps them learn the codebase and run tests / write tests, while not being on the hook for big features. Then again, the results might be very mixed, because good refactoring often requires a deep knowledge of the program architecture.

Here’s a DevOp-ish idea… Have them research then set up an internal wiki for their and your use then have them get Jupyter notebook running. Execute first on their dev machine then on another platform (ex. Mac Desktop-> Linux VM). Now have them automate it using a change management system (ansible, chef, etc.). It’s useful and it exposes them to all sorts of things they’d need to know. Each step is important, easily checked, and the outcomes are clear.

I need an assistant that is at least as capable as I am. Every item on your list appears to me to be an activity that will cost you more time to work with the assistant a a lower-quality result than the time required to actually do the work yourself. Or hire someone with much more capabilities and share the time between you to perform these tasks at a significantly lower overhead.

Or try to develop automated assistants for some of these. At least that would be more fun.