

2013 Resolutions: a man page a day makes the newb go away - sobering
http://sobering.ca/notes/2013-resolutions.txt

======
SoftwareMaven
Naturally, this is the time of year to make goals and attempt to change. What
a person feels like they need to change and whether that is a "good change" or
not is highly personal and probably doesn't require much comment.

More interesting is how you go about making that change. What do you do (from
types of goals you choose down to the daily implementation) to achieve your
goals?

I always try to have a meaningful, measurable goal. I'm not going to lose
weight, I'm going to lose 15 pounds in the next eight weeks. Then I break them
down into tasks that can be followed daily, like measure all food consumed,
exercise 45 minutes, etc.

The place where I struggle is the day-to-day tasks, and I still haven't found
the answer. This can be especially hard for me on the winter as I deal with
seasonal affective disorder (which is why I often wait until spring for my
goals).

How do you manage your desire for growth and change?

~~~
DanBC
> The place where I struggle is the day-to-day tasks, and I still haven't
> found the answer.

One thing that worked for me (but I accept it might not work for everyone)
that was given me by an occupational therapist was to break everything down
into _tiny_ tasks.

Thus, not "I will wash the dishes", but "I will gather everything that needs
washing." then "I will scrape them off" and "I will clean the sink" then "I
will put dishes in sink with hot hot water and dish soap" then "I will scrub
them and let them drain" then "I will dry them" finally "I will put them
away". Each task is small and easily achievable, even if it's a tough day. And
doing one small task gives you a small sense of achievement, and gets you
moving around. That might be enough for you to continue doing things, or you
might decide that's enough for the day. But at least you've stopped things
going backwards, and started making progress.

Another thing that helped me was having a rigid structure. Thus, Thursday is
always "take the trash out". But don't overload each day with tasks. Just put
2 tasks per day, and make sure you include 1 thing for you each day.

I guess these are more useful when days are tough, rather than just everyday.

------
rickdale
I recommend starting with one task and adding to it as the year goes on.
Learning the man pages could potentially make you a better programmer without
reading K&R. Set K&R aside until February and achieve your first goal. It's
important to change one behavior at a time and expect and plan for failure.
Shoot for 5-6 days a week with 1 day review, or 3 with 2 days review, and just
do what you feel with the extra day. Review or move forward.

Good luck. New Years Resolutions are great, stay motivated.

~~~
sobering
Thanks for the advice. I've already gone through K&R, but I just got the C
Answer Book in the mail a couple months back and wanted to go through all the
exercises again. I'll just have to really pace myself and not take in more
information than I can handle in a single day.

------
temp453463343
While I think it's a neat idea - I think in the end it's gunna be a case of
in-one-ear out-the-other.

For instance I read all of "The Unix Programming Environment" by Kernighan and
Pike. It's FULL of useful information (in fact I'd argue it's way better than
reading man pages) and after I was done I felt like I was 10 times the Linux
man I was. However unless you're fighting with Linux a lot on a daily basis
you quickly forget 80-90% of what you read. For instance, I found it near
impossible to remember what '@' does in bash scripts.

It's quite demoralizing - and I've had the same experience many many times
with technical books. You not only have to read, but you also have to DO the
things you read (strangely this isn't the case for history books, or books on
the soft-sciences). This can be almost impossible for the more obscure (though
still very useful) features like the zillions of cool-but-not-so-often-used
flags you will come across in your man page reading.

~~~
npsimons
This is why I try to focus on books with exercises and force myself to finish
_all_ the exercises - "Thinking in C++" (volumes 1 and 2) was especially good
for this. If nothing else, typing in examples helps. Also, try slowing down
and forcing yourself to think of better/alternate ways to do something. Just
having read the docs, your mind will be more open to using different options,
and by forcing yourself to do it differently (even if you have to look it up
again), will help to reinforce.

~~~
tinym
"Don't just read it; fight it! Ask your own questions, look for your own
examples, discover your own proofs. Is the hypothesis necessary? Is the
converse true? What happens in the classical special case? What about the
degenerate cases? Where does the proof use the hypothesis?"

~~~
DanBC
Excellent advice. Also, "try to explain to someone else what you know". That
way you'll very quickly find out what you don't know from what you do know.

------
georgeorwell
Some preemptive advice: pick a small (tiny!) project and do it with C and/or
sh and other command line tools (don't forget about awk and sed). Often you
can do something quickly in a shell script that would be a pain to implement
in C, but the reimplementation can still be a good learning experience. Once
complete, repeat. You will learn far more like that than by trying to memorize
man pages and doing programming exercises out of a book. I mean, did you try
"man gcc"?

Of course, maybe the only way for you to realize this is by actually trying to
memorize man pages and doing lots of programming exercises first. That's what
it took in my case...

------
thinkling
More than worrying about what to read next, I'd worry about fully
understanding how a command is used in practice. It's one thing to read (say)
the xargs man page and another thing to have a sense where it'll come in
handy. Similarly, some commands have dozens of options, while you only need to
understand a few for most of the common uses.

So I'd recommend doing a bit more than reading the man page. The best
suggestion I can think of is to also read the top 3-5 questions on
StackExchange that mention that command.

PS: after reading the man page for man itself, I recommend 'man apropos'. :)

~~~
sobering
The StackExchange idea is excellent. I'll get a sense of how the command
should be used in real environments.

I'll definitely check out 'apropos'. :)

------
Jbudone
I hope this works out for you. I've taken up learning vim this year, but my
main problem is forgetting the things I've learned. I tried cue cards but they
fill up far too quickly; so my answer was to store my notes on a wiki:
<http://wiki.jbud.me/index.php?title=Vim>

~~~
antidoh
Vim is too big to learn. Eventually you'll muscle-memory a set of actions, for
the way that you uniquely use vim, that you don't even know how to explain
without thinking about it.

Rather than trying to go through one end of a tutorial or reference to the
other (don't know if that's you), find a site or two of vim tips, and let them
randomly trigger your mind. I think it's more interesting than going through
anything beyond page/chapter 1 of a reference.

Coupled with that, whatever you find yourself doing in vim, take some time to
understand what it is and the alternatives. Becoming familiar with :help's
table of contents, rather than the contents of every chapter, is probably
helpful here.

Similarly, when you do something accidentally, try to understand what
happened. Sometimes you'll discover a feature. q: for example is discovered by
accident by many people, including me.

------
antidoh
In addition to randomly generating a man page from /bin, consider mining your
command line history and randomly selecting anything whose man page you
haven't yet read. You'll want to keep a file of man pages that you've read, to
help with that.

And since you're stocking up on C, don't forget that C's standard library is
documented via man pages, e.g.

    
    
      man -k sprintf
      asprintf (3)         - print to allocated string
      sprintf (3)          - formatted output conversion
      vasprintf (3)        - print to allocated string
      vsprintf (3)         - formatted output conversion
      XtAsprintf (3)       - memory management functions

------
malandrew
One thing I'd love to see if you embark and stick to this new year's
resolution is creating a blog post per man page with all the exercises and
examples you tried out by applying what you've learned from each man page.
It'd be great if each post included something like:

    
    
      (1) What is the command
      (2) What kinds of things you can accomplish with it 
          (i.e. why should I learn this command? how will 
          it benefit me)
      (3) Examples of the command applied by itself
      (4) Examples of the command applied in conjunction with
          commands you've previously written about via piping.

~~~
sobering
That's what I had planned. Thanks for creating an outline for me. ;)

~~~
malandrew
Also check out the many posts by catonmat (peteris krumins) about linux
commands and scripting. I find that they are good examples of blog posts on
how to use standard command line utilities.

------
bdreadz
Off topic: I love how this was just typed up in a text file. I love using my
text editor for writing and I wish more people I worked with did too.

------
ismiseted
Good plan. I've started to print out man pages and using them for learning /
reference. This post: [http://macgeekery.com/tips/cli/pretty-
print_manual_pages_as_...](http://macgeekery.com/tips/cli/pretty-
print_manual_pages_as_ps_pdf_or_html) got me set up using groff to pretty-
print the good stuff.

------
g2e
Instead of man pages, I'm doing it with books. Goodreads.com makes it pretty
easy (and fun) to manage everything. My goal is to get through all the
classics this year and of course, like you said, apply that knowledge to my
everyday programming.

~~~
sobering
Best of luck to you! I think it's really important to actually apply new
knowledge to your everyday workflow. It's far too easy to go and read a book,
blog post, or article and then just let that information go to waste.

------
npsimons
This is such a good idea, I've added it to my goals, under my "Invest in
Knowledge Portfolio" category. One thing that scares me a bit though is that
some man pages are _enormous_ , possibly more than can be digested in one
sitting.

------
tsahyt
The ultimate goals section lists mainly things I've done in 2012. I've
benefited hugely from every single one and can only recommend those things to
anyone (especially becoming a better C programmer).

------
WinnyDaPoo
Neat! You should keep track of your man page reading and share your
experience! I'm anticipating your homepage growing into a wonderful electronic
flower of information.

~~~
sobering
Hah! 'electronic flower of information'. Awesome.

p.s. I'm from Winnipeg, the city Winnie the Pooh is named after.

------
pacomerh
May I ask why your desire to learn C?, I'd just like to know what are you
targeting specifically.

~~~
sobering
Don't laugh.

My ultimate goal in life is to write software for satellites, space probes or
planetary rovers. I want my code in space. It's a pretty advantageous goal,
but with hard work I can do it.

There is a Canadian company that is currently hiring for my dream position:
<http://www.mscinc.ca/about/MS-engineer.html>

I'd like to help further Canada's contribution to space science.

I'm currently taking my first year of Computer Science. Getting really good at
C is something I feel like I should start now. Then I'll need to get good at
embedded C and eventually start looking at the VxWorks operating system since
it seems like that's what most probes or satellites use. But that's for the
future.

~~~
codezero
This is a pretty reasonable goal. I suggest you also consider learning FORTRAN
(starting with 77) and a solid scripting language like Python or the more
niche IDL (used extensively in space research)

You can get your foot in the door with some more high level programs doing
things like data processing and visualizations, and once you are there you
will be able to find the opportunity to get your hands dirty with space code.

I worked in a group doing solar physics research and although my code didn't
get pushed to a satellite, I did get to do a lot of awesome analysis on data
sent back from the satellite.

You should browse sites like the AAS Job Register as well:
<http://jobregister.aas.org/>

The Science Engineering and Support/Technical staff positions are often open
to people without a PhD and offer a great opportunity to work on space
science.

As an aside: How are you selecting your man pages? Do you have a specific
group in your sights, or will you pick day by day?

~~~
sobering
Thank you for the advice, you've definitely given me some stuff to thing
about, and I'm glad to hear from somebody who's worked in a field similar to
what I'd like to get into.

As for the man pages, I'm starting off with 'man', then will move onto my most
commonly used commands for general Linux use and server administration. After
that, I'll be using a shell script to give me a random man page.

~~~
codezero
Hah, very meta, good idea to start with man's manpage, then work your way from
there. Best of luck to you.

------
seanwoods
How will you know which man page to read "next"?

~~~
sobering
So far the plan is to start with "man" and then go through the man pages of my
most commonly used commands: cd, ls, grep, cat, sed, etc.

After that, I may write a little shell script that simply opens one at random
for me.

~~~
aleprok
Please share that script when you do it. It might be fancy to read man pages
when one is bored instead of watching something as the randomness might dig
some cool facts of the system for you which you did not know before hand.

~~~
sobering
Just found this little snippet via a quick Google search:

    
    
      dir="/bin"; man $(ls $dir |sed -n "$(echo $(( $RANDOM % $(ls $dir |wc -l | awk "{ print $1; }" ) + 1 )) )p")
    

I think I may write my own version as well. Just to gain a bit more experience
with shell scripting.

~~~
ciupicri
Unfortunately there are a couple of commands that don't have a man page, e.g.
mpplu (from argyllcms-1.4.0-2.fc17.x86_64) or showchar (from
psutils-1.17-38.fc17.x86_64).

~~~
npsimons
I know the OP said he was a VIM guy, but here's my first approximation to a
random manual page script for emacs; it doesn't strip out directories (like
man1) or specify different sections of the manual, but it indexes manual
pages, so you not only won't try opening pages for commands that don't have
them, but you'll get other pages too (eg, the TCL library man pages):

    
    
      ;; Taken from http://emacswiki.org/emacs/ElispCookbook#toc57
      (defun directory-dirs (dir)
        "Find all directories in DIR."
        (unless (file-directory-p dir)
          (error "Not a directory `%s'" dir))
        (let ((dir (directory-file-name dir))
              (dirs '())
              (files (directory-files dir nil nil t)))
          (dolist (file files)
            (unless (member file '("." ".."))
              (let ((file (concat dir "/" file)))
                (when (file-directory-p file)
                  (setq dirs (append (cons file
                                           (directory-dirs file))
                                     dirs))))))
          dirs))
    
      ;; Taken from
      ;; http://stackoverflow.com/questions/3815467/stripping-duplicate-elements-in-a-list-of-strings-in-elisp
      (defun strip-duplicates (list)
        (let ((new-list nil))
          (while list
            (when (and (car list) (not (member (car list) new-list)))
              (setq new-list (cons (car list) new-list)))
            (setq list (cdr list)))
          (nreverse new-list)))
    
      ;; Display a random manual page
      (defun open-random-man-page ()
        (interactive)
        ;; Get manual page paths from the environment.
        (setq man-paths (parse-colon-path (getenv "MANPATH")))
        (setq man-dirs ())
        (dolist (man-path man-paths)
          (setq man-dirs (append man-dirs (directory-dirs man-path))))
    
        ;; Get a list of files in manual page paths.
        (setq files ())
        (dolist (man-dir man-dirs)
          (setq files (append files (directory-files man-dir nil "^[^\.].*"))))
    
        ;; Fixup the files to be a list of man pages.
        (setq man-pages ())
        (dolist (file files)
          (setq man-pages (cons (car (split-string file "\\." t)) man-pages)))
    
        (setq man-pages (strip-duplicates man-pages))
    
        (random t)
        (man (nth (random (length man-pages)) man-pages)))
    

Be aware that Emacs lisp is still something I'm learning; I'm sure the above
could be improved.

~~~
npsimons
Another thing to consider: on my main Debian Linux box at home, this script
finds roughly 20k man pages, which would take more than fifty years to read
them all if you are reading one a day. Granted, I have tons of stuff
installed, you could read more than one a day, reading a random one will lead
to/make you aware of what's available on your system, etc, etc. Perhaps I
should write up a blog post about this whole experience . . .

