I'm not convinced. While I've been on the receiving end of such suggestions - and yes, it can be frustrating - a lot of times the question itself reveals problems with the intended solution.
Examples:
"Hey, our home-grown queueing service slows down when we have more than 1,000 insertions per second. How do I make its SQLite backend more scalable?" "Um, perhaps that's not a good solution to your problem." "Would you please just answer the question?"
"Our service can only process one request at a time, so we're thinking of switching from Python to Rust." "Would it make more sense to make your current system multi-threaded?" "Are you gonna help us rewrite this or not?"
Sometimes lack of experience makes suggestions seem like bazookas when they're really cork guns. If you've never used a client-server database, that might seem like a scary upgrade from SQLite. In reality, it's very straightforward and common. If someone recommends a bazooka to you, first make sure that it's actually overkill and not the standard upgrade path from your current situation.
While you have a point, some people seem to think that everything is an XY problem. Sometimes I just want to ask a question and not shoot down a hundred answers because they don't understand the actual restraints I've got.
“your entire idea is cruising for a bruising, trust me i’ve been there and got the t-shirt, for the love of god please use this thing instead” is also true.
Choosing which one is most true is, as usual, a judgement call. Pick the subject matter experts that have earned your trust and respect their judgements enough to at least think it over.
I think the solution to this problem is for the "asker" to know how to respond to these recommendations. I honestly don't have good advice for this, so I usually just do this.
"How do I list a directory with C++ without external libraries?"
"Use Boost"
"Sadly this is not possible due to the requirements listed in my question."
Sometimes the asker is wrong in what they’re asking, or barking up the wrong tree. In the example you give, unless the C++ Standard Library has changed since I last used it a number of years ago, a strict interpretation of your question gives the answer “You can’t;” the person suggesting Boost was trying to be helpful without calling you out as asking an unreasonable question.
The person asking a technical question should always include the goal they’re actually trying to achieve, not just the technical step they think they need to accomplish to get there. Otherwise they won’t actually get the best help possible.
There are two correct answers: Use std::filesystem on C++17, or rename() on POSIX and MoveFileExW() on Windows (which are what boost::filesystem calls internally).
These answers are correct because they answer the question literally, and someone can extract accurate, useful information from it. If there was no correct answer, the answer should be "you can't" from someone confident enough to make that claim. I agree that it is good for the asker to somewhat demonstrate that their question is asked correctly to avoid the XY Problem, but more times than not, the reason they're trying to achieve something in the way they ask it is so incredibly boring, it does nothing but distract from the original question. For example, "I need to rename a file and I'm writing a C++ project for my boss, and we need to distribute this package on a cluster managed by an external IT team that runs a build script on our code that pulls everything from a proxy, where each file needs to be approved by another team, and this needs to take place as quickly as possible because the machines are wiped weekly and someone needs to monitor the build process, so it makes everyone's lives easier if we don't pull in libraries, blah blah blah."
It's 100x easier to just say "I need to rename a file on C++. Constraints: no libraries". When I see a question phrased this way, I can empathize exactly why, because the asker has an encyclopedia of information behind the question that I don't know (or want to know), and they have kindly phrased it as concisely as possible for an expert to quickly help them. I'm just saying that I try very hard to avoid answering questions like "I want to do X without Y" with simply "do Y", because as much as I think I might be helping them by showing them their question is "wrong", I'm not. I just waste their time making them explain the reasons behind their constaints.
Ehh, I somewhat agree but you're generalizing a lot.
To pick one example: containers have been invaluable for setting up reproducible dev environments (via docker compose), even across just a few people. It doesn't take very long to setup, and the time savings are immediately obvious to me when we have to bring someone new onboard or install new dependencies.
Oddly, the time saving is not obvious to me. Deploying to Java app servers was not exactly hard to get running. And it is only in this brave new world of docker that I have joined a team and not gotten a commit on day one.
I don't blame docker. I think. However, I do feel it enables people to move faster with more complicated solutions where not necessarily needed.
So $work did java app deployment with Tomcat and puppet at scale (>100 services). Sweet. Mostly.
3 problems, 1 is that in the unlikely event you had an external system dependency, (say, shudder, imagemagick or really, any non java binary) you were totally hosed, because lots of systems work needed to be done to provide it (say, make rhel packages in corp repo plus puppet guff) and also keep it up to date.
2 was, since it was outside the supported path, actually, you couldn’t ship anything that wasn’t Java in Tomcat, Java invoked binaries were hard, but non Java services, even judiciously and with a super good reason were basically impossible.
3. Your stuff might be coupled to the base operating system in some way... which meant that the operating system patches needed to be tested against all possible application deployments and thus patching (including kernel) became the de-facto responsibility of the team owning the application, which lead to major delays in patch application.
Containers mostly shift these problems around (and create new and different problems too) rather than solving them, but my experience is that they do genuinely shift them around in a useful way.
Amusingly, I've seen all of those problems even in the docker world. It is a bit harder to get yourself into that spot, but for fun, just try and use a GPU on an installation of docker from about 3 years ago. :)
That said, I do agree. It is mostly shifting things around. And if this is where your pain point was, then you will likely like what containers can do for you.
> Deploying to Java app servers was not exactly hard to get running.
I thought that too - not about Java per se, but similarly that "getting this app server running is designed to be easy."
Then, I had to help someone debug an issue with installation over the phone. That was the exact moment I decided to look into containers, and I've never had to re-live that tedium since.
> However, I do feel it enables people to move faster with more complicated solutions where not necessarily needed.
I do agree with you here, but I think that's a people issue and not a tool issue. The tool itself is quite valuable even for simple cases.
I have had to relive the tedium of installing docker images on a coworkers machine. Can be more than a little infuriating when there is no obvious reason things that should be equal are not working. Especially when that is the goal of the system.
And agreed it is a people thing, mostly. I'll even go further and say it is the way things will be soon. I just don't think it is doing anyone favors to pretend previous solutions didn't solve things. Or to pretend that modern solutions solve everything that ever came before. There are plenty of problems to go around.
I used websphere and deployments were hell when something stateful in the server broke and removing and readding the add didn't fix it. I like containers precisely because once you get a running configuration working, it's zero hassle to deploy.
I sometimes use the phrase "don't use a rocketship to pick up your groceries" for a similar phenomenon. Many (most?) webapps are trying to do things that a simpler web page would do just fine, and the amount of bloat that comes from that is a real problem.
Yes. All the slowest, buggiest sites I encounter every day are SPA's that could easily be a regular old forms, especially once you consider datalist, validation, date inputs, and other things that used to require javascript enhancements.
I recently built some web apps for fun, and it shocked me how much was already there. Just an HTML form and a POST handler with no JS at all goes shockingly far.
This totally depends on what you're doing. Sometimes you should be using the bazooka, sometimes not.
Building a large government system, or something internal for a large company that will have heavy and pretty-well-quantified usage, and need to be maintainable? Hell yeah bazookas all the way down. If you know your system is going to end up large and complex, use the more complex but well-defined tools.
If you're not doing this, or you're even just doing a beta or prototype of the above then don't.
Really what this is about is technical debt. Technical debt - like monetary debt - is a useful tool that can get you where you need to be (nobody saves up from scratch to buy their first house - they get a mortgage).
The person advocating the bazooka just doesn't want you to have any debt, in the form of whatever hacked-together fly swat you might build to do the job temporarily, however some debt is a good thing.
>Building a large government system, or something internal for a large company that will have heavy and pretty-well-quantified usage, and need to be maintainable? Hell yeah bazookas all the way down.
My rule of thumb is this: Does the solution solve more problems than it creates?
Taking the example of Vue.js, I found that it makes building UIs a lot easier. But I found that you do need to understand its caveats and its limitations (e.g. limitations in its reactivity system). On balance, it does solve more problems and those limitations are really minor and well documented.
But before I embraced it, I spent some time experimenting with it, assessing the documentation, the community, ecosystem, etc...
I think this is a skill onto itself that comes with experience. I remember jumping on the "cool" bandwagon many times, only to realise I was basically wasting a lot of time switching to cool new technology X.
Nowadays, if I can't understand the problem something is trying to solve, it probably means I don't have that problem.
Edit: added "limitations in" its reactivity system.
I feel like there are two categories of developers, one which has "framework envy" and loves trend-chasing with the latest and most complex technologies, while the other values simple and straightforward solutions. Sadly, the former seems much bigger (although it could just be because they're louder.)
I fully agree. I've learned to auto-filter by skipping over these but haven't put in effort to post corrections because I'm still looking for the answer. If I happen to come to an answer I particularly like, sometimes then search for top hits and add a reference to it.
Similarly, another pet peeve is using npm modules for simple one-off tasks like a single string manipulation function. Self written code has no options you don't need or a nest of subdependencies.
Of course, often the honest answer is "I don't know the solution to your issue, and finding it would take me X hours of debugging (assuming StackOverflow doesn't know the answer)." So you should probably say that instead, perhaps with some pointers on how you'd go about said debugging.
Worse, depending on the size of the project, switching to a different tool just to fix one hard-to-debug issue might genuinely be the easiest option. Of course, doing so without at least trying to debug the issue at hand is slightly insane.
Yes, generally, on stackoverflow (but not only) "going astray" replies are actually due to both:
1) responders that either have not read fully the question or not knowing the actual answer decide to suggest something else that they know (or believe) would work
2) badly asked questions, sometimes it is a good thing to be synthetic when asking, but sometimes providing an even minimal background and particularly listing what attempts have been done before make a better question
I think there are more people that haven't considered other options when asking. They just got stuck for a bit and want others to help them out. This makes people that answer questions jaded, and cause them to act like that.
Like the other poster said, probably best to just specify that you've considered those options.
Examples:
"Hey, our home-grown queueing service slows down when we have more than 1,000 insertions per second. How do I make its SQLite backend more scalable?" "Um, perhaps that's not a good solution to your problem." "Would you please just answer the question?"
"Our service can only process one request at a time, so we're thinking of switching from Python to Rust." "Would it make more sense to make your current system multi-threaded?" "Are you gonna help us rewrite this or not?"
Sometimes lack of experience makes suggestions seem like bazookas when they're really cork guns. If you've never used a client-server database, that might seem like a scary upgrade from SQLite. In reality, it's very straightforward and common. If someone recommends a bazooka to you, first make sure that it's actually overkill and not the standard upgrade path from your current situation.
Further reading: https://en.wikipedia.org/wiki/XY_problem