A funny discussion is going on at HBR Blogs:  Management-type blogger Bill Taylor suggests our culture wrongly celebrates the super-stars, and claims great people are overrated, on the cost of well-functioning teams (via Igor Sutton). But, to illustrate his example he uses software engineers as an example. Cue outpouring of frustration – Bill’s getting hammered in the comment section. 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[…]

Tony Schwartz/Harvard Business Review has an interesting bullet point list of what is necessary to excel in any field: Six Keys to Being Excellent at Anything 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

I stated in an article some time back that a challenge in learning is that the knowledge setting experts apart from novices isn’t explicitly known by either – it’s tacit knowledge. Since that was about learning Perl, I just want to bring attention to this good series of blog posts by chromatic under the header “From Novice To Adept”, as they fill in a bit of this gap: 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[…]

This is inspired by an article by chromatic from ages back, about your programming force multipliers. I think improving your learning is a major “force multiplier”, so this is about how to do that. 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[…]

Apparently, the distribution of marks in introductory courses to programming looks like this: 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[…]