Hacker News new | ask | show | jobs
by arethuza 2307 days ago
While not disagreeing with your point, it is also worth noting that in some contexts developers are regarded as unemployable if they don't have experience with whatever the latest technology is so it is hardly surprising that people use every opportunity they can to get exposure to the latest tools.

'Modern' hiring practises cause a lot of problems.

4 comments

That’s a real problem. I feel that me and my team have done serious damage to our resumes by solving the last few projects in a simple and straightforward way. Instead we should have done cloud, containers, React and whatever even if it made the solution very complex. This became really clear a few months ago when management two layers up gave one of our projects to another company who will move it to AWS. There were already plans for the transition and we said we could do it easily but the director decided that we have no experience and can’t do it.

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.

Do you think this is the reason for some of the supposed ageism in the industry?

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.

I agree. Most of my colleagues think I am quite a decent JavaScript programmer, but because I haven't got much commercial experience with React or Angular it is quite difficult to find a JavaScript role.
You can learn any framework and get good at even while on a project, in just a couple of months. The problem is that there are too many things to learn in terms of tooling and frameworks all the time making you have less time/bandwidth for the actual domain problems which are why you have the said job. Getting good is one thing and becoming an expert is another. Because these frameworks lifetimes you don’t want to become an expert over and over again on things that become obsolete because it takes a lot of energy and the payoff is short term.
The problem I have with many of the modern frameworks is the tutorials is extremely simple or they are far too advanced.

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.

That's why I am saying "while on a project". You have to create a project for yourself or join an existing project to make a framework like Angular click. Just aimlessly learning makes it much harder to make all this knowledge "crystallize", especially if it's the nth framework you're learning and the motivation's become low.
I've worked professionally with Angular 2 and 4 and it just a PITA. People either just end up using it like the JavaScript version of ASP.NET WebForms or you end up with one guy that really knows it inside out and nobody understand the code he has written.

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.

Things have gotten better with Angular 7 but, my experience is different from yours. I built my own project in Angular 7 , followed all the guidelines and maintenance has been a non issue and the project is very clean. But I could see things going crazy complicated if more devs add code to the project, I hear your frustration
It's a self-fulfilling prophecy.

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.

“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.”

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.

Nobody cares how the pie is made. They simply want pie.

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.

”Nobody cares how the pie is made. They simply want pie. 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.”

When paying nobody cares about the tech. When hiring, all they care about is the tech.

Hence the cognitive dissonance I was mentioning in my initial reply.
Yep, that's the other side of the "resume-driven development" coin.