
Chasing the shiny and new - nemild
https://www.nemil.com/musings/shinyandnew.html
======
betadreamer
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.

~~~
didgeoridoo
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...](https://medium.com/@intercom/the-dribbblisation-of-
design-406422ccb026)

------
brandon272
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.

------
jacques_chester
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.

~~~
dccoolgai
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.

~~~
volaski
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!"

~~~
zeveb
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).

------
jt2190

      > 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.)

~~~
angersock
_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.

------
thaumaturgy
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.

------
lewisl9029
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.

------
ilaksh
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.

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

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

But reading how plain Nginx works was surprisingly refreshing..

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

