3 ms·

Interresting, how to you handle the time pressure that stopping and reading the whole documentation generates? (Pick Spring documentation for example)

by cfontes 12y ago

Chlorus 12y ago
Documentation is cheating; you'll never become a rockstar developer that way! Most writers will try to answer the most common questions that a dev will have about their code; this is just as bad, if not worse, than asking them questions yourself. You need to read the source code to truly understand. I shudder at all the young minds that have been warped by the 'USAGE' statements in man pages; back in my day, we used to have to either guess at which arguments did what, or stare at the devs' custom, mangled argument parsing functions to figure out how to use a program.
- tracker1 12y ago
  LOL, that seems to be the case with node projects today... there are plenty of modules that work great, and have some documentation, but when you want to use something in a different way, you have to dig into it.
jquast 12y ago
If it were related to my job: that is my title was "Sr. Java Programmer", I would read it all, and/or maybe some books depending on my current level of familiarity. Given the size of Spring documentation, I would shortcut to my answer as necessary, but make a recurring appointment with myself to spend at least an hour each week reading the rest of the documentation. If it were not, that is my title was "Web Administrator", I wouldn't read it at all -- it is not important for me to know Spring. I would ask the java developers for help and move on with my day, instead reading the documentation for jBoss or WebSphere or whatever is relevant. Chosing what to spend your time learning is a critical function of your career. Imagine if you had spent time learning Flash, Delphi, VMS/VAX, Novell Networking, or any other now-legacy languages or technologies. It's a bit of a betting game, really. Use your intuition.

Interresting, how to you handle the time pressure that stopping and reading the whole documentation generates? (Pick Spring documentation for example)

by cfontes 12y ago

Interresting, how to you handle the time pressure that stopping and reading the whole documentation generates? (Pick Spring documentation for example)

Chlorus 12y ago

Documentation is cheating; you'll never become a rockstar developer that way! Most writers will try to answer the most common questions that a dev will have about their code; this is just as bad, if not worse, than asking them questions yourself. You need to read the source code to truly understand. I shudder at all the young minds that have been warped by the 'USAGE' statements in man pages; back in my day, we used to have to either guess at which arguments did what, or stare at the devs' custom, mangled argument parsing functions to figure out how to use a program.

tracker1 12y ago
LOL, that seems to be the case with node projects today... there are plenty of modules that work great, and have some documentation, but when you want to use something in a different way, you have to dig into it.

jquast 12y ago

If it were related to my job: that is my title was "Sr. Java Programmer", I would read it all, and/or maybe some books depending on my current level of familiarity. Given the size of Spring documentation, I would shortcut to my answer as necessary, but make a recurring appointment with myself to spend at least an hour each week reading the rest of the documentation. If it were not, that is my title was "Web Administrator", I wouldn't read it at all -- it is not important for me to know Spring. I would ask the java developers for help and move on with my day, instead reading the documentation for jBoss or WebSphere or whatever is relevant. Chosing what to spend your time learning is a critical function of your career. Imagine if you had spent time learning Flash, Delphi, VMS/VAX, Novell Networking, or any other now-legacy languages or technologies. It's a bit of a betting game, really. Use your intuition.