| HN Mirror

I didn't say it was entirely a good thing, hence the importance of the PR review process. As I said, I found numerous bugs, sometimes nasty ones that are hard to identify/fix before they got merged. That engineer was building features really fast, however. Maybe it wasn't 1K lines per day every day, but definitely he did hit that mark on some days.

He was surprisingly skilled considering the volume of code and he had a solid understanding of a lot of advanced concepts and nuance so I know he wasn't blindly using LLMs. He did implement features really quickly and bug density was quite low overall.

I'm sure he could have implemented those features using fewer lines of code, but as the team lead, what can I say to a highly motivated 25 year old who is churning out new features faster than the rest of the team combined? Motivated people aren't typically very receptive to generic feedback like "This is great but you should try to reduce complexity"... Of course, I could provide slightly more detailed feedback, but that would be getting into my personal coding philosophy and didn't quite align with the broader practices of the company (a startup) at the time. There were a lot of things that the company was doing, which is standard (most companies are doing the same) but which I don't agree with and which would sound controversial. I could provide strong arguments for my positions, but humans are flawed, and carefully thought out, nuanced arguments that go against conventional thinking often tend to fall on deaf ears... You can only rock the boat so much.

Also, you don't want to de-motivate a highly productive person. Even if they're productive only in one narrow dimension. With me looking over his code, we could keep complexity under control at a maintainable level. Keep in mind, we were a startup in a competitive, growth sector. So developing features quickly was quite important and throwing away entire features to pivot was considered an acceptable risk.