The Industrial Hammer Complex
eisenbergeffect.medium.com
eisenbergeffect.medium.com
I don't like how this paints devs as blind followers without any opinion or agenda of their own. From my perspective many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends.
The way an IC increases their income is usually either by being promoted or by job-hopping to another job with better pay. Getting promoted past a certain point is all about impressing your boss (or promotion committee in certain companies) and "developed a new architecture based on latest insights" is just inherently more impressive than "kept the decade old monolith online for another year". Similarly for job-hopping, hiring managers empirically seem more interested in people with modern tech stacks on their CV than in people who seemingly haven't learned anything in the last 15 years. Thus, devs have a strong incentive to learn and adopt new tech stacks and doing so during work time is clearly the most efficient way to do that.
The jumps in pay between various levels (junior/senior/lead/principal/etc) can be incredibly significant. It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them.
I used to be more hesitant about whether it was a good idea to start out with microservices, then I started going on interviews. I would paraphrase the phone screens I was given as "Have you accepted microservices as your Lord and savior?". Call after call they wanted me to extoll the virtues of microservices before even considering me for an interview.
I also had questions asking me how I would write frontend applications with and without central state management, or even for which cases I would start with a reactive frontend framework.
In one of them I even had a huge disagreement with the interviewer. He still made a point to say I had passed.
I think the main difference in this case was that I was interviewed by seasoned pros. When I had interviews with less experienced developers, the topics were as trivial as possible and just looking for confirmation.
Micro-services have fairly extreme upfront deployment/automation overhead relative to monoliths. This setup effort is common across many firms adopting microservices.
Incentives matter, if you learn nothing else about economics learn this. People do things that they feel are best for them so companies need to align personal incentives with company outcomes or face sub-optimal solutions for the companies because the employees feel the solutions is optimal for themselves.
With an average employee tenure at a company being a few years, how can longer term issues with software ever be a deciding factor for employees.
React became popular because it solved problems that everyone in the frontend was having, did so in a way we could understand, and it did this so well that we were willing to put up with shortcomings like being forced into a SPA, CSS-in-JS, etc. We could jump in with just a little corner of our site or go all-in to a robust ecosystem that was continually evolving to meet the needs of the modern Web, and the resulting code was far more likely to be understood by a new employee than the bespoke jQuery soup that we replaced.
And critically, this was all free and open source. No lifetime hammer subscriptions involved. No lock-in, no monetary sunk costs, so why not try it out?
> I was deeply connected into the valley culture, watching what was happening from the Google side when it all started. It wasn’t money Facebook was looking for, it was talent and mindshare (i.e., power and control).
...Okay? But I'm guessing that most people who adopted and use React on a regular basis have zero interaction with Facebook or Google (the companies that is, not the product).
I dunno. Seems like the critique is a hammer looking for a nail.
I get the concerns about using React in places it doesn't need to be used, and I'm glad that the ecosystem has matured and innovated to allow us to keep what's great about React while also getting back SSR (though there's still work to be done here) and figuring out the best ways to work regular CSS into it.
To me it's so out of reality that it tainted his whole article
Granted I'm not in the US tech scene, but I chose React because AngularJS was horrible (it took one project to never again touch it) and Backbone was arcane and confusing, and I really clicked with JSX
I was sort of expecting him to go after SSR mania, which would make a lot more sense to me (I am guilty of of this). But railing on an abstraction pattern that literally brought JavaScript out of the dark ages seems way off.
I have noticed in myself and other developers with a decade plus that there is new tech fatigue eventually. With enough cynicism it can look like everyone is trying to use their new hammers on everything (sometimes they are). But I think that’s the flip side to this article and I’m glad he made the React point because it really elucidates the whole thing. Everyone looks like they have a hammer complex when you aren’t interested in learning new things. I think there’s so much value in experience and until he got to React, my internal dialogue was shouting “amen” after every sentence but it’s painfully clear the author did not want to engage or think about the problems React solved.
- React is the iPhone of the frontend library world. Not the first, some will never say it's the best, but it put things together in a way that resonated with people and organically conquered a ton of mindshare.
- React is the Model T. Before the Model T there was a massively fragmented landscape full of mechanical wizardry and bespoke manufacturing. After the Model T the industry was larger, more consolidated, and standardized.
I don't believe that React will dominate forever. But I do believe that, 50 years from now, people talking about the history of the frontend will view React as the defining thing from the era we're in now.
React itself is just a really good JS library, not a full opinionated framework. I made the choice to use React because it was possible to add individual interactive components to an ASP.NET Razor MPA without rewriting the whole thing. Gradually React takes over more and more functionality, necessitating a need for a framework, and then we get the iPhone experience.
> I wish I could say this was merely the problem our industry has, but it’s far worse than this. What we actually have is an industrial complex bent on manufacturing only hammers, committed to convincing you that only nails exist, and motivated to sell you a lifetime hammer subscription
SPAs also get a lot of criticism here at Hacker News, but talk to a team of frontend developers and you'll get puzzled looks for suggesting rendering HTML directly in your C# or Rails monolith.
Please notice that I'm not criticizing or advocating anything, I'm just saying that there are trends and they're strong to the point of almost becoming laws. IMO this is what the article criticizes.
If they truly were only used as desktop-based apps, there would be less to complain about. As it stands, they’re packaged incorrectly for the mobile devices people use, caching is an afterthought so we’re loading the same giant bundles across mobile networks on each load, and this affects apparent performance. Then we have too much animation or inefficient component refreshing that reduces responsiveness…
Another aspect is here is that if you have people split up (more or less strictly) in backend and frontend devs, then SPA kinda follows naturally
All kidding aside, life is full of choices just like programming is. It's also full of, at times, cascading tradeoffs. Following popular patterns isn't new to technical fields, even if they can have sharp corner cases. When your income is dependent on delivery then you'll often side with whatever presents a high-confidence score in terms of success.
There are also very few definitely right decisions to make in software architecture and much more definitely wrong ones. How many times have you heard, "I shouldn't have used x full stack framework because I wanted to do y" or "I shouldn't have written x from the ground up because I could've used y". Many of these decisions you can only fully know what category they fit into after the deed is done.
A lot of this derives from the fact that most of these things are learned on the job. There is no course you can take that will succinctly teach you to migrate a hulking, interconnected monolith to microservices or vice versa. You just have to have been the sad sap who's done it before and have enough knowledge of the standards and innards involved.
What I take some umbrage with is just labeling everyone snake oil salesmen.
The metaprogram is an all in one piece of software (or hardware) that replaces all of IT with a system that is easily understood and controlled by management, is relatively inexpensive, easily expandable to new purposes, and solves whatever problems the target company seems to be having at the time.
I've seen IT department middle managers and CIOs try to do this over and over again. When a good solution to a problem is presented that's practical, affordable, and effective, their very next thought is "but what if it also did XXXX". I guess that's how they "add value" or something, by suggesting ideas that have already been discarded for reasons of scope, funding, or time.
So far in my career I've seen salespeople use the idea of solving any pain points for the target company including reducing costs and increasing reliability by selling:
* Desktop Microcomputers
* Peer to peer networking
* Dedicated internet lines (when they were still phone company lines)
* Minicomputers (transition from Mainframes)
* Java machines everywhere
* Clustering software and hardware
* Physical and virtual partitioning of systems
* Thin Clients
* Cloud everything
* Containerized data centers
...and there are many more. I find it's mostly sales people and middle managers that benefit from the hype cycle. As with any new technology in any industry, things become part of the tool box. The main reason a lot of modernization projects get launched is the same reason that business re-orgs happen - they're a way for managers with no other ideas to show they're contributing.
"Remember that you are a problem solver before you are a technologist."
(Almost) everything we make has users. The most important criterion we have for deciding how to build things is "will it make life better for our users?"
“We can improve email validation on the client by shipping a TLD list with the other logic …”
To what end? How does the additional complexity help the user? They can fat-finger any part of their email address and we can’t validate whether the user name should contain a g or h. Who’s going to maintain the list? So rather that listen to reason little ol’ me, we had to set up a meeting involving The Architect …
He made the call that the complexity wasn’t worth the effort, that the UX wouldn’t be improved, and we shouldn’t add TLD validation in the client. That’s when they finally dropped the idea.
I work on two large cloud products. One is a monolith, one is microservice-based.
The microservices and the connections between them are easier to reason about than the free-for-all connections and dependencies between components in the monolith.
We have a far easier time adding new features to the microservice product. And somehow, the microservice produce requires less maintenance and is far more reliable than the monolith.
I could go on and on, but then I'd have more own blog article
https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of...
The author must have barely been paying attention to JS scene pre-React. The churn of tooling from 2010-2015 was far worse than anything since. A large part of this was due to the shortcomings of pre-ES2015 JavaScript itself.
ES5 JS had no module system. It had no package manager. Even if you used server-side rendered PHP, Ruby, Java, or C# (the default in those days), JavaScript ended up becoming a massive part of any code base. What started as a few JQuery selectors adding dynamic/interactive behavior to forms would quickly evolve into an unmanaged mess of tens to hundreds of thousands of lines of code. I worked for an enterprise shop that pitched itself as a C# .NET stack, but when you analyzed the ten year old code base, we had more lines of JS than C#.
When every page imported its own version of JQuery or some plug-in, even updating a package across your code base would turn into a hot mess (and might unpredictably break things, as each page independently managed its own dependencies, often imported from some CDN somewhere).
The desire to build a SPA was rooted in the fact that none of these server-side languages had a good native way of managing JS. It was always treated as some afterthought that was injected into some god awful HTML template somewhere.
The JS ecosystem had to create these tools, and there were lots of attempts at wrangling various parts of the architecture from Backbone, Ember, Grunt, Gulp, Bower, Knockout, Flight, Eve, Angular, Dojo, Closure, Ext JS, Moo Tools, etc (and more that I've forgotten) all pre-dating React.