[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Adopt-a-newbie? Based on actual experience.

Eivind Eklund

2/16/2007 4:11:00 PM

On 2/14/07, SonOfLilit <sonoflilit@gmail.com> wrote:
> What do you think? Would you consider it a good idea? Would you volunteer?
> Is anyone up for infrastructure (preferrably on ruby-lang.org, though
> anywhere is good)?

I'll volunteer; areas of expertise is advanced pure Ruby hackery, and
generic Unix experience. I'm a former kernel hacker on FreeBSD with
>20 years of programming experience, about 10 years of web/database
experience, about 4 years of Ruby experience, and I used to work
professionally with Ruby (though I don't at the moment.)

I can help with generic program design and use of Ruby; I do not
program Rails, nor have I worked with most of the special modules for
Ruby lately, just general Ruby programming (including use of
Test::Unit).

If it sounds useful, just throw me questions.

Eivind.
8 Answers

Robert Dober

2/16/2007 6:23:00 PM

0

Premises:
(1) I believe that the list is the best way to teach.
(2) I know that I am a bad teacher (I love to teach of course).
(3) I understand that some newbies are afraid on posting even on the
friendliest ML of the world ruby-talk IMHO.

Conclusion:
Count me in but only if you are willing to accept, that
(1) I will ignore your mail if tired/overbooked or not interested.
(2) I will give strange answers
(3) I will act as a proxy to the list nobody will ever know who asked
the stupid question. <As a matter of fact I can now ask stupid
questions for free:)>

Cheers
Robert

--
We have not succeeded in answering all of our questions.
In fact, in some ways, we are more confused than ever.
But we feel we are confused on a higher level and about more important things.
-Anonymous

Edwin Fine

2/16/2007 7:04:00 PM

0

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.

Newbies should, in their email or forum post, clearly describe the
problem, and explain what they did, prior to asking for help, to solve
the problem. This will give the ones who are being asked the question
enough information to reduce or eliminate the need to ask the newbie
follow-up questions before being able to answer.

Although some people find the content at the following link to be
objectionable and rude, it does cut to the heart of the matter and is
worthwhile reading for all newbies:

http://www.catb.org/~esr/faqs/smart-ques...

If they agree to adhere to the above conduct, I will volunteer to take
on a couple of newbies. This is dependent on time and workload, so
patience is a virtue; I may not be able to answer instantly. It does not
mean I am ignoring you.

My background is that I have been developing software for an
embarrassingly long time, mostly in C++ and Java, on various platforms.
I use Ruby on a daily basis to automate Linux- and Unix-based tasks such
as performance monitoring, graphing, data analysis, and as a replacement
for shell scripting when possible. I provided some Ruby extension code
for the ruby-informix and RubyWMQ projects. I also use Ruby at home on
Ubuntu Edgy x86_64; the last significant thing I did was reorganize my
MP3 collection's directory structure by artist and album, using the ID3
tags. I have been using Ruby for about 18 months, so IANARG (I am not a
Ruby Guru), but I have pretty much read all the books and manuals and
written a fair amount of stuff. I am a systems-type developer, so GUI
questions are not a great idea. I also don't know Rails (yet).

Finally, I don't think it is a good idea to post email addresses and
personal contact details on this or any forum. I would suggest using the
email links provided by this forum to contact me with your details.

Best regards,
Edwin Fine

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

Rubén Medellín

2/18/2007 1:32:00 AM

0

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

SonOfLilit

2/18/2007 2:35:00 AM

0

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


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

Edwin Fine

2/18/2007 8:57:00 AM

0

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

"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/...)
[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-27411...).

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

SonOfLilit

2/18/2007 11:18:00 AM

0

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 :)
> 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 :)
>
> "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/...)
> [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-27411...).
>
> --
> Posted via http://www.ruby-....
>
>

+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

SonOfLilit

2/18/2007 11:25:00 PM

0

We have a /temporary/ home:

http://rubymentor.rubyforge.org/wiki/wiki.p...


Please take a moment to make a minor contribution to the
presentativeness of this page :-)



Also, coordination moves to the wiki (also I'd gladly help with
whatever, so you might as well mail me instead).

Aur Saraf

SonOfLilit

2/19/2007 11:13:00 AM

0

Quoting Peter Szinek:
"Hello Aur,

Yeah, I think we are really doing fine. We wrote nearly 10 mails
already, and since my wife happens to be a Ruby newbie too, I just set
up a mailing list for the tree of us and I think everybody is enjoying
the whole thing a lot.

Thanks for the great idea! I hope the others are doing well, too.

Shalom,

Peter"


I must say I'm proud.

I also like the idea of working in groups of three. Why? Because three
people generate so little traffic that one can easily follow it
without feeling any burden, and listening to the problems of one
fellow newbie and their solutions can advance one a lot. A group of
three would also still feel personal, unlike a ML.

It's the same reason I subscribe to many low-traffic blogs but almost
never to high traffic ones. I don't have time for a whole lot of
traffic (e.g. reading everything in the ruby mailing list) but I can
afford reading a short post every two weeks that would teach me
something nifty.

This should be handled, however, by the mentors, if and when they
decide they want to do it this way. There's no need, currently, for
infrastructure to handle this.


Aur