4 ms·

So really the same two skills that a senior engineer needs to delegate tasks to juniors & review the results..

skydhash 1y ago
Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.
- steveBK123 1y ago
  Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
  - strgcmc 1y ago
    I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025). Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now. Founders kind of have a perverse incentive, where a CTO doesn't need to solo code the first MVP, and also doesn't need to share/hand-out equity or make early hires quittteee as early, if unlimited interns can scale that CTO's solo productivity for a bit longer than the before-times.
    - skydhash 1y ago
      > Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now That's when experienced developers are a huge plus. They know how to cut corners in a way that will not hurt that much in the long term. It's more often intern level that are proposing stuff like next.js, kubernetes, cloud-native,... that will grind you to a halt once the first bugs appear. A very small team of good engineers will get you much further than any army of intern level coders.
      - steveBK123 1y ago
        Yeah "actually good engineers" are like a 10:1 ratio with intern/new college hire/junior consultant level. Not to generalize too much but if you are contracting out to some agency for junior levels, you are generally paying markup on coders who couldn't find better direct hire jobs to start with. At least with mid/senior level you can get into more of a hired-gun deal for someone who is between gigs/working part time/buy a share of their time you couldn't afford full-time. In fact most junior consultants you are basically paying for the privilege to train other peoples employees who will then be billed at a higher rate back to you when they improve.. if they don't move on otherwise.
    - lolinder 1y ago
      > but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years The point is that no one should hire an intern or a junior because they think it will improve their team's productivity. You hire interns and juniors because there's a causal link between "I hired an intern and spent money training them" and "they joined my company full time and a year later are now productive, contributing members of the team". It's an investment in the future, not a productivity boost today. There is no causal link between "I aggressively adopted Claude Code in 2025" and "Claude Code in 2026 functions as a full software engineer without babysitting". If I sit around and wait a year without adopting Claude Code that will have no measurable impact on Claude Code's 2026 performance, so why would I adopt it now if it's still at intern- or junior-level skill? If we accept that Claude is a junior-level contribution then the rational move is to wait and watch for now and only adopt it in earnest if and when it uplevels.
      - steveBK123 1y ago
        Precisely - AI getting better or not has nothing to do with my burning cycles using it. My juniors do improve based on my effort. I can free ride on AI getting good enough later (wait) whereas I cannot with my own team of juniors. > 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush Having worked in environments with a large number of junior contractors... this is generally a recipe for a lot of effort with resulting output that neither works technically nor actually delivers features.
        strgcmc 1y ago
        To your last point -- I didn't say large number of junior contractors would write good code or whatever. The change that is happening in the startup scene now, as compared to say 10 years ago, is more about lowering the barrier to MVP and making it easier/cheaper for startups to experiment with finding product market fit, than anything to do with "productivity" or code quality or whatever. We're probably just talking past each other, because the thing you care about is not the thing I care about. I am saying that, it used to cost some reference benchmark of $X/idea to iterate as a startup and experiment with ideas, but then it became 0.5X because gig workers or overseas contractors became more accessible and easier to work with, and now it's becoming 0.1X because of LLMs and coding agents. I am not making any sort of argument about quality being better/good/equal, nor am I making any sort of conversion chart between 10 interns or 100 LLM agents equals 1 senior engineer or something... Quality is rarely (never?) the deciding factor, when it comes to early pre-seed iteration as a startup tries to gasp and claw for something resembling traction. Cost to iterate as well as benefits of having more iterations, can be improving, even if each iteration's quality level is declining. I'm simply saying, if I was a founder, and I had $10k to spend to test new ideas with, I can test a helluva lot more ideas today (leveraging AI), vs what I could have done 5 years ago (using contractors), vs what I could have done 10-20 years ago (hiring FTEs, just to test out ideas, is frankly kind of absurd when you think about how expensive that is). I am not saying that $10k worth of Claude Code is going to buy me a production grade super fantastic amazing robust scalable elegant architecture or whatever, but it sure as heck can buy me a good enough working prototype and help me secure a seed round. Reducing that cost of experimentation is the real revolution (and whether interns can learn or will pay off over time is a wholly orthogonal topic that has no bearing to this cost of experimentation revolution).
  - skydhash 1y ago
    > In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year. And mostly their output is not really about incorrect code, but more likely incorrect approaches. By reviewing their code, you find gaps in their knowledge which you can then correct. They're here to learn, not to produce huge amount of code. The tasks are more for practice and evaluation than things you critically need. I don't want to work with a junior, but I'm more than happy to guide them to be someone I can work with.
- AndrewKemendo 1y ago
  Disagree. Some learn, not all and decreasing numbers career to learn Also most juniors have no idea how to write tests, plan for data scale, know which IPC-RPC combo is best for prototyping vs production Etc… 90% of software is architecture and juniors don’t architect
  - macNchz 1y ago
    > Disagree. Some learn, not all and decreasing numbers career to learn This is an organizational issue then—someone who is operating at a junior level who demonstrates that they don’t care to learn should be let go.
    - AndrewKemendo 1y ago
      We’re saying the same thing The business threshold (willingness to pay for something) for the worst automation will eventually beat the marginal expert. So there becomes no business differentiation between a junior and a middle engineer “Architecture” becomes the entry-level job
    - PeterStuer 1y ago
      But they are so cheap, and they increase the headcount on my pfiefdom chart.
      - steveBK123 1y ago
        Yes, a combination of empire building and "but $X exceeds the $Y cap set by HR for Z role! / we can hire XX juniors for this price!" type of mega corp thinking.
  - deleted 1y ago
    [deleted]
- CodeMage 1y ago
  Bingo! Not to mention that "dealing with juniors" is one of the critical ways for a senior engineer to grow.
AndrewKemendo 1y ago
This is exactly how to use it and exactly why it’s a huge deal In my experience so far, the people that aren’t getting value out of LLM code assistants, fundamentally like the process of writing code and using the tooling All of my senior, staff, principals love it because we can make something faster than having to deal with a junior because it’s trivial to write the spec/requirement for Claude etc…
- coldpie 1y ago
  > In my experience so far, the people that aren’t getting value out of LLM code assistants, fundamentally like the process of writing code and using the tooling > All of my senior, staff, principals love it because we can make something faster than having to deal with a junior because it’s trivial to write the spec/requirement for Claude etc… Hm, interesting. As someone who has found zero joy and value in using LLMs, this rings true to me. Setting aside the numerous glaring errors I get every time I try to use one, even if the tools were perfect, I don't think I would enjoy using them. I enjoy programming, thinking about how to break down a problem and form abstractions and fit those into the tools the language I'm writing in gives me. I enjoy learning and using the suite of Unix tools like grep and sed and vim to think about how to efficiently write and transform code. The end product isn't the fun part, the fun part is making the end product. If software engineering just becomes explaining stuff in English to a machine and having some software pop out... then I think the industry just isn't for me anymore. I don't want to hand the fun part over to a machine. It's like how I enjoy going to my wood shop to build tables instead of going to Ikea. It would be cheaper and faster and honestly maybe even better quality to go to Ikea, but the joy is in the knowledge and skill it takes to build the table from rough lumber.
  - AndrewKemendo 1y ago
    Software at scale is a business function You’re describing a hobby/artistry process You can still do all that, the same way that you can still build a table at your house. But the number of number of handmade table builders is going to drop to effectively zero for the majority of table building going forward

Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.

steveBK123 1y ago
Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
- strgcmc 1y ago
  I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025). Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now. Founders kind of have a perverse incentive, where a CTO doesn't need to solo code the first MVP, and also doesn't need to share/hand-out equity or make early hires quittteee as early, if unlimited interns can scale that CTO's solo productivity for a bit longer than the before-times.
  - skydhash 1y ago
    > Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now That's when experienced developers are a huge plus. They know how to cut corners in a way that will not hurt that much in the long term. It's more often intern level that are proposing stuff like next.js, kubernetes, cloud-native,... that will grind you to a halt once the first bugs appear. A very small team of good engineers will get you much further than any army of intern level coders.
    - steveBK123 1y ago
      Yeah "actually good engineers" are like a 10:1 ratio with intern/new college hire/junior consultant level. Not to generalize too much but if you are contracting out to some agency for junior levels, you are generally paying markup on coders who couldn't find better direct hire jobs to start with. At least with mid/senior level you can get into more of a hired-gun deal for someone who is between gigs/working part time/buy a share of their time you couldn't afford full-time. In fact most junior consultants you are basically paying for the privilege to train other peoples employees who will then be billed at a higher rate back to you when they improve.. if they don't move on otherwise.
  - lolinder 1y ago
    > but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years The point is that no one should hire an intern or a junior because they think it will improve their team's productivity. You hire interns and juniors because there's a causal link between "I hired an intern and spent money training them" and "they joined my company full time and a year later are now productive, contributing members of the team". It's an investment in the future, not a productivity boost today. There is no causal link between "I aggressively adopted Claude Code in 2025" and "Claude Code in 2026 functions as a full software engineer without babysitting". If I sit around and wait a year without adopting Claude Code that will have no measurable impact on Claude Code's 2026 performance, so why would I adopt it now if it's still at intern- or junior-level skill? If we accept that Claude is a junior-level contribution then the rational move is to wait and watch for now and only adopt it in earnest if and when it uplevels.
    - steveBK123 1y ago
      Precisely - AI getting better or not has nothing to do with my burning cycles using it. My juniors do improve based on my effort. I can free ride on AI getting good enough later (wait) whereas I cannot with my own team of juniors. > 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush Having worked in environments with a large number of junior contractors... this is generally a recipe for a lot of effort with resulting output that neither works technically nor actually delivers features.
      - strgcmc 1y ago
        To your last point -- I didn't say large number of junior contractors would write good code or whatever. The change that is happening in the startup scene now, as compared to say 10 years ago, is more about lowering the barrier to MVP and making it easier/cheaper for startups to experiment with finding product market fit, than anything to do with "productivity" or code quality or whatever. We're probably just talking past each other, because the thing you care about is not the thing I care about. I am saying that, it used to cost some reference benchmark of $X/idea to iterate as a startup and experiment with ideas, but then it became 0.5X because gig workers or overseas contractors became more accessible and easier to work with, and now it's becoming 0.1X because of LLMs and coding agents. I am not making any sort of argument about quality being better/good/equal, nor am I making any sort of conversion chart between 10 interns or 100 LLM agents equals 1 senior engineer or something... Quality is rarely (never?) the deciding factor, when it comes to early pre-seed iteration as a startup tries to gasp and claw for something resembling traction. Cost to iterate as well as benefits of having more iterations, can be improving, even if each iteration's quality level is declining. I'm simply saying, if I was a founder, and I had $10k to spend to test new ideas with, I can test a helluva lot more ideas today (leveraging AI), vs what I could have done 5 years ago (using contractors), vs what I could have done 10-20 years ago (hiring FTEs, just to test out ideas, is frankly kind of absurd when you think about how expensive that is). I am not saying that $10k worth of Claude Code is going to buy me a production grade super fantastic amazing robust scalable elegant architecture or whatever, but it sure as heck can buy me a good enough working prototype and help me secure a seed round. Reducing that cost of experimentation is the real revolution (and whether interns can learn or will pay off over time is a wholly orthogonal topic that has no bearing to this cost of experimentation revolution).
- skydhash 1y ago
  > In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year. And mostly their output is not really about incorrect code, but more likely incorrect approaches. By reviewing their code, you find gaps in their knowledge which you can then correct. They're here to learn, not to produce huge amount of code. The tasks are more for practice and evaluation than things you critically need. I don't want to work with a junior, but I'm more than happy to guide them to be someone I can work with.
AndrewKemendo 1y ago
Disagree. Some learn, not all and decreasing numbers career to learn Also most juniors have no idea how to write tests, plan for data scale, know which IPC-RPC combo is best for prototyping vs production Etc… 90% of software is architecture and juniors don’t architect
- macNchz 1y ago
  > Disagree. Some learn, not all and decreasing numbers career to learn This is an organizational issue then—someone who is operating at a junior level who demonstrates that they don’t care to learn should be let go.
  - AndrewKemendo 1y ago
    We’re saying the same thing The business threshold (willingness to pay for something) for the worst automation will eventually beat the marginal expert. So there becomes no business differentiation between a junior and a middle engineer “Architecture” becomes the entry-level job
  - PeterStuer 1y ago
    But they are so cheap, and they increase the headcount on my pfiefdom chart.
    - steveBK123 1y ago
      Yes, a combination of empire building and "but $X exceeds the $Y cap set by HR for Z role! / we can hire XX juniors for this price!" type of mega corp thinking.
- deleted 1y ago
  [deleted]
CodeMage 1y ago
Bingo! Not to mention that "dealing with juniors" is one of the critical ways for a senior engineer to grow.

AndrewKemendo 1y ago

This is exactly how to use it and exactly why it’s a huge deal In my experience so far, the people that aren’t getting value out of LLM code assistants, fundamentally like the process of writing code and using the tooling All of my senior, staff, principals love it because we can make something faster than having to deal with a junior because it’s trivial to write the spec/requirement for Claude etc…

coldpie 1y ago
> In my experience so far, the people that aren’t getting value out of LLM code assistants, fundamentally like the process of writing code and using the tooling > All of my senior, staff, principals love it because we can make something faster than having to deal with a junior because it’s trivial to write the spec/requirement for Claude etc… Hm, interesting. As someone who has found zero joy and value in using LLMs, this rings true to me. Setting aside the numerous glaring errors I get every time I try to use one, even if the tools were perfect, I don't think I would enjoy using them. I enjoy programming, thinking about how to break down a problem and form abstractions and fit those into the tools the language I'm writing in gives me. I enjoy learning and using the suite of Unix tools like grep and sed and vim to think about how to efficiently write and transform code. The end product isn't the fun part, the fun part is making the end product. If software engineering just becomes explaining stuff in English to a machine and having some software pop out... then I think the industry just isn't for me anymore. I don't want to hand the fun part over to a machine. It's like how I enjoy going to my wood shop to build tables instead of going to Ikea. It would be cheaper and faster and honestly maybe even better quality to go to Ikea, but the joy is in the knowledge and skill it takes to build the table from rough lumber.
- AndrewKemendo 1y ago
  Software at scale is a business function You’re describing a hobby/artistry process You can still do all that, the same way that you can still build a table at your house. But the number of number of handmade table builders is going to drop to effectively zero for the majority of table building going forward