Interesting that the article mentions SO being better for noobs but really, the quality is so variable that it is hard for a noob to tell a good answer from a workaround from a terrible answer.
If they fixed the reputation system so it more accurately reflected quality, it would be easier but some people have 10K+ reputation for asking a simple question that lots of people upvoted and others who have added high quality replies to more specific questions might only have a few hundred.
The problem I had as a noob was posting a question. Many downvotes and nitpicks about making it more a "mimimum reproducable example" definitely felt like a form of gatekeeping. I remember spending a good hour or so at a time putting together a good question just for it to get downvoted without any mentioned reason. Then the pressure from tech-jargon-filled comments to go read up on every word they just used for another 30 mins in order to give a half witted response because if I ask them to dumb it down they'll ignore and move on, or accuse me of being lazy...
That's the thing though: you don't try out SO answers. Either you understand them and know if they address your problems, or you need to continue your research.
Programming is not like baking cookies, you can't just copy a snippet and hope it'll work out OK.
> Programming is not like baking cookies, you can't just copy a snippet and hope it'll work out OK.
Wait, why not?
Isn't the entire notion of a library or framework literally a book of common recipes? Don't most languages ship with a standard library, common classes, or a common framework?
Sure, thoughtlessly mixing mismatched patterns will get you haggis or oatmeal raisin, but that really doesn't mean the method is flawed.
> If they fixed the reputation system so it more accurately reflected quality, it would be easier but some people have 10K+ reputation for asking a simple question that lots of people upvoted and others who have added high quality replies to more specific questions might only have a few hundred.
Another reason to write your own technical content, even if a similar question/answer does exist on SO, especially in examples where you experiment to put together examples that show/prove a point, is that it is practise for yourself.
I intend to get some of my own content out there (it may never happen, the intention has existed for quite some time!) and if I ever find time to do it some of the things I might include are expansions of things I've given as SO answers, expanding on details that might have been too much in the SO/SE context and potentially caused confusion or sliding off into tangents that would be too far off-topic from the starting point. I might not ever point people at this writing, the main point of it will be my own practise (of technical matters, and just the act or writing and organising information). If it comes to be something that feels useful then it might be the start of an online portfolio that I selectively send people to, or feed back into SO/SE (i.e. giving an answer with bits extracted from something I've already written with a “for some related tangents you might find this fuller article useful” link, as I already do for other people's articles like the very useful tomes of MS SQL knowledge at https://www.sommarskog.se/ that I've referenced on DBA.SE before now).
I write technical stuff to convince myself that I understand a topic. I'll write a tutorial for myself on it, and during this, ask questions that someone who doesn't know it at all would ask, sometimes I don't know the answer so I need to research more.
But at the end I can end up with a pretty good, in-depth, tutorial / notes / blog post.
I just don't publish them to the internet. But I find it's a pretty good way of checking how well you understand something. Like rubber duck debugging with yourself in a way.
There was a thread somewhat related to this recently. I’m wary of having anything that’s not direct professional experience directly listed in the resume.
The consensus is just that outside rare occasion or notability in your field, no one cares about your blog/project/GH/etc.
If I mentioned it directly on a CV at all I would list it in the very small personal interests section at the end along with my other hobbies (running, HEMA, etc.). I've not needed to update my CV in a long time, so advice on this may have changed, but way back when I last touched it up it was worth including such a short list of “what I do in my spare time” and interviewers would sometimes pick something off that as a starting point for a bit of informal discussion.
Though of course it will be linked from my main “vanity page” (which also doesn't currently exist in any touched-in-the-last-decade form) at forename.surname.net or similar, which would be listed on my CV along with other contact details, as well as being linked to on other relevant online profiles. An interested employer might look, those that don't care won't be affected either way.
Another thing I want to mention is that other than SO Google also promotes poor content. Google results are filled with poorly written articles and medium posts that is there because of SEO spam or domain quality.
Some documentation is sadly lacking generally, but even some very good documentation in terms of detail is not terribly useful to a beginner as it is often more a reference work for people with some experience.
With a bit of experience a detailed reference is great, but it can completely overwhelm a beginner who is better served by being given some simple worked examples of a core sub-set of features/methods/properties/processes/… then being given the more referencey docs to find the other details (ideally with some starting pointers, linking what they were shown in the tutorial examples to relevant bits of documentation).
Remember when 4X games came with paper reference manuals? If you skip the SMAC
tutorial and go through the reference in order you'll hit the copter and hovertank units (late-game additions that you don't need to care about initially) long before the speeder (something you have access to early on, from the start in the case of one player faction). Just giving beginners reference docs is much the same thing.
Many have become attuned to searching for a tutorial elsewhere, assuming the docs will be overwhelming initially, even if more introductory information is available for a given thing. Also, many or introduced to new libraries and such through tech blogs, another reason for that being their starting point. And of course if searching via Google et. al. you have the issue of blog-spam that is SEOed to the nth degree coming up before the better documentation.
>>I'm also confused... who reads blogs but doesn't read the docs?
Most docs are hard to read- dense text, millions of options, and not a single example of a use case. Same with most man pages.
90% of the time, I just want to do something simple, and its easier to read thru blogs than trudge thru a dense hard to read official document.
And with Python-- you are guranteed to get out of date docs in Google search. Not just for Python 2, but older unsupported versions of libraries
Sometimes, the page even helpfully tells you it is out of date, and invites you to go to the home page and start searching again (rather than, you know, just link to the latest page)
> I'm also confused... who reads blogs but doesn't read the docs?
I’d say lots of people. Most people are searching for a specific solution to a technical problem. If they see a how-to blog that fits their use case in the results, many people will prefer it over the official docs.
That's honestly entirely dependent on the doc base. Case in point : learning C# recently I've done everything I could to escape Microsoft's official doc and found myself on a lot of blog posts expounding on topical issues I was encountering. It both makes an incredible amount of assumptions and goes for the most cryptic syntax at all times.
Docs are often very terse and assume a lot of background knowledge. When blog posts are written effort is put in to make sure a wider range of audiences can understand them.
IMHO, do write technical blog if you want to, if it helps you learn and if you like to.
But if you can, please try to contribute to the official documentation as well.
It's not applicable in every cases, it takes longer (and may not work), it doesn't bring as much visual karma, but I believe it improves the situation for every one in the long run.
I've always found the "You can accomplish Task A by using Method B, but Method C is way easier and better in the long run" quite helpful, and rarely on stack overflow
Technical blogs worth reading https://web.eecs.utk.edu/~azh/blog/favblogs.html