Fog Creek Software
Discussion Board




"Learning Curve"

When I'm learning something new, I don't think I have problems with shallow or steep learning curves - in fact, awareness of those generally only seems to come after the fact.

What REALLY frustrates me is the "tangle of string" that I face when starting something new. It's not that I don't want to read a book or do some research, but I don't even know WHERE TO START.

Take Flash for example - if you open Flash and try to build a simple animation you will quickly become homicidal. On the other hand, if you take the time to work through some decent tutorials (and there are a LOT of Flash tutorials out there), then you'll come up to speed fairly quickly and start learning what questions to ask.

Ditto on Linux, WordPerfect 5.1 ("It's just a freaking grey screen - NOW what do I do?), Access 2.0, etc, etc.

I don't think I have a question, other than "would 'tangle of string' be a better term than 'steep/shallow learning curve', or is it just me?"

Philo

Philo
Monday, June 30, 2003

hi philo,

I (still) think of it as a 'steep' learning curve rather than a shallow one.
The way I see it, something with a 'steep' learning curve is something that, when you learn fact 1, you suddenly realise that you _also_ have to learn about facts 2,3,4,5,6,7,8 before you can go any further.
...and similaraly, once you learn fact 2, facts 9,10,11,12,13,14,15,15 suddenly become important.

thus for me products that have a 'steep' learning curve are products for whom the information required _grows_ quickly as you learn it.

maybe with the y axis showing 'information required', and the x axis 'skill level'

FullNameRequired
Monday, June 30, 2003

Ignoring the semantics of the term "learning curve" which is a tangle of thorns that's really not worth quibbling over, I think Philo makes some good points.

I find that the absolute best way to learn something is through interaction... with people who know what they're doing.

Like being a musician, you become really motivated to learn when you start jamming with people, and they show you simple things no book could teach you.

What's a good term for "extremely frustrating without a guide" lost in the dark?

I got one: Banging your head against the wall until you're shown the door.


Monday, June 30, 2003

My 4 year old calls it 'Brain Fuzz'.

Our team of programmer
Monday, June 30, 2003

Well put Philo.

That's why the START button was the best thing M$ ever invented.

Entrepreneur
Monday, June 30, 2003

Also, that's why working "Hello world" examples are so wonderful. For example, to learn CORBA, I started off running the sample programs in the Sun tutorial. Then I twiddled those examples, a few lines at a time, until I had integrated CORBA into my main code base.

In contrast, documentation of anything complicated without self-contained clear examples is infuriating.

Julian
Monday, June 30, 2003

It seems like with the stuff that appears to be intimidating at first the best thing is to start learning and using few little things here and there until there is enough critical mass of knowledge to undertake a larger effort. It is very important to support "momentum".
Trying to do something big immediately will lead to incredible frustration due to the lack of knowledge of steps 1,3-6,8-15,18-26, etc. The pain seems to lead to a significant setback. Shooting for instant gratification is both fun and productive.
I think there was some research showing that when students could get a quick and dirty implementation running fast and then improve it piece by piece they got a lot farther than those who tried to take everything into account at first and then started coding things correctly.

Mr Curiousity
Monday, June 30, 2003

The reasons for that Philo:

1.) You don't know C++
2.) You use VB (HA!)
3.) You were unable to sucessfully complete the CAMEL Project

:-)

Prakash S
Tuesday, July 01, 2003

"I think there was some research showing that when students could get a quick and dirty implementation running fast and then improve it piece by piece they got a lot farther than those who tried to take everything into account at first and then started coding things correctly."

Do you remember where you saw this study? I love to look at it.

I'm definitely a "take everything into account at first" type of person. I've recognized this fact lately and decided to change my habits. Not only does it slow me down at times, but it gets expensive. When I decide I want to learn something new, I have a tendency to go buy a book on it, when an on-line tutorial would probably do. If I switched my habit from programming to crack I'd save hundreds of dollars per year.

Nick
Tuesday, July 01, 2003

> I love to look at it.

Me too. I've heard this a dozen times and I'd love to see the original work.


Tuesday, July 01, 2003

> I think there was some research...

I ain't seen the research either, but isn't this what you'd expect:

A student who learns a bit, practices it and absorbs it, then repeats, is surely going to have an easier time than one who has to understand everything before they get any practise.

What would be more interesting would be who produced the better result in the end assuming it's all one project. 

The incremental learn might have bodged bits - that he didn't realize were bodged at the time because of insufficient knowledge - that he's either going to have live with or later go back and change (remind you of any real used-in-the-field programming projects??? of course not, every programmer I know studies a new tech for 6-12 months with lots of practice, before using it in the real world :-))

S. Tanna
Tuesday, July 01, 2003

I think this is it:

"Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality in the long run. We practice this technique in 6.916, Software Engineering for Web Applications, our course at MIT. Each student builds five database-backed Web applications during the 13-week semester. The first few that they build, during the course of the problem sets, are not necessarily elegant or optimal, but by the end of the semester they've become remarkably proficient, especially when you consider that each student is taking three or four other classes. "

http://philip.greenspun.com/ancient-history/managing-software-engineers.html

Matthew Lock
Tuesday, July 01, 2003


A few months back, I got off my horse of pride and learned vi.

Now, I'm amazed that I ever lived without it.  vi  (and vim) rocks.  Lesson learned: "If it seems intimidating, and lots of people are making fun of it rather than humbly learning it ... learn it anyway."

regards,

Matt H.
Tuesday, July 01, 2003

Some years ago I learned vi, or at least the key points.  Not particularly thru choice - but simply have the need to modify a text or source file on Unix. Sorry I never saw the appeal, it was truly horrid.  You had this super fast RISC machine, and there you are in this editor which scrolls like VT52 on a 1200 baud modem, and doesn't even work with the cursor keys right.

S. Tanna
Tuesday, July 01, 2003

Sliding the conversation a bit, getting an "implementation running fast" is a huge deal for opensource software developers. One aspect of a steep learning curve not mentioned yet is the choice you often have to ditch the software entirely in favor of something else with a shallower curve.

For instance, log4j [1] is fairly easy to get up and running. Not quite as easy as using System.out() statements for debugging, but the immediate power you gain, even from the default installation, makes it worthwhile. You only need to grasp a few simple concepts to use it and there are plenty of examples in the docs (key!).

Once you've been using it for a while you realize how easy it is to modify and the flexiibility it gives you. You may not realize the value of this payoff when you first started using the software, but its low barrier to entry made it possible to discover.

One thing opensource software generally needs to work on is the out-of-box experience. If I can't grok how/why something works the way it does in a half-hour or so, or I can't get it up and running in that time, I'm very likely to ditch it unless presented with compelling evidence, like lots of trusted bloggers praising it.

Since opensource developers generally use opensource software for their work it always amazes me they forget this lesson for their own projects. Although I suppose it's simply that everything (including the benefits) seems obvious to you after working on the project for a while so you don't bother explaining it, or make lots of assumptions in your docs. Or you place a higher value on implementing features ("features are fun!") versus telling people what your system does.

[1] http://jakarta.apache.org/log4j/docs/index.html

Chris Winters
Tuesday, July 01, 2003

The whole process of learning a new environment is rather interesting.

I mean, I remember when I was trying to learn a new programming language, the FIRST thing I would wan to learn is a for next loop

For i = 1 to 10
  Print i
Next i

When I jumped into learning Pascal, or VB, or even c++,  the first thing I would learn is how to write that loop.

The next question would be how to read a standard text file.

The same approached works very well then trying to learn a new database environment.

Things like:
    
Standard code to open a table and loop through the records.

Once you can write a loop, and “process” some records, you have learned a lot.

I have often thought that a book to learn new language should be setup with :

Here is a loop

Here is a loop to read a text file

All those little examples gets one up to speed read fast.

Of course, then I hit a system lick Pick. Pick was complete different. There was NO End of File concept in the system. There was no close file command (nor does one need to close a file, and further, closing a file don’t make much sense anyway). There is NO such thing as sequential file access either There is also no tree directory structure either.  Everything in the whole system was a string.

Hence, the problem is that we tend to go into a system with a mental model of what we learned from the past.

While on this topic of command line, all my pick experience was green screen. Pick has a ok command line environment. The script and command line could be extended very well. All of the programming environment supported command line stuff. It was common to write a new command that took parameters.


In other words, I don’t mind typing in a command. Further, most systems have a decent command history, or “command” stack that can be searched/reviewed. The command history in Pick was fully searchable at the command prompt.

Command lines with history are rather nice, since the last few things  you just did are likely needed to be repeated a few times for the task you are working on. It is a very nice way to work.

However, there is one terrible weak spot in command lines that I dont like:

    Files and path names.

I hate typing in file names. A person should NOT have to type in file names anymore.

In defense in windows, I don’t use the mouse to navigate much through folders anyway. (I use the keyboard).


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Tuesday, July 01, 2003

Uh? vi and cursor keys. I just used to play a lot of Larn and burned HJKL into my skull. I never used the cursor keys as the command prompt never worked right. I used to use vi when I swapped around unix boxes a lot, since it was always available, rule one was always never use the cursor keys. Sadly I've now forgotten most of it, but I'm sure it would come flowing back, just like wordstar does when I use a CP/M box.

Peter Ibbotson
Tuesday, July 01, 2003

*  Recent Topics

*  Fog Creek Home