Joel posted his Language Wars and Wasabi posts on September 1, 2006.
He announced the new Joel on Software Jobs Board on September 5, 2006.
Hmm… Joel knew that his Language Wars and Wasabi posts would get a lot of attention, and perhaps some of that attention would last long enough to get a few extra people to notice the new jobs board…
Was the timing of those posts intentional? 🙂
(Yes, I know, Joel gets plenty of attention any time he says anything, but the Ruby comments alone seemed to generate more than the average amount of chatter.)
A couple weeks ago I saw a great talk by Jason Cohen, founder and CEO of Smart Bear Software about lightweight code review (pdf of slides).
A quick summary of Jason’s talk:
- Up-front code review saves time and money by finding bugs earlier (backed up this claim with real world data).
- Smart Bear has a product called Code Collaborator which “enables peer review of source code changes before or after files are checked into version control.”
- His emphasis was on the process of code review rather than Code Collaborator, though he got plenty of questions about the software.
- They did a big study with programmers at Cisco (“the largest-ever case study of peer code review”), talked about the results.
- The most effective reviews are for less than 200 lines of code and take less than 1 hour.
- Maybe you can do 400 lines and 1.5 hours, but that’s pushing it.
- Positive social aspects of code reviews:
- “ego effect:” knowing that someone else will be looking at your code may help you be a better developer immediately
- you may learn a thing or two by seeing how others code
- Create an atmosphere where finding bugs is good – whether you coded them or not. Bugs found here and now are much easier and cheaper to fix (and less embarrassing!) than bugs that turn up after you ship.
Jason was truly excited about this stuff, which helped made it a great presentation.
Jason (& company) wrote a book about lightweight code review called “Best Kept Secrets of Peer Code Review” – they’re offering it free (as in beer) from their website – that book title link will take you there. I just received mine in the mail and I’m looking forward to reading it.
(Yes, I read stuff like this in my spare time. I am, in fact, a geek. And proud of it. Of course if you’re reading this far odds are you too are a geek, so you’re not surprised.) I’ll write more as I read the book.
Robert X. Cringely, tech pundit extraordinaire, said he’s going to change his weeklyish column into a blog.
I’m hoping that means we’ll get to see more frequent content from him. I really enjoy his insight into the tech world – he’s usually thinking things no one else is (or at least he’s the only one saying them publicly), and he’s right pretty often too – bonus.
From an Information Week article about Google:
“Lots of small, short-lived projects mean traditional project management software based on task lists isn’t right for Google. For one thing, techies aren’t very good at cataloging how they spend their hours. What they are good at, it turns out, is writing up a few short sentences or snippets about what they do each day. Those get compiled in a database along with periodic updates from project leaders about a team’s deliverables.”
(That link is from page 4 of 5, fyi.)
What’s more important to a non-consulting / hourly billing company – (A) tracking the number of hours employees work or (B) tracking the actual work done?
Hmm, let’s see:
- (A) Tracking the number of hours worked doesn’t necessarily tell you how much work was done. It may give you a hint, but what if you’re having a day like Joel sometimes has?
- (B) Tracking the actual accomplishments tells you exactly how much work was done. You know where the project stands relative to its milestones.
From a “how is the project doing” point of view, option B seems to make a lot more sense. Getting Things Done is what makes money. More hours will probably lead to more work being done, but why use a second order measurement when the first order measurement is available?
Plenty of people who are smarter and more eloquent than me* have discussed why you can’t just measure “techies” by the number of hours they work. I’m glad Google is doing something better. Meow.
* I’m not even smart enough to know if “me” or “I” is the right word there.
I was hoping to cash in on the popularity of Joel’s post, but then I noticed that everyone and their computer-illiterate grandmother who doesn’t have electricity has already commented on it, so I’ll just throw in some links:
Okay, I’ve got to throw in my 2 cents: Joel drew a line in the virtual sand (silicon?) – not a very thick line, a medium “I stand over here” kind of line – and people started hurling themselves on one side or the other. It’s interesting to see how many people seemed to be threatened by Joel’s post as if it was a personal attack against their professional way of life.
I think Joel was simply being honest – and because his company is successful he knows he’s right. Sure, he makes some generalizations that might be a bit exaggerated (though not much, says I), but he’s got the results to back up his rhetoric.
Thoroughly entertaining – an excellent way to start a 3 day weekend!