So what’s the problem?

First, try to look past that Bill skipped 30 years of research and experience in software engineering and stamps into it like a PHB-cliche, seemingly assuming his opinion is as valid as any research on the subject. That alone probably ticked off the defensive reaction in any software developer accidentally stumbling into the Harvard Business Review blog section.

The main misunderstanding is the assumption that there is only one type of talent. And both Taylor and a fair amount of the commenters makes this mistake and applies their experience with basic bell-curve measured skills onto a type of talent that is ruled by other laws.  Nassim Nicholas Taleb discusses this distinction in great detail in The Black Swan – the environments of “mediocristan” and “extremistan”. The first which you can understand using the bell curve and gaussian distribution, the latter where differences are of an order of magnitude and are qualitative or disruptive differences.

For example, in most manual labour or production line work, a practitioner can get good or even excellent, but mostly within a range that can be measured safely with standard deviations and the differences between average and excellent performance does not differ in it’s nature, but it’s output. Here throwing more people at the problem can solve it – maybe your top salesman makes ten sales a week while your average makes 4. Well, throw in 3 averages and you’re just as good. That’s not necessarily good economy or a good idea, but it can get you where you want.

In contrast, in the world of “extremistan”, a difference in skill can be of such a magnitude that it makes a qualitative difference. In the comment section of Taylor’s article, someone asks, “Would you want a Shakespeare or 100 Bill Taylor’s?”, and countless variations on the theme. And software engineering is that sort of talent. A “superstar developer” doesn’t necessarily a programming Shakespeare make, but he or she can make something a lesser qualified individual can never do, or do it so fast it makes the difference between staying in competition or not. Or just connect the dots and save the day.

Throw in the special problem of software engineering that putting one more person on a task tends to double the time it takes to solve it, and the effect is even larger.

But then, the Bill Taylor’s take their experiences with the “mediocristan” type of talent and applies it on the very different world of software engineering. It comes out, as is well pointed out in the comment section, as commoditization of something that can not be commoditized. Software development can’t be reduced to the number of lines written per day, in any meaningful way. Even business people who really, really want to think about it in that way, will still be wrong. It has been discussed and demonstrated countless times. The classic “The Mythical Man-Month” explains how you can’t just think of your software engineers as burger flippers.

When the original blog post received so much vitriol, it comes from every software engineer in the world’s experience with clueless managers who approach development in the Bill Taylor way. Today’s successful companies are ran in a different way, by Zuckerberg’s and Steve Jobs’ who are playing in a the-winner-takes-it-all world of the Internet. It doesn’t take that many, as long as you have the right people – Facebook has 2000 employees serving over 600 million users.

So what makes a super star developer?

I believe in the old truism that the difference between developers can be of the 100x magnitude – I actually think the Net Negative Production Programmer is a reality, so accordingly a top developer is infinitely better than the worst… However, unless you think the superstars have their skills handed down to them by divine intervention, something must have brought them to this. Here’s some points I believe are what makes up the super star:

• It’s knowing the codebase well. The superstar is often the guy who knows the codebase to the last semi-colon. It’s not about being the smartest guy in the room, but just knowing exactly where to hack in that little change, and that little change, and that little change, and that little change…. before lunch.

• It’s content knowledge. The superstar is the guy who also knows the content of what he is coding really well. If you’re making a chess bot, the developer who is also a chess grandmaster knows all the elements, the edge cases and the purpose of what he is trying to do. He will have a working prototype running while the developer without any chess background is still trying to understand all the implicit assumptions in the instructions he got from his Scrum Product Owner. I think this one is essential, and so often overlooked. Knowing the thing you work with, and working with what you find interesting is not only making development work into a whole other ballgame, it’s also does wonders for motivation.

• It’s situational. You can’t throw Linus Torvalds, Larry Wall or Bill Joy into your hack app shop and expect to have the next Angry Birds in a month. You need the right person and the right setting.

• It’s knowing programming well. The superstar developer doesn’t have to be a superstar in the inner working of his programming language – but he knows it well enough that it’s not in the way of him reaching his ultimate goal.

• It’s practice, practice, practice. Yeah exactly! No one is born into superstardom. This is written about a lot, and Malcolm Gladwell’s thesis of the 10.000 hours of practice rule really applies the software engineering too. One complicating factor with this point is, as I wrote about in accelerating your Perl learning, that most developers are on a lifelong learning mission anyways. They (we…) always look to learn something new, so what puts the superstar apart from the average? It’s not that easy to pick out, but in his article about the 10.000 hours of practice, Gladwell touches upon the differences of training and learning. It’s a large field of research and I hope to post more about it later.

• It’s a high level of intelligence. But not necessarily an extreme level of intelligence. However, a certain level of numeracy and ability of thinking in abstractions is necessary.  Maybe at some point we’ll find that super developers are able to hold more variables at the same time in their working memory, or something along those lines, and that turns out to explain the differences. But I have yet to see any research like that.

And it’s motivation… and the right management… but these things are also things external to the superstar, that you one move around to find. The brain finds it’s ideal setting..

So there, that’s what put the superstars apart from the average. I’d love to hear others’ take on it.

The sad thing is…

..that reality is that a well functioning team can usually match the lone superstar or even has it’s own advantages. It’s actually a good message: let’s not just celebrate these few people, they’re brought forward on the shoulders of people going through the daily grind of facilitating it and cleaning up the mess. Or we can achieve great things just by working together. It’s just presented so boneheadedly wrong.

Finally, Bill followed up with a clarification of some sorts, basically that IBM is made up of average people and see how long they have lasted, while Enron was full of superstars, and look how they crashed.  I wonder what IBM thinks of his base assumption there.

It’s based on Anders Ericsson’s work in the field, and holds as well for computer programmers as practitioners in any other field.

See also: Accelerate your Perl learning

• The Risk of Being Undone
• The Risk of Maintenance
• The Risk of Failure
• Pronouns in Perl
• Functional versus Structural Code
• The Act of Naming
• On Answers to Smart Questions
• Embrace the Copious Documentation
• Embracing Idioms
• Cleaning Up Bad Code
• Declarations and Scope
• Scalar Context and Arrays
  

And a bonus: Essential Skills For Perl 5 Programmers.

Are there any other good resources out there expicitly aiming at taking novices to the next level – or is that just when general “documentation” takes over as learning instruments? What’s it like in other languages?

Also, while updating with Perl news, scruffy old perl.org has become dashing new perl.org!

Updated with new articles March 8, 2010.

Observation 1: Most programmers are on a life-long learning mission.

Actually, all programmers are. Programming is about solving problems. You must pick up something from that.

Observation 2: Learning happens at different speeds, both between individuals and within the same individual.

One day you get the point of mod_perl and burst forward, after  making CGI-scripts in the same way for three years. At the same time your colleague kept discovering new cool skills every week.

Accordingly, most programmers should be concerned not about their learning, but also their learning velocity. Your skill level is not only based on what you know, but how long it took you to learn it and how much more you can manage to squeeze in during your programmer life-span! If you’re ambitious, but your learning curve is slow or stuck, someone will put you on the sidelines. If your goal is to really understand something, you will be able to reach a deeper understanding if you can fit more learning into a short timespan.

So, this isn’t about using mind-maps, role-plays or fancy games at a training course. Rather, this is about tactics and strategies for life-long learning, or the kind of ten-year long learning it takes to create world-class expertise. I want to share something about what Psychology knows about making us learn more, faster, better and deeper – as well as some personal experiences – and hopefully get some feedback about people’s own experiences about increasing their learning rate.

So here are some points:

Avoid Arrested Development

You start a new job. You have an amazing learning curve while you pick up knowledge and skills from your new colleagues. Six months in you’ve found the comfort level at which you can do your job well. Six years later you are still at that level. Meet Arrested Development.  This is why some people are Formula 1 drivers, while most people drive their car good enough to get them to work and the beach.

Getting out of arrested development might not be easy. One key is to avoid automatic behaviours. In coding, this is to be aware of your habits and trying to break them up. Starting every day with opening a secure shell to the server and starting vim? How about learning to use Padre instead? Always firing up CGI::Application for every new web application? Learn Catalyst, HTML::Mason, even Ruby on Rails.

Or push your limits. Try taking on larger responsibilities. Take on a project that is larger, more complex or more difficult than anything you’ve built before.

The problem with getting out of arrested development is that it might take unlearning of the comfort level, and actually decrease your productivity and even understanding temporarily. It’s actually quite easy to explain in a programming setting: If you’re moving on from CGI::Application to Catalyst, your first web application is going to take longer than normal to develop. But your next one might be a big step forward for both you and human-kind.

(Although probably mostly for you)

Take Risks

It is found, again and again, that taking risk is a driving force in learning. In experiments in controlled learning environments, it is regularly found that being willing to try out more, click more buttons and do individual try-and-see experimenting is clearly correlated with higher outcomes in learning. And it’s just because the risk-takers will get more learning opportunities, they will simply see more of how things work.

So make sure you have a safe testing environment, a box for experiments and wild ideas. Try to break things that work, find edge cases or do things in a new way. Have a machine you can re-install without losing your precious collection of photos. Write some crazy ideas on your blog. Try and see what happens. But most important: Create a technical environment that is conductive to risk-taking, just as much as a social environment. If your development server is a sacred cow or people are dependent upon it, set up a crash-test server.

I think a reason Test Driven Development is working is also because it forces you to think about and try out your software. Writing tests is also a great way to get to know new packages or software suites, you can take risks you would never imagine doing while developing code. This method takes two scalars? I wonder what happens if I give it a 10.000 element list of japanese characters!

And let me repeat this: Take on a project that is larger, more complex or more difficult than anything you’ve built before.

Learn the right things

Some knowledge needs pre-requisite knowledge. It’s just a fact of life. If you try to learn how to make 3d graphics, it will take you a lot longer if you don’t know vector mathematics. (And you might want to look at something other than Perl for implementation..)

It’s pretty obvious stuff.

What is less obvious is what the optimal learning direction in computer programming actually is. In Perl, is there a learning run that is better than others? A sequence of reading perldocs that is more effective than another? I can certainly imagine some bad and good places to start, but everyone can do that. What is more unclear is what happens after that start. When you’re half-good and can do what you want, but want to expand, what is the most optimal directions to follow?

I actually don’t have a good answer to that yet. My only advice would be that if the terminology is getting too tricky, it is time to go back a step. And not only to..

Learn the terminology

When you meet a new term, don’t fill in it’s meaning from the context. One of my own most immediate improvements in learning came from always immediately looking up words I don’t understand. I believe there usually is a reason I don’t know the word, and often I’ve had some surprises where my “context fill-in” actually was way off.

Also, as suggested above, it you’re missing too much terminology, it might be a hint you are in over your head and need to gain the pre-requisite knowledge.

Learn something new outside Perl

Everyone will tell you this. Stuck on Perl? Get some new vibes from Ruby. Your C-coding is getting you down, try Scala (should get you back to C soon enough). And you can go further. Adam Kennedy says he gets inspiration from places like TED conferences, New Scientist or Economist. Some people will suggest just learning anything can get you out of a rut.

However, there is a condition. If it is going to help your programming, it must involve some sort of domain-transferable skills. Not everything new you learn will necessarily do that. I’ve been doing digital photography for nearly ten years and have gotten to a decent level. It has absolutely not improved my programming in any way. It is far too domain-specific. Getting a degree in psychology, however, has plunged me forward on a lot of levels, from new learning skills to seeing new ways of solving problems and learning about how the brain does biological information processing. Studying Zen sometimes provides me with a focus that is very conductive to understanding difficult subjects. The same with learning mathematics, particularly discrete mathematics.

So consider well what you learn. Pick the right thing, and you might gain a unique perspective on programming or just sharpen your thinking. Pick the wrong thing and you are wasting good learning time on taking vacation shots.

Of course, you might want a whole and fulfilling life filled with culture and art too, but that’s not what this text is about.

Accessing other peoples experience

Talk with people, and talk with them, not to them. Unless you are Ada Lovelace or Charles Babbage and invented this stuff, learning programming involves transferring knowledge from another human’s brain into your brain (I know some of you will lament this fact). One of the most effective ways of doing this, and the one way we are the most biologically disposed to, is talking combined with listening.  Reading is a hard-learnt skill that is piggy-backed on top of the visual system the last some-thousand years. Conversation, on the other hand, has a significant part of your head dedicated to it. Use that!

Study the code of excellent programmers and learn from it. Avoid the code of bad programmers, and if you have to look at it, don’t learn from it. Perl is fantastic for this. As well as being a great code repository, CPAN is also a fabulous learning resource. In addition, the core modules are often very good and thorough code that has been optimized and looked after a lot. If you bring your laptop on the train and lose the connection to the net, study a core module.

The problem of tacit knowledge. A problem of accelerating training towards an expert level is that the real expert knowledge is not the same as the knowledge written down in documentation and books. Rather, what actually sets a novice or an expert apart is unknown, or at least not explicitly known, to either. If you just squeeze 10 years worth of reading into someone in five years, they might just still be at the 5 year level in real skill, but with a lot of knowledge they don’t really know how to apply. This is related to the concept of declarative or procedural memory, or that what you read and what you do is remembered in completely different ways and places in your brain.

That, for example, is what things like the “variable roles” mentioned in a previous post try to encode. They find how experts understand and use variables, and try to teach that to beginners instead of giving them the basic intro and letting them get the experience the hard way. How do this apply in a life-long learning perspective? Study the how and what people do, not only what they say (or write).  Also: Study design patterns. Don’t necessarily base your own software designs on them, but know them, as they encode expert experience that previously was tacit.

Increase your physical learnability

Up until recently, we thought you grew new neurons (brain cells) up to certain age, then it stops and from then on it went down hill. It is not the case. At least in the hippocampus, which is the center of forming new memories, neurogenesis is found to take place all through life.

But there is a condition…

It takes physical exercise, namely aerobic training – that means running, biking, rowing or anything that makes you pant and sweat for an extended period of time.

I’m sorry… but it will increase your learnability…

Furthermore, your brain needs the right chemicals to actually form new neurons. One major compound that can’t be synthesized by your body from normal foodstuffs is omega-3 fatty acids. Omega-3 is found repeatedly to increase general cognitive ability (meaning higher processing power in your head) under many conditions. And you know you want more processing power as well as increased memory. Omega-3 fatty acids can usually be bought as pure capsules, or they can be found in salmon and walnuts if you want to eat that every day.

But be careful with the portioning. Too high Omega-3 dosages can lead to thinning of the blood, and while you might want to accelerate your Perl learning until your gum bleeds, you didn’t read that here.

And the last, but not least, point, is to be well rested. The code-all-night pattern might work when you are teenager or young adult and physically don’t need as much sleep. After that, it will effectively decrease your hard-won cognitive abilities.

And more?

Believe it or not, but I would actually like to expand on most of the points above and provide some more evidence and put some numbers to the claims above. But I have to post my Perl Ironman 10-day post and that effectively limits the time.

So, please share how you learn, or your advice to increase your learning rate. I know some rather able Perl-programmers drop by here occasionally. If you managed to become a guru, please share what you have done different. Is it just a lot of years of experience? Or do you have a unique approach?

How come? Some people just get it and some don’t? A failure of teaching?

See the discussion at Mik’s blog.

I don’t necessarily agree that this is caused by people falling behind and not being able to catch up (although that is probably also a problem).  If that was the case, you would probably see a skewed single peak distribution, as one of the commenters suggest.

Rather, I think the either/or explanation is the right. Now does that mean people in the left hump will never be able to learn, or are doomed to a life of poor understanding of programming? I think not, but how to move them to the ‘get it’ group is another matter..