I’m skeptical that we can lay the blame for this on NodeJS — that seems reductive, although the observation of the JS community rediscovering all the server-side things that were old hat in other languages is absolutely true.
I think the hype cycle influence of the rise of Cloud Computing had at least as big a role, if not moreso.
The scene accurately describes the absurdity of the state of the current tech culture. We laugh, and yet bringing this up in a serious conversation is tantamount to professional heresy, rendering you borderline un-hirable.
Hah! Not by me.
Edited to add: in fact, I’d go so far as to say that I treat unreasonable enthusiasm for microservices as a red flag during hiring.
I’ve recently interviewed a number of candidates with very binary worldviews like this. They’re usually familiar with one language or framework and almost always they ask something like “I heard your company uses X. Doesn’t that [true but not deal-breaking tradeoff]?” It may be Python and the GIL, or Postgres and vacuuming, or Go and lacking generics, or a monolith and whatever they don’t like about that, whatever it may be. They read one article about the thing and wrote it off. They’re clearly invested in whatever their normal environment enough to know that tradeoffs exist there but as soon as there exists a tradeoff in some other system it’s like there’s a big VETO light in their brain that everybody else has to abide by or justify. The next question is always “do you have any plans to move from that to [my favourite thing] to fix it?”
I think the HN/reddit/etc brain causes this idea that a given system is objectively superior to another one rather than a broad solution space with upsides and downsides specific to how you’re using it. It drives me crazy answering so much “you wrote a 3-line ruby script to solve a one-time problem that you’ll never have to run again? But isn’t ruby slow?”
It’s not even zealotry. Zealotry I attribute mostly to exuberant youngsters but this comes from people more in the middle of the experience curve. This is, I dunno, a weird outcropping of “best practise” brain where they’ve memorised a list of “better than”s that they emit if anybody reminds them of anything remotely similar.
it’s like there’s a big VETO light in their brain that everybody else has to abide by.
I’ve experienced this many times as a manager.
Usually what has been driving this is that developers were hired as “$TOOL developers”, have built their careers around $TOOL, and intend to continue being “$TOOL developers”. In that context, anything other than $TOOL has negative payoff.
Even if it is better in every measurable way for solving the problem at hand than $TOOL, an alternative will harm their ability to execute on their career plans, so it will be rejected.
Most recently I’ve seen this with React, but I’ve observed it with C back in the early 2000s and C# / .NET after that.
I think that’s a problem created from the other side of hiring: companies look for “$TOOL developers”, not “developers”. I’m a well experienced developer (15+ years professionally) and have applicable knowledge in multiple languages and stacks. But because I’ve spent most of my career with Tool A I’m more likely to be disregarded for a position with Tool B than someone with only 3 years experience in Tool B. Never mind the fact that if you gave me 3 months I’d probably be as good as or better than that person (mainly due to compound knowledge and experience).
This creates an ultra-specialization drive where people aren’t incentivized to look for other tools/stacks because it doesn’t help them get hired. With that they lack the nuance that a generalist has, and will try to push for the tool/stack they work with regardless if it’s the best solution.
I like learning other solutions for the fun of it, so I don’t think it’s a wasted effort. But I fully expect that, when I switch stacks, I’ll get a pay decrease. Someone who doesn’t share this drive for learning for the sake of it would make a business decision and decide it’s not worth their time.
Someone who doesn’t share this drive for learning for the sake of it would make a business decision and decide it’s not worth their time.
That’s exactly what I meant by “negative payoff”. As much as it frustrates me, I didn’t mean that as a criticism of the individuals involved. Incentives work; and most companies incentivize specialization of that sort at the cost of fitness for purpose.
Long-term, $TOOL developer positions are not a stable career prospect because our industry seems to revel in killing tools left and right. Professionals need to balance both short and long-term career goals to optimize for what they want.
I’ve had great success with optimizing towards comp sci over tools. It is a long slog to get traction for that as your job but I’ve been able to exit the hamster wheel of trying to keep up with whatever the orange site likes.
Thank you for commenting on this. It is intensely irritating to me and turns me off of about 90% of tech discussion. It generates an incredible amount of noise, and, viewed a certain way, it’s like people show up to these discussions trying to convince themselves and other people. They aren’t there to converse, they’re there to affirm that, yes, they still believe the Correct Thing. You get the feeling that they’re more interested in hoarding these ‘facts’ than actually talking about accrued experience or wisdom. It’s easy to hide behind the fact that “everyone” believes these things, therefore that justifies these beliefs as more true than actual experience.
I don’t know of a solution here other than just not reading or engaging. (Which, actually makes things worse.) Pointing out things is exhausting, presupposes the other party wishes to change their mind, and requires a lot of time and energy for an uncertain payoff. Should I be more willing to educate people? Maybe, but it’s hard to be motivated if I perceive them to be not receptive.
This is the communication equivalent of how we’re tyrannized by “best practices”: collectively, outsourced technical aesthetics, sans accountability, historical context, or nuance. A dream come true for some.
Organizations always exist in a terrible state, in this sense. It’s a core invariant and cannot be eliminated. Good processes accommodate the terribleness and work with it!
Is it bad that I broke up my project into essentially “frontend”, “accounts backend”, “admin backend”, and “core functions backend” ? For me, I saw this problem more as “what if accounts get DDOS’d? what if admin gets DDOS’d and affects everything else?”
Basically “what if there’s a vuln. or problem in one core service? will it affect others functions?”
I like the “macroservices” idea but that’s pretty damn vague of a name from the article. Maybe something more like “category services”… if it doesn’t fall under the category, it should be its own service..?
I’m skeptical that we can lay the blame for this on NodeJS — that seems reductive, although the observation of the JS community rediscovering all the server-side things that were old hat in other languages is absolutely true.
I think the hype cycle influence of the rise of Cloud Computing had at least as big a role, if not moreso.
Agreed. There was a single fleeting mention of kubernetes, and no shout out to Go.
Hah! Not by me.
Edited to add: in fact, I’d go so far as to say that I treat unreasonable enthusiasm for microservices as a red flag during hiring.
I’ve recently interviewed a number of candidates with very binary worldviews like this. They’re usually familiar with one language or framework and almost always they ask something like “I heard your company uses X. Doesn’t that [true but not deal-breaking tradeoff]?” It may be Python and the GIL, or Postgres and vacuuming, or Go and lacking generics, or a monolith and whatever they don’t like about that, whatever it may be. They read one article about the thing and wrote it off. They’re clearly invested in whatever their normal environment enough to know that tradeoffs exist there but as soon as there exists a tradeoff in some other system it’s like there’s a big VETO light in their brain that everybody else has to abide by or justify. The next question is always “do you have any plans to move from that to [my favourite thing] to fix it?”
I think the HN/reddit/etc brain causes this idea that a given system is objectively superior to another one rather than a broad solution space with upsides and downsides specific to how you’re using it. It drives me crazy answering so much “you wrote a 3-line ruby script to solve a one-time problem that you’ll never have to run again? But isn’t ruby slow?”
It’s not even zealotry. Zealotry I attribute mostly to exuberant youngsters but this comes from people more in the middle of the experience curve. This is, I dunno, a weird outcropping of “best practise” brain where they’ve memorised a list of “better than”s that they emit if anybody reminds them of anything remotely similar.
I’ve experienced this many times as a manager.
Usually what has been driving this is that developers were hired as “$TOOL developers”, have built their careers around $TOOL, and intend to continue being “$TOOL developers”. In that context, anything other than $TOOL has negative payoff.
Even if it is better in every measurable way for solving the problem at hand than $TOOL, an alternative will harm their ability to execute on their career plans, so it will be rejected.
Most recently I’ve seen this with React, but I’ve observed it with C back in the early 2000s and C# / .NET after that.
Yeah I think you’re right. It’s been mostly Java and Go folk that I get it from lately, but it does seem to come in waves
I think that’s a problem created from the other side of hiring: companies look for “$TOOL developers”, not “developers”. I’m a well experienced developer (15+ years professionally) and have applicable knowledge in multiple languages and stacks. But because I’ve spent most of my career with Tool A I’m more likely to be disregarded for a position with Tool B than someone with only 3 years experience in Tool B. Never mind the fact that if you gave me 3 months I’d probably be as good as or better than that person (mainly due to compound knowledge and experience).
This creates an ultra-specialization drive where people aren’t incentivized to look for other tools/stacks because it doesn’t help them get hired. With that they lack the nuance that a generalist has, and will try to push for the tool/stack they work with regardless if it’s the best solution.
I like learning other solutions for the fun of it, so I don’t think it’s a wasted effort. But I fully expect that, when I switch stacks, I’ll get a pay decrease. Someone who doesn’t share this drive for learning for the sake of it would make a business decision and decide it’s not worth their time.
That’s exactly what I meant by “negative payoff”. As much as it frustrates me, I didn’t mean that as a criticism of the individuals involved. Incentives work; and most companies incentivize specialization of that sort at the cost of fitness for purpose.
Long-term, $TOOL developer positions are not a stable career prospect because our industry seems to revel in killing tools left and right. Professionals need to balance both short and long-term career goals to optimize for what they want.
I’ve had great success with optimizing towards comp sci over tools. It is a long slog to get traction for that as your job but I’ve been able to exit the hamster wheel of trying to keep up with whatever the orange site likes.
Thank you for commenting on this. It is intensely irritating to me and turns me off of about 90% of tech discussion. It generates an incredible amount of noise, and, viewed a certain way, it’s like people show up to these discussions trying to convince themselves and other people. They aren’t there to converse, they’re there to affirm that, yes, they still believe the Correct Thing. You get the feeling that they’re more interested in hoarding these ‘facts’ than actually talking about accrued experience or wisdom. It’s easy to hide behind the fact that “everyone” believes these things, therefore that justifies these beliefs as more true than actual experience.
I don’t know of a solution here other than just not reading or engaging. (Which, actually makes things worse.) Pointing out things is exhausting, presupposes the other party wishes to change their mind, and requires a lot of time and energy for an uncertain payoff. Should I be more willing to educate people? Maybe, but it’s hard to be motivated if I perceive them to be not receptive.
This is the communication equivalent of how we’re tyrannized by “best practices”: collectively, outsourced technical aesthetics, sans accountability, historical context, or nuance. A dream come true for some.
Unscientific Opinion: the recent love for Microservices is caused, via Conway’s Law by the terrible state of your agile organization.
Disagree, mostly.
The love for microservices is caused these days mainly by the massive ad spend of ZIRP devops and tooling startups.
Developers are way, way more susceptible to manipulation than is commonly believed.
Organizations always exist in a terrible state, in this sense. It’s a core invariant and cannot be eliminated. Good processes accommodate the terribleness and work with it!
Is it bad that I broke up my project into essentially “frontend”, “accounts backend”, “admin backend”, and “core functions backend” ? For me, I saw this problem more as “what if accounts get DDOS’d? what if admin gets DDOS’d and affects everything else?”
Basically “what if there’s a vuln. or problem in one core service? will it affect others functions?”
I like the “macroservices” idea but that’s pretty damn vague of a name from the article. Maybe something more like “category services”… if it doesn’t fall under the category, it should be its own service..?
[Comment removed by author]