
A tech stack should be a well-balanced portfolio - chesterarthur
https://staysaasy.com/engineering/2020/05/30/Picking-Your-Tech-Stack.html
======
twic
> If you’re too boring it gets hard to recruit. You don’t want trend chasers
> joining, but good candidates have a healthy want and interest in new
> technology.

I think this is worth examining in a lot more detail.

I accept that candidates are going to be put off by obsolete or terrible
technology. I wouldn't take a job working on a Java 1.7 codebase, for example.
Or ATG (now Oracle Commerce) - i did three years on that, and will never touch
it again.

But if a candidate is motivated to take a job because they get to use shiny
new technology, i would suggest that they are not, in fact, a good candidate.
In my experience, magpieism is associated with weaker programmers; not the
very worst, but second quartile, say - people who get very engaged with
superficial details, but don't think about deeper things.

~~~
BigJono
I really, really want to double down on this, because it's not expressed often
enough or nearly well enough.

There is a huge contingent of devs (I work in the consulting space, maybe this
isn't everywhere) who have this idea that 'upskilling' is all about using new
libraries in some toy project to familiarise themselves with the API of the
library. They finish a project using React, then ask to be put on a Vue or
Angular one next so they can 'widen their skillset'.

You can pretty much split learning up into three kinds: Learning how to solve
new problems, learning how to solve the same problems in a different way, or
learning how to solve the same problems in the same way, but with a different
representation.

Learning the API of new libraries is almost always the latter, and people
constantly mistake it for the second one and think they're making progress.
Worse, people do this shit long before they've exhausted their options for the
first kind of learning (which is the best).

React, Angular and Vue all do the same thing. They all do it roughly in the
same way. Even when libraries do things a different way, learning the API is
often still the 3rd kind of learning unless the library's abstraction is leaky
as shit and you have to learn all the intricacies of their approach anyway.

Focusing on the wrong kind of learning makes a worse dev than you otherwise
would have been. I've worked with a handful of great devs, and a fuckton of
devs that know 20x as many libraries but churn out nothing but overengineered
unmaintainable shit.

If you want to distinguish yourself from the crowd, learn a boring technology
in an area that you're not as proficient in. Don't chase the fancy shit just
to build stuff you could already fucking build in half as many lines of code.

~~~
stupidcar
I disagree with respect to frameworks like React, Angular and Vue. Yes, they
all "do the same thing" when viewed from a distance, but up close the details
of say, managing state with hooks in React, is very different from managing
state with services and RxJS observables in Angular.

These differences aren't always sexy, but understanding them is usually the
difference between a developer who can deliver a high-quality solution and
solve difficult problems and one who can hack together something that sort-of
works with enough Googling. In my experience, a lot of "overengineering" in
these kind of frameworks is really devs with insufficient understanding of
their details inventing unnecessary workarounds and abstractions.

So, yes, devs flitting between frameworks is a problem, but not because
they're doing the wrong kind of learning, but because they never learn enough
to be truly effective. And I don't think this is a result of some pervasive
attentional deficit, but because hiring practices, especially in consultancy,
favour direct commercial experience above everything, and devs are
economically incentivised to maximise their earning potential and pool of job
opportunities by working with as many technologies as possible.

~~~
mkagenius
> high-quality solution and solve difficult problems and one who can hack
> together something that sort-of works with enough Googling

Are you assuming enough Googling can't produce high quality solution?

~~~
BigJono
Yes that's an absolutely sound assumption when it comes to web development.
The vast majority of resources are written by people that fall into the exact
category stupidcar described, with superficial knowledge of the libraries
they're using. If anything, Googling gets you further from the simple, clean
solution a lot of the time unless you're already experienced and can sift
through the bad sources of information.

------
tango12
Another rule/heuristic that seems to work well, along with Rule 4 from the
article, is having a limited number of golden tickets per team. A golden
ticket gets used up when you use a "new shiny thing" or "cool but not
widepsread" thing.

For us, the risky choice in our stack [1] was Haskell. It's been amazing and
has paid off immensely, but the challenges are very real. Over time we've
wanted to go whole in on things like ReasonML too, but we haven't pulled the
trigger or made safer choices, because that one golden ticket has been used
up.

(I can't take credit for coming up with this, but I don't know who did! I'm
sure it's already better articulated somewhere.)

[1] [https://github.com/hasura/graphql-
engine](https://github.com/hasura/graphql-engine)

~~~
WJW
I think the usual term is "innovation tokens", from the "choose boring
technology" post at [https://mcfunley.com/choose-boring-
technology](https://mcfunley.com/choose-boring-technology). It's definitely
very helpful in preventing projects from choosing all the shiny new tech at
once while not preventing any all innovation at all. Some of the shiny tech is
actually worthwhile, after all.

------
lucb1e
This convinced me the issue is not with people, it's with the system. If the
author chose Markdown for their blog and yet can't seem to spare a single
minute to read up on how it works, then I guess we can't expect people on HN,
stackoverflow, etc. to learn it either. Input whitespace (including newlines)
does not translate 1:1 to output whitespace in Markdown and this mistake
happens a _lot_ in comments here, on stackexchange sites, etc.
[https://dro.pm/a.png](https://dro.pm/a.png)

More on topic, I find it a bit disheartening that people are discouraged from
picking a niche library and are instead supposed to look at GitHub's star
system. So if it's not on GitHub or if my users don't star it enough, you
shouldn't consider it for use in production? Shouldn't the documentation, code
quality, open issues / maintainer responsiveness to issues, etc. speak for
itself?

~~~
gridlockd
> More on topic, I find it a bit disheartening that people are discouraged
> from picking a niche library and are instead supposed to look at GitHub's
> star system.

Just because it's disheartening doesn't mean it's unwise.

> So if it's not on GitHub or if my users don't star it enough, you shouldn't
> consider it for use in production?

If it's big enough to be popular _and_ not be on Github, that's a good sign.
If it's not that popular and refuses to be (also) on Github, that's a really
bad sign.

> Shouldn't the documentation, code quality, open issues / maintainer
> responsiveness to issues, etc. speak for itself?

No, because popularity adds value well beyond those things. It tells you that
_other_ people have found that the piece of tech is "good enough". They've
already run into issues for you, so that you don't have to. They've already
trained on it so you don't have to train. Popular projects are made better
just by being popular, which is self-reinforcing.

Of course that means sometimes ill-conceived technology (like
HTML/CSS/Javascript) wins out over contenders that are better "on paper".

~~~
lucb1e
> They've already run into issues for you

A star does not mean someone used a library for an extended period of time and
decided to endorse the project by giving it a star. I expect most people use
it as a like button (showing appreciation for or approval of the work and
nothing else), a bookmark (since you can view your stars), or both.

Looking at my own stars on GitHub, the first one is something I never used, I
just liked that someone documented the protocol for me and published some
software around it, so I could make my (planned) open source alternative to
the vendor's proprietary crapware more easily.

The second one is a factorio mod that I enjoyed using.

The third is a list with an overview of algorithms. I suppose I gave it a star
for similar reasons as why I might give a comment or article an upvote.

The fourth is a simple PHP project that looks nice, but I honestly don't
remember seeing it and I certainly never ran it.

So that's n=1 but given how easy it is to leave a star and that there is no
way to leave a negative star or any sort of comment: no, stars have nothing to
do with endorsement, quality, running into issues, or any such quality. If I
want to leave a comment to indicate or warn that something is broken, of bad
quality, or something similarly negative, a ticket ("issue") is what I might
create, and so I circle back to my previous statement: look at other qualities
like developer responsiveness in tickets, past tickets...

A "clones+downloads from unique IPs+users" or something similar might be a
metric for how often this was actually attempted to be used, and given that
most people wouldn't forward bad software to others, that might say something
about it beyond some threshold. But it still doesn't tell you anything about
their experience with it, for that you'll (currently) really have to look at
other factors.

~~~
gridlockd
It doesn't matter. A project that has 500 stars is most likely going to have
more active users than another one solving the same problem, but with only 5
stars.

Similarly, a project that has 5000 unanswered issues is going to have more
users than one with 50 closed issues.

In lieu of any better metric, this is the way to gauge popularity.

~~~
lucb1e
> It doesn't matter. [Repeats previous argument.]

Not sure why I bothered replying to you if you're literally saying "I don't
care what you just wrote"

~~~
gridlockd
If I didn't care what you wrote, I would not have replied to explain _why_
your concern doesn't matter.

I did not repeat the argument. Let me explain it differently:

Let's say that on average N% of people give a project a star because they're
active users and (100-N)% give a star for any other reason. There is no reason
to assume that N will be significantly different for similar projects. I don't
know N, but _it doesn 't matter_ how big N is, more stars still imply more
active users.

Is there going to be variance here? Of course, but it's unlikely to distort
the metric to the point where it becomes invalid, unless you have very samples
(stars).

Indeed, if there's one project with 10 stars and another with 5 stars, the
chances are high that it's just noise. You cannot get a good estimate of which
project has more active users in that case. However, you can tell that
_neither_ are popular and both are risky dependencies.

------
jamil7
I feel like this applies especially to the persistence layer, I pick postgres
basically everytime, I don't want any surprises at that layer. The rest you
can chuck out and rebuild without too much pain.

~~~
kfk
I actually feel even better when I am persisting using static files (json,
csv, parquet, etc.), but of course that's not always possible.

~~~
twic
Three years ago, i would have agreed with you. Now, i have three years' worth
of static files, and i am not so sure.

------
wiremine
These are well-reasoned defaults. I think the same can be said of
architectures, not just technologies. I.e., when you're starting out, a
monolith is likely a solid approach: it's easier to reason able, easier to
deploy and debug, etc. But as you scale, you need to rethink your approach.

------
AlchemistCamp
A related discussion here was the cofounder of Scribd talking about how Rails
was a fantastic decision but he wouldn't have picked it for a new startup at
the end of 2015: [https://jaredfriedman.wordpress.com/2015/09/15/why-i-
wouldnt...](https://jaredfriedman.wordpress.com/2015/09/15/why-i-wouldnt-use-
rails-for-a-new-company/)

[https://news.ycombinator.com/item?id=10236210](https://news.ycombinator.com/item?id=10236210)

------
sarreph
This is the important line for me:

> Every time you aren’t boring in a technology pick, you’re likely not
> optimizing for your company’s best interests.

Really helps to underscore the difference between choosing something shiny and
choosing something pragmatic and efficient. When we do the former (as I'm sure
most of us gravitate towards), it's very easy to kid ourselves that we'll
somehow make the product greater as a result, but in reality we're only
serving our own interests (learning something new and fun) rather than the
company's!

~~~
WJW
Most people know this and have no problem with it. It's pretty well known that
the company won't look out for your best interests so you'd better do it
yourself.

------
maps7
I feel like this blog post is written towards people who shouldn't be making
these decisions. I think the people making decisions like this should be in a
senior, experienced position.

~~~
BigJono
There's stacks of people in senior positions that fuck this stuff up
constantly. The start-up graveyard is probably full of companies where the CTO
came in with an impressive resume then spent 2 years building some massive
scale kubernetes clusterfuck for his 5 users while another company ate his
lunch with a shitty PHP app.

~~~
staysaasy
Indeed, this unfortunately does happen. There are also very smart but
relatively inexperienced people who need to pick good technologies due to
circumstance. Younger technical founders or early engineering hires come to
mind.

------
jonnypotty
Any real project would have real requirements. These real requirements are
always going to trump a star rating system, 'what's popular' or a generic
guide on the Internet. You should define your requirements and then pick the
tech which is best at providing a solution to this requirement.

What? I'm going to have a choice of two bits of tech and I'm gonna decide to
use one over the other cos it's 'boring but not too boring'? Come on now.
These are rules for people who don't know what they're doing aren't they?

Understand your requirements. Understand the technology you propose to use.

------
jonnycat
I would add: have a process or framework for evaluating and adopting new
technologies. Sometimes new technologies end up as part of the stack through
pure momentum (hey, we built this prototype...) rather than deliberate choice.
Be mindful of what the technology is being used for and what the costs of
changing down the road might be.

