If you want to achieve anything bigger than yourself, you need others to play along. Even if people management isn’t your calling, knowing how to lead people is a hugely useful skill for anyone who wants to achieve something. Having tried, failed and succeeded in leading development teams in various ways, I want to share these three concepts that has been very useful. I’ve always been on lookout for literature on leadership that fits 3 simple criteria: 1) Not based in ideology. 2) Some backing in data and research. 3) Directly applicable, not grand ideas or personal development plans. So far I’ve found three great concepts to master that I’ve found very useful: the SCARF model, Level 5 leadership and[…]
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 Booking.com so come and ask for me at the Booking.com 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 Booking.com 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[…]
Long time no posting, but this just had to go on here.
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.[…]
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..
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[…]
This is just a funny talk by Ron Burk, which probably explains what is going on at Microsoft pretty well.
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[…]