Adopt-a-newbie? Based on actual experience

ruby-talk
41

Edwin Fine wrote:

First, *my* definition of "newbie" just for this post:

A person who is generally inexperienced in computer programming, and
specifically inexperienced in Ruby programming.

Therefore, when mentioning newbies in this post, I do not refer to
people who are already adept at programming in another language but just
don't know Ruby. I believe most of such people would not hesitate to
post to a forum, and would not really want or need a mentor. They would
also hopefully know how to ask questions in a clear way.

I mentor developers as part of my job. Based on experience, I would say
that newbies as defined above should execute the following algorithm
(which contains polite versions of RTFM and STFW) to get maximum benefit
from a mentor:

newbie.read_the_manual or
newbie.search_the_web or
newbie.read_ruby_books or
newbie.ask_mentor or
newbie.post_to_ruby_forum # Last resort

It is unfortunately not rare to encounter people who will not exhaust
all other self-help possibilities before asking others for help. I will
not opine on why this is so. However, IMHO, help is given freely and
happily when the helpee has demonstrated sufficient gumption, and
consideration for other people's time, to try to find the solution using
the above algorithm.

That's my point: for specific questions a newbie should exhaust as many
possibilities of solving a problem before asking to a mentor. However,
for the learning process of any people, a good technique is to learn
from other people's problems, hence the communities. I believe in
collaborative learning.

I agree with Aur, it can be possible to do this system and benefit the
community by doing it an open process, with browsable search and so
-which yields to a forum-. Or, extending the process and adopt a newbie
for a long time, would better make a course or a tutorial.

In short, I can see the benefits of this by changing the learning
process of the newbie in question. However, it would hurt the community
learning process. As a shy newbie myself, I can say I've learnt a lot if
things -that are not in any manual or book- by searching and posting,
and more important, by looking at other people's learning processes.

Ruben.

···

--
Posted via http://www.ruby-forum.com/\.

42

I agree very much with the effectiveness of such study groups and
would love to join such a thing if it existed, but as I said -
organizing such a thing that would actually pull off is hard.

1:1 is easy - there are just two people involved.

So I did what I COULD do :slight_smile:

Aur

···

On 2/19/07, Chad Perrin <perrin@apotheon.com> wrote:

On Mon, Feb 19, 2007 at 08:25:11PM +0900, Mark Woodward wrote:
>
> 2. Have some (progressively harder) newbie quizzes on RubyQuiz. ie have a
> series of quizzes that brings the (semi) newbie up to the level of the
> quizzes that are there now.

I'd love to see something like that happen. My first brush with
RubyQuiz was frustrating because I wasn't anywhere near familiar enough
with the language to make heads or tails of the quizzes -- despite the
fact that a bunch of quizzes would be an excellent way to build skill
quickly for a newbie.

>
> 3. I remember a while ago, although I can't remember the site, someone was
> organising a series of 'on-line lectures' from the 'Rute User's Tutorial
> and Exposition'. Something along the lines of:
> "In 3 weeks time we're going to start studying each chapter over the
> course of a week. During the first week we'll study 'Computing Sub-basics'
> the second week 'Basic Commands', wk7 'Shell Scripting' etc
> Again, could a small group of newbies under the watchful eye of a Mentor
> do a similar thing with the 'Pickaxe' for eg?

That's . . . almost ironic. I rejoined the ruby-talk list today after a
long hiatus (it's too high-traffic for me to stay subscribed for more
than a few months at a time) specifically because I started putting
something similar together. The idea, however, is not to organize Ruby
newbie groups, but to get a bunch of people interested in programming
languages and similar subjects to benefit from a sort of synergistic
community learning environment for one subject after another. The first
such learning project for this putative study group will be the Ruby
programming language, using one of the several excellent online Ruby
books. Next . . . probably some other programming language, depending
on what the participants in general want to do. We might hit Rails or
another Ruby book, though, for all I know.

I think a "study group" model is one of the most effective means of
learning, when people are actually interested in the subject matter.
While mentors are nice, I don't think they're really necessary -- with a
small group of interested people working together and using each other
as resources, the group becomes the "mentor". This helps keep the
learning process honest (nobody's going to be able to really use a
mentor as a crutch when the "mentor" is a bunch of similarly skilled
people who will also be seeking that person's help), and ensures that
people can come to someone when stuck without feeling like he or she is
imposing on an expert with better things to do. Rather than feeling
impeded by an authority-figure relationship, peers can interact and
figure things out together. That's the theory, anyway.

As such, it occurs to me that maybe what's needed is merely a study
group connection service of some kind, not a formal mentoring program.
Mentoring, I think, would be a far more appropriate system for
professional training than enthusiast autodidactic efforts (which means
that mentoring should be going on in the workplace, and study groups at
home or in coffee shops or online, or whatever).

At least, that's how it seems to me. I'll let you all know how well it
works for the group I've decided to draw together, and how much
mentoring I end up doing with them. (I'm sorta like a re-virgin here,
since I hadn't used Ruby enough for it to really sink in long-term
before setting it aside to do other things that needed doing -- so I'm
in the odd position of being both newbie and old hand at the same time.)
This could either prove me right or very, very wrong, by the time this
first study group project is done.

By the way . . . I also think that some familiarity between members of
such a group before it gets started is important. Otherwise, one might
as well just learn on one's own and ask questions on a mailing list.
The problems that arise there with ruby-talk are the main reason people
show up every few months asking if there's a newbie list (or, at least,
they did so the last two or three times I was subscribed -- and I doubt
that has changed in the interim), I think.

43

You don't need to be a pro.

I'm not.

The questions these... adopters... shoudl answer are those too simplistic to
have the whole list look at them, and giving a direction on implementing
something.

If there's interest, I have permision from Semantha to quote the discussion
that led to this. It was mainly showing her a lighter way to do something
she was going, IMHO, too heavy about. In the process she learned stuff about
YAML and that Hash is general (it turns out too many Hash examples are only
symbol => symbol).

Aur Saraf

···

On 2/14/07, Peter Szinek <peter@rubyrailways.com> wrote:

SonOfLilit wrote:
> Well, until further notice (and please read this thread to the end to
check
> that further notice wasn't issued), I will coordinate this personally.
>
> Any newbie who thinks he would benefit from such tutorship should mail
me
> and will probably get ME as a tutor.
>
> If I'm too swamped I'll ask Logan, and anyone else who volunteers, to
take
> some new ones (and redirect them by email).

I think this is a fabulous idea.

OK, I am also in if Logan will get swamped, too :slight_smile: I am far from being
a Ruby pro myself, but I guess I know enough (and still learning
everyday) to show the way to newbies...
I have learned a lot by answering some simple to semi-advanced questions
on the ML so I guess to have a 'personal newbie' could help a lot
(because of similar reasons)

We (the adopters) could maybe even share our experience and pull out the
most frequently asked questions and compile them into a 'newbie kickoff
FAQ' or something.

Cheers,
Peter
__
http://www.rubyrailways.com :: Ruby and Web2.0 blog
http://scrubyt.org :: Ruby web scraping framework
http://rubykitchensink.ca/ :: The indexed archive of all things Ruby.

44

+1

···

On 2/15/07, Pat Maddox <pergesu@gmail.com> wrote:

On 2/14/07, Jim Clark <diegoslice@gmail.com> wrote:
> As far as the adoptee taking undue advantage of the adopter's time and
> willingness to help, I've been on teams where we use Social Contracts to
> outline expectations and responsibilities from the start.

I hate the idea of a "social contract."

The obvious solution is mentor refactoring:

red: newbie asks question
green: mentor answers question
refactor: each person asks if they like the other guy, find someone
else if they don't

Simple, low stress, low obligation, no hard feelings

The whole point of this is to make it easy and comfortable to learn
the basics of Ruby. Contracts? Yuck!

Pat

p.s. I didn't read the contract, so I have no clue what it looks like.
But I can just about guarantee you that anything called a contract
and delivered in .doc is of no interest to me :slight_smile:

45

Pat Maddox wrote:

p.s. I didn't read the contract, so I have no clue what it looks like.
But I can just about guarantee you that anything called a contract
and delivered in .doc is of no interest to me :slight_smile:

Agreements/contracts don't have to be long, ugly or scary (disclosure: IANAL). I'll do some editing of the one I found but basically it boils down to this:

···

-----------------------------------------------------------------------
This agreement supports the mentoring partnership between:
Mentor:
Mentee:
Date:

Agreed objectives:
*
Mentee:* (What I hope to get from this mentoring partnership....)
*
Mentor**:* (I will provide support in the following ways - email, phone hours, etc. ............):

*The groundrules for our mentoring partnership are:* This should include your agreed responses to issues of confidentiality, time commitment, availability (when and where you can both be contacted), ...

*Reviewing partnership objectives:* (It is a good idea to review this agreement and your objectives at an appropriate time).

We will review this agreement on: _____________

-----------------------------------------------------------------------

If people agree that this is too time consuming or unnecessary, completely understood and I'll drop it. I just think that having potential matches get to know each other a little better and discuss some groundrules is not a bad thing.

-Jim

46

Say... Where do newbies look for help first?

A link here could do wonders.

47

Yours doesn't read your mind, either? The nerve... =)

(btw, thread taken offlist to discuss the pitiful excuse for progress on the
referenced project, or lack thereof.)

···

On 2/15/07, William Smith <wbsmith83@gmail.com> wrote:

Grr. Thats what I meant to do. Stupid non-mind reading computer.

--
Samantha

http://www.babygeek.org/

"Beware when the great God lets loose a thinker on this planet. Then all
things are at risk."
  --Ralph Waldo Emerson

48

I'd like to put myself up for adoption!.

Vincent Franco
Go Montessori
1757 Woodside Dr., Suite 201
Woodland, CA 95695
1.800.331.5147 (Toll-free from the US and Canada)
530.661.1968 (FAX)

Visit: www.montessorijobs.com

···

-----Original Message-----
From: SonOfLilit [mailto:sonoflilit@gmail.com]
Sent: Thursday, February 15, 2007 1:55 AM
To: ruby-talk ML
Subject: Re: Adopt-a-newbie? Based on actual experience.

Since I've been asked a lot, a few guidelines for mentors:

* When you receive an email asking if you're OK hooking up with a newbie,
you're just expected to wait until he asks something.
* It would be more advantageous, though, if you do send him an introductory
email and try and get to know him, his code and his purposes in learning
Ruby. From there you can spawn a discussion on the design of his code,
offering him better ways to do things.
* As important as it is to teach Ruby, it is important to teach both good
practices (from indentation through irb to testing) and how to find
information in the Ruby world (how to use documentation, when to ask on ml,
what's on rubyforge...)
* Don't just spill information. Wait for it to be exactly relevant.
* Think of this whole things like a discussion in a computer lab where the
programmer next to you asks you a question in a field you're better at...
The sort of discussion that also happens a lot at conferences.

Aur Saraf

if anyone has a good tip to add, feel free!

49

Just putting my two cents in... (or maybe a whole nickel, we'll see how
long-winded I get.)

I personally think that every newbie-mentor relationship is going to be
different. Different people have different ways of communicating. For me,
there are a couple of people I've found myself emailing at different points
over the last week or so. Of course I Google for things I need help on, but
if I have a program concept, or a thought about "would it be better to do
something like this, or like that... In this recipe (program) should I use
basil (MySql) or oregano (files as databases...)... " And then that
generates a discussion...

I haven't gotten to a stage yet where I'm saying, I'm stuck at place X --
how do I get out of here??? I'm sure I will at some stage, at which point,
I'll probably send that to the list... I tend to censor myself as I feel I
need to. (ie, while I know there are no stupid questions, I'd rather remain
silent and be thought a fool, than open my mouth, er move my fingers on the
keyboard, and remove all doubt.)

My # 1 rule for myself is not to take myself too seriously. All I know is
that I'm grateful for the few people who have reached out to me and offered
to let me tap their experience and wisdom as resources, and that I'm having
a blast learning new things. It really can't get much better than that.
(Okay, so deploying my first incredibly wonderful program would be better
than that, but ya'll know what I'm saying.) :slight_smile:

···

On 2/17/07, Ruben Medellin <chubas7@gmail.com> wrote:

That's my point: for specific questions a newbie should exhaust as many
possibilities of solving a problem before asking to a mentor. However,
for the learning process of any people, a good technique is to learn
from other people's problems, hence the communities. I believe in
collaborative learning.

I agree with Aur, it can be possible to do this system and benefit the
community by doing it an open process, with browsable search and so
-which yields to a forum-. Or, extending the process and adopt a newbie
for a long time, would better make a course or a tutorial.

In short, I can see the benefits of this by changing the learning
process of the newbie in question. However, it would hurt the community
learning process. As a shy newbie myself, I can say I've learnt a lot if
things -that are not in any manual or book- by searching and posting,
and more important, by looking at other people's learning processes.

Ruben.

--
Posted via http://www.ruby-forum.com/\.

--
Samantha

http://www.babygeek.org/

"Beware when the great God lets loose a thinker on this planet. Then all
things are at risk."
  --Ralph Waldo Emerson

50

I think exposing the dialogs between mentors and newbies is essential,
and if infrastructure doesn't exist, it hsould be done manually.

Personally, I'm going to edit my conversations with Semantha a bit and
publish them since they are such a great learning resource in my
opinion (they just contain far too much personal information as-is, so
major editing is required - I don't think many Ruby newbies are
interested in Jewish prayers :slight_smile: )

With these dialogs published, I don't think the community will be hurt.

There will just suddenly be a huge FAQ with the REALLY frequently
asked question, those too trivial and too abundant for an official
one, all answered until a real newbie approves and groks.

Besides, conversation is a great kind of teaching material, as anyone
who reads Creating Passionate Users (and everyone SHOULD! How much
resonance can begin with an article there) has read lately.

Aur

···

On 2/18/07, Ruben Medellin <chubas7@gmail.com> wrote:

Edwin Fine wrote:
> First, *my* definition of "newbie" just for this post:
>
> A person who is generally inexperienced in computer programming, and
> specifically inexperienced in Ruby programming.
>
> Therefore, when mentioning newbies in this post, I do not refer to
> people who are already adept at programming in another language but just
> don't know Ruby. I believe most of such people would not hesitate to
> post to a forum, and would not really want or need a mentor. They would
> also hopefully know how to ask questions in a clear way.
>
> I mentor developers as part of my job. Based on experience, I would say
> that newbies as defined above should execute the following algorithm
> (which contains polite versions of RTFM and STFW) to get maximum benefit
> from a mentor:
>
> newbie.read_the_manual or
> newbie.search_the_web or
> newbie.read_ruby_books or
> newbie.ask_mentor or
> newbie.post_to_ruby_forum # Last resort
>
> It is unfortunately not rare to encounter people who will not exhaust
> all other self-help possibilities before asking others for help. I will
> not opine on why this is so. However, IMHO, help is given freely and
> happily when the helpee has demonstrated sufficient gumption, and
> consideration for other people's time, to try to find the solution using
> the above algorithm.

That's my point: for specific questions a newbie should exhaust as many
possibilities of solving a problem before asking to a mentor. However,
for the learning process of any people, a good technique is to learn
from other people's problems, hence the communities. I believe in
collaborative learning.

I agree with Aur, it can be possible to do this system and benefit the
community by doing it an open process, with browsable search and so
-which yields to a forum-. Or, extending the process and adopt a newbie
for a long time, would better make a course or a tutorial.

In short, I can see the benefits of this by changing the learning
process of the newbie in question. However, it would hurt the community
learning process. As a shy newbie myself, I can say I've learnt a lot if
things -that are not in any manual or book- by searching and posting,
and more important, by looking at other people's learning processes.

Ruben.

--
Posted via http://www.ruby-forum.com/\.

51

Ruben Medellin wrote:

That's my point: for specific questions a newbie should exhaust as many
possibilities of solving a problem before asking to a mentor. However,
for the learning process of any people, a good technique is to learn
from other people's problems, hence the communities. I believe in
collaborative learning.

...

learning process. As a shy newbie myself, I can say I've learnt a lot if
things -that are not in any manual or book- by searching and posting,
and more important, by looking at other people's learning processes.

Ruben.

Ruben,

You make a very interesting point, and in doing so, expose a deficiency
in my thinking. I did not consider the different categories of learning
with respect to software development. If you will indulge me in a rather
long post, I would like to explore some ideas. I hope this isn't all
stating the obvious! Let's start by listing some of the many things that
we can learn about in the field of software development, in no
particular order:

* Object-oriented concepts
* Problem definition and analysis
* Software design
* Software implementation (coding)
* Testing (e.g. unit, integration, system)
* Software development process (e.g. agile, formal)
* Documentation
* Configuration management
* A specific programming language
* A specific operating system or environment

Many books have been written on each of the above topics. Clearly there
is a lot to learn. But what is the appropriate way to learn each of
these things? This is a critical question. Here are some of the ways of
learning to develop software that I can think of:

* Formal education
* Reading books, articles, forums, tutorials
* Doing it (designing, implementing, testing, and so on)
* Asking questions
* Reading existing code written by experts
* Working with an experienced person (mentorship)
* (Advanced) Reading poor quality code; learning what not to do

I'd like to venture a strong opinion here: there is no effective way to
learn abstract concepts such as analysis and design in a purely
theoretical manner.

First of all, a person has to have the innate capability to abstract; I
don't believe it can be taught. This is not to say that people incapable
of abstract thinking are unintelligent, only that they will never be
able to analyze and design software well, if at all.

Secondly, a person has to be able to solve problems. This requires a
combination of logical and intuitive thinking. I think problem solving
techniques can be taught, unlike the ability to abstract, but there
still needs to be a certain minimum level of logical reasoning to build
on.

Thirdly, a person needs to work with a good or great software developer,
preferably in an on the job capacity, and learn by watching the
"master", trying things out, making mistakes, and learning from them.
This is really an apprenticeship. For two great books on this topic, see
[1] and [2] below. I am sure that many people on this forum will have
read [2], which is co-authored by Dave Thomas of Pickaxe fame. Not
everybody will have this opportunity, which is why the online mentorship
concept in this thread is important.

The bottom line is that... I'm getting tired and need to wrap this up :slight_smile:
The bottom line is that one progresses from novice to expert in an
iterative way, using multiple learning techniques. Of these, I think the
most important are:

* To be "apprenticed" to a "master".
* To paraphrase Miyamoto Mushashi, to practice, practice, practice -
write as much software as you can.
* Read as much good stuff as you can get your hands on.

Thanks to those who read this far :slight_smile:

"I hear and I forget. I see and I remember. I do and I understand." -
Confucius
"This can only be understood by practice" - Miyamoto Musashi
"In theory, there is no difference between theory and practice; in
practice, there is." - Unattributed
"Good judgment comes from experience; experience comes from bad
judgment" - Unattributed

···

--------------
[1] Software Craftsmanship: The New Imperative, Pete McBreen
(http://www.amazon.com/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862\)
[2] The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt and
Dave Thomas
(http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=pd_bxgy_b_text_b/102-2741119-8695365\).

--
Posted via http://www.ruby-forum.com/\.

52

http://rubymentor.rubyforge.org/wiki/wiki.pl?AurSarafAndSamantha

This is an edited transcript of my discussions with Samantha this far.

They speak much better than anything I can write now both in favor of
the project and in attempting to explain what exactly it is and should
be done.

I recommend mentors who have spare time to read some part of it.

It's also a good read for newbies, in my opinion, also a bit of a
waste of time since it's so long.

Aur

53

Hmm.

I've just received private email from a volunteer, who is (self proclaimed)
good enough to cover the basics (which is great and what we need here), but
would also like it if someone would adopt /him/.

First, please send these mails to the list. That is what will generate
interest and hopefully turn this into more than an email-coordinated
project.

Second, when I think about it, I'd also be glad to be adopted (once Calculus
is over and I have time for my Ruby project again). Tutoring is something
that would work even better for those who know their stuff but aren't too
strong on code foo.

Would any of the Ruby masters on this list be interested in mentoring more
advanced users on their projects?

Here, by the way, I can think of perhaps demanding that those projects are
open-source and benefit the community (also I hope not, since mine isn't and
won't be for now).

Aur Saraf

···

On 2/14/07, SonOfLilit <sonoflilit@gmail.com> wrote:

You don't need to be a pro.

I'm not.

The questions these... adopters... shoudl answer are those too simplistic
to
have the whole list look at them, and giving a direction on implementing
something.

If there's interest, I have permision from Semantha to quote the
discussion
that led to this. It was mainly showing her a lighter way to do something
she was going, IMHO, too heavy about. In the process she learned stuff
about
YAML and that Hash is general (it turns out too many Hash examples are
only
symbol => symbol).

Aur Saraf

On 2/14/07, Peter Szinek <peter@rubyrailways.com> wrote:
>
> SonOfLilit wrote:
> > Well, until further notice (and please read this thread to the end to
> check
> > that further notice wasn't issued), I will coordinate this personally.
> >
> > Any newbie who thinks he would benefit from such tutorship should mail
> me
> > and will probably get ME as a tutor.
> >
> > If I'm too swamped I'll ask Logan, and anyone else who volunteers, to
> take
> > some new ones (and redirect them by email).
>
> I think this is a fabulous idea.
>
> OK, I am also in if Logan will get swamped, too :slight_smile: I am far from being
> a Ruby pro myself, but I guess I know enough (and still learning
> everyday) to show the way to newbies...
> I have learned a lot by answering some simple to semi-advanced questions
> on the ML so I guess to have a 'personal newbie' could help a lot
> (because of similar reasons)
>
> We (the adopters) could maybe even share our experience and pull out the
> most frequently asked questions and compile them into a 'newbie kickoff
> FAQ' or something.
>
> Cheers,
> Peter
> __
> http://www.rubyrailways.com :: Ruby and Web2.0 blog
> http://scrubyt.org :: Ruby web scraping framework
> http://rubykitchensink.ca/ :: The indexed archive of all things Ruby.
>

54

Well, I think such things should come AFTER they get to know each other, if
it is needed, on a personal basis.

In general, both give away free time interacting by email.

I think grown up people on this list don't really need such a phase before
every email they send.

If a certain case arises - handle as you will.

Just my thoughts, what do other people think?

Aur Saraf

···

On 2/15/07, Jim Clark <diegoslice@gmail.com> wrote:

Pat Maddox wrote:
> p.s. I didn't read the contract, so I have no clue what it looks like.
> But I can just about guarantee you that anything called a contract
> and delivered in .doc is of no interest to me :slight_smile:
>
Agreements/contracts don't have to be long, ugly or scary (disclosure:
IANAL). I'll do some editing of the one I found but basically it boils
down to this:

-----------------------------------------------------------------------
This agreement supports the mentoring partnership between:
Mentor:
Mentee:
Date:

Agreed objectives:
*
Mentee:* (What I hope to get from this mentoring partnership....)
*
Mentor**:* (I will provide support in the following ways - email, phone
hours, etc. ............):

*The groundrules for our mentoring partnership are:* This should include
your agreed responses to issues of confidentiality, time commitment,
availability (when and where you can both be contacted), ...

*Reviewing partnership objectives:* (It is a good idea to review this
agreement and your objectives at an appropriate time).

We will review this agreement on: _____________

-----------------------------------------------------------------------

If people agree that this is too time consuming or unnecessary,
completely understood and I'll drop it. I just think that having
potential matches get to know each other a little better and discuss
some groundrules is not a bad thing.

-Jim

55

Personally, I'm going to edit my conversations with Semantha a bit and
publish them since they are such a great learning resource in my
opinion (they just contain far too much personal information as-is, so
major editing is required - I don't think many Ruby newbies are
interested in Jewish prayers :slight_smile: )

Aur

HEYYYYYYYYYYYYY. (just kidding)

So, am I a Ruby Jew-bie, as opposed to just a Ruby Newbie??

I think you've sparked a great conversation and am looking forward to seeing
what comes forth from discussions between newbies and mentors.

···

On 2/17/07, SonOfLilit <sonoflilit@gmail.com> wrote:

--
Samantha

http://www.babygeek.org/

"Beware when the great God lets loose a thinker on this planet. Then all
things are at risk."
  --Ralph Waldo Emerson

56

+1000

In my first few years of learning to program I could recognize this.

I saw that there is some kind of conceptual gap between me and
"professional programmers" and looked everywhere for someone who would
accept me as some sort of apprentice. I event got my mom to hire a
software developer as a 1:1 teacher for me (it didn't quite work out,
and now I'm glad for it. To understand how much of a newbie I was, he
was a VB developer).

That is why I set this up - because some things CANNOT be learned
alone, others require genius to reinvent.

"The Pragmatic Programmer", which I've read, was an attempt to talk
about this thigns a bit, and it progressed me A LOT. Reading open
source code is another method, but it is far less accessible at the
beginning, because you don't understand why the programmer does things
the way he does.

For years, I had trouble following multi-file C programs, and even
more so C++ programs. Only after I forced myself to write a few it
became better.

Aur Saraf

···

On 2/18/07, Edwin Fine <efine145-nospam01@usa.net> wrote:

Ruben Medellin wrote:

> That's my point: for specific questions a newbie should exhaust as many
> possibilities of solving a problem before asking to a mentor. However,
> for the learning process of any people, a good technique is to learn
> from other people's problems, hence the communities. I believe in
> collaborative learning.
>
...
> learning process. As a shy newbie myself, I can say I've learnt a lot if
> things -that are not in any manual or book- by searching and posting,
> and more important, by looking at other people's learning processes.
>
> Ruben.

Ruben,

You make a very interesting point, and in doing so, expose a deficiency
in my thinking. I did not consider the different categories of learning
with respect to software development. If you will indulge me in a rather
long post, I would like to explore some ideas. I hope this isn't all
stating the obvious! Let's start by listing some of the many things that
we can learn about in the field of software development, in no
particular order:

* Object-oriented concepts
* Problem definition and analysis
* Software design
* Software implementation (coding)
* Testing (e.g. unit, integration, system)
* Software development process (e.g. agile, formal)
* Documentation
* Configuration management
* A specific programming language
* A specific operating system or environment

Many books have been written on each of the above topics. Clearly there
is a lot to learn. But what is the appropriate way to learn each of
these things? This is a critical question. Here are some of the ways of
learning to develop software that I can think of:

* Formal education
* Reading books, articles, forums, tutorials
* Doing it (designing, implementing, testing, and so on)
* Asking questions
* Reading existing code written by experts
* Working with an experienced person (mentorship)
* (Advanced) Reading poor quality code; learning what not to do

I'd like to venture a strong opinion here: there is no effective way to
learn abstract concepts such as analysis and design in a purely
theoretical manner.

First of all, a person has to have the innate capability to abstract; I
don't believe it can be taught. This is not to say that people incapable
of abstract thinking are unintelligent, only that they will never be
able to analyze and design software well, if at all.

Secondly, a person has to be able to solve problems. This requires a
combination of logical and intuitive thinking. I think problem solving
techniques can be taught, unlike the ability to abstract, but there
still needs to be a certain minimum level of logical reasoning to build
on.

Thirdly, a person needs to work with a good or great software developer,
preferably in an on the job capacity, and learn by watching the
"master", trying things out, making mistakes, and learning from them.
This is really an apprenticeship. For two great books on this topic, see
[1] and [2] below. I am sure that many people on this forum will have
read [2], which is co-authored by Dave Thomas of Pickaxe fame. Not
everybody will have this opportunity, which is why the online mentorship
concept in this thread is important.

The bottom line is that... I'm getting tired and need to wrap this up :slight_smile:
The bottom line is that one progresses from novice to expert in an
iterative way, using multiple learning techniques. Of these, I think the
most important are:

* To be "apprenticed" to a "master".
* To paraphrase Miyamoto Mushashi, to practice, practice, practice -
write as much software as you can.
* Read as much good stuff as you can get your hands on.

Thanks to those who read this far :slight_smile:

"I hear and I forget. I see and I remember. I do and I understand." -
Confucius
"This can only be understood by practice" - Miyamoto Musashi
"In theory, there is no difference between theory and practice; in
practice, there is." - Unattributed
"Good judgment comes from experience; experience comes from bad
judgment" - Unattributed

--------------
[1] Software Craftsmanship: The New Imperative, Pete McBreen
(http://www.amazon.com/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862\)
[2] The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt and
Dave Thomas
(http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=pd_bxgy_b_text_b/102-2741119-8695365\).

--
Posted via http://www.ruby-forum.com/\.

57

So in order to get set up with someone to help you ... message
SonOfLilit?
And if so, how do you private message on these boards?

···

--
Posted via http://www.ruby-forum.com/.

58

One of the downsides of a two-person chat, as opposed to asking a question here is that you don't get as much input. I'm not saying that makes the mentoring idea bad, but I do think it's something we want to keep in mind.

For example, in that transcript, Aur says:

"YAML is really like XML... You can, if you want, do whatever XML thing you wanted but in YAML syntax..."

I know the Ruby community is very pro YAML and really down on XML, but the fact remains that the have different purposes. XML is a markup language. It is for marking up content. YAML is a data description language. It's primarily used for serializing data into a human readable format. These are different purposes.

If you have trouble understanding the difference, try converting the home page of your web site into a reasonable YAML format. It's a good exercise.

I would likely favor XML as a format for my résumé, though that point is certainly debatable.

James Edward Gray II

···

On Feb 19, 2007, at 7:11 AM, SonOfLilit wrote:

http://rubymentor.rubyforge.org/wiki/wiki.pl?AurSarafAndSamantha

This is an edited transcript of my discussions with Samantha this far.

59

I like this movement and want to see it be successful, but I think swamping the list with a match-up service is the wrong idea. I believe it's time to consider providing an external where parties on both sides can express interest.

James Edward Gray II

···

On Feb 14, 2007, at 3:31 PM, SonOfLilit wrote:

First, please send these mails to the list. That is what will generate
interest and hopefully turn this into more than an email-coordinated
project.

60

Oh, by the way, in the future, could volunteers list their topics of
interest in short? Not a long exact enumeration, just something like:

"I work with numeric calculations and Rails and would be more helpful with
those." or "I do graphics with OpenGL and could help with that".

Especially Rails experience matters, since newbies tend to be separated to
pure rubyists and railsists.

···

On 2/15/07, SonOfLilit <sonoflilit@gmail.com> wrote:

Well, I think such things should come AFTER they get to know each other,
if
it is needed, on a personal basis.

In general, both give away free time interacting by email.

I think grown up people on this list don't really need such a phase before
every email they send.

If a certain case arises - handle as you will.

Just my thoughts, what do other people think?

Aur Saraf

On 2/15/07, Jim Clark <diegoslice@gmail.com> wrote:
>
> Pat Maddox wrote:
> > p.s. I didn't read the contract, so I have no clue what it looks like.
> > But I can just about guarantee you that anything called a contract
> > and delivered in .doc is of no interest to me :slight_smile:
> >
> Agreements/contracts don't have to be long, ugly or scary (disclosure:
> IANAL). I'll do some editing of the one I found but basically it boils
> down to this:
>
> -----------------------------------------------------------------------
> This agreement supports the mentoring partnership between:
> Mentor:
> Mentee:
> Date:
>
> Agreed objectives:
> *
> Mentee:* (What I hope to get from this mentoring partnership....)
> *
> Mentor**:* (I will provide support in the following ways - email, phone
> hours, etc. ............):
>
> *The groundrules for our mentoring partnership are:* This should include
> your agreed responses to issues of confidentiality, time commitment,
> availability (when and where you can both be contacted), ...
>
> *Reviewing partnership objectives:* (It is a good idea to review this
> agreement and your objectives at an appropriate time).
>
> We will review this agreement on: _____________
>
> -----------------------------------------------------------------------
>
> If people agree that this is too time consuming or unnecessary,
> completely understood and I'll drop it. I just think that having
> potential matches get to know each other a little better and discuss
> some groundrules is not a bad thing.
>
> -Jim
>