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.
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.
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.
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.
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.
Something I heard at my corporate job: "Bring solutions, not complaints." It's a great rule of thumb to follow.
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.
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.
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.
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.
> “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.
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.
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.
Also. Kind of going to back the complaint being reasonable side of things. In Quality Management, it is more important that the signal is raised, recorded, and put in a pipeline to be dealt with, than to encourage only raising the signal when a possible solution is in hand.
On the other hand, yes, in general, when expressing cross-departmental complaints, come with a suggestion or offer of help to solve the problem in hand. If nothing else, it builds bridges, goodwill, and shows you care about making their lives, not just your own, better.
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.
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.
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.
> "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."
Even in that case, at least in the US, one must do the equivalent of bringing the solution. Lawsuits have to ask for some kind of relief, be it monetary, injuctive, or both [1]. They can't merely be a complaint that open-endedly asks the court to decide the solution.
The exception is for criminal cases, and those are brought by the government, not individuals.
> But you should never
"Never" is an extremely high standard, superlative, even, which makes it difficult to agree with.
> make someone feel like their complaint doesn’t deserve to be heard unless they also have a ready made solution in hand too.
This strikes me as a strawman, because the discussion isn't really about people's feelings, whether they deserve to be heard, nor if a particular solution is ready made (as opposed to merely a proposed, initial version).
Remember, the OP is asking about how best to challenge trends. In that context, the advice is to provide an alternative solution, in addition to criticisms of that trend.
Since that advice is based on the giver's personal experience with the relative receptivity to such challenges, at least in a particular company, that makes it valid advice.
You may well feel that it is somehow morally or ethically wrong for the people in that company to have been less receptive to a challenge in the absence of an alternate solution, but they still were. Such a moral position doesn't invalidate the advice.
[1] Also declarative relief, but that's rarely in response to something that can easily be likened to a complaint, as we're discussing in this context.
I’m only trying to talk about how we perceive people bringing complaints. I think you misunderstood and it’s my fault for choosing a needlessly complicated example to include.
I’m saying it should not matter whether a complaint is big, small, formal, or informal (that’s why I listed a range of possible situations when someone might have to bring a complaint). Across all those cases, the social norm of treating the person as if their complaint deserves to be considered should not be predicated on whether they offer a solution at the same time. (Which is different than any legal requirement or other non-norm aspect.)
In other words, your point about asking for specific types of relief in a legal complaint is not addressing whether people believe the party bringing the complaint is just being a whiner or something, which is all I ever wrote about.
Granted though, maybe I should have chosen a non-legal example, like complaining to a referee in a sports competition, to get the point across about the variety of situations without dragging in possible confusion over red herring legal specifics. Or maybe an example with an arbiter determining the relief, if any, in an employment dispute or something.
> “Remember, the OP is asking about how best to challenge trends.”
I was never responding to the OP, only the parent comment above mine that talked about using a rule of thumb of not bringing complaints, only solutions, and specifically mentioned it was heard in a corporate context. That combination of details seems appropriate for counterpoints that if a corporate environment codifies a culture that dissuades complaints by pressuring people to first have solutions in hand, it’s a very bad thing that will hurt marginalized people (and in a corporate setting that might even be the intended effect). Whether a local rule of thumb making the shy person feel unwelcome to point out a deficiency in some work artifact during a team meeting, or making someone feel they can’t talk about rude behavior of their desk neighbor because they don’t have a seating change proposal or they really like their seat already. The situations where people need to feel free to complain without proposing a solution are constant, pervasive, all around us, and often involve people we don’t consider or see because of biases or other blind spots.
> “Such a moral position doesn't invalidate the advice.”
I believe that is actually does explicitly invalidate the advice.
Obviously, others are free to agree or disagree with the moral point of view behind my comment (e.g. that policies which might discourage suffering people from expressing their suffering are wrong), and then choose for themselves which part of the advice they prefer. That’s why we’re discussing it in comments.
But that doesn’t invalidate my original disagreement of the parent comment, nor have any affect on the usefulness of me writing up counterpoint comments that express dissent to that proposed rule of thumb.
You feel the original advice, in essence, serves to perpetuate the immoral, current standard of behavior and is, therefore, invalid.
(Whereas I, on the other hand, am saying that the advice narrowly serves the OP's immediate, pragmatic interests and is, therefore, valid.)
Is that a fair distillation?
The comment is not written that way at all and it's not implied from context, especially because the comment talks about it as advice heard in a corporate setting, which begs the interpretation of a generic corporate policy or something "team players" will do, etc.
It is specifically because the parent comment was written that way (a generic heuristic for corporate settings) that I felt it was useful to offer a disagreeing perspective and highlight that it could be quite harmful to encourage adopting such a thing as a generic "corporate setting" rule of thumb.
In that case, as I said, I see your point, and I think we merely disagree on fundamentals, which is fine.
> If the parent comment that I disagreed with had come with huge disclaimers that it was only intended as a technique to be applied precisely in the OP's use case
At the risk of breaking the HN taboo of bringing up voting as well as potentially sparking another meta-discussion, I'll say this:
The consistent downvoting combined with the lengthy sub-thread with the OC insisting, in essence, that the context was sufficient to convey intent (and subsequently confirming original intent), in the absence of disclaimers, suggests that your position here may be tending toward the unreasonable.
This isn't to say that you're categorically wrong and that nobody else could possibly intepret it differently, just that it might be beyond a "reasonable person" standard of interpretation. Personally, I prefer being required to exert extra effort to gain context, so as to have writing be more succinct and free of disclaimers.
Perhaps most importantly, though, your belaboring of this point had, at least for me, distracted from your main thesis. It probably still does for some readers, and I find that unfortunate for HN, as diversity of thought is something that I believe helps us all.
I'll have to disagree strongly on that one. Hacker News is a place where the voting is extremely tribalistic. People downvote what they don't like, regardless of its merits or worthwhileness. Hacker News exhibits this just as much as any online community I've ever seen, and it's pure bias that so many of us believe we're exempt and use votes efficiently. Voting on HN is very often about popularity or trying to downvote what you don't like, rather than reserving downvotes for types of discourse that truly fall outside the guidelines or scope.
> "Perhaps most importantly, though, your belaboring of this point had, at least for me, distracted from your main thesis."
I agree, and felt saddened that I was pushed into a corner where I felt it was clearly necessary to belabor it.
> "as diversity of thought is something that I believe helps us all."
Yes indeed, but there truly are many topics for which HN is just another echo chamber and downvotes are just expressions of loyalty to ideological sides of an issue.
Well, yes and no. I certainly agree with your point about tribalism and being like other online communities, but I don't agree with the "just as much" part, at least not within the bounds of certain topics or sub-threads. It takes an effort to see just that HN.
My own experience is that my comments receive few votes one way or the other (and very rarely fall negative), but I believe that's because I make a concerted effort to avoid topics where discussion appear to yield nothing but further controversy. I'll even just hit the "[-]" on the whole sub-thread after reading a few levels and detecting the pattern.
I also self-censor (and let go of things and not take bait). Frequently. How much of a loss this is, to others, is unknown, but I do know I ultimately feel worse when I am the character in the xkcd cartoon who won't leave the computer because "someone is wrong on the Internet".
> rather than reserving downvotes for types of discourse that truly fall outside the guidelines or scope.
I'd say that this reservation (certainly the more severe guidelines violations) is appropriate for flagging, not (just) downvoting.
> I was pushed into a corner where I felt it was clearly necessary to belabor it.
To hang on to one shred of on-topic material :) ...
Considering there was only one other participant in the long chain, that's a strange characterization. More importantly, though, in light of your subsequent remarks regarding guidelines, you may want to take a hard look at whether your initial response, that sparked it all, fully complied with their spirit.
In particular, the one that ends "Assume good faith" (suggesting disclaimers are unneeded), and the one regarding ideology (which I know does not specifically what happened here, but there may be echoes).
Just something to think about in the whole pragmatism vs. morality in advice tension.
> People downvote what they don't like, regardless of its merits or worthwhileness.
I'll personally tend to downvote comments that bring ideology into what had previously been a practical discussion, since, as you may have guessed from my original distillation of our positions, I'm a pragmatist. Of course, this is also idealogical (a position on worthwhileness).
All that said, I recognize your username (which means you comment on topics of interest to me) and generally find myself upvoting your comments.
Our experiences just seem to differ on this. When I’m reading other comments or threads on HN, I see it all the time, in many threads per day, spanning a huge range of topics.
> “but I do know I ultimately feel worse when I am the character in the xkcd cartoon who won't leave the computer because "someone is wrong on the Internet".”
For me, I think that the criticism of that XKCD comic is very shallow when people use it to denigrate someone who just happens to be interested in disagreement and the resolution of it. In an Aumann’s Agreement Theorem sense, as you become closer to the approximation of a rational agent, you might expect to stick it out even in minor disagreements more and more, realizing that “agree to disagree” should be saved for an escape valve when the conversation turns uncivil... but that prior to that, extended disagreement is actually a good thing.
It’s lazy and sloppy IMO to use the line “someone is wrong on the internet” as a glib criticism towards somebody that actually cares about sticking out a disagreement with civil conversation.
In that sense, because I take great pains to be civil even if I am attacked during a disagreement, I would never feel like I am a model of that XKCD cartoon, and in fact would find it thoughtless and lazy if someone else projected that onto me or anyone who is intellectually sincere about enjoying disagreement discussions online.
> “I'd say that this reservation (certainly the more severe guidelines violations) is appropriate for flagging, not (just) downvoting.”
I disagree but I doubt we can find a specific resolution in the guidelines. I view flagging as being reserved for comments that are uncivil, bullying or harmful, and never ever for anything else. Moderation does a good enough job that flagging for off-topic is generally unnecessary and usually is revealed quickly in comments anyway.
When a comment is expressing a disagreeable attitude, it would rarely be good to downvote it. Downvoting is more to downweight purely political comments, comments that are obviously just self-promotional or intended to influence readers towards a certain product, inappropriate jokes or non sequiturs that would distract, and sometimes uncivil comments (though flagging is better).
I don’t actually mind that much that people on HN use votes to push agendas about what to talk about. I just think HN users vote for popularity or downvote what they don’t like just as much as anywhere else. They don’t take any type of “more enlightened” stance on it than other communities. This isn’t a judgmental comment, just an observation.
> “Considering there was only one other participant in the long chain, that's a strange characterization.“
Why is it strange? What does the number of participants have to do with it?
> “In particular, the one that ends "Assume good faith" (suggesting disclaimers are unneeded)”
It says to assume the strongest plausible interpretation, which I believe that I did, even after going back and re-reading the parent comments. Sometimes somebody unambiguously says X, you respond disagreeing with X, and then they backtrack and claim they really meant Y. That’s not what the guidelines are talking about. They are talking about that first interpretation of X and being charitable. I absolutely think I met that criteria based on the original comment.
> “I'll personally tend to downvote comments that bring ideology into what had previously been a practical discussion”
This is a slippery slope though, because from my point of view my whole line of discussion is meant to be totally about pragmatism. The original advice of cultivating a general culture where complaints are discouraged if they don’t come with proposed solutions is not pragmatic advice, because of the danger that such a policy institutionalizes procedure for continuing to harm or marginalize certain groups. This could take the form of making a team member feel his or her voice is not heard in simple team meetings, or could take the form of discouraging harassment claims, and many things in between.
Just because a discussion might take into account some dimension of a desired moral outcome, that does not mean it “brings ideology into it” any more so than how practically any claim of any type ultimately relies on some type of ideology about economic assumptions, utilitarianism, rationality, reductionism, moral philosophy, population ethics, sovereignty, etc. etc.
Applying a “don’t bring ideology into this” criticism to my comments here seems totally unfair, as if to bend that part of the guideline to pick and choose disagreements you merely don’t happen to like, and use the guideline to argue it’s ok to downvote or flag them. You could practically argue that anything beyond the most ultraspecific comments can be said to bring some type of ideology into it, if you wanted. But clearly the guideline is about cases when comments try to steer the discussion into territory that’s only about the ideological debate.
I do suspect you're conflating pragmatism with principle, whereas they're often considered to be at odds. Perhaps, consider, instead, "expediency" as a synonym for pragmatism in this context.
For better or for worse, the advice sought here not likely to have been the kind involving a substantial moral (or idealogical or principled or fairness what have you) component nor strenuous repetition thereof.
> Applying a “don’t bring ideology into this” criticism to my comments here seems totally unfair
It was merely a gentle suggestion for self-examination through a particular critical lens, given the, apparently strong, negative reaction from the community. Clearly, that backfired, and I apologize.
I was hoping I could help reveal maybe a slightly different angle of looking at the whole thing, but I realize that's difficult when one feels particularly strongly. (Nobody else is likely ever to see these writings given the age of the post and depth of the subthread anyway).
It’s an unequivocally civil thread of discussion about a valid interpretation of the parent comment.
To flag and hide this subtree of comments seems like unquestionable misuse of the flagging system for HN. Particularly for this first comment above.
I believe the encouraged best practice is to e-mail hn@ycombinator.com to call the situation to the attention of the moderators. Even if they don't completely agree with your position, I suspect they will at least have a user or two's suspicious flagging behavior to keep under observation and/or revoke.
In both contexts, I would guess the key is recognizing that a trend exists because it answers a wide array of needs - many if not most of which have more to do with the geometries that govern the crystallization of social influence into familiar structures regardless of which novelty happened to seed them.
It's fantastic if they give you time to explore solutions, more often than not it can be translated to "work out a solution without pay on your own time and we'll consider adopting it". And even then the solution has to be obviously better and they have to be able to acknowledge the problem in the first place instead of saying "we've always done it that way".
"Bring solutions not complaints" is just corporate BS for "stop complaining".
No, not in this case.
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.
Typically, this is only an issue at startups, where "nobody ever got fired for buying IBM" doesn't apply, especially if one extends "fired" to include losing a job due to the company ceasing to exist.
Currently, there seems to be a general exception to expense-blame when it comes to cloud, at least partly provided by VCs (who sit on boards).
People like Elon Musk don't do that. When he needs a factory, he hires architects and builds the factory himself.
That was the gist. IIRC, the essence of the argument was that, because running hardware in a colo isn't the startup's core competency, it's best to outsource it.
The push to outsource (especially by VCs and other outsiders and/or "business" interests) is hardly new, nor is it new to do so while ignoring potential future costs or even ignoring how closely intertwined to the core competency something actually is (witness the tech offshoring fad in the US).
What's particularly interesting to me is that cloud outsourcing not only has such huge potential future costs but can start costing right away. Hardware has up-front purchase costs, but those can often be smoothed out with a lease, if cash flow is that much of a concern.
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.
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.
There is a tool to build around that.
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.
I sent you a mail yesterday. Maybe it went to the spam folder.
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)
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.
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.
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,
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.
Moreover, sometimes challenging the trend is so costly that you are better off going with the "wrong" solution than fighting it. In general it's a tricky one, and I'm sure there isn't a single correct answer to it.
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...
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
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.
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"
...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.
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.
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.
Show you understand the use case, the perceived use case, the idealized use case, and the technology. Then make your indictments.
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.
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 :-)
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.
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."
"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.
Nobody thinks you’re a Luddite because you don’t like DevOps. Nobody cares that much.
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.
Doesn't that statement apply to pretty much everything? Horses for courses and all that.
Do what you want, how you want, when you can. Doing beats talking.
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.
Consider the unspoken assumption in your question that these things are cutting edge when they're par for the course these days.
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.
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 ;)
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?
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.