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[…]

One of my own favourite, but generally least liked, genres in Psychology is Individual Differences Psychology. Instead of finding what people have in common, the ID approach focuses on what sets us apart. This is the area of IQ measurement and personality types, often with some visits into cognitive psychology, as well as teaching and – particularly – grading. Related, I just came across this: The Programmers Competency Matrix – it’s the brainchild of blogger Sijin Joseph. It’s not overly scientific (he states he spent an afternoon on it), it makes no claim about predicting work-place skills or productivity, although it does imply a higher score means a better programmer. It’s still a cool and thorough starting point to think[…]

Basing software development decisions on research and controlled experiments currently has some challenges involved with it. One is that there is very little research available: In a survey of research literature, a set of researchers with the IEEE Computer Society found that in the decade from 1993 to 2002 only 103 scientific controlled experiments on software development was reported. In addition to that, a fair amount of these experiments has execution problems and often suffer from small sample sizes and non-significant results. Add that experiments often look into only a very small part of computer programming and the papers often take quite some time to read and digest, and it seems apparent why research and evidence-backing is so limited in[…]

I’m trying to keep the level of “management” articles low on this blog, but this is quite funny and I wanted to comment on it.  Last week Jeff Ello’s article The Unspoken Truth About Managing Geeks did it’s rounds on the Internet. Not surprisingly, with quotes like this: [the IT world] is populated by people skilled in creative analysis and ordered reasoning. Doctors are a close parallel. The stakes may be higher in medicine, but the work in both fields requires a technical expertise that can’t be faked and a proficiency that can only be measured by qualified peers. and When hiring an IT pro, imagine you’re recruiting a doctor. And if you’re hiring a CIO, think of employing a[…]

As a programmer, you write for two very different kinds of readers. One is the rigid computer platform, the other is the human maintainers of your code. For the former we have quite conclusive guidelines on what works, but the latter is only consistent as a source of disagreement and uncertainty. Typically the guideline is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.“, while most people end up writing as if the person maintaining the code is themselves. Neither approach is particularly good -I can’t imagine code written for violent psychopaths  would really be that great to maintain. And on the other end, a lot of coders[…]

Another piece of old research. It’s so interesting, though, I can’t help putting a note up about it. In a piece of research released in 2000, Lutz Prechelt compared C, C++, Java, Perl, Python, Rexx, and Tcl.  (It’s gotten a fair bit of attention before, so it’s not new material) What’s so good is the fairly rigorous and natural approach – instead of leaning exclusively on local students or one company’s employees performing some unnatural task, the researchers solicited for solutions online for the scripting languages (Perl, Python, Rexx and Tcl) and got 80 different implementations of a simple dictionary task. With these tasks they ran a lot of metrics and generated solid, comparable empirical data. Read it for the[…]

15 years ago, the research journal Human-Computer Interaction published their special issue on Object-Oriented Programming.  Having realized that a lot of the claims made about OOP at the time were not technical in nature, but rather were psychological and cognitive, the special issue attempted to present empirical and experimental research examining the claims about OOPs advantages on procedural programming. Or as the editor Bill Curtis notes: Object-oriented (OO) design and programming trace their lineage to research on abstract data types in the late 1960s and early 1970s, but they did not become popular software development techniques until the late 1980s. In all this time there has been little serious empirical or experimental study of OO techniques. What usually passes for[…]

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[…]

I promised to explain better the idea of variable roles I mentioned in the previous post about natural programming. This is based on a finding by Finnish researcher Jorma Sajaniemi (published work), who discovered that 99% of variables in novice’s code can be categorized in to 11 different roles. These roles are variable uses every programmer will recognize: iterators, constants, flags and so on – although in role-terminology the names somewhat differ (steppers, fixed-values and one-way flags, for example).  Mr. Sajaniemi has also found that these roles matches tacit knowledge in expert programmers – i.e. the 11 roles are also typically intuitively recognized by expert programmers even if it is not explicit or active knowledge. Whether or not the same[…]

I just touched upon how natural programming can be a way forward for Perl in my previous post, and quickly saw a twitter from chromatic not understanding the “criticism (?)” of Perl 6. As he is a member of the Perl 6 development team, I am happy that he noticed my post, but not so happy about the lack of understanding. So a clarification is probably called for. My post was not a criticism of Perl 6. I am quite skeptical and apprehensive about P6, which shone through in my article, but criticising a project that started in 2000 for not implementing ideas published in 2008 would be rather unfair. However, Perl seems to be in search of a purpose[…]