Your completely right about best-practices, as well as less chance of messing things up with more complicated apps. My point was just that if noobmonkey is doing simple "Hello World!" - or even a more complicated single-binary app - it would probably be more simple to learn that part first, and then learn packaging once it is needed.
One note about that, because it probably isn't obvious: if you just type "foo" into the shell, the shell will interpret that as an executable program, and try to run it. It will look for that program in one or more places, in a specific order. By default on most Linux systems, those places (in some order) are usually /bin, /sbin, /usr/bin, /usr/sbin. That's all great, but if you're just wanting to run an app from your home directory, it's not going to look there, and it will give you some error about not being able to find it. There are two ways to deal with this:
1) If you want to be lazy: cd into the directory containing the binary, and run it with "./foo" or "/path/to/foo". This qualifies the path to the binary (relative or absolute, respectively), so it doesn't need to search for it.
2) If you are using a non-standard path long-term, or if you aren't running it manually: export PATH=foo will set the PATH environment variable in your shell to "foo". (You don't want to do this - it's just an example.) What PATH normally contains is the paths listed previously, separated by colons. If you want to add your custom binary path to the list, use "export PATH=$PATH:/path/to/custom/bindir". $PATH evaluates to the current value of the variable. You should probably append your custom path to the end unless you have a reason not to (see comments about order). This change will last only for the current shell session, in the current shell. You can make it permanent (or rather, autorun on login) by putting that line in your shell's rc file (e.g. /home/$user/.bashrc, .ashrc (on the N900), etc.)