18 ms·

This is a sentiment that I've seen expressed in comment sections many times. I've been programming professionally now for 10 years, and it just doesn't resonate

This is a sentiment that I've seen expressed in comment sections many times. I've been programming professionally now for 10 years, and it just doesn't resonate with my experience. Problems with build systems for external dependencies, package managers, and underfeatured / overcomplicated / buggy third party dependencies have been by far the worse issue in my career, compared to problems with homebrewed systems. I'm not saying you're wrong, I don't doubt that many people have the opposite experience. It just makes me feel a bit alien when I read comments like this.

marcosdumay 2y ago
I've been there, on both sides, with homebrew ideas pushed from up and down, some that worked nicely, and some that were complete disasters... And I agree with you. The problems with third party dependencies are way worse than any in-house complete disaster. But that happens almost certainly because everybody is severely biased into adding dependencies. Make people biased into NIH again, and the homebrew systems will become the largest problems again.
- lukan 2y ago
  "because everybody is severely biased into adding dependencies" When I make a request to chatGPT to show me a example of something with javascript and node - it always brings me a solution with a external libary needed. So I have to add "without external dependencies" - then it presents me a nice and clean solution without all the garbage I don't need. So apparently adding yet another libary seems normal for many people, otherwise this behavior would not replicate in an LLM.
  - pca006132 2y ago
    This depends on languages. For c/c++ without a package manager, people hesitate to add external dependencies (and especially when high performance is needed, e.g. game engines).
    - lukan 2y ago
      It surely does, but I think in most languages it is a bad idea, to add a external dependency, where it isn't needed. Like in the cases I mentioned, it was just standard stuff, already covered by the browser standard libaries. So when I just need a simple connection to a web socket - I don't need that external baggage. But for high performance graphics, yeah, I won't write all the WebGL code by hand, but use Pixi (with the option of writing my own shader where needed).
  - OtomotO 2y ago
    It simply depends on what you need. I am gladly writing my own left-pad. I am gladly using something like three.js if I need it. The problem are the extreme stances. Don't add any dependency is as stupid as pulling in dependencies for every second line.
    - wizzwizz4 2y ago
      Please don't write your own left-pad. It's built into the standard library, under the name (String.prototype.)padStart.
      - shermantanktop 2y ago
        That example was not picked at random.
      - OtomotO 2y ago
        Exemplum docet
        wizzwizz4 2y ago
        I have seen this argument made many times, but none of the examples used illustrated it properly. Past a certain point, one becomes suspicious of the argument itself.
        chipsrafferty 2y ago
        Have you ever wondered why padStart is part of the standard library? You are unaware of a core part of JavaScript history, which is why you don't understand why "I'm not importing a library to do left pad" is not only a proper example, but THE BEST example. String.padStart was added in 2017. This happened in 2016 https://en.m.wikipedia.org/wiki/Npm_left-pad_incident https://en.m.wikipedia.org/wiki/Npm_left-pad_incident
        wizzwizz4 2y ago
  - sgarland 2y ago
    Same. My standing system prompt for Claude is “do not suggest any 3rd party libraries unless I ask for other options.” Python perhaps isn’t quite as bad as JS in this regard, but people still have a tendency to pull in numpy for trivial problems that stdlib can easily solve, and requests to make a couple of simple HTTP calls.
    - fragmede 2y ago
      fascinating. What sort of web requests are you doing stuff are you doing that it's not just easier to use requests? I use requests pathologically, though I use things in the stdlib when it comes to it. personally I'm more surprised that it isn't in the stdlib by this point.
      - sgarland 2y ago
        It's not a matter of easier, it's that I'm against adding dependencies when they're not meaningfully adding value. It's not that hard to use urllib.request if you just need to pull down some file in a script, or fire a web hook, etc. If you need connection pooling, keep-alive, or any of the other features that requests adds, then sure, add it.
- eitland 2y ago
  In the two last projects I have worked on I have been lucky to work with great younger developers that neither invent things from scratch nor insist on pulling in exotic dependencies. We have used mainstream technologies like just Quarkus or Spring Boot and plain React with Typescript and the absolute bare minimum of dependencies. I have worked with a number of good devs over the years but it is amazing how productive these teams have been. (Should probably also mention that we were also lucky to have great non technical people on those teams.)
quantadev 2y ago
This kind of thing admittedly isn't as pervasive in the last decade as it was the two before, so if you've been a dev only since 2014 years you may not have seen it. The old people like me will get it tho.
dylan604 2y ago
Not targeting you, but the industry in general. In every other industry I've been in outside of software dev, 10 years is not considered elder. You're just now becoming not a greenhorn. You're just now getting your sea legs. It's amazing what additional experience happens after year 10. To that effect, Rust (2015) is 9 years old, Go and Node are 15 years old. While Python (1991) is 33 years old. Just putting things in a different perspective
- Cthulhu_ 2y ago
  It just feels different in software development because things have moved very fast, I'd say especially when github rose to prominence. The amount of software developers on the market has also increased exponentially since then, so the amount of (relatively) junior developers is much higher than those of 15, 20+ years of experience.
  - jltsiren 2y ago
    The number of software developers has maybe doubled in the last 20 years. The number of senior developers has "always" been low, because the field suffers from unusually high attrition. Many people find that software is not for them, many switch fields after losing their jobs in an economic downturn, some move to management, and some make too much money to bother continuing until retirement age.
    - mrkeen 2y ago
      Has there actually been attrition? Exponential growth is enough to explain "many more juniors than seniors" at any time in the past, present or future. Also for attrition to be the cause, you'd need a lot more seniors dropping off than juniors.
      - jltsiren 2y ago
        The exponential growth has been something like 3-4%/year, or 2x in 20 years. Though it's hard to find useful statistics that take different job titles and changing nature of the industry properly into account. If you had asked me in 2010, I would have said that the median software developer lasts 5-10 years in the industry. A lot of people left the field after the dot-com bubble burst. The same happened again in a smaller scale in the late 2000s, at least in countries where the financial crisis was a real-world event (and not just something you heard about in the news). But now there has been ~15 years of sustained growth, and the ratio of mid-career developers to juniors may even be higher than usual.
RangerScience 2y ago
I've seen both, although rarely for either. The worse trash fires were the homebrewed systems, but maybe that's because I could dig in and see how bad they were. But I'd actually agree with you - as bad as those were, I'd rather them than a shitty 3rd party something. At least I can theoretically do something about the in-house one, and, all the ones I've seen were smaller in scope than any SaaS product.
tazjin 2y ago
It's people trying to generalise some rule over the wrong thing. The right thing is that, in both directions, how the project goes is simply a skill question. You have unskilled, sloppy developers? The homebrew project AND the third-party integration will turn out a mess.
kaba0 2y ago
Well, foreign projects communicating with each other is always ground for a mess, but this is not an either-or question. Also, your mileage may vary based on the niche you are working on - in case of, say java, the initial setup of the build system may not be "fun", but it will just work from then on.
jesse__ 2y ago
Strong agree here. I tend to try as hard as I can to write as much as I can in house so that when shit hits the fan, I have a great chance of being able to do something about it. Shelling out to an AST parsing library that happens to be slow? Well, shit, that sucks. Guess your compilers just slow now.
cmrdporcupine 2y ago
The argument is not between NIH and external deps. The argument is over needless complexity and brittle unreliable bits (which can come through either channel) vs keeping things simple. In my experience, younger developers will push both (in-house and external) directions at once, actually. Building out complex edifices with sharp corners over a maze of transitive dependencies that few understand. It's the same thing: A fantasy that a framework will solve the problem, combined with a fantasy that they can develop said framework. It's an urge we all suffer from but some of us have learned the hard way to be careful about. (And others who are great at self-promotion have been rewarded for it by naive investors and managers.) Finding simple solutions takes humility and time.
eitally 2y ago
I think this depends a lot on whether you're already using high level languages and lots of external libraries vs doing lower level programming using something like C/C++. I managed a large dev team in a Microsoft shop and it would never have occurred to anyone to ever create their own compiler. Even the most experienced programmers would have just continued to brute force things atop .Net's compiler until it eventually "worked". The result, combined with esoteric and poorly understood business requirements, was fragile spaghetti code few could parse for bugs or updates, but it was still several layers above the compiler. This attitude is by far the most common among "enterprise developers", and one of the big differences between people building things from preexisting building blocks vs -- as witnessed from my 8 years at Google later -- people who think they're smart enough to build everything from the ground up, and do so, using primitive blocks and custom compilers created by similarly hubristic engineers who came before them. Ymmv, but this has been my experience over the past 25 years.
- neonsunset 2y ago
  To be fair expression trees offer nice capability to write your mini-dsl, then map it to expressions and then compile it. It’s just an uncommon attitude to most enterprise teams, it has less to do with the language and more to do with the part of the industry. I wish more teams knew the tools they already have at their disposal.
MobiusHorizons 2y ago
Thanks for saying this, I feel this way all the time even though I know it’s against the prevailing wisdom. My experience is that in the pursuit of not reinventing the wheel, I am frequently told to use a dependency that doesn’t allow us to solve the whole problem, or prevents us from making making the user experience fast or cannot be made to understand our data model. It’s all well and good to use a tool that exists, but using the wrong tool just because it exists is madness. Even worse is when dependencies are deprecated or our use cases become unsupported. Honestly I would prefer to just build everything above the database layer in house, that way we at least know what we can and can’t deliver, and have some chance of fixing things when they break.
- PartiallyTyped 2y ago
  I am practically having this conversation at work. There's a sister team with a great tool for benchmarking what they are working on, but it is not convenient for our needs, and I am told to "just do the plumbing to make it work for our needs". Reality is that there are far, far easier ways to achieve what we need than doing all that plumbing, adding more layers of abstraction on top of what is a side project of an adjacent team.
- solatic 2y ago
  When dependencies don't deliver 100% of what you want, you should be able to work with upstream to get what you want added. If upstream won't cooperate with you, then fork. It's still usually better to start from a battle-hardened codebase than it is from complete scratch.
- anal_reactor 2y ago
  The problem with being smarter than average programmer is that your insights will rarely ever be considered, even if they're correct, because they're new and controversial. That's because, from the perspective of an average programmer, a bad programmer who doesn't know what they're doing, and a programmer using techniques so advanced that they cannot be understood, are effectively indistinguishable, which means that average team will treat both geniuses and morons in the same way. I feel like the collapse of the tech bro coincided with the masses going to programming, which changed the culture from promoting innovation and development, into simply following whatever best practices someone had already written, turning programming from a creative job into yet another repetitive office job. This is also, in my opinion, the true reason why salaries collapsed. Most business don't need creative specialists, they need code monkeys, and most people aren't creative specialists, they're code monkeys. So why would the salary worthy of a creative specialist even be talked about over here?
rzwitserloot 2y ago
Yes. And one of those vaunted differences between 'senior' and 'medior' is knowing the difference. Because I can confirm what you said: Both experiences are real. Brewing it up yourself can blow up in your face. Reaching for external deps that solve the problem can blow up in your face. Knowing which choice to make is _tricky_ and is hard to confirm. It doesn't sit well with programmers; either solution will _work_ (you can't write a unit test that 'fails' if you made the wrong choice here), and even if you're willing to accept highly suspect, Goodhart's law-susceptible metrics such as LOC, you still can't get anywhere because it's trading off more code you have to write and maintain without help from a larger community against having fewer lines _in total_ as part of the system. I do not know of any way to do it right other than to apply a ton of experience. And it's really hard to keep yourself honest. Even if you're willing to wait 5 years and then spend some time looking back, how do you really know? Anybody with a bunch of experience has seen enough homebrew stuff asplode in their face to be able to paint a picture with how utterly badly that choice could go. If you chose the 'build it on external deps' route you can easily tell yourself you did it right by painting a terrible picture of how it would have gone if you made the other choice. But the reverse is just as true. I think I'm really good at it. But, writing about it here, I don't have any real basis to make that claim. I look around at other dev shops that make products of similar complexity and it feels like they need 10x to 100x more resources, have more downtime, and have far larger dev teams. But no doubt bias is creeping in there too, and no 2 software products are 100% comparable in this sense. I naturally trust homebrewers more because they tend to understand complex technical things better. Someone who can just glue libraries together is lost when I ask them to fire up a debugger and figure out why some interaction is not working. A hopeless NIH sufferer needs to be 'supervised' and their choices about what to write needs to be questioned, but, that's doable with supervision. "Just git gud and be technically proficient" not so much. But then maybe that's bias too - that leads to a codebase that is easier navigated when you're familiar with debuggers and reading code to understand it. Reaching for third party deps a lot leads to a codebase that is easier navigated when you're familiar with docs and tutorials. These are self fulfilling prophecies.
- vanitywords 2y ago
  Been in software 25 years and was board design for telecom before that. Vaunted is a vanity word. I get what you mean based upon experience and I still prefer custom systems that eschew layers of syntax sugar. EE was way harder than managing a code base. The syntax patterns are of a finite set of values. I won’t re-roll encryption libs but there’s a lot of “tooling” packages that just add syntax sugar to parse and cart around that came about in prior eras of sneakerware software that are baked into to development habits that no longer make sense. I for one am excited about using ML to streamline the code base that comprised my preferred Linux system yet still builds to the usual runtime system. There’s a lot of duplication in code that models can help remove and a few tools can help unpack into machine state. EE brain informs me there’s no “code” in a running system. Just electricity. There’s way too much syntax sugar in the software ecosystem that’s just for parsing/marshaling/transpiling between syntax sugars. Bleh. It’s a big dumb monolith of glyph art that needs to be whacked back like a prairie that needs a controlled fire.
segfaltnh 2y ago
I've spent most of my career in the infrastructure space and I agree with this so much. These days prevailing wisdom is just to use 20 off the shelf open source components and spend your entire day debugging YAML integrations. I think we've lost our minds a bit because of this prevailing wisdom that building a simple wheel that does the 10% of this you actually need is somehow self-indulgence or negligent or both.

marcosdumay 2y ago

I've been there, on both sides, with homebrew ideas pushed from up and down, some that worked nicely, and some that were complete disasters... And I agree with you. The problems with third party dependencies are way worse than any in-house complete disaster. But that happens almost certainly because everybody is severely biased into adding dependencies. Make people biased into NIH again, and the homebrew systems will become the largest problems again.

lukan 2y ago
"because everybody is severely biased into adding dependencies" When I make a request to chatGPT to show me a example of something with javascript and node - it always brings me a solution with a external libary needed. So I have to add "without external dependencies" - then it presents me a nice and clean solution without all the garbage I don't need. So apparently adding yet another libary seems normal for many people, otherwise this behavior would not replicate in an LLM.
- pca006132 2y ago
  This depends on languages. For c/c++ without a package manager, people hesitate to add external dependencies (and especially when high performance is needed, e.g. game engines).
  - lukan 2y ago
    It surely does, but I think in most languages it is a bad idea, to add a external dependency, where it isn't needed. Like in the cases I mentioned, it was just standard stuff, already covered by the browser standard libaries. So when I just need a simple connection to a web socket - I don't need that external baggage. But for high performance graphics, yeah, I won't write all the WebGL code by hand, but use Pixi (with the option of writing my own shader where needed).
- OtomotO 2y ago
  It simply depends on what you need. I am gladly writing my own left-pad. I am gladly using something like three.js if I need it. The problem are the extreme stances. Don't add any dependency is as stupid as pulling in dependencies for every second line.
  - wizzwizz4 2y ago
    Please don't write your own left-pad. It's built into the standard library, under the name (String.prototype.)padStart.
    - shermantanktop 2y ago
      That example was not picked at random.
    - OtomotO 2y ago
      Exemplum docet
      - wizzwizz4 2y ago
        I have seen this argument made many times, but none of the examples used illustrated it properly. Past a certain point, one becomes suspicious of the argument itself.
        chipsrafferty 2y ago
        Have you ever wondered why padStart is part of the standard library? You are unaware of a core part of JavaScript history, which is why you don't understand why "I'm not importing a library to do left pad" is not only a proper example, but THE BEST example. String.padStart was added in 2017. This happened in 2016 https://en.m.wikipedia.org/wiki/Npm_left-pad_incident https://en.m.wikipedia.org/wiki/Npm_left-pad_incident
        wizzwizz4 2y ago
- sgarland 2y ago
  Same. My standing system prompt for Claude is “do not suggest any 3rd party libraries unless I ask for other options.” Python perhaps isn’t quite as bad as JS in this regard, but people still have a tendency to pull in numpy for trivial problems that stdlib can easily solve, and requests to make a couple of simple HTTP calls.
  - fragmede 2y ago
    fascinating. What sort of web requests are you doing stuff are you doing that it's not just easier to use requests? I use requests pathologically, though I use things in the stdlib when it comes to it. personally I'm more surprised that it isn't in the stdlib by this point.
    - sgarland 2y ago
      It's not a matter of easier, it's that I'm against adding dependencies when they're not meaningfully adding value. It's not that hard to use urllib.request if you just need to pull down some file in a script, or fire a web hook, etc. If you need connection pooling, keep-alive, or any of the other features that requests adds, then sure, add it.
eitland 2y ago
In the two last projects I have worked on I have been lucky to work with great younger developers that neither invent things from scratch nor insist on pulling in exotic dependencies. We have used mainstream technologies like just Quarkus or Spring Boot and plain React with Typescript and the absolute bare minimum of dependencies. I have worked with a number of good devs over the years but it is amazing how productive these teams have been. (Should probably also mention that we were also lucky to have great non technical people on those teams.)

quantadev 2y ago

This kind of thing admittedly isn't as pervasive in the last decade as it was the two before, so if you've been a dev only since 2014 years you may not have seen it. The old people like me will get it tho.

dylan604 2y ago

Not targeting you, but the industry in general. In every other industry I've been in outside of software dev, 10 years is not considered elder. You're just now becoming not a greenhorn. You're just now getting your sea legs. It's amazing what additional experience happens after year 10. To that effect, Rust (2015) is 9 years old, Go and Node are 15 years old. While Python (1991) is 33 years old. Just putting things in a different perspective

Cthulhu_ 2y ago
It just feels different in software development because things have moved very fast, I'd say especially when github rose to prominence. The amount of software developers on the market has also increased exponentially since then, so the amount of (relatively) junior developers is much higher than those of 15, 20+ years of experience.
- jltsiren 2y ago
  The number of software developers has maybe doubled in the last 20 years. The number of senior developers has "always" been low, because the field suffers from unusually high attrition. Many people find that software is not for them, many switch fields after losing their jobs in an economic downturn, some move to management, and some make too much money to bother continuing until retirement age.
  - mrkeen 2y ago
    Has there actually been attrition? Exponential growth is enough to explain "many more juniors than seniors" at any time in the past, present or future. Also for attrition to be the cause, you'd need a lot more seniors dropping off than juniors.
    - jltsiren 2y ago
      The exponential growth has been something like 3-4%/year, or 2x in 20 years. Though it's hard to find useful statistics that take different job titles and changing nature of the industry properly into account. If you had asked me in 2010, I would have said that the median software developer lasts 5-10 years in the industry. A lot of people left the field after the dot-com bubble burst. The same happened again in a smaller scale in the late 2000s, at least in countries where the financial crisis was a real-world event (and not just something you heard about in the news). But now there has been ~15 years of sustained growth, and the ratio of mid-career developers to juniors may even be higher than usual.

RangerScience 2y ago

I've seen both, although rarely for either. The worse trash fires were the homebrewed systems, but maybe that's because I could dig in and see how bad they were. But I'd actually agree with you - as bad as those were, I'd rather them than a shitty 3rd party something. At least I can theoretically do something about the in-house one, and, all the ones I've seen were smaller in scope than any SaaS product.

tazjin 2y ago

It's people trying to generalise some rule over the wrong thing. The right thing is that, in both directions, how the project goes is simply a skill question. You have unskilled, sloppy developers? The homebrew project AND the third-party integration will turn out a mess.

kaba0 2y ago

Well, foreign projects communicating with each other is always ground for a mess, but this is not an either-or question. Also, your mileage may vary based on the niche you are working on - in case of, say java, the initial setup of the build system may not be "fun", but it will just work from then on.

jesse__ 2y ago

Strong agree here. I tend to try as hard as I can to write as much as I can in house so that when shit hits the fan, I have a great chance of being able to do something about it. Shelling out to an AST parsing library that happens to be slow? Well, shit, that sucks. Guess your compilers just slow now.

cmrdporcupine 2y ago

The argument is not between NIH and external deps. The argument is over needless complexity and brittle unreliable bits (which can come through either channel) vs keeping things simple. In my experience, younger developers will push both (in-house and external) directions at once, actually. Building out complex edifices with sharp corners over a maze of transitive dependencies that few understand. It's the same thing: A fantasy that a framework will solve the problem, combined with a fantasy that they can develop said framework. It's an urge we all suffer from but some of us have learned the hard way to be careful about. (And others who are great at self-promotion have been rewarded for it by naive investors and managers.) Finding simple solutions takes humility and time.

eitally 2y ago

I think this depends a lot on whether you're already using high level languages and lots of external libraries vs doing lower level programming using something like C/C++. I managed a large dev team in a Microsoft shop and it would never have occurred to anyone to ever create their own compiler. Even the most experienced programmers would have just continued to brute force things atop .Net's compiler until it eventually "worked". The result, combined with esoteric and poorly understood business requirements, was fragile spaghetti code few could parse for bugs or updates, but it was still several layers above the compiler. This attitude is by far the most common among "enterprise developers", and one of the big differences between people building things from preexisting building blocks vs -- as witnessed from my 8 years at Google later -- people who think they're smart enough to build everything from the ground up, and do so, using primitive blocks and custom compilers created by similarly hubristic engineers who came before them. Ymmv, but this has been my experience over the past 25 years.

neonsunset 2y ago
To be fair expression trees offer nice capability to write your mini-dsl, then map it to expressions and then compile it. It’s just an uncommon attitude to most enterprise teams, it has less to do with the language and more to do with the part of the industry. I wish more teams knew the tools they already have at their disposal.

MobiusHorizons 2y ago

Thanks for saying this, I feel this way all the time even though I know it’s against the prevailing wisdom. My experience is that in the pursuit of not reinventing the wheel, I am frequently told to use a dependency that doesn’t allow us to solve the whole problem, or prevents us from making making the user experience fast or cannot be made to understand our data model. It’s all well and good to use a tool that exists, but using the wrong tool just because it exists is madness. Even worse is when dependencies are deprecated or our use cases become unsupported. Honestly I would prefer to just build everything above the database layer in house, that way we at least know what we can and can’t deliver, and have some chance of fixing things when they break.

PartiallyTyped 2y ago
I am practically having this conversation at work. There's a sister team with a great tool for benchmarking what they are working on, but it is not convenient for our needs, and I am told to "just do the plumbing to make it work for our needs". Reality is that there are far, far easier ways to achieve what we need than doing all that plumbing, adding more layers of abstraction on top of what is a side project of an adjacent team.
solatic 2y ago
When dependencies don't deliver 100% of what you want, you should be able to work with upstream to get what you want added. If upstream won't cooperate with you, then fork. It's still usually better to start from a battle-hardened codebase than it is from complete scratch.
anal_reactor 2y ago
The problem with being smarter than average programmer is that your insights will rarely ever be considered, even if they're correct, because they're new and controversial. That's because, from the perspective of an average programmer, a bad programmer who doesn't know what they're doing, and a programmer using techniques so advanced that they cannot be understood, are effectively indistinguishable, which means that average team will treat both geniuses and morons in the same way. I feel like the collapse of the tech bro coincided with the masses going to programming, which changed the culture from promoting innovation and development, into simply following whatever best practices someone had already written, turning programming from a creative job into yet another repetitive office job. This is also, in my opinion, the true reason why salaries collapsed. Most business don't need creative specialists, they need code monkeys, and most people aren't creative specialists, they're code monkeys. So why would the salary worthy of a creative specialist even be talked about over here?

rzwitserloot 2y ago

Yes. And one of those vaunted differences between 'senior' and 'medior' is knowing the difference. Because I can confirm what you said: Both experiences are real. Brewing it up yourself can blow up in your face. Reaching for external deps that solve the problem can blow up in your face. Knowing which choice to make is _tricky_ and is hard to confirm. It doesn't sit well with programmers; either solution will _work_ (you can't write a unit test that 'fails' if you made the wrong choice here), and even if you're willing to accept highly suspect, Goodhart's law-susceptible metrics such as LOC, you still can't get anywhere because it's trading off more code you have to write and maintain without help from a larger community against having fewer lines _in total_ as part of the system. I do not know of any way to do it right other than to apply a ton of experience. And it's really hard to keep yourself honest. Even if you're willing to wait 5 years and then spend some time looking back, how do you really know? Anybody with a bunch of experience has seen enough homebrew stuff asplode in their face to be able to paint a picture with how utterly badly that choice could go. If you chose the 'build it on external deps' route you can easily tell yourself you did it right by painting a terrible picture of how it would have gone if you made the other choice. But the reverse is just as true. I think I'm really good at it. But, writing about it here, I don't have any real basis to make that claim. I look around at other dev shops that make products of similar complexity and it feels like they need 10x to 100x more resources, have more downtime, and have far larger dev teams. But no doubt bias is creeping in there too, and no 2 software products are 100% comparable in this sense. I naturally trust homebrewers more because they tend to understand complex technical things better. Someone who can just glue libraries together is lost when I ask them to fire up a debugger and figure out why some interaction is not working. A hopeless NIH sufferer needs to be 'supervised' and their choices about what to write needs to be questioned, but, that's doable with supervision. "Just git gud and be technically proficient" not so much. But then maybe that's bias too - that leads to a codebase that is easier navigated when you're familiar with debuggers and reading code to understand it. Reaching for third party deps a lot leads to a codebase that is easier navigated when you're familiar with docs and tutorials. These are self fulfilling prophecies.

vanitywords 2y ago
Been in software 25 years and was board design for telecom before that. Vaunted is a vanity word. I get what you mean based upon experience and I still prefer custom systems that eschew layers of syntax sugar. EE was way harder than managing a code base. The syntax patterns are of a finite set of values. I won’t re-roll encryption libs but there’s a lot of “tooling” packages that just add syntax sugar to parse and cart around that came about in prior eras of sneakerware software that are baked into to development habits that no longer make sense. I for one am excited about using ML to streamline the code base that comprised my preferred Linux system yet still builds to the usual runtime system. There’s a lot of duplication in code that models can help remove and a few tools can help unpack into machine state. EE brain informs me there’s no “code” in a running system. Just electricity. There’s way too much syntax sugar in the software ecosystem that’s just for parsing/marshaling/transpiling between syntax sugars. Bleh. It’s a big dumb monolith of glyph art that needs to be whacked back like a prairie that needs a controlled fire.

segfaltnh 2y ago

I've spent most of my career in the infrastructure space and I agree with this so much. These days prevailing wisdom is just to use 20 off the shelf open source components and spend your entire day debugging YAML integrations. I think we've lost our minds a bit because of this prevailing wisdom that building a simple wheel that does the 10% of this you actually need is somehow self-indulgence or negligent or both.