[ale] Where to Start?

[Björn Gustafsson]

On Fri, Jun 18, 2010 at 3:32 PM, Derek Carter <goozbach at friocorte.com> wrote:
>
> On 6/18/10 2:01 PM, Lenaud Hughes wrote:
>
>> I came across an article by Joel Spolsky
>> spelling out the deficiencies of what he referred to as  the "Java
>> school" student. That article led me to a Paul Graham article  which led
>> me to a "How to be a Hacker" article which led me to Linux.
>> So at this point in my "career"; I'm not too worried about whether my
>> focus will be on a commercially-viable distro or otherwise. I more
>> concerned with just "digging in" and learning as much as I can. I'm sure
>> once I start learning I'll be able to determine whether I need to stick
>> with my first choice or change course.
>> Thanks again for everyone's assistance.
>>                         - Lenaud

That's really exciting!  I didn't have resources like that when I fell
into programming back in the day.  But then I didn't have floppy
drives yet either.  :)

Derek gave some great advice.  I have a few additional comments.
(Okay, a lot of comments.)

> My suggestion as a former professional Linux instructor is to try the
> big three distros (whatever they should be)[1]. Then find the one you
> like the best and stick with it. Use Linux exclusively. If you have
> issues trying to accomplish something look for help from google, the
> mailing list, IRC etc.

My opinion is, that as a budding programmer, you should learn more
than one operating system and not use a particular one exclusively.
Just the differences between BSD and Linux can be pretty significant
if you happen get into low-level programming.  That said, I have been
using Linux as my primary OS for over 15 years so it's definitely a
usable programming platform.  If you want to deploy software to Linux
systems, you'll really want to learn both the RPM and apt package
management systems, especially their dependency management aspects.

>  * grow a thick skin -- This is one that I wish I didn't have to say,
> but it sometimes occurs that some of the more technical people can get
> burnt out about people asking the simple questions over and over.
> Sometimes they may respond a little brusquely.  Don't take it
> personally. You'll find if you stick around, those brusque folks have
> the most war scars and are *EXTREMELY* helpful in the more dire of pinches.

This was very well-said and I think is surprisingly important.  Many
old-timers like me can be very harsh, even unintentionally but more
often out of frustration or even just lack of social graces.  I know
I've been guilty of it many times.  In most cases, when folks like me
do that there are underlying good intentions, even if they don't show
through.  Rarely does anyone say "RTFM" out of spite -- they want you
to be self-reliant.

>  * learn to RTFM (read the F#@$^ing manual) -- You would be amazed how
> much info is already available in your Linux distro, you just have to
> know where to find it.  If you know what command to run, but not how to
> run it try this: "man <COMMAND>".

Understanding the "man" document layout is very important when you do
low-level programming, and it's helpful with scriptology and commands
as well.  I remember finding the layout a bit confusing when I first
started using it, but there is an underlying logic to how it's
presented.  Nowadays I first go to google though, even for specific
API questions.  In some cases, you'll need to use other tools like the
"info" command to read alternate types of documentation.

>  * don't be afraid to make mistakes -- Linux can be scary (much less so
> in recent years) , there are some commands which can quickly cause
> irreparable damage.

Nowadays it's pretty easy to set up a "sandbox" in a VM (or similar)
to protect yourself against yourself in these scenarios. ;)  Learning
how the various privilege subsystems work also pays off in this area,
and often yields useful results for programming as well.

>  * enjoy the journey --  Relax, enjoy your new freedom, new friends,
> and powerful tools. Find a niche. Play with a new programming language,
> open source projects, etc. Look for Linux blogs. Go to a Linux
> conference (Is Atlanta Linux Fest happening this year?). Have fun.

Find a programming language that makes sense to you and learn it well.
 It doesn't have to be one of the mainstream languages.  Like Spolsky
et al have certainly said, learn *many* programming languages.  Each
one has some kind of distinct lesson hidden in it; even if you don't
learn that lesson it's still useful to try for different perspectives.

Also, start slowly.  Your definition of slow will likely be different
from mine, but what I mainly mean is don't get in too deep or stuck in
a hole too soon.  Walk away from a problem if you need to, even if
it's just for a little while.  Focus on what's satisfying about the
experience, and try to automate away the rest.  :)

> --
> Derek Carter
> aka goozbach
>
> [1]http://distrowatch.com/dwres.php?resource=major

-- 
Björn Gustafsson