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.
Object Factory Pattern: Update on the Natural Programming Project
Data-driven programming: The Evidence Based Software Engineering database
Also, after my talk someone notified me about the interesting blog Psychology of Video Games
And finally: A million thanks to the people who gave me feedback on the talk!
Posted in Resources.
By admin
– June 24, 2010
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 I’m hoping for a bit of slack in the lightning talk approval process…
Posted in Resources.
By admin
– June 20, 2010
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 giving out information best kept confidental, and on the other side because some parts of a recruitment process needs to be kept inside the company to not give candidates unfair advantages (or disadvantages).
Now in a related turn of events, I seem to be heading to the Nordic Perl Workshop 2010 and I’m thinking about putting together a talk introducing the idea of using methods from Psychology to Perl programming. Alternatively just a general light-weight something about some subject from the world of Psychology of Programming. Which leads me to, if anyone who’s been reading the blog still follows it, what was your favourite post? Or what post would you like to seen elaborated on? Or what would just make a good talk?
Or to put it like the quintessential computer/psychology crossover, ELIZA, would: Come, come, elucidate your thoughts!
Posted in Psychology.
By admin
– March 8, 2010
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:
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.
Posted in Language, Learning.
Tagged with Expert knowledge, Learning, Perl.
By admin
– November 14, 2009
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 visual inspection of the first 100 hits indicated that the August and September hits are real Perl mentions. Is this a real empirical indication that the recent efforts are really paying off?
Posted in Language, Metrics.
Tagged with Perl.
By admin
– November 3, 2009
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.
Posted in Resources.
Tagged with links, newsletter, Perl, PPIG.
By admin
– November 3, 2009
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 external consultants? Are the most communicative programmers the ones that will write network services? Are the modules most used also written by the programmers that are most in contact with others?
And does organization structure also shape general code base structure? Will a more hierarchical organization tend more towards hierarchical object structures, while more chaotic or flat organizations tend towards more chaotic or flat code organization?
A lot of questions, but no answers… But one thing that comes to mind is, if organization and code structure follows each other, is this a good idea? I think few people designing a data model or object hierarchy starts with the organization structure as a blueprint, but speaking from my own limited experience, you can often at least see a reflection of either in both. Is this a good or bad thing? What can the consequences be?
Posted in Management, Understanding Code, Writing Code.
Tagged with bugs, organizations, Perl, structure.
By admin
– October 28, 2009
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. I don’t think I’m going too far if I suggest that is rather doubtful for most teams.
Overall, however, the article has some advice and insight. For example, Schulmayer argues that the main cause of any programmer having a negative production is lacking management, and he tries to explain how to remedy this. Also, there are quite a few good quotes, as this one:
John Gardner, in No Easy Victories, said, “An excellent plumber is infinitely more admirable than an incompetent philosopher.” He went on to observe that if society scorns excellence in plumbing because it is a humble activity and accepts shoddiness in philosophy because it is exalted, “neither its pipes nor its theories will hold water.”
But judge for yourself.
Found through Daniel Molina Wegener’s Coder.cl.
Posted in Management.
Tagged with productivity.
By admin
– October 22, 2009
Found through Slashdot: Are Software Developers Naturally Weird? by Eric Spiegel.
Something in the techie DNA results in more weirdness than mere mortals (non-techies). Perhaps this quirkiness is because a certain type of personality is drawn to the techie world. Or maybe we’re somehow transformed over time by our darkened working environments and exposure to computer screen radiation
Personally, I’ve meet a few weirdos, but I think weirdness and skill is generally negatively correlated. Maybe some people just can get away with it easier in the world of programming..
Posted in Management.
Tagged with weirdness.
By admin
– October 18, 2009
I’ve been wanting to post a link to this article for a while, but ever since I discovered it, research.microsoft.com 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 40% to 90% better in the Microsoft research. The cost is increased development time, 15% to 35% in the same studies. (Realizing quality improvement through test driven development: results and experiences of four industrial teams)
- Use of Assertions decrease program faults. However, this is also correlated with programmer experience, meaning more experienced programmers generally write more assertions and have less program faults. (Assessing the Relationship between Software Assertions and Faults: An Empirical Investigation). And here is more about Assertions.
- Organizational metrics, which are not related to the code, can predict software failure-proneness with a precision and recall of 85 percent. Not only that, but organizational structure was by far the best predictor of code quality, and was at least 8% percent better than the best predictor the researchers could get from code-based measurements. (The influence of organizational structure on software quality: an empirical case study)
- Organizational closeness is more important than geographical closeness, which has no effect on quality (Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista)
Here’s Microsoft’s article: Exploding Software-Engineering Myths (or if that doesn’t work, a Google Cache link).
One drawback with this research is that this is primarily based on case studies, which is a generally poor research method for drawing general conclusions. How valid are these observations for other organizations outside Microsoft? Is the organizational structure of your project or company actually more decisive than your programming methodology?
Also, how transferable is this to other programming frameworks. In dynamic typed languages like Perl, is test coverage more important? I often find that a sub-set of my tests do what a compiler could have done in a statically typed language, or even for Perl if I just had a more automatic testing tool. So maybe coverage would be more predictive of bugs if the compiler catches fewer mistakes? That would be a good candidate for further research.
However, this is excellent as a step towards more evidence-based software engineering.
Found through John Tells All.
Posted in Management, Writing Code.
Tagged with Case study, code quality, dynamic typing, Perl, Research, TDD.
By admin
– October 18, 2009
