
Ask HN: How to challenge trends without appearing like a luddite? - amanzi
This is something I&#x27;ve been thinking a bit about recently and would like to ask others how they deal with this. There are many popular trends that I believe are not suitable for every situation, ranging from cloud computing to open plan offices, DevOps and agile are other examples. What are some strategies that can be used to challenge these trends without appearing like a luddite?
======
edmundhuber
A lot of these things that you're pointing out are pretty vague. To pick apart
one: "devops", it can mean "using docker", and/or "continuous deployment of
configs", and/or "greater developer empowerment", and/or "no dedicated
infrastructure team", etc.

IMO, attacking all of "devops" (or "agile", or "cloud computing") at once is
not productive, because it means so many things. So if you don't get specific,
as others have said, it makes you seem like you just oppose new things.

For example with devops, a very rational concern is that if the infrastructure
team shrinks or disappears, then there's no one on the hook for making things
all work at the same time. If you leave it to the developers of each team to
make their thing work, you are likely to have a continually broken development
environment.

A good argument to oppose any change without a clear rationale for the change
occurring is "if it ain't broke don't fix it." This, at least, leads to
someone explaining why change is necessary, and then from there perhaps you
can have a conversation.

~~~
BerislavLopac
My problem with "if it ain't broken don't fix it" is that there can be many
different definitions -- end levels within each definition -- of broken,
especially in complex systems. Take a standard example of a software app which
is working as it's supposed to (so it's "not broken" in one sense) but is a
mess of spaghetti code which makes it insanely difficult to add new
functionalities (so it's "broken" in a different sense).

When you look at it it becomes clear that it is important to understand which
levels and definitions of "brokenness" are possible in your case, and even
more importantly which of them matter and how much. Only then you can look at
each proposed solution to find out which of the important problems it solves
and how well.

~~~
edmundhuber
"If it ain't broke don't fix it" is absolutely a strawman, I agree. The point
is to seed a discussion.

------
DoreenMichele
For one, pick your battles. If you knee-jerk oppose everything that's new or
_trendy_ , people will start to see you as "that person who always objects,
whether it makes sense or not."

~~~
mmt
Agreed. Sometimes, even if every new/trendy thing really _is_ harmful in some
way, some may actually be either minimally harmful or not truly applicable.

A trivial example of the latter (that I've personally experienced) is a
company deciding (at the very top) to implement "Agile" complete with
"mandatory" training (presumably useless and easily skipped in large enough
companies). It may have been more than lip-service for some departments, but
in Ops, our "standups" remained sitting-down meetings in a conference room and
we otherwise worked as we used to. The managers had some new dashboard view
for Jira that would bring some browsers to their knees, which helped
prioritize and redistribute work, but that the only noticeable change.

I'd also suggest that, once you've picked the battles, pick a sequence, so
that you only fight one at a time, with the most winnable (not the most
important) first. That way, you can use the practical benefits of the win as
evidence in the next battle (assuming you can fight based on evidence and
reason, not on politics).

EDIT: Having a "win" early will also help your morale for the next battle.

~~~
DoreenMichele
_only fight one at a time, with the most winnable (not the most important)
first._

This is a good nugget of advice. I wanted to pull it out and highlight it in
hopes it gets the attention it deserves, though I don't really have anything
to add.

------
tCfD
> Ask HN: How to challenge trends without appearing like a luddite?

Wherever possible try to have ready an alternative answer to the need, niche
or opportunity vacuum into which the trend is growing.

It's very difficult to get people to drop a habit- that they have already
invested time, reputation and personal capital (let alone money), into. At
best you may be able to entertain some of the more patient victims with
articulate and substantive criticisms of the trend that hooked them, but if
you don't have an alternative ready to redirect their sunk experience cost
into, they will in all likelihood promptly forget any persuasive arguments you
made and go right back their trusty pint of (say) blockchainism they've been
refilling down the blockchain pub with their new blockchain friends.

~~~
DoreenMichele
_try to have ready an alternative answer_

Something I heard at my corporate job: "Bring solutions, not complaints." It's
a great rule of thumb to follow.

~~~
mlthoughts2018
I think this is bad advice personally. Imagine if you complained about sexual
harassment and were told to “bring solutions, not complaints.”

A complaint is useful feedback that can alert you to a coming problem or an
unintentional pain point or a previously invisible suffering group of people.

It’s exactly attitudes that try to undermine the purpose of a complaint by
trying to implicitly shift the burden of a solution onto the complainer that
create an air of fear or timidity that mere feedback is not acceptable, and
will be treated like it is the same as whining, preventing people from using
the complaint as a mechanism to alert a wider group of problem solvers to the
issue.

It doesn’t matter if it’s complaining to the police about a loud neighbor,
complaining in a court of law about some harm you suffered, complaining to HR
about sexual harassment or complaining to the waiter that your food was
brought to you cold.

It should be seen as a perfectly polite, reasonable, and useful thing to
complain and leave the solution up to someone else.

In cases when it’s appropriate for you to also propose a solution, because you
have relevant skills or experiences or something, even better.

But you should never make someone feel like their complaint doesn’t deserve to
be heard unless they also have a ready made solution in hand too.

~~~
DoreenMichele
In the context of trying of get things done at work, which this question is
apparently framed as, where the issue is not sexual harassment, I have found
it to be a very effective rule of thumb.

I think you are reading in meaning that isn't there. It is a rule of thumb for
precisely this type of goal. It is not a rule of thumb for how to deal with
situations where you are clearly being wronged and it is clearly someone
else's responsibility to right it.

But it works really, really well for trying to insert your agenda where doing
so may not be all that welcome and where you are potentially stepping on toes
politically, toes that could potentially cost you your job if they find you
offensive enough. If you have a better way rather than just a criticism, it
tends to be much, much better received.

~~~
mlthoughts2018
I disagree even in that case. When my colleague complains that a certain
software module is overly complex, say, that’s really useful feedback even if
they don’t have time to itemize the specific reasons why or propose
alternatives. In terms of delegating and scheduling, it might just fall on
someone else to take the complaint and look into whether the code can be
simplified.

Raising a complaint long before having a full alternative is really useful in
matters of team conventions, design principles, adoption of different tooling,
workflow policies, etc.

I would always want to foster an environment where teammates could feel free
and empowered to speak up about a topic that doesn’t sit right with them, and
never feel implicit pressure to be quiet or keep to themselves if they cannot
already propose an alternative.

I like to say that it’s all about empathy, but people often think about
empathy completely backwards, from their own point of view, just “not wanting
to hear it” or getting annoyed with a particular colleague who is often vocal
just because they irrationally wish the person would be quiet and not
introduce extra work via some complaint that needs looking into.

This is backwards because you should be happy and welcoming for people to tell
you all this stuff. Part of being a professional is increasing your capacity
to absorb complaints to make other people happy by solving their problem when
they alert you to it, and not getting upset or annoyed (or at least not
letting it affect you), and thinking _they_ should be holding back for _your_
sake.

It’s a natural extension of a lot of the advice in, “How to win friends and
influence people,” applied to the workplace.

~~~
DoreenMichele
I think you are seriously reading in a huge amount that isn't there. There is
no edict here to keep silent or something.

There are lots of circumstances where it's fine to voice criticisms. But where
you have a clear agenda to oppose specific things at work and you want to
insist on change happening, how you bring that up matters and just loudly
complaining and insisting it is someone else's job to fix it isn't a best
practice.

~~~
mlthoughts2018
I don’t agree. I was responding to the parent comment that said this:

> “Something I heard at my corporate job: "Bring solutions, not complaints."
> It's a great rule of thumb to follow.”

It’s clearly talking about a general office culture, and not restricted to
long-running agendas or anything, but rather having good “corporate
citizenship” by not complaining or something, an institutionalized mantra to
equivocate complaining with whining— I don’t think it involves reading
anything extra into it in order to see that in the parent comment.

~~~
DoreenMichele
Seeing as how I wrote the parent comment, I think I am the ultimate authority
here on what I intended. Given the context in which I was making the comment,
I didn't feel I needed to make a long list of provisos clearly delineating
that it applies to x, y and z context and should not be assumed to be a
written in stone commandment one should follow upon pain of death. "Rule of
thumb" seemed to me to be adequate to convey such.

I have now delineated some of those previously unstated assumptions. If you
want to continue to insist I have no idea what I myself think or intended,
then I don't think there's any point in discussing it further.

~~~
mlthoughts2018
But you specifically say to use it as a general rule of thumb (a general
cultural norm in your workplace), and that’s precisely the point I was
disagreeing with.

If you both literally said, “It's a great rule of thumb to follow.” but also
did not mean it should be a general workplace norm, then I cannot see any
consistent way to interpret your original comment.

If anything, the rule of thumb would be to charitably and patiently listen to
complaints earnestly, and only delineate special cases when complaining would
be discouraged.

~~~
DoreenMichele
No. I did not use the word _general._ I did say this as the lead in:

 _Something I heard at my corporate job:_

Although I can see where that would be interpreted as indicative of a general
cultural expectation, it was a saying of one specific manager in my
department. It was not some kind of cultural edict. I intentionally chose to
not say that as I felt that detail was a pointless derail. I was merely
offering a pithy alternative saying for the point someone else made.

It is, in fact, a rule of thumb I find works well for many things. But, given
the specific context in which my remark was made, you have seriously read in a
lot of assumptions that are wholly unwarranted.

If this comment fails to clear up this misunderstanding, then let me suggest
you just ignore the entire thing and stop trying to parse it. Far too many
words have already been written about this silly misunderstanding.

~~~
mlthoughts2018
I would always read “rule of thumb” as a general rule, something you would
consult in your mind as potentially being applicable in any given circumstance
(and hence is general, by definition, even if you did not use the word
“general”).

I feel like I’m being chastized here for defending a reasonable, obvious
interpretation of your comment, while you are doing mental gymnastics to try
to add qualifications to it.

I’m fine to drop the issue from this point, sure. But it feels rude to me that
I am being told to stop talking about it even though reading back through the
comments after sleeping on it, it seems obvious that my original
interpretation was right, that I described my counter point in a perfectly
civil way, and that your replies don’t seem fair.

~~~
DoreenMichele
You aren't being told you can't talk about it, nor are you being chastised.
You are being told -- repeatedly -- that what I meant is not what you heard
and then you insist you are in the right and I am in the wrong when I know
best what I intended and no one else seems to have some big issue with my
wording, which suggests the misunderstanding is likely primarily on your end,
not primarily rooted in terrible phrasing on my end.

You and I obviously see the meaning of _rule of thumb_ differently. I'm not
going to look it up and get into some pedantic argument here about which of us
is "right."

I don't know why you feel some need to repeatedly inform me that what I think
I meant is not what I meant. But this discussion is fundamentally a waste of
everyone's time if you are going to simply insist that your interpretation of
what I intended is correct and true and my attempts to explain what I intended
are somehow bad behavior of some sort.

I don't know how more clearly to convey that. I think I have been extremely
patient myself here with trying to find some means to communicate while you
appear to be dead set on telling me I don't know what I meant, which just
sounds like a rather crazy assertion on the face of it.

It's reasonable to state that it sounded to you like I meant X. It is not
reasonable to insist I couldn't have possibly intended something else since X
is not the meaning you personally got out of it.

I intend for this to be my last reply. You've taken more than enough of my
time over this matter. If that upsets you again for some reason, so be it.

~~~
mlthoughts2018
I'm only saying that after reading and reflecting on your follow-up comments,
the thing that seems most likely to me is that your original comment was meant
to offer general advice that I felt it was valuable to state a disagreement
with. The follow-up comments don't provide evidence, discussion or any
information that causes me to revise that belief. It seems more likely to me
that you're retrofitting an explanation to your comment because you don't
happen to like my line of disagreement with you or something like that. I am
not even sure why it matters so much to you to repeatedly insist there was a
different intended meaning to your comment. So what? In a LessWrong-style way,
the meaning of your words is what gets induced in the mind of the reader, and
_not_ what you have in mind when you wrote them. It would be super easy for
many other people to read your original comment the same why I did, and that
alone makes the follow-up discussion about disagreeing with it a valuable
thing, totally decoupled from what you meant or even what you personally
believe. It's about how people will read and understand that particular
comment, _not about what you meant by it_ (although, I still think the most
likely scenario is that you _did_ mean something like a general rule to
consult in a general corporate setting, and backtracked to qualify it later
on).

> "You've taken more than enough of my time over this matter."

I don't necessarily agree, but I do agree that this meta-discussion about who
meant what seems counter-productive. Extended discussion about why a rule of
thumb that puts implicit pressure on people to not raise their complaints
would actually be valuable, because it seems a lot of people don't think any
further than the fact that they find complaints to be annoying, and support
the idea of corporate mores rewarding "problem solvers" instead of "whiners."

------
mabynogy
I share the opinions you've expressed. For the cloud, I say "it's expensive"
(10x more than a bardebone server).

I don't try to be people-pleasing. I tell my truth. I'm never aggressive but
people often understand something that is not is my words (something they
believe).

I believe it's also a good strategy to create meaningful relationships. If you
show the others who your are everytime, they can count on what they know about
you. You become more trustful for them.

I wanna improve OSS. I wanna change the current meaning (keep the freedom for
the users but add money for the programers). If I'm successful, the content of
the Wikipedia page about FOSS should changed.

Feel free to reach me to talk about that.

~~~
mmt
> For the cloud, I say "it's expensive" (10x more than a bardebone server).

As do I, although there seems to be some kind of mass delusion in effect that
causes disbelief of this.

I'm careful not to quote a _single_ multiplier, though I do point out that
it's a multiplier, not just merely a percentage (below 100%) premium. I've
found that it can vary between 2x-10x, depending on ones specific performance
needs and how much one is paying for colo "space" (power).

Part of what I've been realizing is feeding the misconception (if not mass
delusion) is that the knowledge on how to price/negotiate commodity servers
without getting, shall we say, fleeced, is quite rare. Getting a good deal on
the base server and CPU doesn't matter if the bulk of the order is RAM and
storage and you're grossly over-paying on those.

~~~
mabynogy
I quote that number because I saw a study about that. The worst was AWS (x10)
and the cheapest was Google (x2).

~~~
mmt
If you still have a reference to that study, I'd be interested to have it,
since all of my own cost comparisons have been done for employers, which means
I haven't been able to release the details.

I'm also curious as to how Google came in 5 times cheaper than AWS. I knew
intuitively (and through an occasional pricing spot-check) that GCP and Azure
could be price competitive enough for certain workloads to be worth
considering (assuming a spikey/elastic enough load that cloud makes sense in
the first place), but I never saw that extreme a difference.

~~~
mabynogy
Sadly no. I tried to find it.

There is a tool to build around that.

~~~
mmt
Someone has started, at least for AWS, as this was on the front page:
[https://news.ycombinator.com/item?id=17551796](https://news.ycombinator.com/item?id=17551796)

Interestingly, many of the comments are asking for support for GCP, although
the response seems to be that Google's tools might be better (enough) than
Amazon's that it's not as urgent.

~~~
mabynogy
Interesting. The mockup on their homepage give some prices. With their 1610$
example, one could rent a whole datacenter (1000 i3 with 4Gb and 4Tb HDD at
1.6$ per day - 50$ per month).

I sent you a mail yesterday. Maybe it went to the spam folder.

~~~
mmt
That example corresponds to $49k monthly, which, among "Silicon Valley" tech
companies is, apparently, not a huge amount.

To be fair, the machines you specify are pretty tiny and would easily fit into
a half-U enclosure. Even assuming only 36U usable (after network, power, etc)
per rack, those thousand would fit in 14 racks, a very small fraction of a
whole datacenter.

(I did see the e-mail.. I think I have HN emails explicitly bypass spam. I'll
check out your site and reply privately later today)

------
AndyMcConachie
The luddites were not against technology, that's a common misperception. The
luddite movement was a labour movement. They just didn't want to lose their
jobs.

~~~
splintercell
Yes, but at the end of the day they opposed something objectively good for
everyone. This is why Luddite is a negative term.

------
1996
Wrong question. Do not challenge trends, challenge yourself. By introspection.

List the proposed changes, and their date. Look at how many of them you agree
with, as a function of time. The proportion should stay approximately constant
with time. If you like new things less and less, this is not just luddism, but
getting old.

I try to apply that to myself - I am generally against cloud computing because
of the greater costs, but pro devops because of the moderate costs increase
and much greater flexibility.

Unfortunately, you seem to have already decided all these things were just
trends, or fads, that should be challenged without looking like a luddite.
This looks like rationalization to me.

~~~
NeedMoreTea
Nice idea but makes no allowance for recent ideas being poorer than earlier
ideas or that the good and bad might run in phases. If I look in the IoT niche
I might easily conclude that terrible ideas and trends are the only ones on
offer.

Choosing _which_ are aging changing one's perspective and which a good ideas
changed for the worse for change's sake is a far more difficult problem.

~~~
1996
If phases are a problem, compute the average on a larger time period. 5 years
would go down to 2013, 10 to 2008

Then, unless you believe the world is becoming a worse and worse place, I do
not see why 1998-2008 should be a golden age, while 2008-2018 would have
poorer ideas in general.

If anything, I believe in the opposite, as most of the mobile low hanging
fruits are gone, and crypto is where the action is now,

------
jchw
Stop focusing on stuff you disagree with. Tell us why. For example, devops may
be BS, but if so, why, and what is the alternative? There are answers.

Try to keep in mind that just because you're challenging a trend does not mean
you're correct and you should always consider that A.) There are absolutely
things you do not know that might change the answer(s), B.) When you disagree
with a trend you're often disagreeing not just with people who follow the
trend, but a large population of smart people that set trends too, and those
people often have reasons for their ideals (which are often valid in context.)

Sometimes it turns out a lot of ideas do make sense with some constraints. Few
ideas make sense if you consider every single possible parameter. You probably
don't want to build a web of microservices running with several internal and
external load balancers that call through webs of RPC requests in order to
serve your personal blog that sees 1000 requests per day, for example, but
that doesn't mean designs utilizing some of those patterns are unilaterally
incorrect or not effective to solve problems at a different scale.

~~~
throwawayjava
_> Stop focusing on stuff you disagree with. Tell us why. For example, devops
may be BS, but if so, why, and what is the alternative? There are answers._

Also, consider the possibility that you are _wrong_ about the fad being stupid
_precisely because_ you've already accepted the fundamental premise behind the
koolaid.

The original instantiation of devops is actually the "fad" that made me
realize this particular truth. I had only ever worked in situations where all
the infra people sling scripting languages along with the best of 'em and the
software developers are as comfortable with iptables and apt and load
balancers as they are with their editor/ide/compiler of choice.

So to me, devops sounded like a lot of ridiculous hot air -- it's just a new
name for how things have always been; how can all these promises about
productivity improvement make any sense to anyone?! And besides, the stuff
that wasn't obvious was often ridiculous cargo culty stuff.

What I didn't know was the sheer number of shops where the IT people didn't
have _any_ programming skills and the programmers had never become competent
with CLIs! In many shops, IT folks knew some recipes in the Windows Server
GUIs and the devs knew how to use one IDE. When I first encountered a shop
like that, I suddenly realized devops isn't hot air, even if for me the core
tenets are just a description of how you should _obviously_ do thins and how
they've always been done...

~~~
dasil003
And what do you think about the current trend wherein 60% of people who use
the term DevOps do not understand any of what you said and just use it as the
new word for System Administration?

------
peacetreefrog
One way: find a way to turn your sentiment (whatever it is, honestly a little
unclear to me) into a testable, observable prediction, and bet on it.

Economist Bryan Caplan has done a lot of this over the years, and -- although
he has a lot of non-mainstream views -- I think this habit means he's taken
seriously even by people who don't agree with him.

[http://www.econlib.org/archives/2012/05/the_bettors_oat.html](http://www.econlib.org/archives/2012/05/the_bettors_oat.html)

~~~
SI_Rob
This is almost an unofficial motto of the "prediction markets" trend, which
I've heard rather elegantly compacted into the form "make cheap talk
expensive"

It runs into a lot of practical problems with standardizing terms, metrics,
and especially with actual money on the line, the difficult task of formally
eliminating (or even just exposing) the moral hazard minefield that surrounds
a mechanism which is doomed to incentivize calculated deception above all
other rewards, truth included.

------
thermodynthrway
Wait until you're in a position to challenge them. Aka a big boss or own your
own gig.

I've tried challenging some of the crazier cargo cults over the years and it's
always just made me look like an idiot. If you're going against the "experts"
it generally makes you look bad unless people see you as someone with the same
level of expertise.

I usually try to temper the excitement by appearing conservative and cautious
about trends I don't like. Saying things like "Maybe we could do that if X app
wasn't full of legacy Y". Disagree with implementing the idea but without
attacking the merit of the thing itself.

This may seem like "beating around the bush" or whatever and it is. It's good
old politics. Don't attack a popular idea directly, nip at the corners where
the "good idea" intercepts reality. Try to let others make the decision that
this good idea might not be so great in our situation themselves.

Most of the time, this approach will fail. But the odds are better than
debating a popular opinion at work or on HN where you will lose 99% of the
time.

Even when this approach fails, people are much more likely to agree with your
critique if the idea does fail. "I thought this was great but maybe engineer X
was on to something when he said Y could be an issue"

~~~
mmt
> "I thought this was great but maybe engineer X was on to something when he
> said Y could be an issue"

...said no trend-follower, ever.

Less flippantly, I do believe this might have been the case when the average
tenure of engineers was much longer than today's 2ish years, but too often, by
the time the idea does fail, enough people (even engineer X) are likely to be
at different companies.

~~~
thermodynthrway
Very true. Although I have had people come back and say I was right. Not the
trend follower, but those that blindly trusted them (usually most of the
engineering team)

------
nradov
Apply the Socratic method. Instead of telling people that they're wrong for
{reasons}, ask them to provide hard data to justify their proposals with hard
data and references to peer-reviewed articles. Often they have no basis and
are just parroting something they read somewhere.

But at the same time be humble and remain open to trying different approaches.
Sometimes things that look stupid end up working well. IT is so complex that
our intuitions can't be trusted.

------
AnimalMuppet
> There are many popular trends that I believe are not suitable for every
> situation

Almost _nothing_ is suitable for every situation. Anyone who is pushing
something as The One Right Way(TM) is almost certainly wrong. Worse, they are
usually either a true believer (zealous but without knowledge of the
limitations), or are selling something.

I don't know how to (successfully) challenge stuff like this without some
grownups in the room. If you have some genuine technical people who have been
around for 20 years, they'll look at cloud computing as just another
technology (with pluses and minuses), rather than as this magic new thing that
changes everything. If you have such people, you can have a rational
discussion with them. Hopefully they're the ones in charge; if not, you can
form a vocal group with them to get your concerns heard.

If you _don 't_ have some grownups... you're going to have to expose the flaws
yourself, in a way that others will believe. My best suggestion is find others
who adopted such approaches in the past, and recommend that the relevant
decision-makers talk to them before jumping in with both feet.

~~~
amanzi
Thanks. Similar points have been raised by other responses - make sure the
recommendations/criticisms are well researched.

------
im_down_w_otp
Be thorough.

Show you understand the use case, the perceived use case, the idealized use
case, and the technology. Then make your indictments.

~~~
amanzi
Thanks, this is a common theme in the responses.

------
keithnz
Workplace culture makes a big difference, if your environment is very
adaptable then the following advice is applicable I think. If your workplace
culture is more rigid and things get locked in place by "policy, then first
thing to advocate for is developing more fluid workplace culture where you can
try and intelligently adapt your ways of working at a pace that makes sense.

1\. Credibility. Be known for being open to ideas and wanting to try new
things and get better at your craft. You want to make sure your concerns are
in the context of trying to get the best outcome.

2\. Be Informed. Dig deep, for most of those things you mentioned, there are
people with deep insights about the topic and know the pros and cons

3\. Try stuff out anyways. I've learnt a lot from trying things I'm a bit
skeptical about. Sometimes I've been justified in my concerns, sometimes not.

~~~
amanzi
Thanks for the response. The credibility angle is something I hadn't closely
thought about and is very important.

------
ssivark
The problem is that "luddite" is an _ad hominem_ insult, that does nothing to
lay the foundation for a constructive discussion. Typically, such name-calling
occurs either when the responder is lazy (and does not wish to go into
details) or not sufficiently thoughtful (Read PG, on the Blub paradox).
Particularly, when the insult is lobbed in a dismissive tone, it might be
meant to reinforce their esteem by asserting their group identity -- this
tactic is often deployed by someone playing zero-sum status games (possibly
subconsciously).

A simple inquiry requesting clarification/elaboration will help you resolve
the situation into the following categories:

1\. Person has thoughtful counterpoints. 2\. Person has simplistic and
superficial counterpoints. 3\. Person is not interested in improving
their/your understanding.

After that, you can choose to indulge depending on your emotional stamina and
the importance of the topic/situation/person i.e. "pick your battles" as
mentioned in another comment.

Your best chance of having a meaningful discussion is when sticking to matters
of substance rather than knee-jerk ad hominem based on pattern matching. If
that's happening, you have nothing to worry about. The best case is often when
the other person has thoughtful points that make you reconsider your position
or evolve to a hybrid perspective :-)

~~~
amanzi
Thanks - not being lazy with the criticism is key. Also, I hadn't heard of the
Blub paradox - will look that up.

------
lucas_membrane
Congratulations for wanting to challenge trends. This is a great way to
develop mental and observational skills and perspectives in a way that can
slow down the inevitable decline of everything.

First is to be able to take things apart. Things are complicated. Be able to
see trends as a combination of factors and to see the results of trends as a
set of somewhat distinct consequences, each of which may be both benign in
some aspects and adverse in others.

Once you have a good breakdown of a trend's inputs and outputs, identify which
outputs people might reasonably be expected to want to keep, which outputs
almost any reasonable person would reject, and which are ambiguous or
controversial. Then consider the inputs, which should never exist, which are
too precious to expend for the results obtained, and which are
uncontroversial.

Now design your challenge. If you are ambitious and do not mind losing,
identify a single output as unacceptable and say that the whole trend is
unacceptable, all the trenders are fools, and that they must all get along
without whatever benefits the trend brings them. Your alternative is to apply
a pragmatic engineering mindset, recognize the reasonable wants of reasonable
people, and propose ways to retain or increase the worthwhile outputs and
abate as many negatives as you can.

~~~
amanzi
Thanks, that's an interesting approach. I'm a fan of pragmatism... :-)

------
johngalt
Technology fads are often about momentum. [Thing X] is created and suddenly it
is supposed to solve all problems. Or it unlocks a new way of operating that
suddenly everyone is jumping into.

Focus on learning the scope of [Thing X]. What problems does it solve? What
problems does it create? Try to form a mental map where [X] would be clearly
necessary, and areas where [X] would be a total disaster. Very few trends are
objectively bad, but they are often overapplied. Be aware that there are
'professionals' who simply want to put [X] experience on their resume, and
don't really care if it fits the project.

If you believe that [X] is a bad choice, you shouldn't directly criticize [X],
but rather you should state your case affirmatively for alternatives.

Bad: "Cloud computing costs too much and doesn't work well. I get the shakes
if I can't touch my server! Harrumph!"

Good: "Cloud is a good option when our needs are flexible but low on average.
Right now we have high baseline utilization and we don't need the whole AWS
ecosystem yet. Let's see how far we can get with a few VPSs before we add the
AWS layer on top of it."

~~~
amanzi
Agree with all that, thanks. Focusing on what problems [X] is trying to solve
and looking at alternatives is a common theme in the responses here.

------
endorphone
Why do you have to challenge trends? At a workplace? Online? Why? What's the
point?

"I believe are not suitable for every situation"

This is a strawman, of course, and it might betray that you aren't being
entirely honest about your motives.

~~~
amanzi
It's in the workplace. I have opportunities to both challenge and recommend
new trends and so I'm just looking for advice on how to best approach
challenging trends that appear to be popular to the point where you are
considered a luddite if you dare to challenge them.

------
goodside
Argue each issue on its individual merits. Don’t dismiss others as Luddites or
neophiles, and don’t worry about people who do.

Nobody thinks you’re a Luddite because you don’t like DevOps. Nobody cares
that much.

~~~
amanzi
Ha - thanks. Perhaps I worry too much...

------
d0m
imho focus more on the problem rather than the trend.

I'd say something like: We have such and such problem and I have looked into
various standard and well-known solutions. Unfortunately, those solutions
don't solve our problem because X. Good news is I found this new technology
that _could_ help. Is it worth giving it a try?

And, to be fair, if you have one solution that is standard, well-known and
solve your problem, I'd stick to it instead of chasing trendy things.

~~~
amanzi
Thanks, good points. Looking at what problems the trend is trying to solve is
a good start.

------
FundThrowaway
"There are many popular trends that I believe are not suitable for every
situation"

Doesn't that statement apply to pretty much everything? Horses for courses and
all that.

------
mgkimsal
Haven't considered "open plan offices" a "trend", or certainly not a recent
one. They've been a staple of most places I've seen over the past 25 years of
professional tech/dev work. Apparently they're suitable for every situation
except management/executive seating. When they want to work together, they'll
hit the golf club or go out for long lunches. ;)

~~~
irrational
My company started adopting open office plans a few years ago. Now they are
moving beyond that to what they call freestyle office plans. Each department
is allocated enough desks for 70% of their workers. You come in in the morning
and, like an open-range animal, wander around until you find a free desk. If
you need to go to a meeting you take all of your stuff with you so someone
else can claim that desk. This is for a campus of 5000+ employees scattered
across dozens of buildings. I can't wait to see what the next trend in office
plans will be. Maybe gladiator style combat to see who wins the right to use a
desk.

~~~
dragonwriter
Interestingly, the thing you point two isn't new: what you describe, also
called “hot desking” (and the similar “hoteling”, which adopts reservations
for desks but is otherwise similar) were trends that came to attention—and
after it's popularity peaked was widely mocked—in the 1990s.

~~~
irrational
Well, apparently it's making a comeback. Unfortunately.

------
p0d
I have a great shed in my garden which folk online would say I built wrong. I
have a ten year old Saas product some developers would tell me I did wrong.

Do what you want, how you want, when you can. Doing beats talking.

~~~
mmt
Unfortunately, this tends to contradict the notion that "programming is a
social activity".

There are, of course, many situations where that notion does not or need not
apply, but I would expect it does to the vast majority of the HN audience
during at least some point in their career.

More importantly, the OP's question makes the social nature of the context
pretty clear, IMO.

That said, much of the advice in the thread is to accompany criticism with an
alternative solution, and I agree that having a _working_ solution (even proof
of concept) beats a proposal/theory any day.

------
zebraflask
Challenging any of these things does not make one a Luddite.

Consider the unspoken assumption in your question that these things are
cutting edge when they're par for the course these days.

------
dbwest
Come up with an alternative solution. Promote it. Watch it trend and devolve
from a real solution to a cargo cult. Repeat.

------
olalonde
Have you considered that you might be one? "not suitable for every situation"
is a platitude.

~~~
amanzi
In general I don't think I'm one, but introspection is important. thanks.

------
ianamartin
Every blogger outside the company will carry more weight and expertise than
you do, unless you are the CTO. And very possibly even then if your CTO is
more of a business CTO than a T CTO.

The bottom line is that there are always going to be problems that are hard to
solve, and newer generation just coming face-to-face with them for the first
time. Some of the lessons they will learn through fads will be the same
lessons you already learned. Some of the lessons with have a slightly better
approach, or the fact that resources are generally cheaper means that cool
things that were a pipe dream when we were struggling with these things are
now a reality.

For example, I still can't take docker seriously. It doesn't take security
seriously, and doesn't have good answers for some pretty common deployment
scenarios. I also sort of hate the way it gets used as function containers, or
generally "lambda"/serverless stacks. That still seems utterly crazy to me,
and the wasted overhead is completely insane.

On the other hand, Vagrant is goddam amazing. Having a perfectly defined dev
environment literally a click away is genius. And it works. And it's for dev,
so a lot of my nitpicks go away.

Both of these things could be described as aspects of DevOps. The core
problems are things we had to deal with when we were green, and we came up
with other things because resources were just differently constrained than
they are now.

I'd still argue against docker for deployments--right now-- even though I
think that some level of containerization will be a trend that ultimately
wins.

The reality is that these trends move in predictable cycles. Some new-ish
people find a problem that is absolutely gross, and they set to work doing
what they are doing: building a solution. Often they are too enthusiastic and
miss some of the wisdom of experience, but so what. It's what we do. And we
all did it when we were starting out.

The idea gets some traction because it's new and fresh and exciting and it
trades this really gross ugly thing for some other really gross ugly things
down the road that they haven't really run into just yet, so it all seems much
better at the moment, so everyone jump all in. First in the startup crowd, and
several years behind, your bread and butter in-house shops start to hear about
some of these trends and figure they've been around long enough, so maybe give
them a try.

So your team tries them out. Or goes whole hog. Whatever. Do your research;
understand what the pitfalls are; make suggestions to mitigate some of them.
You'll find this is hard to do if you haven't really tried them out. So do it.
Use the trendy shit and learn them inside out. Make your arguments from
experience working with them, not a theoretical point of failure or a medium
post about some company that tried X trendy thing and it failed miserably so
they went back to the old way.

The end goal here isn't to keep things the way they are. The trendy shit will
fall over at some point. The goal is for the status quo to land in an overall
better place. To take some of the good parts of the new stuff, mix it in with
the old stuff and gradually chip away at these same problems we keep running
into over and over: team productivity, communication with stakeholders,
priority, deployments, reliability, testing, timelines, data management . . .
except for those of us lucky enough to work in research labs, these problems
are the hardest ones we deal with at work every day. Most of us are not
advancing the state of the art.

As long as these problems are going to be around, there are going be new and
trendy ways of dealing with them. And most of them have at least some novel
approach that's worth taking a look at.

Sorry for the long post. I guess what I mean is that the best way to not
appear to be a luddite is to actually _not be_ a luddite. Engage with and
master these trends when they come up. Your instinct will be a good guide in
helping you predict where problems will come up. Listen to that, but give them
an honest chance at the situations they are designed to solve.

Doing this has a number of good side effects: 1\. You will learn something
valuable from a different approach, even if it's almost entirely wrong-headed.
2\. When people start to realize the trends isn't a good fit, you will have a
voice in the conversation about resetting the status quo. People will listen
to you because you took the time to become an expert on the system. You've
been tracking its successes and failures, and you already know where the good
parts are that can be salvaged and added to previous ways. People will trust
you because you approached the situation with intellectual honesty, technical
curiosity, and aim to improve the overall health of the organization. 3\. Your
resume will look smashing good the next time you go shopping without having to
read 20 "getting started with X" articles so you can put a couple dozen
buzzword trendy technologies on your resume under the <1 year of experience
category of your skills list to get through recruiting filters.

~~~
amanzi
Thanks for the great response. Lots of good points to think about.

------
jrockway
Like others say, pick your battles. The key to being productive is knowing
what decisions you have to make, and what decisions you can delegate. The
thing with delegation is, it's not micro-management. The people you delegate
to are not going to do things exactly as you would. If you can't accept that,
don't delegate, and suffer the productivity loss.

For example, say you're a software engineer that really wants to run your own
servers, but don't personally want to maintain that infrastructure, and the
person/team you delegate to wants to run everything in the cloud. You don't
need to step in and say "that's terrible, I hate you, do it my way." What you
need to do is make sure your needs are taken care of by the team with the
responsibility for building and maintaining the production environment; you
need to be able to connect the special FPGA you developed, you need to be able
to deploy a release within 30 seconds of checking the code in, etc. If they
take care of your needs, you shouldn't care how it's implemented.

On the other hand, you can be in a position of power and decide "the person
I've delegated to has done it completely wrong, and we will be out of business
in 30 days if they continue." In that case, you just shut it down with no
reason. The team that you did that to is not going to be pleased; half of them
will leave your company, the other half will be sad and do nothing for 12
months... but that's the cost of micromanagement.

As for open offices, they're cheap. If you don't like them, the way you talk
someone out of them is to suggest a cheaper alternative. Good luck. Your other
option is to accept less salary -- that $5000 a year they gave you to outbid
their competitor came directly out of the budget for walls around your desk.
As engineers, we certainly want to be productive, but ultimately the benefit
is not tangible enough. It's quite likely that we would use all the extra
productivity to make a once-a-month process 3x faster, which provides no
benefit to anyone except our once-a-month selves. The company does not care.
People do _enough_ work in cheap offices to make the company money, and that
is really all they need. You doing more work would probably be great, but
that's a difficult-to-see benefit and the cost of more real estate is an easy-
to-see cost center. Nobody thinks open offices are good for productivity,
morale, or whatever... they're cheap. Any argument against them must be an
easy-to-see monetary argument, or you'll never win the argument. (Compare Joel
Spolsky's company to the king of open offices, Google. Google makes more money
per engineer. Now that's probably because they picked a better industry, but
if giving people their own offices is worth the huge financial hit... they
should be doing better than someone. But they're not, they're the same. That's
why the "better productivity" argument is not going to get you a private
office.)

You can always start your own company predicated on giving every employee a
giant office. If you do well, I'll join you! But I do require a salary
increase as well ;)

~~~
mmt
> if giving people their own offices is worth the huge financial hit...

I would think it's only a _huge_ financial hit in places like NYC and maybe
the most expensive parts of SF. Elsewhere, even class A real estate isn't that
expensive. You yourself quoted about $5k annually per employee above. While
not peanuts, compared to salary or even benefits and perks, "huge" seems like
an exaggeration.

> they should be doing better than someone. But they're not, they're the same

Do we know that to be true, though, for a private company? The same as whom,
Atlassian?

~~~
jrockway
I mean, I made that number up. What I'm saying is, if you always pick the
offer that provides the highest salary, you will get that salary at the
expense of all else.

~~~
mmt
> I made that number up

Perhaps it would have been better not to specify, then, as it was a source of
confusion in contrast to "huge". However, $5k a year is roughly $400/mo, which
would pay for a 10x10 office at $4/sqft, which doesn't strike me as
outlandish.

> if you always pick the offer that provides the highest salary, you will get
> that salary at the expense of all else

Firstly, that's a big "if". It assumes there are always/frequently multiple
competing offers. I have found, alternatively, at least among more senior
engineers, that the offer stage is only reached after first evaluating other
factors (such as suitability of working environment).

Secondly, salary offers are, especially in the cases of multiple competing
ones, are rarely final, as evidenced by many discussions and advice regarding
salary negotiation tactics.

Thirdly, "at the expense of all else" is demonstrably false, as there are
numerous examples (Google, whom you mentioned, being not the least) of
companies who provide remarkably generous benefits and perks, in _addition_ to
high salaries, while not providing private offices.

The idea that the _sole_ motivation is cost is, therefore, unpersuasive.

------
jstewartmobile
Do the opposite and win. Everyone is just chasing performance. Arguments and
"reasoning" are impotent and after-the-fact.

