james mckay dot net

Half a dozen or so of us from work were at the London Stack Overflow Dev Days event with several hundred other developers today. I’ve been pretty impressed with the way Jeff Atwood and Joel Spolsky’s enterprise has turned out to be such a resounding success, and I’ve also been an avid reader of Jeff’s blog, Coding Horror, for several years now, so I was naturally delighted to get the opportunity to go.

Encountering Joel and Jeff in real life was an interesting experience, since I’ve only ever read their blogs and Twitter feeds up to now. Over the past year or so, I’ve had to get used to seeing certain people in real life that most people only ever see on TV or on the Internet, but it still seems a bit odd when you do. It certainly gives you a totally different impression of them from what you had before though. You can certainly see why Joel and Jeff in particular are both so successful in what they do: as well as being excellent online communicators, they are both brilliantly engaging and entertaining public speakers. So too was Jon Skeet, who gave a very funny talk about localisation entitled “Humanity: Epic Fail,” assisted by a sock puppet called Tony the Pony. Joel’s talk on FogBugz was a pretty hard sell, but it certainly looks impressive, boasting a feature set that makes Trac look like Notepad.

The other talks included an introduction to Python by Michael Sparks of the BBC, who explained to us Peter Norvig’s 21 line spelling corrector (it didn’t escape my attention that Jon Skeet spent the lunch break porting it to C#); introductions to mobile development for no less than three rival platforms (Google Android by Reto Meir, iPhone by Phil Nash, and Qt/Nokia by Pekka Kosonen); introductions to jQuery (Remy Sharp) and Yahoo! Developer Tools (Christian Heilmann); and an academic talk on “How not to design a scripting language” by Paul Biggar, who recommended the book “Engineering a Compiler,” by Cooper and Torczon as a superior alternative to the Dragon Book.

I spoke to Jeff during the afternoon break and asked him if he had any plans to publish the best of Coding Horror in a book. He said he’d thought about it a bit, but wasn’t entirely convinced it was worth doing. It’s something I’ve recently thought that he’d do well to do—a lot of his posts are ones I’d consider “must-reads” for every working developer, and if he did, I’d buy it in a shot. He wouldn’t be the first person to do something like that either—after all, Joel did it (twice), and so did Raymond Chen. It was interesting what he asked me when I told him I work for Parliament—he was most interested to know whether Britain is part of Europe or not. It’s a good question, that. Officially we are, but unofficially I sometimes think that as a country, we’re not entirely sure ourselves.

There were just two disappointments to the day. One was the catering. I was half expecting something along the lines of a buffet lunch—after all, I do tend to think of the Fog Creek Way as one where they go the extra mile to get these things perfect—but it turned out to be the kind of mass produced sandwiches that you get in a motorway service station that are all ridiculously overpriced, taste exactly the same as each other, and don’t meet with my approval anyway because they’re spread up with margarine. The other disappointment was the venue itself. Kensington town hall simply is not big enough for however many of us (800? 1000?) were there today. Consequently it felt very crowded and claustrophobic, and even a little bit uncomfortable, especially during the breaks when we all crowded into the foyer and had to form a queue stretching seemingly all the way to Barking and back to get to the food.

The day ended at about ten past six and I came away with a whole lot of freebies: a Qt rucksack, a copy of the Aardvark’d DVD, a handful of FogBugz pens, and a handful of Stack Overflow, Server Fault and Superuser stickers. All in all, it was a pretty full day (I had to get up half an hour earlier than usual and I got home an hour and a half later than usual, and sitting through seven hours of talks was pretty intense) but it was well worth it.

Comment on this »

Posted at 23:00 on 28 October 2009.
Tagged: Jeff Atwood, Joel Spolsky, Stack Overflow

Jeff Atwood wrote an interesting post the other day where he asked the question, Is Open Source Experience Overrated? He quoted an anonymous developer who had lamented not being able to find a job despite being the architect of a couple of open source projects:

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed. Then I asked whether he had looked at the open source projects I mentioned. He said no – but it seems his impression was already set based on my performance in the coding test. The coding test did not indicate what criteria they were using for evaluation but my solution seemed to kill the interview.

I must confess that I was a little bit incredulous when I read this. It seems the correspondent was expecting the recruiter to consider his open source contributions as a substitute for his poor performance in the coding test — and it would be an irresponsible recruiter who did that.

The problem with open source contributions is that they don’t necessarily tell a recruiter what they need to know about you. They indicate passion and enthusiasm for programming, which is a plus, but they don’t necessarily indicate competence — and passion is no substitute for competence. In fact, some open source projects, such as this example cited by Ayende the other week, are very badly written and do not reflect well on the developer. And in the recruitment process, it’s competence that a responsible recruiter will be looking for first and foremost. That’s why it’s so important to have a coding test. The team needs to have a certain baseline standard, and that standard needs to be treated as a “must have” — failing the technical test should be an automatic “no hire,” regardless of passion or experience. Yes, they should take a look at your open source contributions, but they only really become relevant in the later stages of the recruitment process, once they have carried out the technical screening and are getting into the final round of interviews.

Here are some examples of things that a recruiter may want to know about your abilities that he or she is unlikely to find in a typical open source project:

• How quickly you can write code
• How quickly you can troubleshoot code
• How quickly you can learn new technologies
• The extent of your understanding of the company’s core technologies (how much you have committed to memory, and how much you need to refer to the documentation)
• How well you can understand and implement customer requirements
• How clean you can keep your code when working to tight deadlines
• Whether you can grok recursion
• Whether you understand Big O Notation and its implications for performance
• How well you can integrate with the rest of the team

Different companies also have different attitudes towards open source. The ones that are most likely to be interested will advertise job openings in the open source community itself — they reason that that way they have a generally richer pool of talent to draw on than the hordes of unqualified and mediocre people that you get in places like monster.com and recruitment agencies. Larger organisations, on the other hand, are only likely to take notice if your contributions are to a project that they’re actually using, such as NHibernate or Tomcat, and some companies actually have a prejudice against it, so it pays to do some research and bear in mind that YMMV.

One other thing. If you want to pitch your open source contributions to your prospective employer, you need to make sure that your code is the best quality that you can give it. You might find that they take it into account in ways that you hadn’t expected, and if you’re doing stupid things such as silently swallowing exceptions, or writing thousand-line, hundred-parameter, multi-responsibility, copy-and-paste methods, or giving them names like DoIt(), or if your code formatting is sloppy and difficult to follow with inconsistent indentation, it may work to your disadvantage if they ask a technical reviewer to look at it. Open source coding isn’t like coding for work or profit: you have no deadlines, so you can afford to give it a lot more tender loving care.

Comments closed »

Posted at 08:00 on 20 April 2009.
Tagged: Jeff Atwood, open source, recruitment

I find it rather ironic that the author of the blog entry from which this excerpt is taken:

It seems like any time you try to measure the performance of knowledge workers, things rapidly disintegrate, and you get what Robert D. Austin calls measurement dysfunction. His book Measuring and Managing Performance in Organizations is an excellent and thorough survey of the subject. Managers like to implement measurement systems, and they like to tie compensation to performance based on these measurement systems. But in the absence of 100% supervision, workers have an incentive to “work to the measurement,” concerning themselves solely with the measurement and not with the actual value or quality of their work.

is also one of the faces behind a programmer website which does exactly what he is railing against.

I’m talking about the Stack Overflow reputation and badge system. Granted, it was more Jeff Atwood’s idea than Joel’s — he took his inspiration for it from the Xbox 360 — but the big problem is that when you try to turn a serious system that is supposed to be all about Getting Things Done into a game, people just game the system and turn it into an unusable mess that is not fit for purpose.

If you want to see what I mean, just take a look at this question, which I asked yesterday afternoon. I’ve been looking for a bug tracker system which can work as an integrated system for both developers and project managers for a while now, and none of the ones I’ve looked at so far have the particular feature I’m asking for.

The first so-called answer came within seconds and didn’t answer the question properly, which isn’t surprising since you would need at least 2-3 minutes just to read the question in the first place. It was followed by a string of about ten or so responses over the next half hour, again, very few of which made much effort to read the question, let alone answer it. Most people seemed to treat it as saying “What is your favourite issue tracker?” and one busybody even tagged it as “subjective” when I was asking for something very specific. And nobody so far has reported any success or otherwise with using an issue tracker of any description to integrate both the developer’s-eye view and the project manager’s-eye view.

This is a BIG problem with Stack Overflow, and I’ve seen it to an extent on other questions too. The system doesn’t favour good answers or correct answers or answers that actually make any attempt to answer the question, it favours quick answers. Being the first off the mark with something that at least looks like it could plausibly be an answer to the question means you’re most likely to get voted up. Getting voted up means appearing at the top of the list of answers, and it’s kind of self perpetuating because then you get more votes, and each vote means that you get ten reputation points, and if you get enough reputation points, you automatically become the Stack Overflow equivalent of a Wikipedia administrator.

The result is that you get a whole lot of knuckleheads gaming the system trying to pimp their reputation. They put up a response that looks fairly plausible and seems right to other knuckleheads but which either (a) doesn’t answer the question, or (b) is plain wrong. If the person asking the question is also a knucklehead, their answer gets marked as the accepted answer, which means even more reputation points. In the meantime, someone who arrives several days or weeks later with the correct answer doesn’t get any attention because their answer gets buried in all the other zeros. It’s particularly worrying because it’ll be the knuckleheads who end up running the show and deciding what goes and what doesn’t.

It’s as broken as lines of code per day, and it really really annoys me.

It really annoys a lot of other Stackers too — a request to fix it is the most popular user request on the Stack Overflow uservoice forums, though the problem is that there is no consensus about what needs to be done to stop it. I do hope they come up with some fix for it, otherwise the site could end up with no more value than its arch-nemesis, expertsexchange.

Comments closed (2) »

Posted at 12:30 on 27 September 2008.
Tagged: Jeff Atwood, Joel Spolsky, metrics, Stack Overflow

I’ve been checking out the private beta of the new Stack Overflow website from Jeff Atwood and Joel Spolsky. You need to sign up for an invitation if you want to get involved with the beta, and they’re only sending out a hundred or so invitations a day, so you may have a bit of a wait, but from what I’ve seen it looks fairly promising.

The concept is fairly simple: it’s a programmers’ question and answer website, a bit like a cross between Yahoo Answers and Digg. You can vote answers up and down, with popular answers appearing at the top and useless answers falling to the bottom. This means that it should help to filter out answers of the type “I’m having the same problem too” which render Google search results for pretty much 100% of the problems you encounter with SharePoint development totally useless. However, it is not well suited for discussions — there are some questions where people have been posting answers in response to other answers, but it can be a bit difficult to follow the thread of the discussion.

Another interesting twist, however, is that you can vote questions as well as answers up and down. This is based on the premise that the old adage “There are no stupid questions” is wrong. This is a common sentiment in geek — especially hacker — circles, and I have mixed feelings about it. Yes, vague and misdirected questions can be an irritation, but they usually come from newbies who don’t know any better, and highlighting newbies’, er, newbie-ness, could be a bit off-putting to them. Having said that, it could — and probably will — work out fine, but the site may need some kind of equivalent to the Wikipedia policies of “Don’t bite the newbies” and “Assume good faith” to avoid the hacker types from getting too carried away with themselves there.

You can also earn “badges” and reputation points, for a whole lot of things such as answering questions, getting a certain number of votes on your answer or question, or having your answer judged as the best one by the person asking the question. You need a certain number of reputation points in order to do certain things — for example, you can only vote questions and answers up and down if you have 25 or more reputation points.

At the moment, there are just under a thousand users on the site, and since it’s populated by the kind of people who have actually heard of Joel Spolsky and Jeff Atwood, the questions and the answers are on the whole pretty smart ones. How much this changes in a month’s time or so when it opens to the public and its eternal September gets underway, remains to be seen. There is always the possibility that it will see an influx of the kind of morons that hang out on Digg, or people asking questions such as “Help, I deleted the database and we didn’t have a backup, how do I get it back before my boss finds out?” but hopefully the moderation system will keep it on track, mitigate that, and preserve the flavour of a community of developers who actually know what they are doing and can give constructive answers to questions.

Comments closed »

Posted at 22:09 on 10 August 2008.
Tagged: Jeff Atwood, Joel Spolsky, Stack Overflow

Marco Arment (in a response to Jeff Atwood) came up with a list of five common complaints that are not valid reasons for hating a programming language:

• You’re unfamiliar with it.
• You don’t like the language’s vendors.
• Idiots often use it to write bad code.
• It doesn’t fully resemble your favorite language.
• You don’t like its syntax.

PHP’s not a perfect language, of course. Nothing is. But it’s by far the best language to use for nearly any web application, as long as you use an appropriate framework and good coding practices. Any language without either of those is bad.

I’d agree that PHP has its foibles, such as its lack of closures, its bloated global namespace and its ad-hoc, inconsistent approach to conventions. However, none of these are insurmountable, and in fact, once you get used to its foibles, working with PHP isn’t all that hard.

A few days ago I finished up on several days’ work on a PHP project and started on a SharePoint workflow. It’s an exercise that I highly recommend for anyone who is tempted to write an anti-PHP rant, because it will put everything in perspective, and give you a list of valid reasons for hating a programming language, platform or framework:

1. Vertical and infinite learning curve.
2. Unnecessary complexity.
3. Useless documentation.
4. Excessive pitfalls, gotchas and leaky abstractions.
5. Design that obstructs you from adopting best practices.
6. Meaningless, cryptic and uninformative error messages, buried in a massive log file deep in an obscure part of the bowels of your file system.
7. Painful debugging process.

Check this out: to debug a SharePoint workflow you can’t just hit run in Visual Studio. You have to attach the debugger to the w3wp.exe process, and even then it still won’t hit your breakpoints or break on exceptions. According to this blog post, you have to copy the .pdb file by hand into a part of the GAC’s directory structure that you can’t even access through Windows Explorer, so you have to do it via the command line. On top of that, the edit-compile-test loop is agonising — it can take two minutes to re-compile, deploy, and re-load your test site into your browser, after which you may well have to remove and restart the workflow.

Admittedly it’s not all bad. The vertical and infinite learning curve at least gives you some immense satisfaction when you finally “get it”. However, getting there feels at times like climbing the Inaccessible Pinnacle in rollerblades with your hands tied behind your back.

Comments closed (1) »

Posted at 15:58 on 9 July 2008.
Tagged: Jeff Atwood, PHP, programming, SharePoint