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
The video recording of my talk from YAPC::NA on the Psychology of Perl is online. It has a very funny beginning when Tatsuhiko Miyagawa walks into the room receiving standing ovations as I start my talk, which is really weird in the video. Still made for a fun start of the talk… I have to admit I haven’t watched the whole video myself, but word around is that people liked it. Which is motivating for putting together a larger, more detailed talk for a smaller interested audience, rather than a quick overview for a generally less-than-interested audience.
Wow, I managed to sneak in a lightning talk about the Psychology of Programming, with a Perl twist, at the YAPC::NA 2010 conference. Very fun – it was my first ever conference talk, and I could certainly work a bit on the style, but it got some people thinking and talking, and that’s a great response. Someone requested that I post the slides so he could get the url’s I referenced. I think there was too many copyrighted images in the slides for me to put them online, but I’ll post the links for reference: Working memory limitations: Oberauer & Risse (2010), Selection of objects and tasks in working memory, The Quarterly Journal of Experimental Psychology, vol 63 (4), 784-804.[…]
I’m attending the YAPC::NA 2010 which is starting today. If anyone is going there and want to chat about the psychology of programming and how it may relate to Perl specifically, feel free to get in touch with me! I’ll be hanging out with the Booking.com people as we will be there trying to recruit some people over to Amsterdam too. I’m also hoping I’ll be able to put together a lightning talk about an interesting little finding from cognitive psychology that might put a light on what the default variable does to Perl code readability. But as the talk is neither finished, submitted nor approved on the day of registration, it is a bit unlikely that will happen, although[…]
It turns out I’ve done to my blog what I swore not to: Stop updating it. However, I’ve also sworn that if I did I would come back to it and not give up. So what happened? Well, it’s been quiet here because the heat turned up a few notches in my day job, and the opportunities to actually apply psychological methods turned plentiful. I’ve been involved heavily in recruitment in a (the) major Perl employer these days, and while I’ve learnt plenty about the minds of computer programmers, I also find myself in the situation where there’s correspondingly little I can write about it. On one side because there’s limits to how much detail I can write about before[…]
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[…]
Can a programmer on your team be an overall negative asset for your project? G. Gordon Schulmayer argues that this is the case, with the NNPP, or the Net Negative Production Programmer. His point is that a substantial amount of programmers will introduce so many flaws to your code that the overall cost is higher than the value of their positive contribution. I believe he has some beauty marks on his theory, such as that for every ten man programmer team, there is statistically a nil change of there not being a NNPP on the team. This assumes, in addition to assuming normal distribution, that your team is a representative sample of the world distribution of programming skills and productivity.[…]