The industry is rife with people that instead of looking at a problem and choosing the appropriate tech to solve the problem. They choose the technology and then try to solve a problem with it.
'Modern' hiring practises cause a lot of problems.
My advice now is to always jump on the latest trend. It may make no sense for the business but it makes total sense for the devs. In many companies doing what’s right for the business will impede your career.
Programmers develop new technology and paradigms to solve problems caused by existing technology and paradigms. As those new technologies are adopted, they are perceived to give an edge. And so, this creates a demand for experience in this new technology.
As time moves on, the impact of the new paradigm or new tech is getting better understood and the initial optimistic bias aligns with reality. Meanwhile, programmers develop new solutions to solve problems caused by... and the cycle repeats.
The problem here is that the problems that are being solved aren't necessarily new. It's just this foundational "how do you build a website or web interface efficiently" problem that underpins everything.
In a way, it's not much different from re-inventing the wheel. There are only so many specific ways of doing that before the entire exercise turns silly.
The bigger issue here is that - unlike tire manufacturing - the subsequent cycles of innovation are too short for a majority part of the workforce to keep up with changes. Why? First, because the complexity of those solutions creates a prohibitive cost for their employers to easily migrate on short notice and keep up with the cycle. Second, because the vast majority of new tech are just small optimizations in the real world with a limited impact on business making migration a risk and not an opportunity.
Hence why, once a tech has been chosen, companies stick with it for the long haul at the expense of individual developer experience keeping up with the innovation cycle.
That's what turns this into a self-fulfilling prophecy. The faster the cycle goes, the more tight the labor market becomes. That's why you'd see those crazy "Must have 15 years of React experience" requirements.
Finally, what we see is developers are being goaded into whimsical HR hiring processes that shake them down. In reality, it's not developers being "unemployable", it's the hiring process that's essentially broken as it is driven by individual business needs that aren't really that sustainable in the long haul.
When businesses lament that they can't find good talent, but at the same time reject the vast majority of candidates because they can't possibly be proficient in the latest cycle of hype technology (unless you're a core contributor to a particular framework or live a monastic life foregoing any and all other aspects that make life worthwhile living, that is), well, that's a form cognitive dissonance I would say.
As a developer, I feel it's important to keep an eye out of how things evolve, but there's little to no point in trying to keep up with the nitty-gritty at all costs without knowing if you're ever going to need it.
I'm not sure why jQuery is mentioned either. It was popular when I started programming but fell out favour when its major functionalities were implemented in ECMAScript.
What am I missing?
However much of the JavaScript written on those sites was done by back end programmers who didn't really understand jQuery or JavaScript and thus you ended up with jQuery spagetti code which others have lamented about. However if you were proficient with JavaScript at the time you could use a few JavaScript patterns and keep everything fairly clean.
This architecture while dated works incredibly well (minus the jQuery spagetti) for quite a few web applications. This includes everything from shopping sites, bespoke CRUD apps, Forms etc. However it isn't cool, it doesn't look as good on your CV and you actually have to really understand what you are doing to keep it performant.
less than a year ago I was doing Magento, yea, jQuery is still there.
Now working on an already established Angular web and hybrid mobile apps, I saw jQuery symbol, and immediately checked it in the source, really surprised to see it there
Web interfaces are unlike other tech layers in the sense that without tooling, it's often not 'simpler' it's diving into the cruft and weirdness of browserland.
React etc. are not just 'frameworks' they are also 'making something very hard to use, usable in a specific way'.
This issue exposes the inherent hidden complexity of browser weirdness.
If you really want to keep it simple, within some very specific parameters, and have enough experience to know what those are ... it's managable 'by hand' or whatever. But it usually gets ugly.
The problem is that JavaScript just isn't that well understood and this is partially because superficially it looks very similar to C# and Java.
You can sprinkle some jQuery here and there without it being 'spaghetti'. Also, how is having thousands of dependencies for a bit of HTML rendering 'simple'?
Usually you need to consider a lot of alternative solutions in order to come up with the simplest solution and that takes time and a lot of thinking and a deep understanding of the requirements.
When I start a new complex project, in the early stages, there are entire days where I'm just thinking about stuff without writing any code. Then as the project moves forward, I spend less and less time thinking about things until I get to a point where it feels like the code pretty much writes itself because the design is aligned with my original goals.
You just have to be very clear about what your big goals are and where you're going to need flexibility from the beginning.
"Overthink it' first, and then smooth it down to its essential simplicity" is usually the process.
FYI the reason I don't like the musical analogy is because in that scenario, the tooling can easily overwhelm the creative process. You get caught up in the tools and literally never think about the problem.
I suppose a software analogy be might be using 1000x various frameworks to try to do something: you'd never get past the frameworks.
Author here - I should have tweeted that instead of writing a blog post
In the past I managed migration of a few services away from Hazelcast as the team started peeling away the nice abstractions they'd become used to so they could handle things they hoped it would protect them from. All of a sudden a distributed lock isn't a lock if your cluster splits.
In the end almost everything ended up back in Postgres. Resistance was surprising - there was a lot of opposition to simple things due to a fear that the database would be harmed by being used to hold a few row locks, for example.
I can see why people overlook the obvious when the complicated solutions seem more sophisticated, which is easy to mistake for "better".
Replacing a known solution with known limitations with a new, unknown solution which has no known limitations!
(... which means that there are limitations, you just don't know where they are.)
I recently found out that a simple .txt file serves me exceptionally well (a good IDE plugin definitely helps, too!). No more messy software, apps, journals, etc. which I feel are making my time management tasks even more challenging.
Sorry, someone had to do it!
Here's an archive snapshot if you prefer: https://web.archive.org/web/20200202175812/http://boringtech...
If you wanted to get fancier, feed a message queue into Azure Functions for the services.
