Hacker News Reader

> Another solution could be encouraging personal projects.

Agree. This is necessary to encourage learning, which helps keep people sharp, which in turn benefits the projects that they are working on in the day job. Even if the technology is the "same old".

A couple of decades ago, many software developers were content using the tools they had and knew. Few demonstrated the eagerness and openness to try something new. These few were also the ones who were better at coming up with out of the box solutions because they were willing to try something new -- both tools and/or approaches. Now, we have reached a point where the bare minimum required of a software developer is familiarity and comfort with the new and shiny, leading to the reverse problem we had early on. Now, people can spend way too much time and energy learning and trying out new tech that they miss out on the opportunity of staying long enough with a technology to learn from experience.

In other words, today we spend way too much time on accidental complexity than on essential complexity.

"..today we spend way too much time on accidental complexity than on essential complexity"

This. So much this!

> encourage learning

Hell, I'd settle for just not discouraging it so damned hard.

The root cause of writing unnecessary code is the way the work day and compensatory systems of the modern workplace are structured. Employed software and infrastructure engineers are not paid to just drop in the simplest, most appropriate solution, do the minor customizations/reconfigurations that may be needed, and get out. They're paid to be in butt-in-chair for at least 8 hours per day, and the presumption is that they're engineering that whole time. In reality, places often must make up tasks to keep their employees busy, and using the most efficient solution is disincentivized, because you have to say you're doing something for those 8 hours.

I think the fact that we have the white-collar workforce organized after the assembly line pattern is the primary cause of unnecessary, borderline intentional complication, which includes mixing in unstable/untested components. If we could find a way to compensate engineers fairly without monopolizing their time, we'd be much better off, because the need to continually invent additional work for oneself would go away.

The bliss of a stable, low-maintenance project can be had through side projects, which often work fine for years with minimal modifications. It's really rewarding to go back to the same utility that you've written and know that the comparatively little quantity of time you spent on it is still paying dividends years later. There's an awesome sense of pride attached to that.

In reality, places often must make up tasks to keep their employees busy, and using the most efficient solution is disincentivized, because you have to say you're doing something for those 8 hours.

This does not match my experience. Slow times are for experimenting with things and catching up on less-urgent tasks.

> Slow times are for experimenting with things

You've led a charmed life. In my 25 years in this business, I've found that very little induces the same level of panic in management as "experimenting" with something, especially something that you can't put a solid "business case" behind and "estimate" down to the nearest half hour.

Which is only to be expected. Middle management is not about leadership but all about mitigating risk (Seth Godin explains this quite well in 'Tribes').

It's both a shame and moronic that often assembly line paradigms of management are applied to non-assembly line work (i.e. work that isn't the same for each iteration).

What's needed is to reframe work in terms of value instead of time wasted.

What's interesting is that if you look at history, there are different 'assembly line' paradigms of management, one which could be maybe be termed 'classic American' style (which could be argued necessitated the rise of old-school unions, leading to anti-productive standoffs between management and labor), and the 'Toyota style' which ironically was founded/seeded in Japan by Americans which could not get larger American car companies to listen at the time.

The 'Toyota style' could be argued as more responsive to worker initiative and fits better philosophically with software work. (And Agile is influenced by Toyota-way thinking too, though in a mutated form..)

The "Toyota style" has already played a substantial role in the philosophy of influential technology companies like Apple and Pixar. Steve Jobs was a known admirer of W. Edwards Deming, who created it.

Yes, that. I always feel managers are pressured to make sure devs are worked 8 hours a day, necessarily or not. As for side projects, it is really hard to keep a flow doing that knowing that at any time you may be given a "real task" or a maintenance issue to work on. Maybe contractors have a different work day since they are paid by the hour to do specific things, but full time always have the issue of nothing to do but not being allowed to go home or work on something to enhance knowledge.

> Recruiters filter resumes with a keyword based search

Although true, this is is somewhat shooting the messenger. If as a client of the recruiter I ask for COBOL developers and all I get are Clojure resumes because the recruiter thinks it's cooler, then the recruiter won't be my recruiter for very long.

Surely where there's an issue it's that the recruiters are being asked for developers with those attributes. They're presumably being asked because the employer, for good or ill is seeking developers with those attributes.

Now, I've personally seen 4 reasons for hiring devs with cutting edge knowledge: because it's cool, because it's the only way to attract good talent, because we checked and we absolutely need that technology and because we run a research lab looking into cutting edge tech we may or may not use.

The latter two are very good reasons to seek hotness. They're also the least likely to be the reason, in my experience. Using shiny, shiny to attract talent is often a successful approach. And who doesn't like cool stuff (though it's a terrible justification)?

It has been suggested several times on HN that another reason is that it attracts younger coders.

Younger coders tend to be more willing to just follow the lead of the management, rather than ask "is this really going to solve the problem?"

Younger coders will put in massively more hours -- this may result in problems like reinventing the wheel, piles of garbage code, etc. -- but it generally "feels good" to be the manager with an energetic, 24-hour around the clock team of young coders.

Younger coders can be paid less, and are willing to forego benefits, stability, medical plans, or even pay sometimes.

Almost half of my time in the past few months have gone into interviewing and hiring and I approached the subject with a complete beginners mindset and tinkered to see what works. Much to my chagrin turns out there is a positive selection effect to filter candidates by resumes based on hot tech. Maybe the smart ones know this increases there employability? Maybe they are naturally more curious? Who knows, it just seem to be a good signal.

> hot tech

your bias is showing.

I'm not sure what you consider hot tech but I can assure you whatever it is it is based on tech that has been around for ages and has just been rebranded. I find that people that hop from "hot tech" to "hot tech" don't ever build up a depth of knowledge and understanding to tackle hard problems in an elegant way. It is essentially a major contributor to the 1 year of experience repeated 10 times phenomena.

>I find that people that hop from "hot tech" to "hot tech" don't ever build up a depth of knowledge and understanding to tackle hard problems in an elegant way

You immediately assumed that the folks I found are just jumping from tech to tech without building anything substantial. Which is probably also bias, just an opposite of mine. You also assumed that I didn't vet them or test them on "elegant solutions". Maybe your heuristic worked for you. But this heuristic, in my current situation is thus far working for me.

Tackling hard problem is often so much social endeavor than the effort to solve it. You have to convince everyone the solution works despite all the bias they might have.

Maybe that's why many of the major changes you see in tech, like Linux, Git, Vim or Redis started as a single person's work rather than a clever corporate product.

I saw this at one large uk Telco Some one was going for a promotion so they spent a year and a team of 15 people to redevelop an existing perl system into an oracle based one as oracle was the company standard.

one of the markers for promotion was manage a team of x size and a > 1million budget - so they where gaming the system not the best use of the share holders money

The overwork thing has to be culture. I'm sure they think they're cost minimizing, but I doubt adding the additional labor costs more than the additional time of the current staff doing it all alone and being stressed out and so on. The "stressed out and so on" adds up to negatives that your company will pay out.

Remember that managers too respond to incentives. People working 9-5 are probably more productive than those doing 12 hour days, but which is more likely to keep the VC money flowing?

Also, most managers won't act on anything they can't measure directly.

It definitely factors into employee turnover rates. That is probably also where employees hurt themselves. People don't like looking for work and for good reason.

It's worth noting that the buzzword-keyword-madness is driven by web stuff, and amplified to an extreme the more a job is web and/or frontend related.

If you don't work in that field, you're fine :D