Chasing the shiny and new | Hacker News Reader

Chasing the shiny and new

nemil.com

66 pointsnemild16 comments

I don't think the problem is in the developers but rather the employers, especially the recruiters. They love to find a developer that is a perfect fit in terms of stack. If A developer is a better coder than B but if B has experience in the companies stack, they will put B as a higher priority. This makes sense since people can't tell which one is a better programmer by looking at resumes.

So what does a startup developers do? We have to chase after those shiny and new stack to keep up with the trend and be high in the market.

When we are looking for an another job, which job do we apply to? The one that is closer to your stack. You will be high in the market and get to say "I have experience". Because these are the things that recruiter/employer cares the most.

Designers face a similar problem; often companies do first-pass sourcing and filtering on the basis of Dribbble and Behance portfolios, which are heavy on pretty visuals but light on process and solving business problems. This was discussed extensively after https://medium.com/@intercom/the-dribbblisation-of-design-40...

This is something that has consistently frustrated me for years. I used to worry that I wasn't keeping up with the newest and most hip languages and frameworks.

When I saw other "trend" focused developers taking longer to launch apps and products, if they ever launched at all, I realized it was my ability to actually get something out the door that mattered, not only to myself but to my clients.

Part of me still likes learning new things, and I do occasionally experiment with new frameworks and languages, but having strong core competency in a few old languages has served me really well.

In general, people don't care how you mine gold.

They care that you have gold to sell.

Tinkering with hyperspatial hoversmelting 0.1.1-beta is a waste of time if you can just crush rocks, leach 'em and sell some flake.

To torture your analogy a bit further, though - it might matter to the miners. If you want to go at rocks with a steel pick - you're right: You can pull gold out that way and when someone buys it they don't care how you got it... But if you are mining with more than one person and the other competing mining crews are using power equipment and you're banging metal against rocks with your bare hands, you might find it tougher to get miners on your crew.

A more adequate analogy would be: You're a miner who carries your mined gold using your truck. It's efficient and cheap. Just what you need to carry stuff. But some new kids on the block think they should carry them using Ferrari, just because. "It's so cool! This way I'll attract all the miners to work under me because they probably want to ride a Ferrari than a truck to carry gold! Sure trucks can carry more, but my Ferrari can reach 315KM/h!"

+ a new model ferrari every year.

Or ~every 7 months for scribd who mention in the article 5 frontends in 3 years!

No, it's more like: some miners are carrying gold in wheelbarrows pulled by cars, with very intricate mechanisms to keep them from tipping over; some miners are hauling ore in the back seats of Jaguars; some miners are hauling it in trucks hitched to mules; and one shows up with a fully-fueled ore-hauling truck, and everyone looks at the new guy and laughs at someone trying to do something so foolish: the car-pulled wheelbarrow guys note that truck-users are using old-fashioned mule-hauling technology ('but i'm not using mules!' says the new guy); the truck-users note that people who don't use mules tear up their backseats or spill their wheelbarrows ('but I'm not doing either!'); and the back-seat-loading Jag-haulers note that internal combustion is a superior way of generating hauling energy ('but that's what I'm using, and a truck engine is superior to a car's for hauling ore!' says the new guy).

  > What worries me is that certain developers, especially 
  > developers early in their career, may get the idea that a 
  > startup engineer is not a problem solver or computer 
  > scientist, but... their task is [instead] to memorize a 
  > new... language, framework, or library - in many cases to 
  > get limited benefits.

While I agree that it's possible that an early stage startup (and I mean _early_, like building their first version) might flounder around rewriting their app using different tech stacks and never actually ship anything, I suspect that it's more common to see companies delay releasing their first version due to reworking things that are perfectly acceptable for a rough first version.

(edit: Also, I think the idea of a "sacrificial architecture" is useful when starting out. If you're lucky enough to need to massively scale, you're going to have to replace everything eventually anyway, so don't get too hung up on trying to make things scalable from day one.)

I suspect that it's more common to see companies delay releasing their first version due to reworking things that are perfectly acceptable for a rough first version

My observation has been that this gets a project into what I call the "done-but" category. "It's done, but could you change this?". "It's done, but can we make it responsive?".

This is especially rough if the company uses pretty mockups to sell products--the cultural focus on design/UI/UX can drag out development, burn out developers, and generally just slow everything down.

I've been thinking along similar lines for quite a while, you really did a nice job of laying it all out and making it coherent though. I've bookmarked your essay for future reference.

Something that doesn't get talked about too much, that I worry about, is the massive amount of duplication of work effort that happens as a result of this hyperchurn in software architectures. For an industry that relies on terms and phrases like "NIH" and "premature optimization" and "great programmers reuse" to emphasize the importance of productivity, a huge amount of effort is spent every year building out libraries and frameworks and languages to replace previous libraries and frameworks and languages that largely did the same thing.

Probably the finest example of this is is CPAN. Perl still has one of the largest community-managed repository of libraries of any other language (probably C or C++ or similar has got it beat). Any software developer in 2015 that decides Perl is just too antiquated to use and wants to move a large Perl codebase to, say, Node.js, now has to either rewrite those libraries or find libraries that have already been rewritten by someone else.

If Node (for example) were the only major new language since Perl, I could see how maybe the initial investment in effort to duplicate all of Perl's functionality might pay off if Node offers a significant enough improvement in productivity in the long term. But, since Perl there's been PHP, Python, Ruby, Node, Go, to name a few, and each of those have had their own competing frameworks ... we simply aren't gaining enough in long-term productivity when each new language or framework is being replaced within a couple of years by another new language or framework.

I have a hunch that a lot of this is a result of a competitive software developer job market. Newer and younger developers, lacking the background and experience of older greybeards, migrate towards newer technologies as a way to differentiate themselves. They eventually get hired into management roles (in startups, this can happen very quickly), where they have the freedom to operate their own fiefdoms, and they quickly establish rules of software architecture that ensure they get to hire other young developers that are comfortable with the latest trend.

It can seem a little bit absurd, but fortunately I'm not seeing many signs that this is happening that much yet outside of the HN & startup microcosm.

Let me preface this by saying I agree with pretty much everything in the article.

However, I just wanted to say that, as a heavily opinionated developer, I do happen to actively avoid applying to positions that involve working with certain technologies.

I avoid these technologies not because of any lack of shininess, but simply because I find them frustrating to work with, knowing there are better approaches available for the problems they're intended to solve.

I bet he wouldn't switch back to whatever he was using previously unless he had a friend working there and/or it was significantly more money.

It is a little tough learning new programming languages and frameworks every year or two though. But sometimes that's fun. Is it really necessary to track the winds of development fashion? No. But mostly I think people should realize a lot of it is about whats trendy and not hard technical issues.

Most companies don't have interesting engineering problems to solve, so all they have to attract talent is a shiny new stack.

I dunno, I lost all the hope understanding these shiny web-programming things...

But reading how plain Nginx works was surprisingly refreshing..

Something stack chasers should consider: one of the fastest product to unicorn, Slack, still uses PHP.

Reply on news.ycombinator.com