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

+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