AHCI still not working
w_schmidt at ...181...
w_schmidt at ...181...
Sun May 31 12:08:38 CEST 2015
>To be honest this kind of mindset is what makes developers keep back
>from helping beginners in public forums. It also leads to the wrong
>conclusion that it's not worth the effort to invest time as *those
>people* are lazy anyway and never read documentation.
Not really, it's a problem in the linux world imho.
If you take a look at question and answer sites like stackoverflow you will
most likely get an answer to things you would think as a beginner question /
described in a faq.
For example you have a really good documentation from microsoft for c#
The documentation does not only show methods etc, but also gives examples.
For a lot of people an example is more clear then an abstract description.
On stackoverflow you will find questions like how dictionaries (hashtables
for the rest of the world) are used efficiently to get the resulting
key/value-pairs in some order.
It would be trivial to say: it's unordered, get every element and order them
for yourself. Or: read the MSDN.
Most likely you will see code for some solutions. You will also get most
likely an explaination that .net has specialized dictionaries which can be
better used for such a task and if somebody has always used something liek
this you will get an explaination that you should not used
OrderedDictionary, but SortedDictionary and an example. That is sufficent
for the beginner to know. (I personally think nobody knows all classes of
such a huge framework and sometimes you will get a better result if you have
other people to talk about a problem. Asking a question means to think about
Explaining to others what you want to do is a way to structure a problem. Do
you know rubber duck codding/debugging? If you have something you don't now
and you seem to be stuck take a rubber duck. Try to explain to the duck the
problem you have. In the moment you are beginning to ask the duck a question
you are forming the question in a way somebody can understand. In this
process it is likely that you get an answer from yourself. (instead of a
rubber duck a working student is a good replacement - it doesn't matter if
the duck/student can't answer the question. You have thought about it and
then know better what you need. Think about a possible answer. Sometimes you
see a problem from another site and get a solution. Sometimes you need to
search further or find somebody with the knowledge.
If you have something like a sourcecontrol system it is not the thing you
want to focus on. It is nice to know a lot of things about let's say git or
svn. But it is not the main job. Wading through tons of documentatino for a
sidetask is not efficent. If you have a larger organization put the task to
somebody who then can be the reference /oracle which can be asked if
something needs to be done which is complicated. But normally for most tasks
a more simple howto can help. For example i have seen 4-5 pages articles in
magiazines which describe things you need to do an a sourcecontrol system on
3-5 pages. And it seems to be sufficent for daily work. Not a ton of things
you never need and forget, but a simplified form for somebody just need
using it. It's a more practical approach which can be read and adopted in 20
minutes if you are slow (not heise, itwas something linux specific - heise
articles only start to explain a problem and in the moment then it starts to
get interesting - they stop.)
The thing is: most documentations are written by somebody who does not want
to write a documentation, but needs to do.
No didactical knowledge, just some facts (like throwing some kitchen junk to
pigs to eat it)
Documentation is a thing which is outdated quite fast.
That is the sole reason why people are wading through documentation - it is
most likely not written for somebody to learn something fast or get only the
things to know first. If you look at programming books you have a lot of
old-style thigns and some which are explicitly written for beginners (e.g.
Schrödinger lernt XYZ or XYZ Head To Toe). For some people it is better to
learn somethign which such a book (i don't like them, but they take a modern
approach using learning theories - somethign you doin't normally find for
something liek a source control system).
Something like https://rogerdudler.github.io/git-guide/index.de.html will be
enough for most starters. http://git-scm.com/book/en/v2 is a bit of
If no questions from starters are asked you will not have a feedback whats
wrong with your documentation. Or where things you need to know are not
described or linked to descriptions which are sufficent for tasks.
Respect is a two way thing - not onyl going from an asker to somebody asked.
Many developers think about as not worth answering.
More information about the users