Lessons from 2 years coding with 60 junior developers

For almost two years I was the tech lead of a team that kept renewing itself. More than sixty developers came through, in cohorts of about twenty. Most were finishing engineering school and doing their end-of-studies project with us. Some stayed and became colleagues.

That chapter closed in December. Before the details fade I want to write down what it looked like, what they learned, and what I learned. I am not going to describe the products. This is about the people and the way we worked.

What the days looked like

A cohort arrives with very different levels. Some have shipped side projects, some have never opened a pull request. So we started with a small exercise of an hour or two, such as a page that calls a movie API and shows the results. It was never a test to pass. It gave me something concrete to sit next to them and talk about.

Then they joined a real team, on a real product, with a real ticket. I think that was the most important decision we made. People learn faster when someone is waiting for what they build.

My own days had three parts. Unblocking: someone stuck on a migration, someone unsure how to cut a ticket in two. Reviewing. And writing code with them, often in their branch, on their screen.

I picked up the phone a lot. A question that takes twenty messages takes four minutes out loud, and you hear what the person did not write.

A small frame

In my first weeks I put three things together: coding guidelines, a short guide to pull requests and reviews, and a team handbook.

The technical rules were few. Work in a branch named after the ticket. Commits that work on their own. Push early and often, several times a day. Nothing reaches the shared branch without a pull request and a review.

The handbook was about the rest: how to join a team, how to disagree in a meeting and still commit to the decision, how to give feedback and how to take it. One line in it I still repeat: honesty without kindness is cruelty, and kindness without honesty is manipulation.

Later we added starter projects for the back end, the front end and mobile, so a new team could deploy something on its first day and spend its energy on the product.

I was surprised by how much freedom a small frame gives. When the boring questions already have an answer, people take initiative on the interesting ones.

Reviews were the classroom

If I had to keep one practice, it would be the code review. We did not treat it as a gate. It was where the teaching happened.

I tried to never write "change this" without writing why. Why this query will be slow with real data. Why this component will be hard to test. Why the name matters to the next person. It takes longer the first time. The second time, they explain it to someone else, and that is when it is learned.

I also learned to ask before telling. "What happens here if the list is empty?" does more than "handle the empty list". They find it themselves, and they look for it the next time without me.

Across about fifty repositories we merged several hundred pull requests. I read a large share of them, and I think I learned as much as their authors did.

Then AI arrived

This was 2023 and 2024, and the tools changed under our feet. I was curious, and so were they, so we tried things early.

In 2023 we put an AI review on every pull request. It read the diff first and left comments before any human did. I also built a small command-line tool that proposed unit tests for staged changes.

It changed our reviews for the better. The machine caught the forgotten null check, the unused variable, the missing error case. By the time I opened the pull request, those were fixed, and the conversation could be about design: is this the right place for this logic, what will this cost us in six months.

It also changed how juniors learn. They could ask a patient assistant the questions they did not dare ask in front of the team, at any hour, as many times as needed. They got comfortable with a new framework much faster than I did at their age.

We kept one sentence through all of it: the author is responsible for every line, whoever typed it. They took it seriously. In review I would ask someone to walk me through a function, and that conversation was often the best part of the review. The assistant had written some of it and they had understood all of it. That is the use I hoped for.

My role moved a little. I spent less time explaining syntax and more time on judgement: what to build, what to leave out, how to know it works. I enjoyed that version of the job more.

What they learned

I can only repeat what they told me.

They talked about understanding what happens under the hood, and not only how to call it. About delivering fast and still delivering something solid. About working in a team: cutting work in small pieces, asking early, reviewing each other.

Several said the thing that mattered most was feeling free to ask questions and to try. I am glad, because that was the part I cared about most.

It was not only developers. Interns from business and marketing worked with the same teams, and I spent time with them too. Watching a developer and a business student shape a product together was one of the best parts of those two years.

What I learned

Explaining why forces me to know why. Writing a reason next to every comment showed me which of my rules were reasons and which were only habits.

Time is the real gift. Not the clever answer, the twenty minutes. People remember that you were available.

People grow into the confidence you show them. Give someone a piece that is a little too big, stay close, and they usually carry it.

A team of juniors is not a slow team. With a clear frame and fast feedback, they shipped real products for real users, and they brought an energy I had missed.

And I learn best by teaching. I understand React, databases and deployment better today because sixty people asked me questions I could not answer on the spot.

After

Many of them are working as engineers now, some with the same teams, some elsewhere. Watching that happen is the part of the job I am proudest of.

Whatever I do next, I will want juniors around.