Why Don't You Use(brendangregg.com)
brendangregg.com
Why Don't You Use
https://www.brendangregg.com/blog/2022-03-19/why-dont-you-use.html
142 comments
I'm surprised at the ire around this question. "Why don't you do X" is a great way to understand why someone did Y. A perfectly valid answer might be "X might be better, but Y is fine and it's not the highest priority at the moment." Or the answer might be any of the dozens Brendan Gregg gave (including "for reasons I can't disclose."). Any of these answers might be illuminating to the asker.
Now, admittedly, it's very tone dependent. "Why don't you X" can be asked humbly and with a truly inquisitive tone, or with a sneering tone whose obvious implication is that you must be either ignorant of X or too dumb to see its merits. But in writing, at least, I try to infer the more charitable attitude of genuine curiosity.
Now, admittedly, it's very tone dependent. "Why don't you X" can be asked humbly and with a truly inquisitive tone, or with a sneering tone whose obvious implication is that you must be either ignorant of X or too dumb to see its merits. But in writing, at least, I try to infer the more charitable attitude of genuine curiosity.
This is why I try to never ask "why don't you do X" without making it clear that I'm using it as a forcing function to satisfy my own curiosity, rather than trying to sneer at folks. Often this requires being a bit more verbose, but I've personally always found a bare "why don't you do X?" without any other context to come across as sneering.
But yes, I also try to interpret it charitably as well too. I just also try to make my own curiosity clear on the flip side.
But yes, I also try to interpret it charitably as well too. I just also try to make my own curiosity clear on the flip side.
I've known a couple people who characterize others as getting upset for no reason/escalating a situation and I wonder if they were participating in the same conversation I was witnessing? Like seriously, you started it. Plenty of reason to be had.
There's a whole thing called nonviolent communication and the basic premise is that if you spin someone up by choosing your words poorly, that's as much on you as it is on them.
There's a whole thing called nonviolent communication and the basic premise is that if you spin someone up by choosing your words poorly, that's as much on you as it is on them.
NVC is important, but I like to view it as "reducing the likelihood of inspiring defensiveness". It's definitely a two way street, and the skillfulness with which I communicate is definitely on me, and affects a dynamic.
That said, sometimes even the most skilled communicator might find themselves spining someone up despite their best efforts. At the end of the day all we have is self awareness and good intent, but if the other person is hell bent on being oppositional, that's gonna be very hard to navigate.
That said, sometimes even the most skilled communicator might find themselves spining someone up despite their best efforts. At the end of the day all we have is self awareness and good intent, but if the other person is hell bent on being oppositional, that's gonna be very hard to navigate.
Yeah, that's fair - I try to do the same. I've yet to find a particularly elegant way of asking it - it's usually something like "Why didn't you do X here? To be clear, I assume there was a good reason, I'm just curious what it was!"
In addition to being tone sensitive it is also very dependent on who's asking. If that person is, and that is something I hate, obviously less qualified in whatever field is concerned asks in an inquisitive tone (especially when having more hierarchical power), it's a sure way to knock any respect I had for those down a notch or two (or multiple, depending on circumstances, including my mood).
That being said, I love being challenged. Also by people new or un experienced in my field. Because it's an opportunity to learn. Either because I missed something (naive questions are really great for that), because I have to voice my thoughts and explain my thought process (and discover flaws in it), because the person asking is way better in what ever we are talking about,... you name it. Being challenged just because definitely isn't part of that.
That being said, I love being challenged. Also by people new or un experienced in my field. Because it's an opportunity to learn. Either because I missed something (naive questions are really great for that), because I have to voice my thoughts and explain my thought process (and discover flaws in it), because the person asking is way better in what ever we are talking about,... you name it. Being challenged just because definitely isn't part of that.
You hate when someone with more power than you uses an inquisitive tone?
What tone do you want?
What tone do you want?
Depends on one's connotations of the word "inquisitive." You may be associating to "general inquiry", while the GP is thinking more "the Spanish Inquisition".
[deleted]
Some general politeness and respect? Apparently too much to ask these days...
Could you please explain what tone of voice that would be, and why it would not be inquisitive?
I'm extremely confused, and I don't understand your implication that an inquisitive tone won't be respectful or polite.
I'm extremely confused, and I don't understand your implication that an inquisitive tone won't be respectful or polite.
The comment above mine sums it up pretty well, IMHO. There's general curiosity, a justified demand for an update and the inquisitive version indirectly implying whatever you do might be wrong. The latter, from someone with more authority, is putting you in a defensive position from the get go. It is passive aggressive. And it is borderline hubris from someone with no qualification in the subject matter at question. I especially hate the last version of it, if you don't trust me to do my job properly, why hire me in the first place? Plus, it creates a toxic culture where everyone has to justify every single one of his decisions all the time.
Well I understand now and I think your preference is entirely reasonable but I would suggest different wording in the future. The normal definition for "inquisitive" doesn't imply those things, just curiosity. Asking at all would generally be inquisitive. "inquisition-like", maybe? Or some other word, I don't know what fits best.
(And when it is curiosity, it's less offensive from someone that doesn't know much, which is part of what threw me off so badly.)
(And when it is curiosity, it's less offensive from someone that doesn't know much, which is part of what threw me off so badly.)
[deleted]
The 'why' in the question implies that one knew X was a possible solution, or that you should know that X is a possible solution. An alternate to the question might be 'have you tried to do X?'.
Also, if you want to understand why someone did Y, ask deeper questions around why they did Y, don't ask why they didn't pick the other 500,000 possible solutions.
Also, if you want to understand why someone did Y, ask deeper questions around why they did Y, don't ask why they didn't pick the other 500,000 possible solutions.
I very often find that my mind jumps to X as a solution. Then when X wasn't picked two things happen.
Firstly, and sadly, I get a bit mentally stuck on X. Secondly I assume I have missed something. Whatever I have missed is probably quite important, since otherwise X was a good choice.
Both of these effects mean that I will probably learn a lot from knowing why someone decided not to do X. So, if I've been mulling the question for a while, and can't get an answer, I think it makes perfect sense to ask "why didn't you do X". After all, that is exactly what I am wondering in good faith.
It sucks that the question is often used sarcastically, because to me it's a very useful question for understanding someone else's process.
Firstly, and sadly, I get a bit mentally stuck on X. Secondly I assume I have missed something. Whatever I have missed is probably quite important, since otherwise X was a good choice.
Both of these effects mean that I will probably learn a lot from knowing why someone decided not to do X. So, if I've been mulling the question for a while, and can't get an answer, I think it makes perfect sense to ask "why didn't you do X". After all, that is exactly what I am wondering in good faith.
It sucks that the question is often used sarcastically, because to me it's a very useful question for understanding someone else's process.
Asking why they used what they did has always ended up in good explanations and less than expected defense of the tool/tech itself. Often it's just because it does the job and whoever used it knew it.
Often I've asked it because I privately thought "why didn't they use X?", but I'm seldom actually interested in hearing why they didn't.
Often I've asked it because I privately thought "why didn't they use X?", but I'm seldom actually interested in hearing why they didn't.
[deleted]
It’s true. I built a robot intended to be open sourced and reproduced by others. I wrote the entire stack from scratch in Python. People on the forum asked “why didn’t you use ROS?” which is a perfectly valid question. My answer was that at the time I started the project ROS didn’t support Python 3, ROS is in many ways mostly a system for multi process communication which is something Python already does fine, and I wanted to avoid the learning curve of both learning ROS and learning our system. Also, I wanted to see if I could do it and what it would be like.
But ROS is indeed a popular framework for robotics, so the question is a reasonable one to ask.
But ROS is indeed a popular framework for robotics, so the question is a reasonable one to ask.
If you've say through enough conferences, the ire is because the question usually isn't in good faith. More often than not, it's someone with whatever you call the personality defect that leads them to constantly needing to "show how smart they are" to the room full of people by, presumably in their mind, dunking on the speaker with their wildly naive "what didn't you do X?"
I've also say through Q&A sessions where a guy got up to the microphone to recommend books for the guy giving the presentation to read. It was uncomfortable.
I've also say through Q&A sessions where a guy got up to the microphone to recommend books for the guy giving the presentation to read. It was uncomfortable.
We solved the Q&A issue at our conference by having all attendees (in-person and online) use the same private chat server to funnel questions. We don't allow audience microphones.
> I'm surprised at the ire around this question.
Because even if you exclude the concern trolls who aren't actually interested in your answer, just fighting with you, it is a never-ending stream of people who want to bikeshed your choices devoid of the context that makes it worth even trying to answer.
Life is too short.
Because even if you exclude the concern trolls who aren't actually interested in your answer, just fighting with you, it is a never-ending stream of people who want to bikeshed your choices devoid of the context that makes it worth even trying to answer.
Life is too short.
I think it's much better to instead ask "Have you tried X?" or "Have you heard of X, it might solve your problem or solve it better?", both of which don't imply that the receiver should have known of those solutions.
> "Why don't you do X" is a great way to understand why someone did Y.
As the running joke on the TV series goes "Phrasing". Phrasing is the key difference, especially in a textual medium. As you point out, it's the tone.
I've seen "Why don't you do X" phrased in a variety of ways, and the best phrasing I've found seen was along the lines of "I would normally do X in the scenario you've described, but Y was obviously better for your use case, would you mind sharing why?"
The worst possible phrasing of "Why don't you do X" is "Why would you even consider Y, everyone competent knows X is how you do it".
...and then it turns out that actually, Y was the best way to approach the given use case, X wasn't suitable, and now someone looks like a bit of a dick.
As the running joke on the TV series goes "Phrasing". Phrasing is the key difference, especially in a textual medium. As you point out, it's the tone.
I've seen "Why don't you do X" phrased in a variety of ways, and the best phrasing I've found seen was along the lines of "I would normally do X in the scenario you've described, but Y was obviously better for your use case, would you mind sharing why?"
The worst possible phrasing of "Why don't you do X" is "Why would you even consider Y, everyone competent knows X is how you do it".
...and then it turns out that actually, Y was the best way to approach the given use case, X wasn't suitable, and now someone looks like a bit of a dick.
> I've seen "Why don't you do X" phrased in a variety of ways, and the best phrasing I've found seen was along the lines of "I would normally do X in the scenario you've described, but Y was obviously better for your use case, would you mind sharing why?"
There are multiple assumptions in that question that could make it crash and burn really badly. What if they actually didn't consider X? What if they do think Y is better, and X is interim? What if they had a lazy reason to prefer Y, and interpret the hyping up of the quality of their decision as calling them out?
There are multiple assumptions in that question that could make it crash and burn really badly. What if they actually didn't consider X? What if they do think Y is better, and X is interim? What if they had a lazy reason to prefer Y, and interpret the hyping up of the quality of their decision as calling them out?
Of course they're assumptions. They're assuming that the person doing Y did so in best faith and full knowledge.
As opposed to assuming they're cousin loving inbreds who did Y because they hate every computer scientist ever.
Assuming that doing Y was indeed wrong, and you want to correct that... do you think approaching it with the mindset of "you're a competent person who made the best choice you could see" is going to work better or worse than approaching out as "you're so incompetent, I've met more capable toasters, and you obviously did this because you hate America"?
It's just people skills, my friend. Start your disagreements by assuming the best of your opponent.
As opposed to assuming they're cousin loving inbreds who did Y because they hate every computer scientist ever.
Assuming that doing Y was indeed wrong, and you want to correct that... do you think approaching it with the mindset of "you're a competent person who made the best choice you could see" is going to work better or worse than approaching out as "you're so incompetent, I've met more capable toasters, and you obviously did this because you hate America"?
It's just people skills, my friend. Start your disagreements by assuming the best of your opponent.
Why are you pretending those are the only two options?
And why is this an "opponent"?
How about both not being rude and trying to minimize assumptions?
Consider that they probably looked at X, but don't put them into an extremely awkward position if they didn't. And the same for the other things I pointed out.
It's just people skills, my friend.
And why is this an "opponent"?
How about both not being rude and trying to minimize assumptions?
Consider that they probably looked at X, but don't put them into an extremely awkward position if they didn't. And the same for the other things I pointed out.
It's just people skills, my friend.
I once worked in a department of a fortune 50 which did not have seemingly any need to produce profit or in practice ship any software. Every design came down to debating why don't you do x, for every value of x that the team could come up with.
This lead to the pathological condition whereby adding engineers to the team slowed progress, as it simply created more values for x.
This lead to the pathological condition whereby adding engineers to the team slowed progress, as it simply created more values for x.
Perhaps a previously un-noticed reason for Brooks' Law being true...
"Not worth it, at least right now" is a perfectly valid answer to this question. Before doing X, someone needs to estimate the benefits of doing it / the costs of not doing it. If there's no clear reason to do X, but there are clear reasons to do Y, then forget X and do Y. If things change and a reason for X appears, then you do X.
Not worth it, at least right now according to what metric? This can be interpreted as a dismissive answer to a colleague. It also presumes that the owner of the project has both full autonomy over the implementation, outcome and the perception of the outcome.
If you piss off enough people over the course of a 6 month to a year project, it's unlikely that the perception of even a game changing win will be positive. As most large companies base promotions off of feedback, pissing off the wrong people will also block development.
When you see tenured members of a team exhibiting certain behaviors, it's often due to those behaviors optimally solving for the incentives of the organization.
If you piss off enough people over the course of a 6 month to a year project, it's unlikely that the perception of even a game changing win will be positive. As most large companies base promotions off of feedback, pissing off the wrong people will also block development.
When you see tenured members of a team exhibiting certain behaviors, it's often due to those behaviors optimally solving for the incentives of the organization.
Honestly, I have learnt to reply with we think Y was the best option to bring the discussion back on track. In the case where the person insists to try X, I ask them - How would you do it? More often than not, the conversation ends there. If not, I ask the to make a proposal and convince the team to do X.
The question of that form is akin to “proving a negative”
The question of that form is akin to “proving a negative”
Disagree. I regularly ask something like "explain why this is better than x" or "why shouldn't we use x instead?". I'm not asking because I think x is better. I'm asking because it's interesting to hear the reasons a potentially more senior engineer gives, which then helps me learn more about their decision making process. And in some situations it may open a discussion about other things we haven't considered.
I think the premise of the article is dealing more with random drive-by comments where the person is really just advertising x, rather than being genuinely curious.
I think the premise of the article is dealing more with random drive-by comments where the person is really just advertising x, rather than being genuinely curious.
Infuriating indeed. It’s not just internet randos though, it’s also (for example) engineering executives lacking in self awareness.
Internet randos, executives. Next in line should be fellow programmers "Why the f should I tell you my reasons, if you are competent programmer you should allready know everything".
You don't need to explain to "internet randos", and nobody expects you to. Public posts though will obviously get public commentary.
However it's a great question to understand why certain decisions were made. The best engineers know that most of the work gets done in the planning and decision-making, not by stubbornly diving into something. If it was really the best decision at the time then the merits should stand the test, otherwise the defensiveness to answer is far more suspect than an innocent question.
However it's a great question to understand why certain decisions were made. The best engineers know that most of the work gets done in the planning and decision-making, not by stubbornly diving into something. If it was really the best decision at the time then the merits should stand the test, otherwise the defensiveness to answer is far more suspect than an innocent question.
You're missing the point.
Asking why you did something is a reasonable question. Asking why you did not do something tends know-it-all and/or help-vampire territory.
Asking why you did something is a reasonable question. Asking why you did not do something tends know-it-all and/or help-vampire territory.
Why you didn't do something is a completely valid question and often requires much more awareness (that it exists) and introspection (of how it fits) to figure why it wasn't the best choice.
Instead of assuming the asker is a "know-it-all", what if they actually do know more? I've learned more from counter arguments (both hearing and making them) in all aspects of engineering and life in general.
I'll never turn down such a question and actively engage them because it makes me aware of alternatives at the very least, and often helps in future decisions. There are plenty of stories posted on HN of poor decisions that probably could've been avoided if someone considered some alternatives.
Instead of assuming the asker is a "know-it-all", what if they actually do know more? I've learned more from counter arguments (both hearing and making them) in all aspects of engineering and life in general.
I'll never turn down such a question and actively engage them because it makes me aware of alternatives at the very least, and often helps in future decisions. There are plenty of stories posted on HN of poor decisions that probably could've been avoided if someone considered some alternatives.
Actually engaging with people who ask this question has never led to anything other than getting mired in batting back their own choices presented as obviously better than my choices.
"Why don't you use Reaper?"
"Why not Bitwig?"
"Why not Linux?"
"Why not Ardour?"
"Why not LMMS?"
(the answer is "I spent tens to thousands of hours in each and they all feel like a regression next to Ableton Live and my very stable and productive Windows 11 Pro install")
This is music, but from this thread it sounds like it's the case with most fields. It's always the Standard Alternative Suggestions that assume the askee is an absolute novice who wouldn't be aware of and wouldn't have extensive experience trying or at least considering the entire space of possibilities before settling on a path.
"Why do you assume the asker is a know-it-all?"
Experience. It's cool that you have a different experience where it's not a waste of time.
"Why don't you use Reaper?"
"Why not Bitwig?"
"Why not Linux?"
"Why not Ardour?"
"Why not LMMS?"
(the answer is "I spent tens to thousands of hours in each and they all feel like a regression next to Ableton Live and my very stable and productive Windows 11 Pro install")
This is music, but from this thread it sounds like it's the case with most fields. It's always the Standard Alternative Suggestions that assume the askee is an absolute novice who wouldn't be aware of and wouldn't have extensive experience trying or at least considering the entire space of possibilities before settling on a path.
"Why do you assume the asker is a know-it-all?"
Experience. It's cool that you have a different experience where it's not a waste of time.
I’ve asked other engineers a question in this manner, but I was genuinely curious. E.g. why did you implement this this way etc.
For internet randos, this is true. For coworkers, this is useful. There are times where technology outside has outpaced internal tech. For instance, there was a time where a company I worked at implemented MapReduce before it was available as Hadoop, where we had a k-v store more performant than others before a nice one was available with the props we wanted, where we had an internal partitioning tool to enable efficient joins before one was available; and each time outside technology outpaced us and someone asking "Why don't we just" was right.
Personally, I always get that feeling of fright plus eagerness. "Oh god, have we wasted our time" plus "Oh man, can we save so much more?". And you only have to explain to coworkers once anyway. They'll either demonstrate their idea is better or turn into additional broadcasters for the viewpoint.
Personally, I always get that feeling of fright plus eagerness. "Oh god, have we wasted our time" plus "Oh man, can we save so much more?". And you only have to explain to coworkers once anyway. They'll either demonstrate their idea is better or turn into additional broadcasters for the viewpoint.
Or worse: “Why don’t you just x?”
I respond with "Why dont you just send me a pull request?"
[deleted]
Curiously, this doesn't include the most common reasons I've seen:
1. Because we our engineers don't know X, and we wouldn't be able hire people who already know X.
2. Because we are already invested in Y, and the benefits of X are nebulous and speculative, or can't be connected clearly to business outcomes.
In essence, both of these come down to a matter of organizational inertia, but that inertia can either be good or bad.
A lot of times, organizations don't really have a process to proactively evaluate technology, and the process for making technology changes is ad-hoc. Even when there is a clear need to make a change, it's not clear who all the stakeholders are or who makes the final decision.
Ideally this is something that should be sponsored by senior technical leaders (CTO, VPE, etc) but the decisions should be made by your most senior, boots-on-the-ground technologists.
(Or you can just individuals/teams to use whatever tech they want, with thr understanding that they have to be good citizens with regards to maintenance, documentation, tooling, etc.)
1. Because we our engineers don't know X, and we wouldn't be able hire people who already know X.
2. Because we are already invested in Y, and the benefits of X are nebulous and speculative, or can't be connected clearly to business outcomes.
In essence, both of these come down to a matter of organizational inertia, but that inertia can either be good or bad.
A lot of times, organizations don't really have a process to proactively evaluate technology, and the process for making technology changes is ad-hoc. Even when there is a clear need to make a change, it's not clear who all the stakeholders are or who makes the final decision.
Ideally this is something that should be sponsored by senior technical leaders (CTO, VPE, etc) but the decisions should be made by your most senior, boots-on-the-ground technologists.
(Or you can just individuals/teams to use whatever tech they want, with thr understanding that they have to be good citizens with regards to maintenance, documentation, tooling, etc.)
Yeah, I suspect the most common reason is some version of "we have already spent millions on hiring people with experience in x, and it would be too expensive to refactor and use y". Sometimes the best tool is the one you already own and use.
A million times this.
I use x. Y exists. When someone pitches y to me, I'm happy to stipulate that y is better. (it is, or isn't, but that doesn't matter, so I'm happy to concede/ignore that point.)
The question is, will Y compile all my existing code? Since the answer to that is no you are suggesting either
A) we rewrite existing code in Y. Or B) we add resources enough to build new stuff in y while maintaining the existing in x.
That becomes an economic question not a technical one. Also what happens when all my highly qualified, experienced, and proficient X leave (cause their careers just came to a dead end) and in left with the thing we actually sell and no one to support it?
Swapping y for x sounds like a technical decision, but is far more an economic /existential decision for some part of the business [1].
[1] I'm not talking about the small stuff here - we can easily swap out a text editor, but changing a language or in some cases a database is a big deal.
I use x. Y exists. When someone pitches y to me, I'm happy to stipulate that y is better. (it is, or isn't, but that doesn't matter, so I'm happy to concede/ignore that point.)
The question is, will Y compile all my existing code? Since the answer to that is no you are suggesting either
A) we rewrite existing code in Y. Or B) we add resources enough to build new stuff in y while maintaining the existing in x.
That becomes an economic question not a technical one. Also what happens when all my highly qualified, experienced, and proficient X leave (cause their careers just came to a dead end) and in left with the thing we actually sell and no one to support it?
Swapping y for x sounds like a technical decision, but is far more an economic /existential decision for some part of the business [1].
[1] I'm not talking about the small stuff here - we can easily swap out a text editor, but changing a language or in some cases a database is a big deal.
Indeed. X might be the hyped up flavour of the day, but if you've got large codebases and/or workflows based on Y, then changing to X is a) non-trivial and b) X may not solve the problems as well as Y.
As an example from my experience, when Apache Spark became popular (around v1.8), there were a fair few people in certain circles sneering at Hive, clearly Spark was superior because you could cache intermediate results to RAM.
Except Spark at the time (I haven't used it in anger since v2.2) was rather terrible at the very large datasets Hive could grind through with no issue. Sure, Hive was slower, but then it had the distinct advantage on very large datasets of not dying with an OOM error 2 hours into a job.
As an example from my experience, when Apache Spark became popular (around v1.8), there were a fair few people in certain circles sneering at Hive, clearly Spark was superior because you could cache intermediate results to RAM.
Except Spark at the time (I haven't used it in anger since v2.2) was rather terrible at the very large datasets Hive could grind through with no issue. Sure, Hive was slower, but then it had the distinct advantage on very large datasets of not dying with an OOM error 2 hours into a job.
Yup, in a corporate environment, it's often a very rational reason to say, we already know X. The full meaning is, we have a bunch of stuff built in it, we have a dozen experts on it on staff, we have hiring and training pipelines for it, we have a bunch of standard tools built around it, etc. Even if Y is legitimately better, switching is very expensive and time-consuming. Just trying Y doesn't help much, if we do anything significant with it, then we have to double our efforts in keeping experience with X and Y in house, keeping tools compatible with both, keeping watch on security updates for both, etc. It's pretty rare for such switches to ever generate any business value.
+10
> I used to be the outsider asking the big companies, and their silence would drive me nuts. Do they not know about this technology? Why wouldn't they use it?...I finally get it now having seen it from the other side. They are usually well aware of various technologies but have reasons not to use them which they usually won't share.
I can't speak for the OP, but this insight often just comes with experience and rarely needs seeing it "from the other side".
With some exceptions, the reality is that most technologies aren't introducing a new class of tool.
They're not contributing a wrench to a world that had only seen hammers and screwdrivers, let alone a power drill or industrial crane. The innovations they contribute are more incremental than a lot of early-career developers realize: they're a wrench with a more ergonomic handle, or a hammer with a claw on the back. They're a power drill with a simpler way to change bits.
If your organization already knows how to do its job with some other style of wrench or hammer or power drill, there are many reasons you might pick some new one, but few reasons you should pick any particular one at any particular time.
Articulating an answer to "buy why not?" is usually just an exercise you perform for the benefit of juniors, outsiders, marketers, evangelists and people who happened to be used to that tool already.
I can't speak for the OP, but this insight often just comes with experience and rarely needs seeing it "from the other side".
With some exceptions, the reality is that most technologies aren't introducing a new class of tool.
They're not contributing a wrench to a world that had only seen hammers and screwdrivers, let alone a power drill or industrial crane. The innovations they contribute are more incremental than a lot of early-career developers realize: they're a wrench with a more ergonomic handle, or a hammer with a claw on the back. They're a power drill with a simpler way to change bits.
If your organization already knows how to do its job with some other style of wrench or hammer or power drill, there are many reasons you might pick some new one, but few reasons you should pick any particular one at any particular time.
Articulating an answer to "buy why not?" is usually just an exercise you perform for the benefit of juniors, outsiders, marketers, evangelists and people who happened to be used to that tool already.
These effectively boil down to ROI - it's tricky to quantify what return a tool will give, but its even harder to quantify the cost of switching over. At a big enough company, most will shudder at the thought of a massive migration without an equally passive payoff.
A payoff has to happen over years too. Sure you optimally ignore sunk costs when looking at a given project, but if you keep ditching solutions 2 years into a 3-year payoff you're going to lose a bunch of money.
But, sometimes, a lot of times... It's just "the way we do things here". Some companies really are insulated from outside inovation.
That and sometimes the connectedness of their tools means that switching to some new technology means opening a massive can of worms. I've moved my company over to M365 but we are going to continue to use Slack rather than Teams due to the sheer amount of bots and integration we have set up in Slack. It's just not worth the time to re-engineer for the marginal benefit.
That feels like you dodged a bullet based on how I experience using Teams vs Slack.
I disagree completely. If you're bought into the M365 ecosystem, Teams is fantastic, everything is in one spot.
> Teams is fantastic, everything is in one spot.
But that can be a downside for finding stuff. If everything is in one spot, each time you're looking for something you may have to look through everything. If everything is split up over X spots, you usually only have to look through 1 / X amount of stuff in the spot you're searching.
But that can be a downside for finding stuff. If everything is in one spot, each time you're looking for something you may have to look through everything. If everything is split up over X spots, you usually only have to look through 1 / X amount of stuff in the spot you're searching.
I just want to say I kind of hate Teams but I am not convinced by this argument. Google has the whole internet for example, but it's relatively easy to find things. And segmenting a search space in X spots is easy, so you can get the same effect in just 1 place.
> Google has the whole internet for example, but it's relatively easy to find things.
Used to be; not so much any more.
Used to be; not so much any more.
Just use the search function?
Yeah. And it will find mountains of stuff for you to wade through, a lot of which you could have avoided (since you know it has nothing to do with this humongous chat app, if it had been made available to search elsewhere in stead of in Teams). So now maybe you won't even find what you're looking for in the sea of search results.
This is related to the "directories vs tags" discussion, and that whole "the kids don't even know what files are any more" thing.
This is related to the "directories vs tags" discussion, and that whole "the kids don't even know what files are any more" thing.
Never used Teams myself, but this sounds more plausible to me. MS stuff mostly works fine, but you need to buy into the ecosystem fully. Usually Unix people try a few MS things, try to use it just like their Unix things, and bash it because it's not exactly the same.
Yes, especially if your entire universe of possible choices are almost identical to what you use now, by definition, everything under consideration offers no new ideas. Anything with actual new ideas is automatically excluded without consideration. This lets old farts talk about "picking the right tool for the job" and not realize how incredibly narrow-minded and intellectually dishonest they are.
Well often the really old timers ( still in tech, so survivor bits here) have seen several waves of tech and know some qualities can withstand the test of time, and other fads will not. And having seen the previous fad come and go, they often are less attached to it than the ones that grew with only it, accepting some of the real benefits of the new tech.
As someone teaching electronics, media technology and programming at a art university I'd argue that the space between those who chose a solution because they didn't know it any better and those who considered every available option and made the rational choice is not only big, but the borders are foggy as well.
At least with my students who are usually not experts at electronics, programming or similar things, the chosen solutions are often ridiculously naive. They would probably also work 90% of the time — however they would (and do!) pay that naive approach by gaining an unreliable, expensive, overly complex rube goldberg type of system that falls appart when the stars don't align in just the right way.
People like these are extremely grateful when you sit down with them for a while, analyze their problem, explain some possible solutions to them and then in turn discover that there is a solution that is magnitudes less work, has magnitudes less moving parts and will probably also work in a decade. And you can do that without forcing your language or other strong preferences on them.
There are many companies who chose the solutions they chose because they cannot imagine something else, they only have an employee who does x etc as well — but assuming you can just recommend a thing and everything complicated about the problem would be neatly encapsulated and solved is naive as well.
At least with my students who are usually not experts at electronics, programming or similar things, the chosen solutions are often ridiculously naive. They would probably also work 90% of the time — however they would (and do!) pay that naive approach by gaining an unreliable, expensive, overly complex rube goldberg type of system that falls appart when the stars don't align in just the right way.
People like these are extremely grateful when you sit down with them for a while, analyze their problem, explain some possible solutions to them and then in turn discover that there is a solution that is magnitudes less work, has magnitudes less moving parts and will probably also work in a decade. And you can do that without forcing your language or other strong preferences on them.
There are many companies who chose the solutions they chose because they cannot imagine something else, they only have an employee who does x etc as well — but assuming you can just recommend a thing and everything complicated about the problem would be neatly encapsulated and solved is naive as well.
From the other side of the fence, more often than not when someone offers an open source or COTS replacement to an in-house system the result is that it replaces easily 90% of the functionality, but for the last 10% you need to either serious mental gymnastics to fit your system into the third party system's way of doing things or just put more effort into patching it than doing it from scratch would have needed. Sometimes the 10% is not really needed, sometimes it's the whole reason why the product was built.
To be fair, this also happens if you switch to a commercial system, or from one commercial system to another. I can't count the number of times I've arrived at a health clinic, and was told: "Please bear with us, we just switched our system to **, and it has effectively shut us down."
Medical information systems are the worst, because the poor people who have to use them can't influence the initial choice or development of the thing.
Or even, "we've just upgraded to a new version of our health system and it has effectively shut us down"
That initial list is a brilliant checklist for before you stake a key part of our architecture on X, answer the following....
reworded to the positive
Does it perform well?
Is it inexpensive?
Is it open source?
Does it lack features?
Does it have a community?
Does it have debug tools?
Does it have maintainers? (or other quality symbols)
It is properly documented?
Does it receive timely security fixes?
Does it show subject matter expertise?
Are we the audience it was developed for?
Why isn't our custom internal solution is good enough?
Is it's longevity understood: Its startup may be dead or sold soon.
Have we been in touch with the maintainer?
Does this solution make sense for a reasonable window of time?
Does it have industry credibility?
Is the community Code of Conduct congruent with our values?
Do our lawyers accept its T&Cs or license?> It is properly documented?
IMO If you're really staking a key part of your architecture, you should be comfortable enough with the technology to basically be able to document/maintain it yourself if you need to.
Put another, if your understanding of the tool/stack depends on someone else making it accessible to you, either you have an unshakable trust in that someone else, or you're in for a wild ride. I'll concur sometimes you might not have a choice.
IMO If you're really staking a key part of your architecture, you should be comfortable enough with the technology to basically be able to document/maintain it yourself if you need to.
Put another, if your understanding of the tool/stack depends on someone else making it accessible to you, either you have an unshakable trust in that someone else, or you're in for a wild ride. I'll concur sometimes you might not have a choice.
> IMO If you're really staking a key part of your architecture, you should be comfortable enough with the technology to basically be able to document/maintain it yourself if you need to.
Hmm. Not entirely sure I agree. To use an example, I find it much easier to read https://pkg.go.dev/encoding/json than the dozen or so files in https://github.com/golang/go/tree/master/src/encoding/json
Perhaps I'm misunderstanding your point.
Hmm. Not entirely sure I agree. To use an example, I find it much easier to read https://pkg.go.dev/encoding/json than the dozen or so files in https://github.com/golang/go/tree/master/src/encoding/json
Perhaps I'm misunderstanding your point.
Good documentation has different level of criticality depending on where you are on the "I use a closed library with no access to the source" down to "this library is just a stepping stone, we have full control and will modify it as needed"
If you are on the completely blind side, documentation is your only window into how it works, and good documentation is non negotiable (you will take a slightly worse working library if it has way better documentation).
In comparison if you adopt a library as a time saving move, and audit all of its code the same you would review your own code, good documentation is a nice to have, but won't be the make or break point of your decision. You'll chose the better working code even if its documentation is meh.
I you are putting your fate into a specific stack or library, I hope it falls on the latter category than the former. On the two json libraries, I guess they both work decently, and the only criteria is which one feels better to use ?
If you are on the completely blind side, documentation is your only window into how it works, and good documentation is non negotiable (you will take a slightly worse working library if it has way better documentation).
In comparison if you adopt a library as a time saving move, and audit all of its code the same you would review your own code, good documentation is a nice to have, but won't be the make or break point of your decision. You'll chose the better working code even if its documentation is meh.
I you are putting your fate into a specific stack or library, I hope it falls on the latter category than the former. On the two json libraries, I guess they both work decently, and the only criteria is which one feels better to use ?
You're assuming someone places value on proper documentation because they need proper documentation to make it "accessible to you". That doesn't have to be the case.
For me, lack of proper documentation constitutes a red flag, and says something very negative about the project. The question "Is it properly documented?" serves as a simple and convenient way to filter out projects that have a low chance of being mature enough to fit my needs.
For me, lack of proper documentation constitutes a red flag, and says something very negative about the project. The question "Is it properly documented?" serves as a simple and convenient way to filter out projects that have a low chance of being mature enough to fit my needs.
> The question "Is it properly documented?" serves as a simple and convenient way to filter out projects
I hear you, my point is there are dozens of other convenient questions you can ask to filter out projects.
For me personally "Is it widely used in production" is a better one for instance.
I hear you, my point is there are dozens of other convenient questions you can ask to filter out projects.
For me personally "Is it widely used in production" is a better one for instance.
> my point is there are dozens of other convenient questions you can ask to filter out projects
Absolutely. And I agree with you that "Is it widely used in production?" is a better filter. But that does not diminish the value of the filtering done by "Is it properly documented?". After all, it's not like we're limited in the number of criteria we can use to filter out bad projects.
Absolutely. And I agree with you that "Is it widely used in production?" is a better filter. But that does not diminish the value of the filtering done by "Is it properly documented?". After all, it's not like we're limited in the number of criteria we can use to filter out bad projects.
[deleted]
There's a corollary here for engineering managers managing a new (to them) team. With the caveat that they must be very clear that they trust the team and are there to learn, "why don't you do X" is incredibly valuable for a manager to connect their limited experience with the deep experience on the team. The reasons often fall into one of three categories:
- X is not a good solution outside of internal considerations (what this article mostly focuses on)
- X is a good solution but not worth it for a good list of reasons (ie it makes slightly different tradeoffs than the internal solution and the cost of switching is higher than the benefit of changing tradeoffs)
- X is better than what the team is currently doing but the team hasn't been able to get buy in for the investment needed to change to X
All of these scenarios are great for the manager to understand, but the last one is the manager's dream because they actually have a concrete opportunity to help the team!
- X is not a good solution outside of internal considerations (what this article mostly focuses on)
- X is a good solution but not worth it for a good list of reasons (ie it makes slightly different tradeoffs than the internal solution and the cost of switching is higher than the benefit of changing tradeoffs)
- X is better than what the team is currently doing but the team hasn't been able to get buy in for the investment needed to change to X
All of these scenarios are great for the manager to understand, but the last one is the manager's dream because they actually have a concrete opportunity to help the team!
Personally, a better framed question which works for me is - “What options did you consider and how did you choose this option?”
Agreed, there are lots of ways to explore the problem space.
The OP framing can be helpful when the manager has context on solution X and its pros and cons so it’s helpful for the team to explain through a shared understanding.
The OP framing can be helpful when the manager has context on solution X and its pros and cons so it’s helpful for the team to explain through a shared understanding.
how about:
it is of course important to actually understand what the real problems are, instead of what they are imagined to be to avoid solving the wrong problems.
most real problems are measured in cost, lost revenue, reduced profit.
beyond that there are only a few more important reasons: user/developer satisfaction and security.
if your suggestion does not affect those then it's probably not important.
if there is something that makes developers happier, then they are probably already using it. (unless they work in a company with lots of red tape and the answer to the question in the headline is: because we we can't (for whatever reason.))
and i mention security separately, because while it is a real problem, it often doesn't affect revenue/profit (until something happens)
the point is, i don't ask why companies don't use something that i think would be better. you do you. but if you present me with a problem that you'd like me to solve then i'll tell you what i think you should change (and then i won't ask)
it doesn't solve a problem that we have.
it is of course important to actually understand what the real problems are, instead of what they are imagined to be to avoid solving the wrong problems.
most real problems are measured in cost, lost revenue, reduced profit.
beyond that there are only a few more important reasons: user/developer satisfaction and security.
if your suggestion does not affect those then it's probably not important.
if there is something that makes developers happier, then they are probably already using it. (unless they work in a company with lots of red tape and the answer to the question in the headline is: because we we can't (for whatever reason.))
and i mention security separately, because while it is a real problem, it often doesn't affect revenue/profit (until something happens)
the point is, i don't ask why companies don't use something that i think would be better. you do you. but if you present me with a problem that you'd like me to solve then i'll tell you what i think you should change (and then i won't ask)
Quick searching doesn't yield my "why don't you use" - migration cost. Unless a tool is bringing in functions never used before, e.g. Jira to a team where project management was non-existent, otherwise there are at least data , user behaviour, integration and reporting that need to migrate from. That means most of the time it just isn't worth it
This is how we had people using CVS in 2010 and Subversion in 2020, and why we can never get rid of autoconf.
I believe that the kind of company that Brendan Gregg would work for would have excellent reasons to use or not to use a particular piece of software. There are a great many more companies that don't hire people of Gregg's caliber, and a lot of them are quite likely to have many terrible reasons for using not using a particular piece of software. Not being aware of the product being among those reasons. By definition, most workplaces are mediocre.
Yes, I believe most companies have poor reasons for the technology they use.
Gregg says:
> People think it's poor technical choices ten times more than it actually is.
I'm skeptical. My experience shows that technical choices are often driven by politics:
- The boss knows the people selling the software so he chooses it based on that
- The boss used this software in the past and he wants to stick with it
- Penny pinching (Superior software is more expensive)
- The boss who chooses the software doesn't have to use it.
- We get this software for free because it is included in another contract. We might as well use it...
And many other bad reasons.
Gregg says:
> People think it's poor technical choices ten times more than it actually is.
I'm skeptical. My experience shows that technical choices are often driven by politics:
- The boss knows the people selling the software so he chooses it based on that
- The boss used this software in the past and he wants to stick with it
- Penny pinching (Superior software is more expensive)
- The boss who chooses the software doesn't have to use it.
- We get this software for free because it is included in another contract. We might as well use it...
And many other bad reasons.
Personally I don’t think it’s actually secrecy.
I think it’s that you’re asking the wrong person most of the time.
From my experience, a lot of the times it’s just a few people who really are deciding and everyone else is just part of the meetings and they don’t really care that much.
I think it’s that you’re asking the wrong person most of the time.
From my experience, a lot of the times it’s just a few people who really are deciding and everyone else is just part of the meetings and they don’t really care that much.
> Technology X may be too expensive because we're using another technology with a special discount that's confidential.
I'm really proud of myself that I didn't insta-rage upon reading this one. Couple years ago, as the software project lead, I suggested a number of processor technologies for a custom device for a specific customer. Any of them would have worked well, they were all very well documented and popular and most of them we already had experience with.
Which one did the company owner go with you ask? The obscure, brand new processor that we had never used, lacked documentation, manufacturer-supplied sample code was either full of bugs or only showed how to use the features in the most brain-dead, trivial fashion.
Why you ask? Well, it turned out that we were some kind of "technology evangelist" for that semiconductor company and we got a substantial kickback for just putting one of these chips into a new design.
I'm really proud of myself that I didn't insta-rage upon reading this one. Couple years ago, as the software project lead, I suggested a number of processor technologies for a custom device for a specific customer. Any of them would have worked well, they were all very well documented and popular and most of them we already had experience with.
Which one did the company owner go with you ask? The obscure, brand new processor that we had never used, lacked documentation, manufacturer-supplied sample code was either full of bugs or only showed how to use the features in the most brain-dead, trivial fashion.
Why you ask? Well, it turned out that we were some kind of "technology evangelist" for that semiconductor company and we got a substantial kickback for just putting one of these chips into a new design.
> It tolerates brilliant jerks and has no effective CoC.
That reason exists only in the wet dreams of a few open source social justice troublemakers. No corporation would refuse a great tool that fits their use case over what happens in its mailing list or whatever.
That reason exists only in the wet dreams of a few open source social justice troublemakers. No corporation would refuse a great tool that fits their use case over what happens in its mailing list or whatever.
Right, can you imagine telling the higher ups "Sorry, we can't use Linux like our competitors because Linus Torvalds is a brilliant jerk and he swears at contributors sometimes which is harmful to inclusivity"? Yeah right. Most FOSS users don't say boo to the maintainers of the software they are using, let alone contribute.
But many large companies, like Brendan's, _do_ contribute to large projects that they use. To successfully adopt big pieces of OSS infrastructure, large companies often want some assurance that their bug fixes, performance improvements, and possibly feature additions can be upstreamed without too much pain.
It's hard to get brilliant jerks to accept new ideas. It's hard to motivate your engineers to invest deeply in toxic, unfriendly ecosystems. Of course, extreme technical success can outweigh many of these factors, but that's the exception and not the rule.
It's hard to get brilliant jerks to accept new ideas. It's hard to motivate your engineers to invest deeply in toxic, unfriendly ecosystems. Of course, extreme technical success can outweigh many of these factors, but that's the exception and not the rule.
What any sensible company wants is that their changes get upstreamed, but changes that they don't care about from other sources (such as other such companies) do not.
Someone who can work with toxic and unfriendly upstream anyway has an advantage; they are able to get stuff into a project that is stable because it loudly rejects crap and fluff.
A corporation doesn't care about toxic and unfriendly; that just describes their world, pretty much.
If I'm dealing with some external project as part of company work, that's the situation in which I least care about people's personalities. I represent a company, not some individual and his fragile ego. I might be in charge of upstreaming something that doesn't even have my own name on it.
In business you have cutthroat competitors who unfairly bad-mouth your product.
You have irate, rude customers.
You may have suppliers to whom you are a low priority because their volume is elsewhere.
Your HR doesn't control any of those external people. You have to be cool as a cucumber, or it behooves you to be so.
Someone who can work with toxic and unfriendly upstream anyway has an advantage; they are able to get stuff into a project that is stable because it loudly rejects crap and fluff.
A corporation doesn't care about toxic and unfriendly; that just describes their world, pretty much.
If I'm dealing with some external project as part of company work, that's the situation in which I least care about people's personalities. I represent a company, not some individual and his fragile ego. I might be in charge of upstreaming something that doesn't even have my own name on it.
In business you have cutthroat competitors who unfairly bad-mouth your product.
You have irate, rude customers.
You may have suppliers to whom you are a low priority because their volume is elsewhere.
Your HR doesn't control any of those external people. You have to be cool as a cucumber, or it behooves you to be so.
This.
I've pushed back on "why not X?" before; the most often reason being "it does not have the features we need". Then implemented it anyways when some astronaut architect decreed it shall be so, and duct taped around the aforementioned gaps as best I could. To whomever handles that in the future: I'm sorry.
Or sometimes the decree just comes down "adopt X" with nobody really having done any legwork to see how good X actually is in practice and we just find out by adopting.
> Why not protocol buffers?
Because we were looking for performance, but the backend was in Python and wasn't getting re-written in Rust anytime soon, and JSON was faster because it is a native C extension¹.
¹and technically, protobufs can be too. We evaluated the C extension, and there was one problem with it: it reliably segfaulted. We disabled it, and tried the pure-Python version, but it lost to JSON.
> Why not cloud-managed relational DB?
We need spatial indexes, and the cloud provider didn't offer them, then later did offer them but they didn't work. I hear they work now, but we didn't wait around for the cloud to implement…
Although sometimes, the answer is just "honestly, I'd love to adopt X. Haven't had the resources to do it, (probably, haven't had the time)."
I've pushed back on "why not X?" before; the most often reason being "it does not have the features we need". Then implemented it anyways when some astronaut architect decreed it shall be so, and duct taped around the aforementioned gaps as best I could. To whomever handles that in the future: I'm sorry.
Or sometimes the decree just comes down "adopt X" with nobody really having done any legwork to see how good X actually is in practice and we just find out by adopting.
> Why not protocol buffers?
Because we were looking for performance, but the backend was in Python and wasn't getting re-written in Rust anytime soon, and JSON was faster because it is a native C extension¹.
¹and technically, protobufs can be too. We evaluated the C extension, and there was one problem with it: it reliably segfaulted. We disabled it, and tried the pure-Python version, but it lost to JSON.
> Why not cloud-managed relational DB?
We need spatial indexes, and the cloud provider didn't offer them, then later did offer them but they didn't work. I hear they work now, but we didn't wait around for the cloud to implement…
Although sometimes, the answer is just "honestly, I'd love to adopt X. Haven't had the resources to do it, (probably, haven't had the time)."
Two potential answers he left out:
- It ships/deploys next month and you'll find out then
- We've been shipping/using it since 2014 and you really should do your homework
- It ships/deploys next month and you'll find out then
- We've been shipping/using it since 2014 and you really should do your homework
One thing I’ve noticed is that people who haven’t worked for large companies think that if you work for a huge company that money must never be an issue. That’s not true at all. Everyone works for a department within the organization. Your department has a fixed budget. It’s basically like working for a tiny company within a larger company. Just because the large company made X billion dollars in profit last year doesn’t mean that any of us peons have access to that profit beyond our allotted budget.
When I've asked this question to engineers that work at famous companies they're usually happy to explain what the tradeoffs are and why some decision was made if they know the reason (often there might even be a blog post).
Usually they just don't know the reason unless it's within their specific team or area of expertise and they just say they don't know.
Maybe it's different at the executive level or something.
Usually they just don't know the reason unless it's within their specific team or area of expertise and they just say they don't know.
Maybe it's different at the executive level or something.
Another straight-forward but non-obvious reason, depending on your industry:
Because the computer we would run it on is not connected to the internet.
From google docs to numerous npm-things, there's myriad software I was unable to run at a digital forensics shop.
And of course the opposite is true: we were always thankful for software who's authors had taken the time to make work offline.
Because the computer we would run it on is not connected to the internet.
From google docs to numerous npm-things, there's myriad software I was unable to run at a digital forensics shop.
And of course the opposite is true: we were always thankful for software who's authors had taken the time to make work offline.
I don't want to rewrite my app when the framework/API inevitably changes.
[deleted]
The worst part is 99% of the time the person asking "why don't you use X?" has never used X, and 90% of the time doesn't even understand X, and 50% of the time has merely seen "why don't you use X?" used for this particular situation before, and is trying to score internet karma points / upvotes by being the first to ask it.
This also happens in companies. Unfortunately, in tech you're penalized for not speaking up in meetings, and the easiest contribution to make is often "why not X?". Sad but true.
This also happens in companies. Unfortunately, in tech you're penalized for not speaking up in meetings, and the easiest contribution to make is often "why not X?". Sad but true.
Ctrl+F: legacy
> Phrase not found
Aw, come on.
> Phrase not found
Aw, come on.
Another common reason is: it doesn't fit our culture. Or variations on that theme, like: we don't have people who could support it because we don't have people who understand the programming language X is written in.
Obviously, the list of possible reasons (good, bad, whatever) is potentially very long. It's enough to consider a sufficiently large list of such reasons to understand why you might not be told a reason or reasons.
Obviously, the list of possible reasons (good, bad, whatever) is potentially very long. It's enough to consider a sufficiently large list of such reasons to understand why you might not be told a reason or reasons.
worse:
"why dont you just use ..."
"why dont you just use ..."
(robot voice) Why don't you use MongoDB. MongoDB is web scale. Relational databases don't scale because they use joins and write to disk.
(At the worksite I've been known to say "MongoDB is web scale" in a robot voice to remind coworkers to stop and think about whether Mongo (or any noSQL solution) really is the best choice or whether they chose it due to convention or fashion.)
(At the worksite I've been known to say "MongoDB is web scale" in a robot voice to remind coworkers to stop and think about whether Mongo (or any noSQL solution) really is the best choice or whether they chose it due to convention or fashion.)
Oracle V2 was known as the "roach motel of databases". Data went in and it didn't come out. By V5, Oracle was a solid database. Why do people not give MongoDB the credit for growing up from a memory-mapped db to something far more serious, where they say they have ACID transactions, HA, a managed cloud service, etc? The industry memory of that meme is impressive, hilarious...and misplaced.
It's not really about MongoDB which may or may not be a good fit for your app (personally I was never faced with a good use case, but that doesn't mean it's not any good elsewhere). It's about MongoDB zealots and more generally about people following the trend instead of making proper choices based on their real needs.
MongoDB Zealots I hear you say? Wherefore art these zealots? I watch social media for MongoDB on a regular basis and I can't say I have come across much zealotry in the last 8 years :-)
Most of our customers are reasonable rational people who use MongoDB alongside a collection of other database technologies.
Personally as someone who has worked in pre-sales and more recently developer relations, at MongoDB I find our customers and users are suspicious of zealots.
Most of our customers are reasonable rational people who use MongoDB alongside a collection of other database technologies.
Personally as someone who has worked in pre-sales and more recently developer relations, at MongoDB I find our customers and users are suspicious of zealots.
> I can't say I have come across much zealotry in the last 8 years :-)
This meme is from 2010, the dust has settled. But there are plenty of tools generating the same kind of zealotry these days. It used to be "why don't you use MongoDB ?", now it's "why don't you rewrite [X] in Rust ?". Call them early adopters instead of zealots if you want. Some of these early adopters just act like they've discovered sliced bread and obviously others are fools for not using it. And later the dust settles.
This meme is from 2010, the dust has settled. But there are plenty of tools generating the same kind of zealotry these days. It used to be "why don't you use MongoDB ?", now it's "why don't you rewrite [X] in Rust ?". Call them early adopters instead of zealots if you want. Some of these early adopters just act like they've discovered sliced bread and obviously others are fools for not using it. And later the dust settles.
Haha, not many people say that to me at MongoDB :-) Early adopters are, I guess, revolutionaries with all that that entails.
> Wherefore art these zealots?
Are. "Art" goes with second person singular ("thou"), not plurals.
Also, it looks like you're using "wherefore" as a synonym for "where". It isn't; it means "why". (Compare Ger wofür, Sw varför, etc.)
Are. "Art" goes with second person singular ("thou"), not plurals.
Also, it looks like you're using "wherefore" as a synonym for "where". It isn't; it means "why". (Compare Ger wofür, Sw varför, etc.)
Poor bitwize. Tried to make an analogy to MongoDB zealotry but everyone is too young to remember 8 years ago.
Lol. I heartily endorse people making proper choices based on their needs. With the proliferation of shiny things for developers, it's really important for people to have this focus. Very good point.
For many of us though, ignorance and fear are blocking factors.
A company used a postgres safe migration gem that blocked default values with a not null constraint that became safe 3 years earlier, but 1) nobody questioned with the tool version changes 2) once you learn a constraint it's hard to forget it.
With the add that you have to take time to upgrade the gem if you want to keep using it.
A company used a postgres safe migration gem that blocked default values with a not null constraint that became safe 3 years earlier, but 1) nobody questioned with the tool version changes 2) once you learn a constraint it's hard to forget it.
With the add that you have to take time to upgrade the gem if you want to keep using it.
> It tolerates brilliant jerks and has no effective CoC
Is an interesting ones. Do big companies actually do enough due dilligence to know? I mean of course things can get to a point where the entire internet knows, but for most products i use, i have no idea what their internal culture is like and whether or not its full of assholes.
Is an interesting ones. Do big companies actually do enough due dilligence to know? I mean of course things can get to a point where the entire internet knows, but for most products i use, i have no idea what their internal culture is like and whether or not its full of assholes.
> Do big companies actually do enough due dilligence to know?
I was talking to a company about a role, and one of their ex-employees warned me that one reason they'd left was that the company required contact with shitty upstream communities that make contributors' lives very unpleasant. I passed on that role, and one item I carried from the experience was that in discussions about a subsequent employer's open source contribution was that we needed to make sure that we weren't expecting people to deal with upstreams whose behaviour would be drive our staff out, or give them grounds for legal action against us.
So yes.
I was talking to a company about a role, and one of their ex-employees warned me that one reason they'd left was that the company required contact with shitty upstream communities that make contributors' lives very unpleasant. I passed on that role, and one item I carried from the experience was that in discussions about a subsequent employer's open source contribution was that we needed to make sure that we weren't expecting people to deal with upstreams whose behaviour would be drive our staff out, or give them grounds for legal action against us.
So yes.
Usually when evaluating a new technology, one of the important things to do is look at the public support channels and see the kinds of problems people are having and the solutions.
If you are looking in there and keep seeing someone who is very often right but also very condescending about it, you can tell they tolerate brilliant jerks.
I've worked with a lot of brilliant jerks in my life so it doesn't bother me, but it bothers a lot of other people, so I still try to avoid it.
If you are looking in there and keep seeing someone who is very often right but also very condescending about it, you can tell they tolerate brilliant jerks.
I've worked with a lot of brilliant jerks in my life so it doesn't bother me, but it bothers a lot of other people, so I still try to avoid it.
>> "I've worked with a lot of brilliant jerks in my life so it doesn't bother me, but it bothers a lot of other people, so I still try to avoid it."
This is a good perspective. There's a gradient of intersections of levels of Brilliant and Jerk, and everyone has a cutoff point for Jerk where Brilliant stops being worth it. If you optimize for Brilliant and try to limit Jerk, it's probably easier to referee between a Jerk and someone with a different tolerance when they have to work together since there's less distance between tolerance levels.
This is a good perspective. There's a gradient of intersections of levels of Brilliant and Jerk, and everyone has a cutoff point for Jerk where Brilliant stops being worth it. If you optimize for Brilliant and try to limit Jerk, it's probably easier to referee between a Jerk and someone with a different tolerance when they have to work together since there's less distance between tolerance levels.
Sometimes the jerks are too brilliant...
Could this be a less offensive question:
Have you been tempted by any other frameworks etc ?
This is open-ended on the side if the person being asked wants to demonstrate additional knowledge. At the same time, it invites the simple response: We have, but [our approach] seems best for us now.
Have you been tempted by any other frameworks etc ?
This is open-ended on the side if the person being asked wants to demonstrate additional knowledge. At the same time, it invites the simple response: We have, but [our approach] seems best for us now.
> It's rarely because we don't know about it or don't understand it
That's pretty arrogant. In fact, big companies have many (influential) people who've been working there for a long time and have relatively weak knowledge of the technology landscape outside their company.
That's pretty arrogant. In fact, big companies have many (influential) people who've been working there for a long time and have relatively weak knowledge of the technology landscape outside their company.
I usually ask this if someone asks me "why don't you use" -
Tell me how it will solve my current (not future) challenge without making any subjective assumptions but knowing what we are trying to do, and better than the technology/* we have chosen ourselves.
Then usually people shut up.
Tell me how it will solve my current (not future) challenge without making any subjective assumptions but knowing what we are trying to do, and better than the technology/* we have chosen ourselves.
Then usually people shut up.
True, but the analysis done in companies have variable quality and are subjected to bias / preferences of whoever is tasked with doing the research.
There's a lot of decent tech not used by companies because some guy didn't like the project.
There's a lot of decent tech not used by companies because some guy didn't like the project.
"It tolerates brilliant jerks and has no effective CoC."
That's what she said.
That's what she said.
For startups the reasons are more often:
* The benefit X will bring in the foreseeable future does not out weight the cost of switching.
* We have limited engineering resources and they're better spent working on Y.
* The benefit X will bring in the foreseeable future does not out weight the cost of switching.
* We have limited engineering resources and they're better spent working on Y.
Or maybe your codebase is just crap and changing something would require tearing the whole thing down!! It happens more often than it doesn't even in great companies!!!
Even more annoying is the question "Why do you still use..."
[deleted]
[deleted]
I find this article pretty pointless. People are curious, nothing new.
If you’re tired of explaining to satisfy their curiosity, write a better rationale and hand it out on a pamphlet.
If you’re tired of explaining to satisfy their curiosity, write a better rationale and hand it out on a pamphlet.
Part of the whole point of this blog was to explain why it's not possible to explain and satisfy their curiosity, because the reasons can't be disclosed externally outside of the company (either because the reasons are under NDA, or involve lawyer's concerns over terms or conditions, or because the company doesn't want to call out some project leader as a toxic jerk).
The blog post is a general answer of why sometimes people's curiosity can't be satisfied; pamphlets are so 18th century, after all. Sure, that's what the authors of the Federalist Papers used, but in the 21st century, we use blog posts instead of pamphlets. :-)
The blog post is a general answer of why sometimes people's curiosity can't be satisfied; pamphlets are so 18th century, after all. Sure, that's what the authors of the Federalist Papers used, but in the 21st century, we use blog posts instead of pamphlets. :-)
Now I'm imagining the Federalist and Anti-Federalist papers restructured as a pair of blogs with links and comments. I like it.
Sometimes people ask because they're curious. Sometimes when people ask that, the question really seems to be "I think people should use my favourite tech by default, so I expect you to explain why you've diverted from the Chosen Path". To exaggerate a little, but if you've met one of those people, you get the idea.
I've seen both. The latter seems to sometimes occur with people who have a clear favourite (language|stack|whatever), mostly if they're also somehow overly confident that it's the right choice regardless of your problem.
I've seen both. The latter seems to sometimes occur with people who have a clear favourite (language|stack|whatever), mostly if they're also somehow overly confident that it's the right choice regardless of your problem.
I suspect that’s why he wrote the article. Now he can just point people to that.
I think it's a solid concise article about the various rationales behind making technology decisions. A lot of the reasons given would make for a solid checklist to go through when trying to decide on a technology to use. A lot of the stuff he goes through is not obvious to people who have not contemplated these types of decisions before.
The pithy answer is because of all the things in the world that someone might propose need doing, I can only do a vanishingly tiny fraction of them. Even the largest, most profitable company in the world can only do a slightly larger tiny fraction of them.
The reason we don't do the things you ask about is because we are focused on doing the things which we've prioritized using our best judgement. The idea that we somehow owe an explanation to internet randos about everything we don't do is indicative of a personality that must not be allowed anywhere near engineers with work to do.