Interested in discussing psychology and software development? I’m at the OSCON in Portland, Oregon all week this and I would be really interested to chat with others interested in psychology. I’m mainly at the conference to help hiring for so come and ask for me at the stand in the Expo hall. And if you’re interested in any of the many positions we’re looking to fill also drop by, of course! Have a look at our available openings at the jobs portal. We’re still trying to get hold of many, many experienced Perl developers, and we’re also willing to teach highly experienced developers in other languages Perl.

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

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

Google Timeline is a wonderful tool! Here is a Google Timeline for the search “Perl” showing an exceptionally interesting trend: It may seem like the recent efforts to market Perl, as well as the Perl Ironman blogging drive, is paying off big time in terms of online attention! The graph certainly sends a clear message that Perl is alive and kicking as never before. Note: I tried to create comparative graphs for Ruby, Python and Java, but was left with enough noise from fake gems, snake attacks and earthquakes to fill several Hollywood movies. Any suggestions for good searches for comparison are welcome. Note 2: Maybe this is just caused by some Google indexing algorithm gone bad, but a quick[…]

This would perhaps not be newsworthy normally, but I thought the PPIG newsletter was dead. Those rumours were apparently highly exaggerated: the November 2009 issue was just released, detailing among other things the PPIG 2009 workshop and the upcoming 2010 workshop. It also includes a few links to some really interesting blog posts: Does parallel processing require new languages?, What do you consider readable code?, The Top 25 Most Dangerous Programming Errors and this old article from Computerworld on how community and culture goes hand in Perl. Enjoy. Oh, and it also seems to be written extensively in rhyme.

After writing about the Software Engineering Myths Microsoft claims to have busted, I’ve been thinking about their find that organization structure is the most predictive factor for bugs. And it makes me think, to what degree are organizations’ code bases shaped by their formal or informal organization structure? Are core modules and root objects often the domain of senior developers and objects lower in the hierarchy the domain of juniors? My experience is that it often tends to be, and it seems a reasonable overlap: after all, you want your more trusted developers fiddling where the damage can be greatest. But how about other attributes of the code base? In the world of Perl, are CPAN authors often hired as[…]

I’ve been wanting to post a link to this article for a while, but ever since I discovered it, has been unreachable for me, so I’ll post a small summary: Microsoft has done research on some popular conceptions about software engineering and come up with hard numbers on some factors affecting code quality.  Here are the main findings reported in the artice, with links to the research papers, in case the original is lost forever: More test coverage does not equal better code quality, as measured by number of post-release fixes.  Usage patterns and code complexity are the main reason test coverage is a poor predictor of quality. Test Driven Development increases quality, creating code that was up to[…]

How do programmers differ, and why should you care? Steven Clarke from Microsoft’s usability labs has identified and demonstrated at least three different programmer styles, which has been reported in quite a few places, hence programmers do indeed differ. The types Clarke found are: THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions. THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications. THE OPPORTUNISTIC DEVELOPER: Writes code in[…]

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

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