While I can't list all the pitfalls, often, formulating a question and boxing it up into a self-contained problem often takes so much work that by the time you've prepared it sufficiently, you've answered your own question in more time than it would have taken otherwise.
I experience the same for >75% of questions I post.
However, that is not an argument for not bothering to do so. This is effectively rubber duck debugging. You're finding answers to questions that you think might crop up in response to your question; which means you're thinking about the problem from different people's points of view; which means you're thinking about the problem from all possible directions; which is the best way to find the flaw.
At best, you've conclusively proven that you clearly cannot think of the answer here. At "worst", you end up answering your own question. Mind the quotes, because this isn't bad at all. It was maybe a little time inefficient, but solving the problem slowly is better than quickly deciding to not tackle the problem. You'll get faster at solving the problem eventually.
Case in point:
When I was a fledgling developer, I dealt with the ASP.Net eror page plenty of times. I needed to Google the message to figure out what's wrong. it could take several hours before I got the right solution. I basically made every mistake in the book and subsequently had to deal with with the consequences of having to debug the issues.
Now, when an error pops up, I already know the "usual suspects" of what could be causing the issue. My mental list of "usual suspects" is effectively based on the problems I've had issues with the most during my career. Without first having done the time-inefficient leg work of hours of Googling, I would never have made this mental list. But now that I have that mental list, I'm considerably faster at troubleshooting.
Also, while I can't quite put my finger on it, the responsiveness of free conversation can't be matched by the any form of textual internet discussion that I can think of.
I somewhat disagree here. You're right that internet communication is less responsive, but you're (in my opinion) wrong that this is bad for you.
As a lone developer, you'll be reliant on rubber duck debugging. The key ingredient to making RDD work is that you anticipate questions that the rubber duck may have for you. You obviously can't rely on what the rubber duck actually says.
When dealing with slow messaging systems (posting on StackOverflow or communicating by writing letters), you are inherently incentivized to make sure that you get it right the first time. Because needing to correct a mistake will be a slow and arduous process.
By comparison, consider that fast messaging systems (conversation, instant messaging), you can immediately correct something. The ability to quickly correct something makes people less incentivized to ensure that it is correct.
Four cases in point:
- When I'm making my own personal analysis/todo list as a developer, I still use pen and paper. I've noticed that I gloss over assumptions and falsehoods when I'm typing my notes, because my mind thinks that "I can easily fix this later". However, having to correct something you've written on paper is annoying, you need to cross things out and write between the lines and the document looks so much worse when it has scribblings on it. Writing on paper makes me fact-check myself before I commit to writing it. This catches a lot of misunderstandings early, before I even write code that would produce bugs.
- My grandmother was a secretary (age of the typewriter). Making a typo in a formal document meant having to type the whole page again. My aunt is a secretary (age of the word processor). She can rely on an automatic spell checker, and mistakes can be fixed easily and with minimal effort. Unsurprisingly, my grandmother makes considerably less typing errors and spelling mistakes compared to my aunt.
- Video games used to be printed on cartridges. Fixing a bug after release was nigh impossible. You'd need to reprint all cartridges, distribute them to all vendors, and hope that the vendors could somehow get in touch with the customers who already bought the game. It would cost tons of money (double the physical production cost) and would still not reach some customers. Now, in the age of internet patches, game developers have shown to be considerably less invested in testing their games so that they can avoid release day bugs, because it's so much easier to simply push a fix to every customer directly. The impact of making a mistake is minimized to a point where it's better to fix a handful of problems after the fact, compared to having to test for all possible errors that could occur.
- I used to live in a third story apartment, no elevator, and had to often park one or two streets from my building. I hardly ever forgot to take something from my car. Now, I live in a house with my car right next to me in the driveway. I forget to take things from my car all the time.
The underlying idea here is that a difficult exchange system incentivizes people to make correct and fact-checked exchanges. The severity of the punishment (= difficult correction process) teaches you to not make mistakes.
Also, hiding away details to ask a well defined question eliminates the possibility of someone spotting problems you hadn't thought of.
When you make an MCVE, you shouldn't just create it and post it in the question. You should first make it for yourself, so that you can isolate the problem. And then, when you think the problem cannot be reduced anymore, and you still don't see the cause; then you have a valid question for StackOverflow.
Case in point:
I always have a second Visual Studio running with a simple console app called Sandbox. Whenever I run into a technical issue, I copy the offending code into the sandbox and start playing around with it.
- What happens when I change this setting?
- Can I reproduce the issue if I shorten the code?
- Which settings make it possible/impossible to reproduce the issue?
In 90% of cases, I find the cause of the issue because the sandbox helped me look at the offending code without being distracted by the surrounding context (or, for example, any uncertainties about values that come for different parts of the code.
In the other 10% of cases, I am left with the minimal code to reproduce the issue, which serves as a perfect example snippet to post on StackOverflow.
Last but not least, I don't want to post my whole project for the world to look at for the rest of eternity, for obvious reasons.
When you already have your MCVE, you shouldn't have much in the way of personal (or company) information in it. If you do, since the code is minimal, it's easy to rename things to a more basic foo/bar/baz example.
