2013 Resolutions: a man page a day makes the newb go away | Hacker News Reader

2013 Resolutions: a man page a day makes the newb go away

sobering.ca

37 pointssobering46 comments

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?

I too, seem to struggle with the day to day tasks. I hope that by publicly announcing my goals, it will make it slightly easier.

I also tried to break down my daily tasks into something that is actually manageable. I feel like many people, when breaking down their goals, tend to overload themselves or put themselves into a routine they simply can't manage or maintain for long periods of time.

> 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.

Some tasks contribute directly to goals, other tasks just get you through the day.

Don't know what to make of that, other than to think that those two types of tasks are probably managed differently, and they probably give you different emotional payoff.

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.

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.

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.

Agreed. I've had the same demoralizing experience with books and manuals in the past. What I really hope to do after reading each manual page is use it throughout the day wherever I can. Someone else also suggested reading some StackExchange questions on each command. I think that will be beyond valuable, and provide some real world uses that I can add to my toolbelt.

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.

"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?"

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.

I felt like I was forgetting 90% of the stuff I read in man pages too and I probably did. But reading them once showed me some of the possibilities those nifty little tools have. Sometimes when I approach a problem I remember one or two things I didn't know before. Even though I don't remember them exactly, I still know about their existence and can easily look them up again.

When I have some spare time on my hands I like to skim manuals for those features. Vim for example, I have been learning continuously ever since I first used it and I dare to say that by now, I know a bit about it. However, I never sat down trying to memorize everything but kept skimming the help every now and then and when I found something cool I just tried to start using it. Some things I've forgot, others stuck.

I guess that's just the way I learn.

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...

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'. :)

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'. :)

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

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.

I second taking notes as you go, here are mines (from 2 years ago, in french): https://github.com/romainl/dotvim/wiki/Notes

Bram Moolenaar's seven habits has great insights about this subject: http://www.moolenaar.net/habits.html

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

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.

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

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.

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.

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_... got me set up using groff to pretty-print the good stuff.

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.

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.

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.

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).

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.

Hah! 'electronic flower of information'. Awesome.

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

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

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.

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?

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.

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

As I recall, SpaceX does their stuff with C++ on Linux with no exceptions. It the rest of their coding standards are anything like NASA's I imagine the subset of C++ that they aee using is closer to C than any normal production C++, so getting a very firm grasp on C is probably the best way to go throughout the industry.

This is some very interesting stuff you want to do there. Try to reach that goal! There's nothing better for an engineer than challenges.

Anyway, even in case you fall short of your goal, learning C can't be wrong. The language provides a very good abstract machine. Probably the best abstract Von-Neumann machine I've seen. Working with it is kind of mind expanding when it comes to understanding computers as well as problem-solving.

A quick suggestion since you said you were taking your first year of CS. Try to implement things you learn, especially algorithms and data structures. It will help you learn the material as well as coding and may give you a couple of insights.

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

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.

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.

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.

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).

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.

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 . . .

cd is a shell builtin, not a command, so there is no man page for it. There will be information about it in your shell's man page, though, which should be worth reading.

May I suggest:

* Read your primary shell's manpage.

* Read alternative shell's manpages. Most particularly zsh, if you're not already using it.

* Look at your bash history and most frequently used commands. Read those manpages.

* Read manpages of language(s) you're looking to develop in.

* Read manpages for tools that are supplanting existing tools. E.g.: ip(8) vs. ifconfig(8).

* Read manpages for not just commands (1 & 8) but file formats (section 5), special files (4), and system and library calls (2 & 3).

* Follow references in manpages (the "SEE ALSO" section(s).

* Try reversing the process. Use apropos to find tools which accomplish a given task.

* On Debian or Ubuntu, install the dwww package and surf manpages locally at http://localhost/dwww/man/ within your web browser.

Reply on news.ycombinator.com