Knowledge or rate of learning?

Saw a great comment on JOS recently.

Its not what you know that matters its the rate you are learning

It links here which is a post by Eric Sink talking about several things, this post is about the rate, the next about responsibility.

I think in mainstream dev, the rate is probably key, but in Excel I don’t think things move quite as fast. A few of us are still trading mainly on our Excel 97 knowledge!

Personally I find in .net terms I struggle to keep up, but real world Excel is pretty consistent – eg very few people are on 2007. So I still don’t need to go through the pain of learning the silly ribbon. Yet those VS2008 numbers I found the other week seem to suggest the VS guys have already adopted the beta. I notice Beta 2 Vs2008 doesn’t have the ribbon – maybe they’ll put it RC1?

I would say the .net world is moving fast, C++ is a much more steady pace. I’m not really sure about Java? The new dynamic typed languages or scripting languages seem to be moving fast. Do you think stability is important? or is rapid change/improvement(?) better? (I prefer stability I reckon)

And what do you think about the rate of learning v knowledge thing?



8 Responses to “Knowledge or rate of learning?”

  1. Harlan Grove Says:

    Perhaps Excel Services, once it takes off, will shake up Excel development.

    It’s essential to continue learning, broadening your scope. It may not be directly applicable to your coding today, but at the very least it would allow you to see how other developers attack various tasks, and that could provide new and possibly better ways to attack spreadsheet tasks.

  2. Jon Peltier Says:

    Simon –

    “Its not what you know that matters its the rate you are learning.”

    My motto is:

    Its not what you know that matters but what you know how to find out.

    Harlan –

    The problem with Excel Services is that you neet to be an IT pro to set it up (i.e. Sharepoint Server etc.). There’s usually not much intersection between the Excel folks and the IT folks, so I think this will be a hard sell.

  3. Simon Says:

    Jon, good point – what about speed/ability to assimilate new info as a key factor?
    I find I can get an answer quicker from Google than people with less experience, just because I can interpret things quicker and filter out irrelevant stuff sooner.

  4. Ross Says:

    “Its not what you know that matters its the rate you are learning”

    Personally I think it’s a bit of a none statement. You want to both know a lot and learn quickly, the more you know the better (less is rarely better than more, although more is often not an advantage)
    Learning quick is always an advantage, but so long as you don’t fall behind the “new technology/methods” curve the effect will be small. – 2 things here, one you might choose to be behind the curve, second the curve may be lead/defined by different things, market place, technological demands, etc etc.

  5. Ross Says:

    Oh, and slow and steady for me all the way!

  6. Lord Says:

    Personally, rate of learning is far, far, more important because what one knows is almost always irrelevant to what one does next. The market however thinks only in terms of knowledge and does not want to pay anyone to learn anything. This is very short sighted and the reason business always complains about lack of skills. Skills are really obsolete by the time they are learned.

  7. Stephane Rodriguez Says:

    “rate of learning” and “moving market” rings to me as something that belongs to the fashion industry, not software.

    You’ve got to make a difference between fundamentals, and the rest. That’s why we have schools. I remember learning functional programming languages in an engineering school 15 years ago, and now that functional languages are all the craze because some people think that’s going to solve the multi-core concurrency efficiency execution problem, major vendors are coming with their own flavor of functional languages, with no fundamental differences between them. When you’ve learned the fundamentals, you don’t have to learn the constant stream of new stuff being marketed (which is only new on the surface of things), which can feel overwhelming at first sight. You can safely defer that until your next project when you need to use functional languages. After all, when functional languages are assimilated fundametally, putting it in practice with some very real developer environment is just a matter of writing the code itself. Compare it with people out there who have to understand the fundamentals *after* their project is started and the clock is already ticking. A whole world of difference.

  8. Jon Peltier Says:

    “Skills are really obsolete by the time they are learned.”

    No, skills are not obsolete, they just are not necessarily sufficient. However, the practice of developing skills improves the ability to learn new skills. Also, if you have developed a broad skill base, it’s easier to see multiple solutions when faced with a problem.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: