6 ms·

The whole industry is stupid at this point. I don’t think anyone knows what they are doing. Everyone just wants to play with the new shiny thing. Half the engin

The whole industry is stupid at this point. I don’t think anyone knows what they are doing. Everyone just wants to play with the new shiny thing. Half the engineers probably have ADHD which leads to this behavior of seeking novelty. Everyone is obsessed with their shitty stack they used at their last company, and this shit will keep going on and on. The only things that matters is how easy is something to debug and to change. Think about how often you have heard that as any kind of priority. So many shitty decisions would be avoided if people started thinking about that.

zwischenzug 3y ago
I've often mused about creating a language that put readability, maintainability, logging etc over, say, performance.
- Arbortheus 3y ago
  You might enjoy Go. Lots of emphasis has been put into the development tooling and ecosystem. There is an impressive commitment to avoiding breaking changes. We have a legacy Go microservices codebase that’s over a decade old and because the Go maintainers have paid so much attention to avoiding creating breaking changes and a guarantee to never create a “Go 2”, the codebase has aged much better than stuff written at the same time in Python (some of which is still in Python 2 because it is too risky to upgrade, and that functionality will be killed instead because we don’t know how to safely update it). Most of the time we don’t need to make any changes when bumping Go versions, just fixing up things our linter warns is deprecated.
- Nextgrid 3y ago
  Performance is absolutely a non-issue when modern "engineering" insists on running everything on underpowered VMs with high-latency network-based storage. Even if your language is truly, actually slow, you can get an instant performance boost just moving that workload to a modern bare-metal server (cloud providers basically ate all the performance improvements of modern hardware), or scale that (most likely stateless) workload horizontally if a single bare-metal machine isn't enough.
  - zwischenzug 3y ago
    Exactly.
projectileboy 3y ago
Alan Kay once pointed out something along the line that when excitement exceeds knowledge you get fashion. For 10 years I’ve been in and around languages that were declared dead by the HN crowd because there wasn’t enough new hype around it. It’s not a perfectly inverse correlation, but honestly at this point when I see HN is excited about something new it raises red flags for me.
- jack_riminton 3y ago
  I see this more on twitter to be honest. HN, of late, has been a great source of info on the ‘boring’ stacks e.g Rails. Twitter is where you get the JavaScript ‘influencers’ who appeal to a core demographic of engineers with FOMO who signal their ‘in status’ by waxing lyrical about the latest framework
- vishnugupta 3y ago
  Not to pat myself on the back but fashion was the exact analogy I came up while describing the situation. When everyone begins focusing on tech as an end in itself as opposed to it serving a bigger purpose we end up here. And add to that the zero cost of capital of 2010s, it lead to engineers being given almost free reign which is generally a bad idea. “we are a technology company” would attract VC money, as if tech itself was a product of every darn startup.
  - namaria 3y ago
    >And add to that the zero cost of capital of 2010s I suspect the timing of ChatGPT release just as interest rates started going up is a ploy to layer more obscurity into tech choices to drive the hype harder ad keep the gravy train going even as capex becomes more costly.
mk89 3y ago
I don't have ADHD but I find your comment quite offensive. It also seems that people without ADHD don't like innovation? That either came out wrong, or ...boh?
- beerpls 3y ago
  I do have ADHD and op is spot on. The software industry is filled to the brim with midwits who think their idea is the only right idea even though its nothing special and they’re ignoring actual problems As op said - when’s the last time you heard someone talk about writing code that’s easy to debug? Never. Yet 90%+ of companies will make you pass arbitrary algorithms tests The field is dominated by A types who confuse their neuroticism and ego for talent
  - mk89 3y ago
    But why to bring ADHD into this? This I don't understand. I do understand the fact that everyone is following one or two bandwagons, but I don't have the need of saying that someone must have a mental condition for doing that. There are MANY more reasons for adopting technologies. Marketing, corporate culture, hiring, trying things out, wrong people in leadership position (as the article shows!), etc etc. It's not just always the minions to do things wrong.
    - cactusplant7374 3y ago
      Because people with ADHD crave stimulation and pursuing new and exciting technologies is very satisfying.
      - faeriechangling 3y ago
        Does adopting serverless actually accomplish that? With servers you have a bunch of technologies to learn about that are abstracted away with serverless. Every person I know with ADHD in the IT field, not knowing many, is into servers.
WinLychee 3y ago
There are a lot of financial incentives pushing engineers to seek novelty, even if they might not necessarily want to. Promotions and raises are heavily tied to projects introducing or inventing shiny new tech. Heck, even VC funding for starting a business is tied to this. One might also view this as the human condition: a bias to solve problems by adding rather than subtracting.
- Nextgrid 3y ago
  > even VC funding for starting a business is tied to this This is the main problem. Excluding VC, businesses exist to make profit. The purpose of IT and engineering is to enable that business or make it operate more efficiently - engineering and technology should never be a goal in and of itself. Given this situation, the most efficient technology (that enables faster delivery of business software) would win. "Shiny" stuff would never win in terms of mindshare unless it's actually good and enables faster delivery than the status quo. Now add VCs to the mix. Suddenly you have an infinite supply of free money that distorts the usual market dynamics, allowing businesses to keep operating with no regard to profitability. The downwards pressure of the market pushing for businesses to operate more profitably is no longer there. As an engineer, you no longer have the pressure of building technology for the purposes of making the business more efficient - you lost that valuable feedback loop. Now run this for 10 years. Entire careers will be built on this - why even try to build a profitable business when you can be a "serial startup CEO" and merely use the right amount of shiny to solicit endless VC funding to continue the adventure? Imagine a well-meaning, budding engineer joining such a startup and learning such a corrupted idea of "engineering" with none of the usual objectives, pressures and feedback loops of engineering. In the end, you end up with "senior" engineers (with over-inflated titles) whose entire careers are built on technology that wouldn't actually pass muster in an actual business under the normal market pressures. But they don't even know anything else or why that is wrong (because they've started their career during this charade and never had any taste of what real engineering is), so they keep pushing for these (now-inadequate) solutions, deluded that they are doing the right thing.
lemmsjid 3y ago
It's easy to sit back and say that, but I can almost guarantee that if you actually follow this up with a set of opinions about what stack / architecture / approach is easiest to debug and change, you will find yourself back in the argument with the rest of us stupid people. I believe there's a lot more variables than "how easy is something to debug and change". The issue is that how easy something is to debug and change is very contextual to the point in the lifetime of an application, the industry the application will live in, and the changing requirements as the application grows in complexity. Even the simplest interpretation of your statement leads to considerable argument. Often the ease of change and the ease of debugging are at odds with one another, where a highly dynamic approach might make change a breeze, but make debugging more difficult.
- Timpy 3y ago
  I agree that "easy to debug" is subjective. But it's insanity to act like that doesn't mean that some architectures are objectively easier to debug than others. How can splitting something up into different services and introducing network calls make it easier? You're not reducing complexity at all. It makes debugging harder.
  - lemmsjid 3y ago
    It would indeed be insanity to argue that, which is why I didn’t. The argument for splitting into micro services is generally that particular teams would own particular services and therefore make debugging/change easier for them, at the cost of increased overall complexity of the overall system. Anyone arguing it reduces complexity is being very hopeful. I personally think an org should generally cling to a so called monolith as long as they possibly can. But it’s very hard to be prescriptive without knowing particulars of the problems an org is trying to solve.
- antoniojtorres 3y ago
  This very much. I find that often times we are looking at a narrow subset of the factors that lead to certain choices or technologies. Yes, there is a lot of fluff sometimes but there’s also the cycle of wanting to improve on existing pain points. Things like serverless appeal to businesses due to the much smaller logistical implications it presents to a business. Some businesses enjoy that (at least as promised), It’s all taken care of and the team you need to manage it is likely to be smaller. It’s pay as you go for what would otherwise imply more human beings and contracts on your plate. I imagine at some point those baked in costs and redundancies, the luxury of having huge scale on demand in a general sense, will be much higher than something thoughtfully designed when a company has understood their needs well enough after operating at scale. For what it’s worth I prefer bare metal clusters :)
pmontra 3y ago
I don't think ADHD had anything to do with it. Young people with little knowledge (because they are young) give a try to every new piece of technology and start projects with them. I've been there. Older people that eventually found good tools to solve problems have less time and enthusiasm to try new things. They still do but only when they think it's worth it. I'm there now. Most developers and many CTOs are young.
- mattgreenrocks 3y ago
  > Older people that eventually found good tools to solve problems have less time and enthusiasm to try new things. They still do but only when they think it's worth it. I'm there now. The best thing about this phase is you just get so much shit done instead of screwing around with 10 half-baked over-marketed frameworks.
gherkinnn 3y ago
Half the engineers are made to believe they are God's gift to humanity and like so totally clever. But we all spend our time building banal and ultimately dumb shit nobody wants. But people construct their entire identity around tech anyway. It is no surprise the place is littered with ivory towers.
unbearded 3y ago
I don’t think it’s the ADHD. I have it but I’m very conservative on the stack. And I know many developers who don’t have ADHD, some newbie and some who code longer than 20 years and are going after the latest shiny thing. I think it’s more of what people assume it’s a status symbol among their peers. I noticed for example, in church, that some people think the more boring is more saint and don’t like more a church with a more contemporary dynamic approach and I think the same effect applies in the software development world.
hnick 3y ago
> The only things that matters is how easy is something to debug and to change. These are important, maybe most important, but software exists in an ecosystem. We still use some ASPX with .NET Framework at work and it's old tech but reliable - however, the world is moving on and it's becoming difficult to start new projects in it, not to mention end of life for patching and so on. Likewise, at a prior role we used Perl and a lot of interfacing was made difficult by the fact that no one bothered making modules for Perl anymore. So while we can file these under easy to change, sometimes the world moves on without you and you have to think about the new shiny thing whether you want to or not. I personally started using Python at home not for any love of the language, but because everyone wrote modules and API examples for it.
- foffoofof 3y ago
  I found a similar thing with Node.js. There are tons of under maintained packages while everyone moved to Go and Rust. A lot of packages you never care what’s underneath if they are maintained and do the job. But when you have to manually patch something and it’s a pile of crap underneath then it sucks. I much prefer to write things myself if I can now instead of using an existing package or framework. Having my own simple packages in my monorepo that I can instantly change is far better than new third party packages. I start to wonder if checking in third party modules is the way to go.

zwischenzug 3y ago

I've often mused about creating a language that put readability, maintainability, logging etc over, say, performance.

Arbortheus 3y ago
You might enjoy Go. Lots of emphasis has been put into the development tooling and ecosystem. There is an impressive commitment to avoiding breaking changes. We have a legacy Go microservices codebase that’s over a decade old and because the Go maintainers have paid so much attention to avoiding creating breaking changes and a guarantee to never create a “Go 2”, the codebase has aged much better than stuff written at the same time in Python (some of which is still in Python 2 because it is too risky to upgrade, and that functionality will be killed instead because we don’t know how to safely update it). Most of the time we don’t need to make any changes when bumping Go versions, just fixing up things our linter warns is deprecated.
Nextgrid 3y ago
Performance is absolutely a non-issue when modern "engineering" insists on running everything on underpowered VMs with high-latency network-based storage. Even if your language is truly, actually slow, you can get an instant performance boost just moving that workload to a modern bare-metal server (cloud providers basically ate all the performance improvements of modern hardware), or scale that (most likely stateless) workload horizontally if a single bare-metal machine isn't enough.
- zwischenzug 3y ago
  Exactly.

projectileboy 3y ago

Alan Kay once pointed out something along the line that when excitement exceeds knowledge you get fashion. For 10 years I’ve been in and around languages that were declared dead by the HN crowd because there wasn’t enough new hype around it. It’s not a perfectly inverse correlation, but honestly at this point when I see HN is excited about something new it raises red flags for me.

jack_riminton 3y ago
I see this more on twitter to be honest. HN, of late, has been a great source of info on the ‘boring’ stacks e.g Rails. Twitter is where you get the JavaScript ‘influencers’ who appeal to a core demographic of engineers with FOMO who signal their ‘in status’ by waxing lyrical about the latest framework
vishnugupta 3y ago
Not to pat myself on the back but fashion was the exact analogy I came up while describing the situation. When everyone begins focusing on tech as an end in itself as opposed to it serving a bigger purpose we end up here. And add to that the zero cost of capital of 2010s, it lead to engineers being given almost free reign which is generally a bad idea. “we are a technology company” would attract VC money, as if tech itself was a product of every darn startup.
- namaria 3y ago
  >And add to that the zero cost of capital of 2010s I suspect the timing of ChatGPT release just as interest rates started going up is a ploy to layer more obscurity into tech choices to drive the hype harder ad keep the gravy train going even as capex becomes more costly.

mk89 3y ago

I don't have ADHD but I find your comment quite offensive. It also seems that people without ADHD don't like innovation? That either came out wrong, or ...boh?

beerpls 3y ago
I do have ADHD and op is spot on. The software industry is filled to the brim with midwits who think their idea is the only right idea even though its nothing special and they’re ignoring actual problems As op said - when’s the last time you heard someone talk about writing code that’s easy to debug? Never. Yet 90%+ of companies will make you pass arbitrary algorithms tests The field is dominated by A types who confuse their neuroticism and ego for talent
- mk89 3y ago
  But why to bring ADHD into this? This I don't understand. I do understand the fact that everyone is following one or two bandwagons, but I don't have the need of saying that someone must have a mental condition for doing that. There are MANY more reasons for adopting technologies. Marketing, corporate culture, hiring, trying things out, wrong people in leadership position (as the article shows!), etc etc. It's not just always the minions to do things wrong.
  - cactusplant7374 3y ago
    Because people with ADHD crave stimulation and pursuing new and exciting technologies is very satisfying.
    - faeriechangling 3y ago
      Does adopting serverless actually accomplish that? With servers you have a bunch of technologies to learn about that are abstracted away with serverless. Every person I know with ADHD in the IT field, not knowing many, is into servers.

WinLychee 3y ago

There are a lot of financial incentives pushing engineers to seek novelty, even if they might not necessarily want to. Promotions and raises are heavily tied to projects introducing or inventing shiny new tech. Heck, even VC funding for starting a business is tied to this. One might also view this as the human condition: a bias to solve problems by adding rather than subtracting.

Nextgrid 3y ago
> even VC funding for starting a business is tied to this This is the main problem. Excluding VC, businesses exist to make profit. The purpose of IT and engineering is to enable that business or make it operate more efficiently - engineering and technology should never be a goal in and of itself. Given this situation, the most efficient technology (that enables faster delivery of business software) would win. "Shiny" stuff would never win in terms of mindshare unless it's actually good and enables faster delivery than the status quo. Now add VCs to the mix. Suddenly you have an infinite supply of free money that distorts the usual market dynamics, allowing businesses to keep operating with no regard to profitability. The downwards pressure of the market pushing for businesses to operate more profitably is no longer there. As an engineer, you no longer have the pressure of building technology for the purposes of making the business more efficient - you lost that valuable feedback loop. Now run this for 10 years. Entire careers will be built on this - why even try to build a profitable business when you can be a "serial startup CEO" and merely use the right amount of shiny to solicit endless VC funding to continue the adventure? Imagine a well-meaning, budding engineer joining such a startup and learning such a corrupted idea of "engineering" with none of the usual objectives, pressures and feedback loops of engineering. In the end, you end up with "senior" engineers (with over-inflated titles) whose entire careers are built on technology that wouldn't actually pass muster in an actual business under the normal market pressures. But they don't even know anything else or why that is wrong (because they've started their career during this charade and never had any taste of what real engineering is), so they keep pushing for these (now-inadequate) solutions, deluded that they are doing the right thing.

lemmsjid 3y ago

It's easy to sit back and say that, but I can almost guarantee that if you actually follow this up with a set of opinions about what stack / architecture / approach is easiest to debug and change, you will find yourself back in the argument with the rest of us stupid people. I believe there's a lot more variables than "how easy is something to debug and change". The issue is that how easy something is to debug and change is very contextual to the point in the lifetime of an application, the industry the application will live in, and the changing requirements as the application grows in complexity. Even the simplest interpretation of your statement leads to considerable argument. Often the ease of change and the ease of debugging are at odds with one another, where a highly dynamic approach might make change a breeze, but make debugging more difficult.

Timpy 3y ago
I agree that "easy to debug" is subjective. But it's insanity to act like that doesn't mean that some architectures are objectively easier to debug than others. How can splitting something up into different services and introducing network calls make it easier? You're not reducing complexity at all. It makes debugging harder.
- lemmsjid 3y ago
  It would indeed be insanity to argue that, which is why I didn’t. The argument for splitting into micro services is generally that particular teams would own particular services and therefore make debugging/change easier for them, at the cost of increased overall complexity of the overall system. Anyone arguing it reduces complexity is being very hopeful. I personally think an org should generally cling to a so called monolith as long as they possibly can. But it’s very hard to be prescriptive without knowing particulars of the problems an org is trying to solve.
antoniojtorres 3y ago
This very much. I find that often times we are looking at a narrow subset of the factors that lead to certain choices or technologies. Yes, there is a lot of fluff sometimes but there’s also the cycle of wanting to improve on existing pain points. Things like serverless appeal to businesses due to the much smaller logistical implications it presents to a business. Some businesses enjoy that (at least as promised), It’s all taken care of and the team you need to manage it is likely to be smaller. It’s pay as you go for what would otherwise imply more human beings and contracts on your plate. I imagine at some point those baked in costs and redundancies, the luxury of having huge scale on demand in a general sense, will be much higher than something thoughtfully designed when a company has understood their needs well enough after operating at scale. For what it’s worth I prefer bare metal clusters :)

pmontra 3y ago

I don't think ADHD had anything to do with it. Young people with little knowledge (because they are young) give a try to every new piece of technology and start projects with them. I've been there. Older people that eventually found good tools to solve problems have less time and enthusiasm to try new things. They still do but only when they think it's worth it. I'm there now. Most developers and many CTOs are young.

mattgreenrocks 3y ago
> Older people that eventually found good tools to solve problems have less time and enthusiasm to try new things. They still do but only when they think it's worth it. I'm there now. The best thing about this phase is you just get so much shit done instead of screwing around with 10 half-baked over-marketed frameworks.

gherkinnn 3y ago

Half the engineers are made to believe they are God's gift to humanity and like so totally clever. But we all spend our time building banal and ultimately dumb shit nobody wants. But people construct their entire identity around tech anyway. It is no surprise the place is littered with ivory towers.

unbearded 3y ago

I don’t think it’s the ADHD. I have it but I’m very conservative on the stack. And I know many developers who don’t have ADHD, some newbie and some who code longer than 20 years and are going after the latest shiny thing. I think it’s more of what people assume it’s a status symbol among their peers. I noticed for example, in church, that some people think the more boring is more saint and don’t like more a church with a more contemporary dynamic approach and I think the same effect applies in the software development world.

hnick 3y ago

> The only things that matters is how easy is something to debug and to change. These are important, maybe most important, but software exists in an ecosystem. We still use some ASPX with .NET Framework at work and it's old tech but reliable - however, the world is moving on and it's becoming difficult to start new projects in it, not to mention end of life for patching and so on. Likewise, at a prior role we used Perl and a lot of interfacing was made difficult by the fact that no one bothered making modules for Perl anymore. So while we can file these under easy to change, sometimes the world moves on without you and you have to think about the new shiny thing whether you want to or not. I personally started using Python at home not for any love of the language, but because everyone wrote modules and API examples for it.

foffoofof 3y ago
I found a similar thing with Node.js. There are tons of under maintained packages while everyone moved to Go and Rust. A lot of packages you never care what’s underneath if they are maintained and do the job. But when you have to manually patch something and it’s a pile of crap underneath then it sucks. I much prefer to write things myself if I can now instead of using an existing package or framework. Having my own simple packages in my monorepo that I can instantly change is far better than new third party packages. I start to wonder if checking in third party modules is the way to go.