StackOverflow DevDays Toronto Recap/Review
6 November, 2009 § 7 Comments
It seems a little late to write my review of the StackOverflow DevDays conference I attended in Toronto on October 23rd, but I had said that I was going to put it up here. This is me backing up my word.
The conference had six talks, including the opening keynote. Of the six talks, I felt three could have been left out. The whole conference took place in one large theater, meaning there was no choice of talk to attend. Given that, the language/framework overviews of ASP.net/MVC, Python, and jQuery all were pretty boring. I’ve used all three of them before, and all the talks felt redundant (to me). I think that had it been a conference where you could choose which session to attend, then these talks could have had a lot more value.
The three notable talks were those given by Joel Spolsky (co-founder of StackOveflow), Greg Wilson (Associate Professor in Computer Science at University of Toronto), and Reginald Braithwaite (Software Developer and Development Manager).
Joel Spolsky‘s Opening Keynote
Joel Spolsky’s keynote was all about writing software with less features and simplicity. He mentioned a study where researchers had customers of a grocery store sample either 6 different flavors of jam or 24 different flavors. When 6 flavors were offered, 40% stopped and tried some. When 24 flavors were offered, 60% stopped and sampled. Yet the interesting twist comes from who purchased. The 6-different group had 30% of the stores customers (not just the ones who sampled) purchase, while the 24-different group only had 3% purchase. He draws the conclusion that too many choices just complicates things and people get intimidated. (I’d like to get access to this research. If anybody knows the publication, please let me know in the comments Update: I just got a link to it: When Choice Is Demotivating).
The main point of the talk is that we should have less features and less choices. Joel mentioned that:
Too often we developers ask users to make decisions that they shouldn’t need to. We tell them, “don’t hit the back button”, “how many items should show up in a recently used list?”, “continuing will cancel your appointments. should i cancel your appointments? [ok] [cancel]”.
Users do not want a dialog with their software, they just want to get stuff done. They don’t want to be interrupted while giving a presentation, or when there is a time crunch and the software pops up to tell them that an update is available.
One of the scenarios he brought up when explaining the need for less dialogs is of a CFO and her secretary. The CFO was cheating on her husband with her secretary and one day out of the blue her husband walks in to the office. The CFO panics and her secretary turns to face her. He says pay me now or I tell your husband. She obliges and opens up QuickBooks (with only a minute to spare before her husband walks in) and then QuickBooks tells her that she has an update pending. That update dialog is the last thing she wanted to see.
Greg Wilson – Professor at University of Toronto
This was an awesome talk. Most of the talk centered around how people within the computer science field are too willing to take data and new methodologies at face value without digging in and calling people’s bluff. He also jumped around and brought up the lack of women in Computer Science and code quality as it pertains to a company’s organizational chart.
When talking about taking new methodologies at face value, he says that none of the facts that argue for Agile have been proved and those following Agile are just the blind leading the blind. For an example, he cited the quote “The best programmers are 28 times more productive than the worst.” The study that originated that quote is heavily cited, yet looking deeper in to the study, it can be seen that we shouldn’t take at face value all these statistics. It turns out that the study was conducted by observing 12 programmers for one afternoon. Even then, what does it mean to be more productive?
He also talked about the need for more women in computing, and the Dweck Effect that is happening. He recommended reading the book, “Why Aren’t More Women In Science?“. (I’ve added it to my want-to-read list).
We as developers need to be humble. This does not mean bowing down to our bosses. It means if we are screwing up, admit it, fix it, and move on. We are not the best developers in the world, we do write crap code, and we need to be honest. He also brings up that code reflects the organizational chart of the company. If two people have different managers, they will be pulled in different directions and the code will show.
Reginald Braithwaite – Software Developer and Development Manager
Reginald Braithwaite was introduced by Joel Spolsky as one of the smartest people that Joel knows. Reg is known from rewriting Ruby to include Lazy Evaluation and Extension Methods. Very little of the talk focused on Ruby, and more about how we are “thinking about thinking about programming“.
He says that you should organize your code as though you are creating a presentation or writing an essay. If there is a large amount of code that does not matter, you should look at abstracting it out or fixing it.
Throughout the talk, he continued to drive in the point that we should think about thinking about programming. We will run in to a problem that appears hard to solve. There is a way that it can be made easier, and we might need to take a step back. “A programming language is just a notation of thought. A programming language can tell somebody how the developers who use that language think.” We should be saying, “What is the way that I should be thinking about solving this problem?”
To give an analogy, he brought up a Winston Churchill quote where he said that he was at a bar and a young lady came up to him and called him a drunkard. In reply he said, “Yes, and you are ugly. But in the morning I will be sober.” The point of that quote is that, “if there is a limitation, don’t accept it as an ugly problem, make it a drunk problem.” No problem is impossible, you may just be thinking about solving the problem wrong, and you should be thinking about how you are thinking about solving the problem.
In closing, he gave an Alan Perlis quote: “A language that doesn’t affect the way you think about programming, is not worth knowing.”
Those three talks were well worth the trip from Okemos, MI to Toronto, Ontario. I’m looking forward to next year’s StackOverflow DevDays. Will I see you there?
Thank you for your very kind words!
I totally agree. Those language/technology-specific talks were boring. But then, I’m not a web developer. I think if the aim of a conference is to make better programmers, we shouldn’t be focusing on languages; we should be learning about advanced techniques and science.
(Also, I would strongly recommend getting rid of that shortened URL to the study and replacing it with the actual URL. Not only will it look more authoritative, but you won’t have to worry about the URL shortening service going out of business.)
My other coworker that was at the conference with me felt the same, as he only works on client-side applications for Windows and Mac. Sessions that focus on introductions to a language or framework will probably find a better reception at conferences geared specifically towards one group of software developers.
The StackOverflow conferences were advertised to users from all different backgrounds, and half of the talks focused solely on web development. On the other hand, I did hear one comment from another developer who works on client software saying that he figures “the web just looks like that is where everything is going”.
Oh, and thanks for the tip about the shortened URL. I had meant to place the full URL in the post but accidentally used the shortened one. I’ve updated it now.
Alright; I get it with shampoos and ice-cream flavors. But take a Swiss-Army knife. It it just had a flat-head screwdriver and if you had to use that for everything you could; but the more controls the better. And with software; I’m sure you could sell more of your product. But it seems making software is all about making money these days.
A Swiss Army knife with only a flat-head screwdriver *and* a knife may not be that useful. The paper, “When Choice is Demotivating”, talks about how as the number of options increases, so does pleasure, but that the pleasure from the many choices reaches a peak just after 7 + ~2, and after that, most people get overwhelmed by the many choices.
A Swiss Army knife with 7 tools could be very useful, but one with 24 tools becomes cumbersome, doesn’t fit in your pocket, and presumably isn’t that good at _any_ of the tools.
I don’t think this is so much a knock at software, more of, if you are going to add a feature, you better be sure that the features you already have in your product are rock solid and that the time invested in feature X couldn’t be better spent improving the usability/stability of the features that have already been developed.
Touche! At least in software I can have the 24 features available in debug mode (or if some preprocessor is defined), right? 🙂
That’s true, you can always do an ‘advanced mode’, like VLC’s settings.