← Back to context

Comment by johnfn

4 days ago

Senior engineers delegate to junior engineers, which have all the same downsides you described, all the time. This pattern seems to work fine for virtually every software company in existence.

> Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think.

You read this quote wrong. Senior devs outsource _work_ to junior engineers, not _understanding_. The way they became senior in the first place is by not outsourcing work so they could develop their understanding.

  • How about a CEO delegating the work to an Engineer ? CEO does not understand all the technical detail but only knows what the outcome will look like.

  • I read the quote just fine. I don't understand 100% of what my junior engineers do. I understand a good chunk, like 90-95% of it, but am I really going to spend 30 minutes trying to understand why that particular CSS hack only works with `rem` and not `px`? Of course not - if I did that for every line of code, I'd never get anything done.

Comparing apples to oranges in your response but I’ll address it anyway.

I see this take brought up quite a bit and it’s honestly just plain wrong.

For starters Junior engineers can be held accountable. What we see currently is people leaving gaping holes in software and then pointing at the LLM which is an unthinking tool. Not the same.

Juniors can and should be taught as that is what causes them to progress not only in SD but also gets them familiar with your code base. Unless your company is a CRUD printer you need that.

More closely to the issue at hand this is assuming the “senior” dev isn’t just using an LLM as well and doesn’t know enough to critique the output. I can tell you that juniors aren’t the ones making glaring mistakes in terms of security when I get a call.

So, no, not the same. The argument is that you need enough knowledge of the subject call bs to effectively use these tools.

  • > For starters Junior engineers can be held accountable. What we see currently is people leaving gaping holes in software and then pointing at the LLM which is an unthinking tool. Not the same.

    This is no different than, say, the typical anecdote of a junior engineer dropping the database. Should the junior be held accountable? Of course not - it's the senior's fault for allowing that to happen at the first place. If the junior is held accountable, that would more be an indication of poor software engineering practices.

    > More closely to the issue at hand this is assuming the “senior” dev isn’t just using an LLM as well and doesn’t know enough to critique the output.

    This seems to miss the point of the analogy. A senior delegating to a junior is akin to me delegating to an LLM. Seniors have delegated to juniors long before LLMs were a twinkle in Karpathy's eye.

    • > This is no different than, say, the typical anecdote of a junior engineer dropping the database. Should the junior be held accountable? Of course not - it's the senior's fault for allowing that to happen at the first place. If the junior is held accountable, that would more be an indication of poor software engineering practices.

      Of course the junior should be held accountable, along with the senior. Without accountability, what incentive do they have to not continue to fuck up?

      Dropping the database is an extreme example because it's pretty easy to put in checks that should make that impossible. But plenty of times I've seen juniors introduce avoidable bugs simply because they did not bother to test their code -- that is where teaching accountability is a vital part of growth as an engineer.

    • The second part of my response addresses why your response isn’t analogous to what we’re discussing.