4 ms·

The problem I have with this line of thinking is that it only works when you're talking about bottom of the barrel developers. The tech world has this tendency

by whstl 1y ago

The problem I have with this line of thinking is that it only works when you're talking about bottom of the barrel developers. The tech world has this tendency to dumb down every advice so it caters to the lowest common denominator, but I honestly have never worked in such an environment where developers couldn't learn to duplicate the functionality of shitty dependencies while at the same time fixing the problem. And as much as people love to mock CRUD, bad abstractions can be a horrible drain on teams doing CRUD work. And even the popular stuff can often suck and be a timesink unless you're doing absolutely basic stuff that's just repeating the tutorial.

BiteCode_dev 1y ago
Most professionals are average, by definition, because skill follows a Gauss curve. HN is a bubble, the world runs on "meh".
- whstl 1y ago
  Average doesn't mean rock bottom. I've seen "Meh" do the things HN claims nobody can. Plenty of times.
jack_h 1y ago
> but I honestly have never worked in such an environment where developers couldn't learn to duplicate the functionality of shitty dependencies while at the same time fixing the problem. I have absolutely seen this. It’s not a matter of them being bad developers, but no one is an expert in all things and gaining expertise takes time which costs money. All dependencies have a lot of trade-offs baked in that must be re-evaluated if you decide to go the NIH route, and that’s usually where expertise is needed. If you lack the expertise you will still be making trade-offs, but you will lack the knowledge to foresee the long term consequences of these decisions. In my own opinion core business differentiators are where engineering resources should be used. That’s not to say a dependency that is more generic than the problem your business is trying to solve should never be pulled in house, but the decision to do that shouldn’t be taken lightly as it will increase the burden of learning, maintaining, documenting, testing, etc for a team that is being judged on the success of business objectives. To put it another way, the business will be hesitant to give you time to work on something that is only tangentially related to their objectives and quality can and usually will suffer which will put you in a worse position. I think software development has some unique characteristics that makes NIH a problem. If you’re an electrical engineer you will never be given the resources to make a custom microcontroller or a new way of manufacturing a PCB unless that is what your company is selling; the upfront costs would be staggering and that would not be allowed. The limitations of the technology available is simply that, a constraint on what the business can do given current tech. Perhaps there is an opportunity for something better, but that would be best served as a new company focused on providing that solution if it can be done in an economically viable way. Software doesn’t have these massive upfront manufacturing costs that are obvious like the example above, but they still exist. AI may change this calculus.
- whstl 1y ago
  I am not saying it doesn’t exist, just that I have been around the block for quite a while but even then didn’t personally work in a place like this. Places with average developers are more than equipped to do tasks that HN claims to be impossible to anyone but Carmack or Torvalds. And average doesn’t mean rock bottom! I don’t understand why those conversations only focus on the extremes. We should stop being so prescriptive of other people’s work.
marcosdumay 1y ago
I've seen a few people from the bottom of the barrel outside on the real world... The funny thing is that no advice is dumbed-down enough for them. They will take anything you can say and implement wrongly. That idea that if you dumb-down everything, it will be helpful is just plain bullshit. People that can't duplicate a dependency just can't choose the right dependency either, and if you force them to use some good one, they will use it wrong.
- whstl 1y ago
  Yeah, that's a great argument. Not only it's harming people of average capability, it's also not even benefiting the people on the bottom. The Overton-window of supply-chain has shifted so much to one side that it no longer benefit anyone but supply-chain providers.

by whstl 1y ago

BiteCode_dev 1y ago

Most professionals are average, by definition, because skill follows a Gauss curve. HN is a bubble, the world runs on "meh".

whstl 1y ago
Average doesn't mean rock bottom. I've seen "Meh" do the things HN claims nobody can. Plenty of times.

jack_h 1y ago

> but I honestly have never worked in such an environment where developers couldn't learn to duplicate the functionality of shitty dependencies while at the same time fixing the problem. I have absolutely seen this. It’s not a matter of them being bad developers, but no one is an expert in all things and gaining expertise takes time which costs money. All dependencies have a lot of trade-offs baked in that must be re-evaluated if you decide to go the NIH route, and that’s usually where expertise is needed. If you lack the expertise you will still be making trade-offs, but you will lack the knowledge to foresee the long term consequences of these decisions. In my own opinion core business differentiators are where engineering resources should be used. That’s not to say a dependency that is more generic than the problem your business is trying to solve should never be pulled in house, but the decision to do that shouldn’t be taken lightly as it will increase the burden of learning, maintaining, documenting, testing, etc for a team that is being judged on the success of business objectives. To put it another way, the business will be hesitant to give you time to work on something that is only tangentially related to their objectives and quality can and usually will suffer which will put you in a worse position. I think software development has some unique characteristics that makes NIH a problem. If you’re an electrical engineer you will never be given the resources to make a custom microcontroller or a new way of manufacturing a PCB unless that is what your company is selling; the upfront costs would be staggering and that would not be allowed. The limitations of the technology available is simply that, a constraint on what the business can do given current tech. Perhaps there is an opportunity for something better, but that would be best served as a new company focused on providing that solution if it can be done in an economically viable way. Software doesn’t have these massive upfront manufacturing costs that are obvious like the example above, but they still exist. AI may change this calculus.

whstl 1y ago
I am not saying it doesn’t exist, just that I have been around the block for quite a while but even then didn’t personally work in a place like this. Places with average developers are more than equipped to do tasks that HN claims to be impossible to anyone but Carmack or Torvalds. And average doesn’t mean rock bottom! I don’t understand why those conversations only focus on the extremes. We should stop being so prescriptive of other people’s work.

marcosdumay 1y ago

I've seen a few people from the bottom of the barrel outside on the real world... The funny thing is that no advice is dumbed-down enough for them. They will take anything you can say and implement wrongly. That idea that if you dumb-down everything, it will be helpful is just plain bullshit. People that can't duplicate a dependency just can't choose the right dependency either, and if you force them to use some good one, they will use it wrong.

whstl 1y ago
Yeah, that's a great argument. Not only it's harming people of average capability, it's also not even benefiting the people on the bottom. The Overton-window of supply-chain has shifted so much to one side that it no longer benefit anyone but supply-chain providers.