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.
I have been doing this for 17 years and I prefer server side rendering and jQuery to React / Angular plus some REST API I know it will take around half the code, and will be easier to debug and maintain. It doesn't make my CV look good though.
But to each his own.
react is doing what php did a while ago (and is still doing). it's mixing frontend with backend stuff. i personally find it refreshing!
we did that for a while then people came and told us how bad it was and we needed to do strict MVC or whatnot. now everybody is doing it and it's cool again!
React / Angular JS etc tend to require spending a lot of time learning how it works first. Then you have to build almost all your application around it. This can take a lot of time, which pushed up costs and complexity. If you are building something like Google Docs or Google Maps you want to build it like a SPA. For a lot of the sites I've worked on in the past building it as a SPA was completely unnecessary.
> react is doing what php did a while ago (and is still doing). it's mixing frontend with backend stuff. i personally find it refreshing!
We've been trying to get away from that for quite a while. I try to write almost all my JavaScript in a way that assumes as little as possible about the page structure, the web application etc. It can be done, however it requires thinking about how your markup works and how the page works.
Generally you should have good separation between your markup, your styling and your scripts.
> we did that for a while then people came and told us how bad it was and we needed to do strict MVC or whatnot. now everybody is doing it and it's cool again!
The problem is that it is cool again. I don't want my backend code tied to my front end code.
Also there is a lot of jargon around each frameworks. So a lot of the time, I just give up and go back to jQuery, Handlebars and event delegation as that does 90% of what I need.
The certificate guarantees that the information you are getting is from the entity who actually has access to the server serving the website.
It seems the worst thing that can happen to you is to work on a successful, stable product. Almost by definition you will become an outdated dinosaur. To keep up your own market value you constantly have to insert friction by jumping on new stuff that doesn’t really improve anything.
When it comes to new tech and frameworks, those who pay don't care if use React, Angular or Svelte. They only want a working product that provides value for money.
Losing business has little to do with the technology that's being used or sold, it has everything to do with the problem that the business intends to solve or the need it intends to cater. And how well it succeeds in doing that.
You don't become an outdated dinosaur overnight because someone comes up with technology that brings marginal improvements to the customer. You become an outdated dinosaur if your competition figures out a radical new way of doing things.
IKEA didn't roll-up the furniture business because it re-invented chairs, tables, beds or cupboards. It succeeded in doing that because it successfully marketed self-assembly as a convenience to it's customers, eliminating a big part of the production chain. Moreover, that - in turn - opened up the door to disposable furniture by introducing low-cost materials, and a faster design cycle that has come to a point that it defines furnishing fashion trends.
My point is that - as an engineering team - you could decide to switch to the newest framework, stay on edge in tech trends, and still miss the boat completely because business still sticks to an outdated model while customer behavior - wants, needs, trends,... - have already shifted a long way ago.
Put differently, it's still possible to build a Facebook/Reddit/Twitter clone based on the latest and greatest technologies and still fail because you expect to push those out of that market. Whereas it's viable to do the same thing, but only if you differentiate by catering to the needs of a specific market segment. Hence why you see platforms like Mastodon thrive without exponential growth, even though Twitter caters to billions.
A successful or stable product is by definition not tied to temporary trends. It caters to a universal need that people will always have. When the market is saturated and sales plateau, the trick then isn't to fundamentally re-invent your product. It's to use what you've learned and tackle an adjacent segment of the market with a new product or service.
In software the vast majority of companies are one-trick ponies that stick to a single product or service that's too specific, and doesn't allow them to expand to other areas. That's what makes them so vulnerable for either a competitor that brings true business innovation, or fundamental shift in what consumers want next.
Put more succinctly: people tend to rail against corporate, boring, byzantine constructions such as SAP. But that's exactly how they operate. They started out doing payroll and accounting, and they expanded from that by incorporating adjacent parts of business processes in their software such as logistics, material management and production planning. A corporation like SAP doesn't go along in the short-run hype cycle unless a significant game-changer comes along such as affordable cloud solutions.
Now, hiring for experience in specific technologies or frameworks only makes sense if you're going to hire someone for the long haul, whereas if the horizon of your business doesn't extend beyond the next 2 or 3 quarters, well, you're shooting yourself in the foot by rejecting good, well-motivated candidates based on them not having 5 years experience with bleeding edge FancyFramework2020.
When paying nobody cares about the tech. When hiring, all they care about is the tech.
I've seen fairly decent backend developers having a right mare trying to get their head around just the npm tooling (no it isn't obvious if you haven't worked with it before).
People don't realise that there is a lot of the eco-system you have to learn just to do something fairly basic. You also have to unlearn things that you've done before elsewhere which itself can be difficult.
So I find this hard to believe.
Anyway this is going down the road of "why don't you use this it is easy?" which isn't the point I was originally making. I personally getting fed up of all the bloody tooling you have to learn to make something basic, when I can just ignore it and go back to basics.
Reach is quite a different abstraction than we are used to, it's huge and prolific.
It generally takes some time to get used to it. Though one might be able to do 'some production quality stuff' in a week, generally speaking, there's far too much that anyone is going to master in a week.
It hides too much of what is going on for my liking and if you break something a lot of the time it is impossible to diagnose without slowly pulling the code apart.
With just plain old JS I can always crack open the debugger and I am sorted.
Angular 4 was a lot better than Angular 2 as there were more docs available. One of my major frustrations at the time was that you couldn't just pull up an example of how to do something that I would imagine would be pretty common and you were scrounging around for blogs or things were behind a paywall.