3 ms·

Only non-engineers listening to VC-hype on podcasts think that AI can replace fully junior engineers. Here is a problem I recently asked a junior dev to solve:

Only non-engineers listening to VC-hype on podcasts think that AI can replace fully junior engineers. Here is a problem I recently asked a junior dev to solve: Our service occasionally gets especially expensive requests that amplify to our dependencies, one of those dependencies have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z. AI is pretty far from able to do this. A cracked out vibe coder maybe could have just added a one-off naive rate limit algorithm pulled from stack overflow or maybe pulled in an unmaintained 3rd party 'rate-limit' package and called it a day. And that would be fine for a MVP but in large organizations figuring out what to build, how to build it, and getting agreement with stakeholders is way, way more work that doing than actual implementation (which still rarely can be one-shotted and needs a lot of hand-holding and iteration to get decent solutions).

deleted 1y ago
[deleted]
haiku2077 1y ago
The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. In most organizations junior devs are not expected to design solutions for open ended problems on their own.
- azemetre 1y ago
  Why not? How else do you get these skills without doing it?
  - jlawer 1y ago
    Job / Position description means something more... It means that your expected to do the task and perform well at it or you will be let go. Generally you don't put those skills in a Junior PD, but you would expect a Junior to take on these tasks if they hope to progress. The Mid level PD would have it listed and as the junior shows they can meet each and every additional skill, the option of a promotion becomes available.
    - azemetre 1y ago
      None of this seems hard for a junior dev tho... it just takes time, which I'm assuming the others workers don't really have with more pressing matters making this a great issue for juniors to grit their teeth on.
  - haiku2077 1y ago
    Note the words "on their own". They would be paired with a more experienced dev to collaborate with.
    - azemetre 1y ago
      That seems self-selected and biased toward their own experiences. When I was a junior I was allowed and given free reign to design the test system for the product and implement a design system for the frontend team. Junior doesn't mean stupid, it just means less experience. How else do you expect people to gain experience if you don't give them basic independent projects?
- com2kid 1y ago
  My first job out of coll, task 1 was improved query perf on our test result database. job 2 was "get performance tests working again." Both 100 % open ended problems.
  - decGetAc 1y ago
    That task seems perfect for a junior dev. It's open ended but low risk and not interacting with multiple teams as directly It's different from the one described above > talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z. I'm sure some junior devs could do this but the majority wouldnt be able to
- conro1108 1y ago
  In my experience, the problems given to juniors are often open ended “improve this” or “fix this” type projects, but smaller scope or lower priority things that more senior devs would just never get to. I will say though, needing to socialize across other teams to understand the problem and drive the correct solution does strike me as more mid/senior level work.
  - t-writescode 1y ago
    In my experience, those are the worst sorts of jobs to give juniors if you want actually throughout though. They need direction, releasable pieces, etc. they don’t know how to break something apart into small, releasable parts yet. That’s a major thing more experienced devs can teach them.
- AdieuToLogic 1y ago
  While I would not have used the descriptor "dependencies", substitute that with the term "partners": Our service occasionally gets especially expensive requests that amplify to our partners, one of those partners have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. > The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. With the clarification above, I believe a junior dev could perform this task, even if the proposed solution is known to be a learning exercise. The immediate value to the team is the collection of partner concerns.
- siliconc0w 1y ago
  For Junior, problem is already triaged/scoped, low criticality, solutions to this kind of problem are provided but may need judgement or extension to identify the best approach. Design and implementation should be based on requirements gathering from immediate known stakeholders. May need low-level supervision/guidance. For mid-level, they are capable doing more of the problem triaging/classification and can handle vaguer, larger scoped problems. They can identify the correct stakeholders to engage with and, ideally, influence. Can identify the most likely best approach amongst a set of possible approaches. Guidance is high level- like a weekly or bi-weekly 1:1. Better design taste as far as how to measure outcomes or rollout changes safely. For senior you're ideally solving classes of problems rather than specific problems. You're charting a longer term roadmap that generates work and exerts influence amongst number of teams to drive long-term business outcomes. You are mentoring juniors/mid-levels so they're setup for success and have the right work at the right level of guidance at the right time to grow in their careers.

deleted 1y ago

[deleted]

haiku2077 1y ago

The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. In most organizations junior devs are not expected to design solutions for open ended problems on their own.

azemetre 1y ago
Why not? How else do you get these skills without doing it?
- jlawer 1y ago
  Job / Position description means something more... It means that your expected to do the task and perform well at it or you will be let go. Generally you don't put those skills in a Junior PD, but you would expect a Junior to take on these tasks if they hope to progress. The Mid level PD would have it listed and as the junior shows they can meet each and every additional skill, the option of a promotion becomes available.
  - azemetre 1y ago
    None of this seems hard for a junior dev tho... it just takes time, which I'm assuming the others workers don't really have with more pressing matters making this a great issue for juniors to grit their teeth on.
- haiku2077 1y ago
  Note the words "on their own". They would be paired with a more experienced dev to collaborate with.
  - azemetre 1y ago
    That seems self-selected and biased toward their own experiences. When I was a junior I was allowed and given free reign to design the test system for the product and implement a design system for the frontend team. Junior doesn't mean stupid, it just means less experience. How else do you expect people to gain experience if you don't give them basic independent projects?
com2kid 1y ago
My first job out of coll, task 1 was improved query perf on our test result database. job 2 was "get performance tests working again." Both 100 % open ended problems.
- decGetAc 1y ago
  That task seems perfect for a junior dev. It's open ended but low risk and not interacting with multiple teams as directly It's different from the one described above > talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z. I'm sure some junior devs could do this but the majority wouldnt be able to
conro1108 1y ago
In my experience, the problems given to juniors are often open ended “improve this” or “fix this” type projects, but smaller scope or lower priority things that more senior devs would just never get to. I will say though, needing to socialize across other teams to understand the problem and drive the correct solution does strike me as more mid/senior level work.
- t-writescode 1y ago
  In my experience, those are the worst sorts of jobs to give juniors if you want actually throughout though. They need direction, releasable pieces, etc. they don’t know how to break something apart into small, releasable parts yet. That’s a major thing more experienced devs can teach them.
AdieuToLogic 1y ago
While I would not have used the descriptor "dependencies", substitute that with the term "partners": Our service occasionally gets especially expensive requests that amplify to our partners, one of those partners have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. > The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. With the clarification above, I believe a junior dev could perform this task, even if the proposed solution is known to be a learning exercise. The immediate value to the team is the collection of partner concerns.
siliconc0w 1y ago
For Junior, problem is already triaged/scoped, low criticality, solutions to this kind of problem are provided but may need judgement or extension to identify the best approach. Design and implementation should be based on requirements gathering from immediate known stakeholders. May need low-level supervision/guidance. For mid-level, they are capable doing more of the problem triaging/classification and can handle vaguer, larger scoped problems. They can identify the correct stakeholders to engage with and, ideally, influence. Can identify the most likely best approach amongst a set of possible approaches. Guidance is high level- like a weekly or bi-weekly 1:1. Better design taste as far as how to measure outcomes or rollout changes safely. For senior you're ideally solving classes of problems rather than specific problems. You're charting a longer term roadmap that generates work and exerts influence amongst number of teams to drive long-term business outcomes. You are mentoring juniors/mid-levels so they're setup for success and have the right work at the right level of guidance at the right time to grow in their careers.