Hacker News Reader

Comment by bovermyer | Hacker News Reader

I see several comments here defending new-shiny syndrome in the context of improving the developer.

From a business standpoint, that doesn't make a ton of sense. Development is meant to complete the business's objective of solving a problem for humans. It's not meant to make the developers enjoy their work more (though that's a nice bonus when it happens).

Chasing the new shiny puts the team in a perpetual state of re-learning how to do a known process. Maintaining and extending existing code in a known way is more predictable and more cost-effective.

View on HN

Yet, if the developers who successfully mislead their employers into misguided tech choices have notably better careers, on average, it's exactly what we should do. And we shouldn't feel a bit bad about it unless we're in one of those rare roles where lives are on the line.

> Development is meant to complete the business's objective of solving a problem for humans.

Sure, but every layer of management is making decisions constantly, including about what to direct development to do, that are in their own personal interest rather than the business' interest. If they can do that, the peons can (and should) too.

This strikes me as very cynical.

In my own life experience, the majority of my employers have genuinely wanted to work together to improve things for a large group of people.

I have never worked for an employer where it was obvious that everyone was only out for themselves.

> I have never worked for an employer where it was obvious that everyone was only out for themselves.

I guess you mustn't have worked for very many employers. Or at least not in the USA. The sentiment is endemic where I am in Houston, TX and previously in CA

I have never worked in Texas or California, but my career started in 2001, and I've worked for 13 different companies.

Most of those companies have been in the upper Midwest - either South Dakota or Minnesota. My latest employer is based out of North Carolina.

Interesting that you assume my experience is invalid because it doesn't match yours.

The larger and less well managed (from the top) a business becomes the more likely that becomes. If you haven't experienced the converse I would advise you to seek it out. Working in an environment where the goal is understood and (mostly) everyone is working toward it because that is how they will be measured, is a joy.

I mostly have, which is the only reason I haven't taken my own (implicit) advice and become parasitic, like everyone else who's (personally) successful in large enterprises. That would have been a better move for my finances, for sure, but I don't really have the stomach for it.

OTOH I still think that complaining that people at or near the bottom of the org chart follow incentives to achieve better personal outcomes, because it might hurt the company a little, is naïve at best—at worst, it's propaganda in the class war. "Workers, please limit your own career trajectory to help out the company. Here, let me (deliberately?) misunderstand your motivations and, as is typical, present developers as akin to children, not like the fully-formed adults in management".

Haha. No.

I feel like you're reading more into my comments than you should. I'm a developer, too.

Your second paragraph... what is that in response to? How is saying that forcing other developers to follow the tech whims of some wannabe 10X is a bad thing "propaganda in the class war?"

> Your second paragraph... what is that in response to? How is saying that forcing other developers to follow the tech whims of some wannabe 10X is a bad thing "propaganda in the class war?"

The article, mainly, which reads very much like it's from the perspective of a project manager or engineering manager or something like that—as in "This morning you found out to your surprise that one of your senior developers" (emphasis mine), which seemingly-not-a-developer voice and POV it continues throughout. The (inevitable) infantilizing is here:

"Magpie Driven Development is when you have developers who want to use something new for no better reason than it’s shiny and fun."

Sure—except when developers do it because it's how you get ahead in this career. But that's something a rational person, not a toddler, might do, so we can't allow that that might be the reason. This sneering "oh, those childlike developers" tone is typical of management most places, when they talk/write about developers. I've even seen it in places that are pretty damn developer-friendly and tech-driven—it's subtle, but "oh, you know how software developers are" is deeply ingrained in management vernacular. I think it's a defense mechanism, mainly—and a very successful one, from what I've seen—because devs are paid like we're upper-middle-class but managers are, unconsciously or otherwise, very uncomfortable with us being in the same (or higher, maybe) social class as them, so take care that we do not rise in status on that front. I think that's how you end up with that kind of language being the norm, when managers treat of developers. "Well OK they make a lot of money but aren't they so immature and flighty and distractible? And god knows they can't be good at talking to people, or understanding how business works, or anything else that's our job. Now hold on, I've got really strong bad opinions about how this button should look and I expect to have my thoughts treated with deference and close attention. Why? Well, look at the org chart! That's why."

Anticipation and avoidance of this dynamic is why lawyers and doctors tend to resist having non-doctor and non-lawyer managers—and it's part of why those professions still, on average, carry significantly more social value than "software engineer". Pay's only part of the equation.

> defending new-shiny syndrome

this is itself a negative phrasing for the phenomenon. For one thing, Rust isn't just shiny and new - it has actual benefits.

Depicting "a perpetual state of re-learning" as negative/positive omits whether or not the process is actually improving or not.

> Maintaining and extending existing code in a known way

depends how debt-inflicted it is. In any case, this article describes a new service, so there wouldn't be the same issue as extending existing services.

There are cases - like a brand new service - where a new language or framework is a good idea.

In some very rare cases, rewrites can also be a good idea.

But choosing a new technology just because it's new and popular? Almost never a good idea.

Exactly. Remembering Scala? It had a lot of drag around 2010-2015 and everybody was like "this is going to replace Java everywhere". Now it is still alive, you will find some jobs, but career wise Java devs are in higher demand, and I don't think that'll change again.

Don't confuse popularity with hotness. The latter is the first derivative of the former. Rust is hot, but not popular. Scala is somewhat hot (was truly hot a couple years ago) and somewhat popular. Java is lame, but very popular. JavaScript is... a goddamn black hole.

> But choosing a new technology just because it's new and popular?

Sure, but the given example states that as assumption. IRL how is that determined. The article states:

> Investigating, you find out that there’s no compelling business reason for the component to be written in Rust. Not much of a technical reason either

but doesn't detail if that was based on (or in agreement with) the opinion of the senior engineer who implemented the service, or the opinion of the author (whose role isn't that clear).

I'd also state that that while "choosing a new technology just because it's new" is bad (although could easily be a proxy for the features that the new thing actually brings - Rust isn't just a new rehash of existing languages, it brings unique features); "choosing a new technology just because it's popular" does have merit.

Every technology has benefits - and costs. It's always a case of deciding if adopting it is going to be a net gain or loss.

Haskell has benefits as well. So you would be OK with somebody rewriting your Rust code in Haskell for example?

C, C++ etc are similar wrt domain as Rust, maybe even go. Haskell isn't the same kind at all.

A company has multiple stakeholders.

- Investors

- Workers

- Customers

- Community

A delicate balance has to be achieved by the company to meet everyone's need. If the company cannot achieve this, it will suffer one way or another.

This is true.

However, characterizing workers as only needing to work with their latest interest misses out on a world of other (and sometimes conflicting) needs.

Not every developer in an organization is going to want to change languages and ecosystems every Tuesday.

> Not every developer in an organization is going to want to change languages and ecosystems every Tuesday.

Not every developer wants to work with whatever Linus, Netflix and other Googles have concocted for their unique reasons yet here we are.

I don't understand what you're trying to say here.

It's OK.

That depends on the business. A lot of (but not all) software development is focused on making something possible that was not before. Experimenting with the shiny and new in those cases can lead to serendipitous advances.

Reply on news.ycombinator.com