Re: On motivating a Ruby nubie

On 4/14/05, Chris Pine <[e-mail]> wrote:
> 
> UNLESS (I am fervently hoping) you happen to know that your weird
> conversion program is in fact an integral part of a webserver/blog
> program you have been told you are writing.  You don't know which
> part, but you've been told that at some point near the end of the
> book, all of the pieces will come together and *poof*!  A big, cool
> program.

Faith isn't so good with someone who's just starting out.  Everyone
knows that eventually it'll all come together.. and yet nobody trusts
that.

The best thing to do in life is to approach big issues one step at a
time.  Sure there is the occasional pecking at a topic from
different angles, and there is some charging in and tackling huge
things.. but the best overall skill to learn in my opinion is
encapsulating
problems and approaching one at a time without being overwhelmed.  I'm
just not quite sure yet how I should apply this to learning ruby.  =)

What popped into my mind with your description is the idea of painting
by numbers.  I think this should be applied in a tutorial sense.
Painting by numbers is approaching specific problems with specific
solutions while overall keeping in mind the end-goal.  Each small
problem,
each lesson, each bite-sized chunk is one perfectly coloured area in
the whole picture.  The *real* trick for the person designing that
structure is to be able to communicate to the painter the whole picture.

So you would need to take your completed project, and work it
backwards.. breaking it up into pieces and arranging them in order of
complexity and relatedness and all that easily-said but
horrifically-difficult stuff.  Somehow it would have to be arranged in
order of
"shade".. related colours.. so that the student is provided things in
a more-or-less linear fashion.. they are building skills on top of
skills.. or building complexity into their earlier and simpler code.

The student's perspective is that they are given one problem at a
time, they are learning one thing at a time.. and as they progress
they are
slowly beginning to realise the interrelatedness of one problem to the
next to the next.  At one point a good student should be able to
predict the use of the tools they are being shown.

All throughout all of this mess, somehow the student needs to have a
greater picture reinforced.  When working on a puzzle, or a
paint-by-numbers picture, the person has a kind of reference always
available, assuring them that yes they've completed a part of the
whole,
and that part goes there.. and they are now working on the next part
over here.. etc.  This is the motivation necessary for a truly
engaging
tutorial.


> (My currently problem:  being told to write the parts is one thing.
> Figuring out what parts need to be written is something else
> *entirely*.  How do you teach this sort of design, or is this even in
> the scope of a beginner's book on programming?)

There are a few schools of thought as far as the process of learning
goes.  There are more than this list, but I'll just point out some
stuff
I found obvious just now when thinking about it.

* A teacher knows all and the student should model themselves after
the teacher's abilities.
* A student should learn from the mistakes of others.
* A student should explore on their own whenever inspired to do so.

The middle ground is to get a good introduction to concepts like best
practices, common problems, simple examples and form a basic set of
tools to work with.  This should be the student's first priority and
should be addressed a good intro to programming.

All of the philosophies and strangeness just does not apply to someone
who is new to programming.  Telling them that there is really no such
thing as a best practice will scare the hell out of them.  Still, it's
good to say things like "we're going to approach this problem with a
simple common solution.. there are always different ways to solve one
problem, but let's keep it simple"

Ok, so the good perspective is that the student should have their
goals structured and still understand the greater, or more whole value
of
the skills.  They should be given specific problems to solve a
specific way but they also need to learn to be creative.  So they also
need to
be provided a workbook of things to do their own way.

We've all seen this with existing tutorials.  I think that the
"workbook" side of things needs to be expanded a little.. enforced
some more.
I have found more value in my experimenting with the tools I've been
shown than with any other learning resource.  I think most would agree
that skill is fueled internally.. anyone who is good at anything is
that way because of a fire they stoke themselves.


--

On 4/14/05, Paul Hanchett <[e-mail]> wrote:
> Sy wrote:
> 
> Hey Syeed--  Welcome to the fray!  ;-)

Dammit, I've been found out!  ;)


> Find a (small) project to do on your own and begin to write the code.
> Make it simple to start.  I began by rewriting the coWiki text parser in
> ruby.

Holy crap man.. I didn't know you were a rubyist.  And on this mailing
list.  And working on stuff like that.  Small world.


For the audience: Paul recently took the maintainer role for coWiki, a
wiki which I have a fairly long and strong love/hate relationship
with.. which had I the skills, I would have written myself, but
"better" (using my opinions, solving my problems), and in Ruby.  =)


> I started by using SciTE for it's ability to easily run the code I'm
> editing.  But I think I'm going to spend some more effort on working
> doing the same with FreeRIDE, as it has more bells and whistles.  ;-)
> jEdit is also a choice.  I don't like how long it takes to start
> FreeRIDE and jEdit, SciTE is very quick and seems to understand about
> many languages-- It will run PHP scripts, if the computer is set up for it!

Thanks for jogging my memory.. I need to go through some
tools/environment-related options.


--

On 4/14/05, Osuka Adartse <[e-mail]> wrote:

> ...keep wishing, keep wanting , keep
> coding, remember to congratulate yourself everytime you succed, and try
> harder when not(but take a rest,get away to gain a better perspective,
> heck ask for help here).

Definitely there is concensus on the spark of inspiration which a
person finds within themselves, and on working on problems close to
onesself.  Starting small is another good point.

On the note of achieving.. I think also that a more public database is
an incentive for me.. because sharing is a motivator.


--

On 4/14/05, Dave Burt <[e-mail]> wrote:
> "Sy" <[e-mail]> wrote:
> >
> > of note, I want to make a life manager
> > -- a  to do list, with requirements and such which also acts like a
> > mind mapper, a wiki, etc.
> 
> Pimki?
> http://pimki.rubyforge.org/
> 
> If you're set on making your own, it may well be worth looking into the guts
> of this to see how it runs and/or hacking features you want on top of it.

I saw pimki but haven't tried it yet.  I'm pretty sure that I would
end up needing to make my own solution, but definitely peeking inside
the
code of other projects with end up on my list.  I don't think I'll
tackle this type of project anytime soon, but the first thing I'd do
before beginning a big thing is to research other approaches (even via
other tools) to learn how other people's UIs work, and learn of the
various other opinions on things.


--

On 4/14/05, Assaph Mehr <[e-mail]> wrote:
> 
> If you're interested in the guts, Pimki is an Instiki-Wiki base plus
> general PIM features. It's currently being updated to the new Instiki
> (modern rails based), and will hopefully be released soon -- with more
> features -- as Pimki2.
> 
> Maybe not the greatest source of clean software in its current state,
> but I'll be happy to answer any question you may have, and add to the
> features list (developed in open source time - i.e. two hours past
> midnight per day :)

Here's what I know about myself so far:

* I have a bad memory

* I am organized (necessary due to my bad memory)

* I learn easily

* I like to experiment.

* I forget easily (if unused, my skills evapourate.. leaving ineffable
"portable skills")

* The only thing truly saving my learning and experimenting efforts is
my organization.

* I work well with others (willing to listen, wanting to learn,
appreciating opinion)

* I write "too much".  I like to discuss angles, get opinions and
understand a larger picture.  This makes threads go off into wild
tangents
and all kinds of fun stuff.  I'm getting much better by not repeating
the same argument over and over.. heh.

* I don't colour in the lines (I go into tangents easily)

* I am strangely opinionated and desire to see my problems solved.


So this means that I am an excellent team member, but motivated
towards my own goals.  I am an unherdable cat.  I would desire to help
with
project but would only be motivated while the project direction meets
my needs.  I would go off into tangents because my opinion would have
me work on problems of interest as opposed to team goals.  I would
always be driven to do things myself, and yet I wouldn't want to
manage a
project.

So looking at someone else's code would always have me want to do it
all myself.. and patching, while a good idea, would always be
secondary
to my redoing the entire project myself.  Actually.. I think I'd be
more interested in forking someone else's work and fixing it up myself
than helping fix that project.  I tend to see things in terms of "tool
x works, but feature y doesn't work how I'd do it, or feature z is
missing.  This is probably a bad wrinkle of a habit which I'll have to
iron out.  I should prefer to patch rather than fork.