Recently I gave my first ever presentation at iO. It was about what it actually feels like to be a junior developer in a world where AI is just always there. This is a write-up of that talk, including what the room said back.
Recently I gave my first ever presentation at iO. It was about what it actually feels like to be a junior developer in a world where AI is just always there. This is a write-up of that talk, including what the room said back.
This is silly posturing. Anyone that is troubleshooting a problem tends to start by googling the error message, and more often than not Google will return SO hits, not official documentation.
Is that because you didn’t bother to read the documentation before using product X, and now you encountered some issue because you used X incorrectly?
Your comment shows some ignorance mixed with lack of experience. Errors do happen due to many reasons, and there is no project on earth that is nearly as documented as you pretend them all to be. This is one of the reasons why googling for error messages ended up being a very basic and mundane technique in software engineering.
What makes your comment stand out is the fact that you are completely unaware that some projects even use Stack Overflow to help users troubleshoot issues, with project maintainers taking the lead in providing answers. But here you are, pretending that reading docs is a silver bullet
After years of using SO, then years of going to docs first, I’ve started going back to SO. It just tends to be faster. You can find a question that is 90% similar to yours, rather than piece together scattered bits of information across pages and pages of docs.
I agree you can find an answer quickly on SO. And you can find it even faster by asking an AI. But you will not have learned much, if anything, by copy/pasting the answer. As opposed to reading the documentation, which might have taught you how to solve similar issues in the future.
Your ignorance is showing. The whole point of using SO to help troubleshoot problems is avoiding the troubleshooting stage and all the iterative work of cross-checking docs with parametric tests. The main deliverable of SO is not a magical code snippet but a root cause analysis on a particular failure. You end up with a nice summary of someone else’s prior work troubleshooting the same issue, and a clear indication that X causes Y because of Foo.
And you do not get that by reading official docs documenting the happy flow. You’d know that if you had any relevant experience developing software.
Well I can also tell you that from years of trying to go straight to documentation: you rarely learn anything. Often the docs are written badly and missing usage examples, so it’s unclear how certain options work. Often the tool you’re having trouble with is one you only use once a month so by the next time you use it you’ve forgotten everything you learned.
Speaking from my experience, in most cases it’s just not worth it. In the few cases where it’s something you use every day, then sure invest some time in the docs.