Joel losing his touch?
I used to look forward to every new installment of Joel on Software. I found
his words wise, his writing simple and his messages intelligent.
But lately, his stuff seems to be getting more and more arrogant and
self-important. Take this article for
example. I find it hard to believe that Joel equates QR codes with CueCat
and assumes that nobody working on them ever heard about CueCat because they're
simply too young. Come on, Google isn't hiring 7-year-olds. Even fresh out of
school college grads remember CueCat.
Frankly, no, there isn't a huge chicken and egg problem. Everybody has a camera
phone these days. Just try to get a cell phone without a camera. It's damn near
impossible. And yes, URLs are hard to type, at least on any phone I've ever
used. Basically Joel has missed the two most important differences between QR
codes and CueCats:
- Everybody has a camera phone, whereas nobody had a CueCat, or wanted
one
- URLs are hard to type on phones and in some locations where latin keyboards
are not common, whereas they are not hard to type on a full US-English
keyboard
The model with CueCat was that you got some special device, and hooked it up
to your computer, and then sat next to your computer while reading a magazine
and scanned the bar code. Obviously, that's next to useless. If you're at
your computer anyway you might as well type in a URL. Especially since they
were US-only and typing English on an English keyboard is pretty easy.
With QR codes, the idea is that you see them on the street, not in a magazine.
Then you take a picture with your phone, and then you go straight to the web
site. This is much easier than suffering with a crappy phone keyboard to type
in a URL, even a short URL. And everyone already has the phone, so adding this
convenience seems like a no-brainer.
Or I don't know, maybe I'm just too young. At least according to Joel.
git rocks!
I'm a bit behind the times on this one, I must admit. At Google we use
Perforce, and I hadn't really had occasion to try git much
until recently. I think I pulled a kernel from somebody's git
tree once but that was about it.
One of the things I hate about Perforce is p4 edit. The only
advantage you get from having to do this annoying step is a little
message that tells you who else is editing the file when you edit it.
Frankly, I don't really care. It's not like that's going to stop me
from editing the file.
At Google, it gets so bad that during peak time, p4 edit can
take minutes. This completely disrupts your thought process.
Here you are, coding away, and you go to edit a file, it hangs, and
then (at least in my case) you go look at email or something and
completely forget about what you were doing. Of course you can just
chmod the file yourself but then you risk forgetting that you have
in fact edited it, so you might forget to include it when you submit.
(Incidentally, this is one of several reasons I prefer to work at
night. At 4am there's at least a small chance Perforce might perform
decently.)
Anyway, I recently started using git to manage local changes,
only talking to Perforce when absolutely necessary. It completely
changes the way I work, and I can work way faster too, because I
can pipeline my changes so easily. I write some code, then send it
for review, branch, write more code that depends on it, send that for
review, etc. And then I can merge any changes made during the review
into the branch and keeping working on the depending code. Doing
development like that in Perforce was a royal pain. You made your
changelist, sent it for review, and then had to patch it in to another
Perforce client if you wanted to work on stuff that needed the first
changelist. This encourages people to write huge, massive changelists
because they don't want the burden of maintaining multiple Perforce
clients. Huge, massive changelists that make me grumpy when I have to
review them :P
