5 ms·

I think you're right; I can see it in the accelerating growth curve of my good Junior devs; I see grandOP's vision in my bad Junior devs. Optimistically, I thin

I think you're right; I can see it in the accelerating growth curve of my good Junior devs; I see grandOP's vision in my bad Junior devs. Optimistically, I think this gives more jr devs more runway to advance deeper into more sophisticated tech stacks. I think we're gonna need more SW devs, not fewer, as these tools get better: things that were previously impossible will be possible.

zozbot234 2y ago
> more sophisticated tech stacks Please don't do this, pick more boring tech stacks https://news.ycombinator.com/item?id=43012862 https://news.ycombinator.com/item?id=43012862 instead. "Sophisticated" tech stacks are a huge waste, so please save the sophisticated stuff for the 0.1% of the time where you actually need it.
- marcosdumay 2y ago
  Sophistication doesn't imply any increase or decrease in "boringness".
  - zozbot234 2y ago
    The dictionary definition of 'sophisticated' is "changed in a deceptive or misleading way; not genuine or pure; unrefined, adulterated, impure." Pretty much the polar opposite of "boring" in a technology context.
    - rcxdude 2y ago
      That is an extremely archaic definition that's pretty far from modern usage, especially in a tech context
    - whstl 2y ago
      No, this is not "the" dictionary definition. This definition is obsolete according to Wikitionary: https://en.wiktionary.org/wiki/sophisticated https://en.wiktionary.org/wiki/sophisticated (Wikitionary is the first result that shows when I type your words)
    - Timwi 2y ago
      No clue what dictionary you looked at but this is not at all what dictionaries actually say.
- sophacles 2y ago
  That's great advice when you're building a simple CRUD app - use the paved roads for the 10^9th instance. It's terrible advice when you're building something that will cause that boring tech to fall over. Or when you've reached the limits of that boring tech and are still growing. Or when the sophisticated tech lowers CPU usage by 1% and saves your company millions of dollars. Or when that sophisticate tech saves your engineers hours and your company 10s of millions. Or just: when the boring tech doesn't actually do the things you need it to do.
  - zozbot234 2y ago
    "Boring" tech stacks tend to be highly scalable in their own right - certainly more so than the average of trendy newfangled tech. So what's a lot more likely is that the trendy newfangled tech will fail to meet your needs and you'll be moving to some even newer and trendier tech, at surprisingly high cost. The point of picking the "boring" choice is that it keeps you off that treadmill.
    - sophacles 2y ago
      I'm not disagreeing with anything you said here - reread my comment. Sometimes you want to use the sophisticated shiny new tech because you actually need it. Here's a recent example from a real situation: The linux kernel (a boring tech these days) has a great networking stack. It's choking on packets that need to be forwarded, and you've already tuned all the queues and the cpu affinities and timers and polling. Do you - a) buy more servers and network gear to spread your packets across more machines? (boring and expensive and introduces new ongoing costs of maintenance, datacenter costs, etc). b) Write a kernel module to process your packets more efficiently? (a boring, well known solution, introduces engineer costs to make and maintain as well as downtime because the new shiny module is buggy?) c) Port your whole stack to a different OS (risky, but choosing a different boring stack should suffice... if youre certain that it can handle the load without kernel code changes/modules). d) Write a whole userspace networking system (trendy and popular - your engineers are excited about this, expensive in eng time, risks lots of bugs that are already solved by the kernel just fine, have to re-invent a lot of stuff that exists elsewhere) e) Use ebpf to fast path your packets around the kernel processing that you don't need? (trendy and popular - your engineers are excited about this, inexpensive relative to the other choices, introduces some new bugs and stability issues til the kinks are worked out) We sinned and went with (e). That new-fangled tech met our needs quite well - we still had to buy more gear but far less than projected before we went with (e). We're actually starting to reach limits of ebpf for some of our packet operations too so we've started looking at (d) which has come down in costs and risk as we understand our product and needs better. I'm glad we didn't go the boring path - our budget wasn't eaten up with trying to make all that work and we could afford to build features our customers buy instead. We also use postgres to store a bunch of user data. I'm glad we went the boring path there - it just works and we don't have to think about it, and that lack of attention has afforded us the chance to work on features customers buy instead. The point isn't "don't choose boring". It's: blindly choosing boring instead of evaluating your actual needs and options from a knowledgeable place is unwise.
- itronitron 2y ago
  Today I learned that some tech stacks are sophisticated, I suppose those are for the discerning developer.
- ungreased0675 2y ago
  An edge case in startups is something that provides a competitive advantage. When you run a startup, you have to do something different from the way everyone else does, or you’ll get the same results everyone else does. My theory is that some part of a startup’s operations should be cutting edge. HR processes, programming stack, sales cycle, something.
gorjusborg 2y ago
> I think we're gonna need more SW devs, not fewer Code is a liability. What we really care about is the outcome, not the code. These AI tools are great at generating code, but are they good at maintaining the generated code? Not from what I've seen. So there's a good chance we'll see people using tools to generate a ton of instant legacy code (because nobody in house has ever understood it) which, if it hits production, will require skilled people to figure out how to support it.
- kmoser 2y ago
  We will see both: lots of poor code, lots of neutral code (LLMs cranking out reasonably well written boilerplate), and even some improved code (by devs who use LLMs to ferret out inefficiencies and bugs in their existing, human-written codebase). This is no different from what we see with any tool or language: the results are highly dependent on the experience and skills of the operator.
  - gorjusborg 2y ago
    You've missed my core point if you think those isn't different. Before AI there was always someone who understood the code/system. In the a world where people are having machines build the entire system, there is potentially no human that has ever understood it. Now, we are talking about a yet unseen future; I have yet to see a real world system that did not have a human driving the design. But, maintaining a system that nobody has ever understood could be ultra-hardmode.
    - kmoser 2y ago
      Humans will always have a hand in the design because they need to explain the real-world constraints to the AI. Sure, the code it produces may be complex, but if the AI is really as smart as you're claiming it will eventually be, then it will also have the ability to explain how the code works in plain English (or your human language of choice). Even today, LLMs are remarkably good at summarizing what code does. Philosophical question: how is LLM-produced code that nobody has ever understood any different from human-written legacy code that nobody alive today understands?
thomasfromcdnjs 2y ago
I agree with this stance. Junior developers are going to learn faster than previous generations, and I'm happy for it. I know that is confronting for a lot of people, but I think it is better to accept it, and spend time thinking about what your experience is worth. (A lot!)
- zahlman 2y ago
  >Junior developers are going to learn faster than previous generations, and I'm happy for it. I would have agreed, until I started seeing the kinds of questions they're asking.
- Glawen 2y ago
  > Junior developers are going to learn faster than previous generations, and I'm happy for it. How? Students now are handing out LLM homework left and right. They are not nurturing the resolve to learn. We are training a cohort of youngs who will give up without trying hard, and end learning nothing

zozbot234 2y ago

> more sophisticated tech stacks Please don't do this, pick more boring tech stacks https://news.ycombinator.com/item?id=43012862 https://news.ycombinator.com/item?id=43012862 instead. "Sophisticated" tech stacks are a huge waste, so please save the sophisticated stuff for the 0.1% of the time where you actually need it.

marcosdumay 2y ago
Sophistication doesn't imply any increase or decrease in "boringness".
- zozbot234 2y ago
  The dictionary definition of 'sophisticated' is "changed in a deceptive or misleading way; not genuine or pure; unrefined, adulterated, impure." Pretty much the polar opposite of "boring" in a technology context.
  - rcxdude 2y ago
    That is an extremely archaic definition that's pretty far from modern usage, especially in a tech context
  - whstl 2y ago
    No, this is not "the" dictionary definition. This definition is obsolete according to Wikitionary: https://en.wiktionary.org/wiki/sophisticated https://en.wiktionary.org/wiki/sophisticated (Wikitionary is the first result that shows when I type your words)
  - Timwi 2y ago
    No clue what dictionary you looked at but this is not at all what dictionaries actually say.
sophacles 2y ago
That's great advice when you're building a simple CRUD app - use the paved roads for the 10^9th instance. It's terrible advice when you're building something that will cause that boring tech to fall over. Or when you've reached the limits of that boring tech and are still growing. Or when the sophisticated tech lowers CPU usage by 1% and saves your company millions of dollars. Or when that sophisticate tech saves your engineers hours and your company 10s of millions. Or just: when the boring tech doesn't actually do the things you need it to do.
- zozbot234 2y ago
  "Boring" tech stacks tend to be highly scalable in their own right - certainly more so than the average of trendy newfangled tech. So what's a lot more likely is that the trendy newfangled tech will fail to meet your needs and you'll be moving to some even newer and trendier tech, at surprisingly high cost. The point of picking the "boring" choice is that it keeps you off that treadmill.
  - sophacles 2y ago
    I'm not disagreeing with anything you said here - reread my comment. Sometimes you want to use the sophisticated shiny new tech because you actually need it. Here's a recent example from a real situation: The linux kernel (a boring tech these days) has a great networking stack. It's choking on packets that need to be forwarded, and you've already tuned all the queues and the cpu affinities and timers and polling. Do you - a) buy more servers and network gear to spread your packets across more machines? (boring and expensive and introduces new ongoing costs of maintenance, datacenter costs, etc). b) Write a kernel module to process your packets more efficiently? (a boring, well known solution, introduces engineer costs to make and maintain as well as downtime because the new shiny module is buggy?) c) Port your whole stack to a different OS (risky, but choosing a different boring stack should suffice... if youre certain that it can handle the load without kernel code changes/modules). d) Write a whole userspace networking system (trendy and popular - your engineers are excited about this, expensive in eng time, risks lots of bugs that are already solved by the kernel just fine, have to re-invent a lot of stuff that exists elsewhere) e) Use ebpf to fast path your packets around the kernel processing that you don't need? (trendy and popular - your engineers are excited about this, inexpensive relative to the other choices, introduces some new bugs and stability issues til the kinks are worked out) We sinned and went with (e). That new-fangled tech met our needs quite well - we still had to buy more gear but far less than projected before we went with (e). We're actually starting to reach limits of ebpf for some of our packet operations too so we've started looking at (d) which has come down in costs and risk as we understand our product and needs better. I'm glad we didn't go the boring path - our budget wasn't eaten up with trying to make all that work and we could afford to build features our customers buy instead. We also use postgres to store a bunch of user data. I'm glad we went the boring path there - it just works and we don't have to think about it, and that lack of attention has afforded us the chance to work on features customers buy instead. The point isn't "don't choose boring". It's: blindly choosing boring instead of evaluating your actual needs and options from a knowledgeable place is unwise.
itronitron 2y ago
Today I learned that some tech stacks are sophisticated, I suppose those are for the discerning developer.
ungreased0675 2y ago
An edge case in startups is something that provides a competitive advantage. When you run a startup, you have to do something different from the way everyone else does, or you’ll get the same results everyone else does. My theory is that some part of a startup’s operations should be cutting edge. HR processes, programming stack, sales cycle, something.

gorjusborg 2y ago

> I think we're gonna need more SW devs, not fewer Code is a liability. What we really care about is the outcome, not the code. These AI tools are great at generating code, but are they good at maintaining the generated code? Not from what I've seen. So there's a good chance we'll see people using tools to generate a ton of instant legacy code (because nobody in house has ever understood it) which, if it hits production, will require skilled people to figure out how to support it.

kmoser 2y ago
We will see both: lots of poor code, lots of neutral code (LLMs cranking out reasonably well written boilerplate), and even some improved code (by devs who use LLMs to ferret out inefficiencies and bugs in their existing, human-written codebase). This is no different from what we see with any tool or language: the results are highly dependent on the experience and skills of the operator.
- gorjusborg 2y ago
  You've missed my core point if you think those isn't different. Before AI there was always someone who understood the code/system. In the a world where people are having machines build the entire system, there is potentially no human that has ever understood it. Now, we are talking about a yet unseen future; I have yet to see a real world system that did not have a human driving the design. But, maintaining a system that nobody has ever understood could be ultra-hardmode.
  - kmoser 2y ago
    Humans will always have a hand in the design because they need to explain the real-world constraints to the AI. Sure, the code it produces may be complex, but if the AI is really as smart as you're claiming it will eventually be, then it will also have the ability to explain how the code works in plain English (or your human language of choice). Even today, LLMs are remarkably good at summarizing what code does. Philosophical question: how is LLM-produced code that nobody has ever understood any different from human-written legacy code that nobody alive today understands?

thomasfromcdnjs 2y ago

I agree with this stance. Junior developers are going to learn faster than previous generations, and I'm happy for it. I know that is confronting for a lot of people, but I think it is better to accept it, and spend time thinking about what your experience is worth. (A lot!)

zahlman 2y ago
>Junior developers are going to learn faster than previous generations, and I'm happy for it. I would have agreed, until I started seeing the kinds of questions they're asking.
Glawen 2y ago
> Junior developers are going to learn faster than previous generations, and I'm happy for it. How? Students now are handing out LLM homework left and right. They are not nurturing the resolve to learn. We are training a cohort of youngs who will give up without trying hard, and end learning nothing