Steve Yegge: “Up until maybe a year ago, I had a pretty one-dimensional view of so-called ‘Agile’ programming, namely that it’s an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who’ve never read ‘No Silver Bullet’, the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends and who don’t know how to avoid eye contact with leaflet-waving fanatics in airports and who believe writing shit on index cards will suddenly make software development easier.”
Remember when I complained that my Mac kept freezing with bouncing beach balls?
A lot of people suggested it might be a hardware problem, but the diagnostics on the setup disks didn’t find anything.
Well, Daniel Jalkut over at Red Sweater Software suggested that I look in the console app to see what was going wrong, and lo and behold, there were lots and lots of messages that said:
Sep 19 22:56:39 joel-spolskys-computer lookupd: NetInfo connection failed for server 127.0.0.1/local
This totally corresponded to what I was seeing… suddenly any app that tried to do a DNS lookup of any sort would go into permanent beachball mode and never recover.
Some Googling around led me to a page by John Bafford that said “Lookupd has a bug (rdar://3632865) in its cache cleanup code that causes it to randomly crash. CrashReporter, the system crash log agent, does not properly handle lookupd crashes, and as a result, when lookupd crashes, the process is not terminated. Since lookupd has not terminated, mach_init does not respawn lookupd. From this point, any application that attempts to access lookupd, either directly or indirectly, will hang.”
Hmmph. Kindly, John provides Unlockupd, a daemon that watches lookupd and restarts it if it gets jammed up.
I’ll try this for a while and see if it helps. In the meantime, if it’s true, it’s odd that Apple hasn’t fixed this bug in over two years. If somebody inside Apple wants to peek into that bug (link only works inside Apple) and let me know what they see there, I’ll update this article!
Over the last six months, Sprint has been trying to get bloggers (like me) to write about their new Power Vision Network by sending us free phones and letting us download music and movies and use the phones for free.
That’s rather nice of them, but honestly, I have a really strong aversion to writing about things just because some PR person wanted me to. Basically, there’s no better way to make me not want to write about something than to ask me to write about it. I accepted the free phone because, gosh, well, it’s a free phone, but I decided that I simply wouldn’t write about it no matter how much I liked it.
As it turns out, I had the opposite problem. The phone they sent me, an LG Fusic, is really quite awful, and the service, Power Vision, is tremendously misconceived and full of dumb features that don’t work right and cost way too much. So I’m going to review the dang phone anyway, even though if anybody from Sprint is paying attention they’re going to lose their lunch and some executive bonehead over there is going to go nuts and I sincerely hope that this doesn’t put an end to the entire free-phones-for-bloggers boondoggle, because I’d hate to get beaten up at Etech next year by all the other bloggers who would hate me for spoiling all the fun.
Now, on to the review. I was pretty excited to try out this phone because I’ve been longing for one that could double as a decent MP3 player. Most days, I get to work via a combination of subway and walking, which takes about half an hour, and listening to podcasts makes the commute much more pleasant. So I’ve been carrying a phone (a Motorola RAZR) and an iPod (Nano) with me everywhere. Merging the two into one device would be great.
When it finally arrived, the physical appearance of the phone was rather disappointing. If you’ve been spoiled by Motorola’s latest phones, or the seamless, screwless, elegant iPod, the LG Fusic will strike you as butt-ugly. Where a Motorola RAZR has a solid case made out of almost sensual matte-black steel that just feels great, the LG Fusic is made out of the cheapest kind of gray plastic, the same material you find on a $3 toy. Where Motorola goes to great lengths to hide the screws, and minimize bumps and seams, the LG Fusic has dozens of ugly protuberances, gaps, holes, screws, seams, etc. Worst of all, the LG Fusic has no less than three of those evil, flimsy, rubbery plug-caps that are connected to the phone by the thinnest of filaments. You know, those stupid rubber plugs that you have to pull away to plug anything into the phone, and then they just dangle there like chicken wattles (when they’re not getting in the way of the thing you’re trying to plug in) for a couple of weeks until they finally tear off. The phone is almost twice as thick as a RAZR. It comes with a break-offable front plate which can be used to change the accent color of the very front of the phone. Your choices are Barbie Pink, Barbie Green, Barbie Blue, and Black which would be the only stylish choice, if only it didn’t clash so badly with the rest of the phone. (Believe me, it is hard to make black clash with anything, but LG did it.) Overall this phone seriously looks like a Fisher Price toy, not a top-of-the-line cell phone.
OK, maybe you’re not so vain that appearances are a big deal. I tried to get over it. I really did. I promise I won’t talk about the style thing any more.
I opened the clamshell and turned on the phone.
The screen lit up instantly! Wow, something about this phone is nice.
Oh, wait a minute. What’s going on there?
The main screen shifts between pictures of Mount Fuji, the Eiffel Tower, etc. That’s charming. But what’s that bus?
There’s a cheezy little black and white child’s drawing of a bus bouncing up and down in front of the cheezy tourist pictures. Again with the Fisher Price Toy theme. The first thing I try to do is find a better screen saver. Everything looks like some kid’s 6th grade BASIC graphics project. Oooh, look, colored squares flying around. Terrible clip art of a “DJ”. One of the screen savers is called “Funny.” You get a silhouette of a lizard climbing around on a pink background. Bwa ha ha! That is funny. TO TWO YEAR OLDS.
OK, ok, I promised I’d stop talking about style. On to UI design.
The main menu was really, really confusing.
The first thing you see when you click on the Menu button is that you missed some alerts:
Although, it turns out, you didn’t, that’s just the name of the menu item that comes up first.
You can’t see all the icons at once because someone had the bright idea of using a weird 3-D perspective, and the currently selected icon comes zooming out in front, covering up some of the other icons. All the unselected icons are shown in silhouette, so at first they just look like a background. It took me quite a while to figure out just what the menu was and how to find things I wanted from the main menu.
But don’t worry… there are random bits of sparkle that fly around on the screen. That’s the important part. The random bits of sparkle, again, a 6th grader’s BASIC graphics project.
Now, on to the whole reason I wanted this phone: the MP3 player.
There’s no desktop integration, no ITunes integration, no feature for subscribing to Podcasts, nothing like that. When you plug the phone into your computer using the supplied USB cable, it thinks you want to use the phone as a modem. Yes, one day I might want to do that, that’s true, but for now I just wanted to get MP3s onto the thing. Somehow, somewhere, I managed to stumble on a menu that made the phone act like a USB hard drive. Tada! The phone pops up on my computer looking like a hard drive. And then there was already a MUSIC folder there, and I could drag MP3 files in. Yay! I downloaded TWiT episode 69 manually and headed off to the subway to listen to it.
Wait… I need headphones. Ahh, here they are. Wait a minute. The headphone cord is only about 8 inches long. Am I supposed to hold the phone up to my chin to listen to music?
Oh, I see, there are two cords. You have to plug the headphone cord into the microphone cord and plug that into the phone. Now it’s long enough. OK, it’s awkward, but I can live with that.
To listen to the MP3s you’ve downloaded:
- Hit the MENU button
- Find the ON DEMAND menu item (I demand to hear MP3s!)
- Nope, that’s not what you wanted
- Hit BACK
- Nothing happens (darn!)
- OK, try END
- Do you want to exit this application?
- YES is already highlighted. Click OK.
- Huh? The application didn’t exit.
- Click END again.
- YES is already highlighted… oh… wait a minute! Maybe NO is highlighted? There’s no way to tell the difference. There are two choices, one is white and one is blue, it’s hard to see which is highlighted.
- Fool around with the cursor keys until you’re pretty sure that YES is highlighted. This is confusing, because the two-item menu wraps around, so the up button moves down and the down button moves up, or vice versa.
- Remove the battery and put it in again. That should get you back to the main menu.
- Media player? Is that what you want?
- Yeah, there’s something in here called Music…
- It has about 50 options. What do they mean? SIRIUS hits? MUSIC CHOICE? SIRIUS MUSIC? Some of them are listed as My Channels and some are listed as Available Channels. Which is which? The UI here is really getting confusing.
- OK, none of those options lets you listen to MP3s. It turns out there’s something called MUSIC on the Main Menu.
- Ahh, that brings up the happy “booting Java” screen which is so heartwarming. Thank you Sun Microsystems for bringing programming language advertisements into consumer electronics.
- The Java applet has two tabs, “Store” and “Player.” Try buying a song. It’s $5 for 3 songs. That’s a ripoff, Sprint. Apple already established that the fair price for one song is $0.99.
- OK, I just want to listen to Leo Laporte, dammit. Maybe the Player tab?
- Gotta choose between “All My Music” and “Create Playlist…”.
- W00t! THERE’S TWiT!
- Click on it, and listen to TWiT.
All right. TWiT is more than an hour long, and I only listened to half of the episode by the time I got home. Luckily, there’s a handy PAUSE button on the outside of the clamshell. Unluckily, it doesn’t work. Pressing it once informs you that the buttons are locked, and you have to press and hold the pause button to unlock. So you do that, and the key guard goes off, and you press the pause button again, and nothing happens, so you press it again, and finally you’ve paused the music.
In the meantime, if, say, hypothetically, you were pausing because you live in a country where the police brutalize people, and a policeman was brutalizing you, and you wanted to stop the music so you could try to figure out what the policeman wanted and perhaps there was some way if you could just hear him that you could get him to stop beating you with a riot bat, you’re already DEAD by the time you figure out how to make the pause button actually pause.
While the MP3 player is paused, the backlight on the external display just won’t go off. So inadvertently, the phone almost completely runs down its battery overnight staying in “Pause” mode.
Why not turn the phone off overnight? Well, because then I’d have to listen to the first half of TWiT all over again. Can’t you fast forward? No. Doesn’t it remember where you’re up to like an iPod? No. Pause is your only hope.
The next morning, with a single bar of battery juice left, I got into the subway and resumed listening to the podcast, and I’m a wise guy, so I decided to see what the battery looked like, and of course, the phone lost power, oops, lost my place in the Podcast.
Put back the battery. Turn on the phone. Go into the MP3 player again. There’s no signal, and, guess what? You can’t get into to the MP3 player unless you can establish a network connection to the Sprint Music Store. Even to play your own MP3s!
OK, so this is an MP3 player that doesn’t really work on the subway and won’t work on a plane, the two places I’m most likely to listen to MP3s. Not very appealing.
A little bit more exploring and I discovered that there’s another entirely separate MP3 player on this device. It’s hard to find. You have to go to Tools, then Memory Card, then to the Music folder, and another MP3 player starts up which you can use to listen to your MP3s. For this player, you don’t have to be on the network, so it works in the subway, but—get this—the minute you close the clamshell, the music stops! I am literally not making this up. There are two bad MP3 players on this device, neither one of which remembers where you’re up to, neither one of which can be used on the subway with the phone folded in my pocket, neither one of which has a fast-forward feature.
I have literally never seen such a useless MP3 player.
OK, onward. Yes, you can watch movies on this phone. For example, for $5.95 a month, you can get something called mFLIX. Until you pay the money, there’s no way to find out what mFLIX is or what it is you’re getting for your $5.95. I’ll tell you what you get: a bunch of garbage film-student videos that nobody would ever vote up on YouTube, in a tiny blurry window that reminds you of QuickTime 1.0 (“look! It’s on a computer but it’s moving!”).
That was disappointing. I thought this thing was supposed to have full length movies somewhere. Ah yes, how about “MSpot Movies?” It says I’m going to get “Full-length Hollywood movies.” Only $6.95 a month. Yes. Buy buy buy. (Thankfully Uncle Sprint is paying for this). Oh look… you can preview before you commit to spending! Clicking Preview brings up a page that says PREVIEW with a “Done” button. That’s it.
OK, maybe they don’t want me to preview. Fine. After you click Buy, you’re thrown back to a main menu somewhere and then you have to remember what the hell you bought and go find it again. Annoying UI, again.
OK, MSpot Movies. A menu comes up with a bunch of folders:
- Classic Cartoons
- Freestyle Motorcross
- Nightmare In Blood
- The Projectionist
- Heart of a Champion
- One Love
I don’t understand. Are these movie titles? Not movie titles I’ve ever heard of. Yep, it’s true. What you get for $7/month is about 10 movies that seem to be in the public domain. Literally nothing worth watching, least of all on a smudgy 1 5/8” (diagonal), pixelated screen. I did, actually, as a part of my sacred duty as a reviewer, try to watch a whole movie. I could only stand about the first 1/3rd of it, and the battery was dying, and the phone was getting too hot to hold. I cannot imagine anybody finding any value in MSpot Movies. If Sprint makes any money off of them, it’s probably by mistake. This service is literally as much of a scam as those X-Ray glasses they used to advertise in comic books to steal a few bucks from some little kids.
The only kind of content you might really want to watch on this device is the stuff you find on YouTube, or video podcasts like The Show with zefrank. But that’s not what Sprint gives you. Instead they give you $7/month, ripoff, non-previewable scammy garbage.
A long time ago, I was working on MSN 1.0, and there was a long line of content providers working to make deals with Microsoft to put their content on the Microsoft Network, but in those days, it wasn’t clear exactly who should be paying who, so hardly any deals got made. In the meantime, the whole Web thing happened, where anybody could provide content without signing a deal with a Microsoft executive, and there was tons of content, and some of it was garbage, yes, but some of it was good, and we found the good stuff, and it floated to the top, and all was well, but Sprint doesn’t get this. They relish their ability to serve as the gatekeeper to what they hope will become a new medium, because the gatekeeper gets to charge tolls. And it’s 2006, and I almost can’t believe I’m writing this, because way back in 2000 I wrote almost exactly the same thing about WAP, and how cell phone companies keep failing to insert themselves as toll collectors because they’re so darn clueless about how the Internet works, and about the value of many-to-many networks instead of broadcast networks.
And now suddenly someone at Sprint read some book by Scoble and then they read Malcolm Gladwell’s theories of tipping points in the airport and Hey Presto! Maybe we can make this work by finding the tipping point people! You know, the bloggers! And all the bloggers get free cell phones, and Sprint gets tons of publicity, but frankly all the publicity in the world is not going to help them foist on us a product that is utterly pathetic. The phones they send us are so lame there is literally no area you can go into without being disappointed and shocked at just how shoddy everything is and how much it costs and what a rip off scam they’re trying to run here with the music that costs too much and the movies that you don’t want to watch on the screen that makes them unwatchable and you just KNOW that if you call to cancel the extra $7/month, their customer service department is going to give you the phone menu runaround and then put you on hold for an hour and then you’ll get some cancellation specialist with an incomprehensible accent who will spend 15 minutes trying to talk you out of canceling the useless service until you just give up and let them have the goddamned $7 a month. No amount of pampering bloggers and calling them Ambassadors is going to get around the fact that you’re sending us plastic junk phones that look like bath toys. (Hey, does it float?) All the “tipping point” theories in the world won’t protect Sprint from the basic truth that the LG Fusic user interface could basically serve as an almost complete textbook for a semester-long course in user interface design, teaching students of usability exactly what NOT to do.
Wait a minute.
Wait just one minute.
Maybe I completely missed the point.
Maybe this phone is for four year olds!
It all makes sense now!
The nonsensical menus don’t matter—four year olds can’t read! The toy-like appearance—duh! The ripoff movies—who cares, as long as the kids press BUY by mistake and the parents keep paying the bills!
Now I get it.
So really the only stupid thing that Sprint did is to send this phone to a bunch of know-it-all, hipster-wannabe, pretentious early-adopter engadget-reading 41-year-old bloggers, with our pretentious black iPods and our sleek gun metal RAZRs and our MacBook Pros and our so-called “Podcast” listening habits, watching zefrank tell potty jokes about The Decider.
No no no no no. This phone is for 4 year olds, albeit spoiled 4 year olds with rich parents. They’ll love the colors, the plastic, the impossible UI, they can watch the one 1936 movie that inadvertently fell into the public domain in class when the teacher is getting boring, and they sure as heck aren’t going on a subway with that thing.
I gave the phone to a friend’s 4-year-old.
MarkDown is a simple processor that converts text to HTML. For example, it converts *text surrounded by asterisks* to italics.
SmartyPants replaces “straight quotes” with “curly quotes” and makes a few other typographic improvements.
EditPad Pro is a very respectable text editor for Windows. It’s fast and contains scrillions of useful features. It’s not the fanciest thing in the world, but if you’re still using Notepad for the occasional bits of text, it’s a fine drop-in replacement.
Here’s what it takes to get them all working together on a typical Windows setup:
- Install Perl, if you don’t already have it. For Windows, the easiest way to do this is from ActiveState’s download page. Just download the Windows MSI package and run it. Make sure to choose the option to associate .pl files with Perl.
- Go into c:\Perl and make a directory called markdown.
- Download Markdown and SmartyPants. Open the ZIP files and put Markdown.pl and SmartyPants.pl in the directory you just made, c:\perl\Markdown.
- Also in that directory, make a little batch file named md.bat:
c:\perl\markdown\Markdown.pl %1 > "%~dpn1.tmp"
c:\perl\markdown\SmartyPants.pl "%~dpn1.tmp" > "%~dpn1.html"
start "" "%~dpn1.html"
- In EditPad Pro, choose Tools | Configure Tools. Click New. Set the Caption to “MarkDown”, and set the Command Line to
c:\perl\markdown\md.bat "%FILE%". You may want to check the box in the Files tab that says “Save the current file if it has unsaved changes.”
- Now you have a menu item Tools|Markdown which will save the file you’re working on and generate an HTML version of it (replacing the extension you used with .html), then it pops it up in a web browser so you can check it.
Avi Bryant describes a method for making method calls really fast, even if they do happen to be duck-typed. Cool!
(Ruby’s still slow. Film at 11.)
Jack Herrington emailed me, in reference to the issue of Ruby on Rails performance, to write:
I agree with you about unicode. And I agree that Rails needs some time to evolve. But I use a bunch of web technologies and they all have issues.
I do disagree with the scalability statements. I don’t think Rails has scaling issues that can’t be gotten around, and which don’t have cousins in other technologies.
What I would ask is that you at least put some framing around your scalability comments. Tell us about the scalability problems. Even if we don’t fix it for you, the entire community can gain from your experience.
David Heinemeier Hansson wrote:
Rails is for the vast majority of web applications Fast Enough. We got sites doing millions of dynamic page views per day. If you end up being with the Yahoo or Amazon front page, it’s unlikely that an off-the-shelve framework in ANY language will do you much good. You’ll probably have to roll your own. But sure, I’d like free CPU cycles too. I just happen to care much more about free developer cycles and am willing to trade the former for the latter.
By way of clarification, I’m not concerned with Rails performance, I’m concerned with Ruby performance, and here’s why.
I’ve seen lots of comparisons of Ruby’s performance with bytecode languages like Java which I would consider slow, and I see a lot of reports of performance claiming Ruby is 10x slower, 50x slower, etc. Besides the random blogobuzz, Ruby comes pretty darn close to dead last in the Computer Language Shootout Benchmarks.
Without knowing much about the implementation of Ruby, I would guess that the biggest issue is around late binding and especially duck typing, which prevents type inference or strong typing, which means that function calls will always be slow because you can never get something compiled down to the point where a function call is just a single CALL instruction (on x86)… you always have to be exploring the object, possibly even scanning a hash table to find the function you want to call. Calling methods on objects is really, really, really, really common, especially in pure OO languages, and that bit of the code needs to get down to at least a CALL indirect on the CPU for Ruby to offer the same performance as languages where the type of the object can be determined at compile time and therefore the instruction where you’re jumping to can be gotten either at compile time (like in C) or with a single indirection through a single vtable (like in C++).
I understand the philosophy that developer cycles are more important than cpu cycles, but frankly that’s just a bumper-sticker slogan and not fair to the people who are complaining about performance. Even though our product, FogBugz, seems like something that should be perfect for Ruby on Rails, we have several parts of code where performance is extremely important. In FogBugz 6 there’s one place where we need to do literally millions of calculations to display a single chart on a single web page. We have gotten it down to 3 seconds or so in our current development environment with a lot of optimization, but frankly with a duck-typed function call I really don’t think we could do it before the web browser gave up and timed out and the sun cooled down a couple of degrees. We also have to scan incoming email messages for spam using Bayesian filtering. This is compute-intensive can take 1 sec. per message. Receiving one email per second is not unreasonable for many of our customers so we are very close to being CPU pegged. That is using a language which we know to be orders of magnitude faster than Ruby at this type of code. We would be absolutely dead on Ruby.
Even classic, simple CRUD applications — the kind of application that basically just shows you a table from a database and gives you operations to add, delete, and edit records — often discover somewhere down the line that there’s something enormously computationally intensive that they want to do, for example, blog software might want to add Bayesian filtering to eliminate spam from comments. This is where you suddenly realize that if your language of choice is 10x slower than the competition, you may be simply unable to add that feature, or you may have to call out to another language (with all the marshalling overhead that implies).
This doesn’t apply to everyone, but when people say they have performance problems with Ruby or that they just need to be able to run code faster than the core Ruby language engine can run it, it doesn’t help to have Ruby advocates singing hymns about developer cycles vs. CPU cycles. Even if you aren’t doing compute-intensive things, if you find yourself needing to buy 100 servers instead of 10 servers, you may suddenly revisit the whole developer cycle vs. CPU cycle equation.
I understand that there are plans for Ruby to address performance with some kind of bytecode compiler and that will be nice. When these things happen and when Ruby starts getting competitive benchmarks it will be a lot more appropriate for a lot more types of applications. In the meantime I stand by my claim that it’s not appropriate for every situation.
Normally I use CityDesk to compose things for Joel on Software, but the long articles on recruiting were written from home where I have a MacBook Pro (CityDesk is Windows only).
I was trying to find appropriate software that I could use to compose long articles that felt smooth on a Mac, that generated extremely clean HTML, and that generated curly quotes (“”) which I’ve grown fond of, especially for longer articles.
The combination I found that made me happiest was TextMate in Markdown mode. It was a surprisingly good experience. TextMate is an “emacs inspired” editor for the Mac, with tons of build-in stuff for editing different types of text files that they call Bundles. Markdown is a very simple way to format text, for example, putting *asterisks* around text that you want italicized; it generates nice clean HTML. Even Markdown source is quite clean and still highly readable, useful if you need to post the same content to Usenet or use it in plain text somewhere.
I have a few complaints though:
OS X antialiasing, especially, it seems, with the monospaced fonts, just isn’t as good as Windows ClearType. Apple has some room to improve in this area; the fonts were blurry on the edges.
Also, I don’t understand all these people who say that Macs never crash. I probably had to reboot the MacBook Pro (hard reboot — hold down the power button for five seconds) about every two hours. It was always the same problem: the Wifi network would go down for a second, something which happens to everyone, but on Windows, it just comes back, while on the Mac, I get a spinning colored ball and everything is frozen. Everything. Forever. If I try to wait it out the beachball will still be spinning the next morning. If anybody is aware of this problem and knows of a specific fix I’d love to hear of it. It was like a Windows 3.1 deja vu all over again thing.
I still have to say that composing large amounts of text with Word 2007 on Windows XP is a better experience, all told, because of the autocorrection and the better screen display.
One more note — all the pictures I’ve published in the last few days are of the Fog Creek office, of course, taken recently by photographer Gregg Conde.
The standard job application of cover letter plus resume is a phenomenally weak way to introduce a candidate. They give you only the faintest clues as to the quality of an applicant.
Sometimes, though, a resume gives pretty strong negative clues which allow you to screen out applicants without going much further. Once I got a resume from someone who claimed to be an expert in Microsoft Window [sic] programming. Another time the only experience listed on the application was a job at Dunkin’ Donuts. That resume did a pretty good job of following all the suggestions that high school career-guidance advisors love to give out (this guy “managed trays of donuts”) but there was not a smidgen of evidence that the applicant had ever seen a computer.
Other than that, though, it can be extremely hard to tell much about a candidate from a resume. Our policy at Fog Creek, then, has three parts:
- We try to be selective about how we advertise our jobs, so as to limit the amount of noise in the resume pile.
- We certainly don’t hire based on resumes; we only screen out based on resumes to reduce the number of people whom we have to interview.
- In order to sort the remaining resumes to decide what order to interview people, we use a strictly objective system of reviewing and scoring them, so at least we are being fair and consistent in our interpretation of that very weak signal that comes from resumes.
There are several fairly objective measures that we look at, again, solely for the purpose of sorting resumes so that the first people we call are the ones that are most likely to work out.
Passion. We look for evidence that the applicant is passionate about computers and really loves programming. Typical evidence of this:
Jobs with computers or experience programming going back to a very early age. Great programmers are more likely to have spent a summer at computer camp, or building an online appointment scheduler for their uncle the dentist, rather than working at Banana Republic folding clothes.
Extra-curricular activities. People who love programming often work on their own programming projects (or contribute to an open-source project) in their spare time.
Waxing rhapsodic in their cover letter about how they were moved to tears by The Structure and Interpretation of Computer Programs.
Sometimes certain programming languages or technologies on a resume indicate evidence of someone who loves programming enough to explore new technologies. At the time I’m writing this, seeing Ruby on a resume is a good sign of the kind of programmer who loves to check out the latest thing and try to improve their skills because they’re passionate about programming, because not so many employers are really demanding Ruby yet. You have to be careful here; in 1996 Java on a resume was a sign of the same passion, but today it adds almost no information.
Pickiness. We look closely at the cover letter for evidence that the applicant really wants to work for us. We don’t want to see a generic cover letter talking about me, me, me: we want to see a coherent argument as to why they’ve thought about this seriously and concluded that Fog Creek is the place they want to work. There are two reasons for using this as a clue. First, it’s a sign that the candidate is not applying to hundreds of jobs at the same time. The fact that they took the time to learn about Fog Creek and wrote a custom cover letter just for us means that they have a lot of confidence in their abilities, so they’re applying to a select few employers, not bulk mailing a thousand. A bulk-mailed resume can be a symptom of desperation. More importantly, a custom cover letter is a sign that if we do make this candidate an offer, they’re likely to accept it. That improves our yield. If I only have time to interview six people, all else being equal, I’d rather interview six people who really want to work for Fog Creek, not generic smart people that are also applying to a hundred other jobs. All else being equal.
English. Scoring resumes by English skills was a hard decision for us to make, because computer programming is one of those fields where an immigrant who doesn’t speak English can still be a brilliant programmer. That said, years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler. It is crucial for documenting code, it is crucial for writing specifications and technical design documents that other people can review, and it’s crucial even for those meetings where you sit around discussing how to do something best: brilliant programmers who have trouble explaining their ideas just can’t make as much of a contribution. In this particular category, we also consider the neatness and orderliness of their resume. A disorganized resume rife with grammatical errors where nothing lines up is a pretty big red flag for a disorganized thinker or just general sloppiness; for many jobs this can be fine but not for software development. In particular we usually completely disqualify resumes that are full of English mistakes. It’s not that hard, even for a non-native speaker, to find someone to check your resume, and failure to do that usually reflects a profound lack of concern over the quality of the things that you do. That said, we try to be considerate of non-native speakers who are nonetheless excellent communicators: leaving out articles in that charming Eastern European way, or starting every paragraph with “So” in charming Pacific Northwestian way, is not a showstopper.
Brains. In this category we’re looking for evidence that a candidate is, well, smart, or at least, the kind of nerdy brainiac that went to math camp. Signs of this include high GPAs, high standardized test scores, honors societies like Phi Beta Kappa, people who participate in Top Coder competitions, play competitive chess, or go to ACM Programming contests.
Selectivity. Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past. Not everyone at Ivy League schools is worth hiring, and not everyone at community college is worth avoiding, but getting into a very selective school does at least mean that someone, somewhere judged you using some kind of selection process and decided that you were pretty smart. Our company criterion for selectivity is usually getting into a school or program that accepts less than 30% of its applicants (there are about 60 schools in the US that meet this standard), or working for a company which is known to have a difficult application process, like a whole day of interviews. Highly selective branches of the military like officer’s training or pilot’s courses, or even just getting into the Marines indicates someone that has made it through some kind of difficult application/selection procedure and all in all this is a positive sign.
Hard-core. For experienced programmers, there are certain technologies that are considered somewhat more hard-core than others, simply because they are, well, harder to do well. Again, this is a pretty weak indicator, but all else being equal, I’m more impressed by someone who has done work in OCaml than someone who has worked in Java. Assembler or device-driver or kernel work is somewhat more impressive than Visual Basic or PHP. C++ with ATL is harder than Perl. People who have worked on operating systems or compilers are more hard core than people who have worked on simple database front-ends.
I’m sure that this will be seen as incendiary; after all, most of my personal programming experience in the past five years is with VBScript, which is sort of like a version of Visual Basic dumbed down for people with severe brain trauma. Remember again that I said that resumes are a very weak way of judging programmers and you only get the faintest signals from them; that said, some technologies are just harder than other technologies and if you happened to have worked with them successfully, there’s a smidgen more evidence that you might be the right person to hire, so for the purpose of sorting resumes, difficult technologies tend to float you to the top, while claiming competence in, say, Microsoft Word tends to float you toward the bottom.
Diversity. Before I start a massive flame war of international scope by using the loaded term “diversity,” let me carefully define what I mean by this. Specifically, I’m looking for people who come from enough of a different background than the existing team that they are likely to bring new ideas and new ways of thinking to the team and challenge any incipient groupthink that is likely to keep us boxed into our own echo-chamber way of thinking about things. When I say different background, I mean culturally, socially, and professionally. Someone who has a lot of experience with enterprise software may bring useful diversity to a team of internet programmers. Someone who grew up poor is going to bring useful diversity to a startup full of Andover preppies. A stay-at-home mom rejoining the workplace may bring useful diversity to a team of recent graduates. An electrical engineer with Assembler experience may bring useful diversity to a team of Lisp hackers. A recent college graduate from Estonia may bring useful diversity to a team of experienced management consultants from the midwest. The only theory here is that the more diverse your team is, the more likely that someone on the team will have some experience in their background that allows them to come up with a different solution.
It is really really important to remember that these categories—Passion, Pickiness, English, Brains, Selectivity, Hard-Core, and Diversity—are not hiring criteria. They are just too weak for that. There are way too many excellent people who would score low on this test or poor programmers who would score high. Before you go off ranting about how Joel only thinks you should hire from the Ivy League, or that I have some kind of GPA fetish, or whatnot, it’s important to understand that this list is just not a list of reasons to hire someone or reject someone. All it is is an objective and fair way to sort a big pile of resumes to find the candidates who are most likely to work out so that you can interview them first, and then decide if they’re worth hiring.
If resumes are so weak, can’t we add some other hoops?
This is certainly not, by any stretch of the imagination, the ideal set of rules for sorting resumes. I’d much rather be able to sort resumes by the candidate’s ability to implement a recursive algorithm, how long it takes them to find a bug in code, or whether or not they can keep nine items in short term memory, all of which are better indicators of success as programmers than things like whether you got past an elite college’s admissions committee. Unfortunately, those things aren’t on resumes.
One temptation of recruiters is to try and add a few extra hoops to the application process. I’ve frequently heard the suggestion of including a programming quiz of some sort in the application procedure. This does work, in the sense that it reduces the number of applications you get, but it doesn’t work, in the sense that it doesn’t really improve the quality. Great developers have enough choices of places to work that only require the usual cover letter/resume application to get started; by inventing artificial hoops and programming tests and whatnot simply to apply, you’re just as likely to scare away good programmers as weak programmers. Indeed, you may be more likely to scare away the best programmers, who have the most alternatives, and get left with a pool of fairly desperate candidates who are willing to do extra work to apply simply because they don’t have any alternatives.
Don’t look for experience with particular technologies
Once I was on a panel at NYU giving students advice on careers in I.T. My advice, excerpted from this article, was that before graduating you should make sure to learn how to write well, maybe by taking a creative writing course, and take a class in Econ so that the business side of the business isn’t a mystery. I also recommended at least one low-level programming course in C or Assembler just to help you understand how computers work at a lower level.
On the panel with me was a nice chap from a local headhunter, in fact, one of the better tech recruiters in the city. His speech consisted of 15 minutes of tedious alphabet soup. “We’re seeing a lot of XML, some C++, SOAP and WSDL are getting hot but you’re not seeing as much COM or even ATL.” And on, and on, until my eyes were spinning. This was a fellow who entirely thought of the world in terms of keywords on resumes.
To top programmers, the most maddening thing about recruiters is their almost morbid fascination with keywords and buzzwords. The entire industry of professional headhunters and recruiters is bizarrely fixated on the simple algorithm of matching candidates to positions by looking for candidates that have the complete list of technology acronyms that the employer happens to be looking for. It becomes especially infuriating to realize that most of these recruiters have no idea what any of these technologies are. “Oh, you don’t have MSMQ experience? Never mind.” At least when real estate agents prattle on about Subzero refrigerators and Viking stoves, they at least know what these things are (although any stainless steel refrigerator counts as “Subzero” these days). The easiest way to catch-out a technical recruiter is when they inevitably insist on 5 years of experience with Ruby on Rails, or refuse to consider someone for a “Windows API” job when they only have “Win32” on their resume.
The reason recruiters do this is because it’s easy, it can be computerized, and it’s the only way they know how to judge developers.
For almost all software development positions, though, it is the worst possible way to hire.
Our philosophy is that we’re hiring for the long term, and any technology you happen to know right now may well be obsolete next year. Furthermore, some of these technologies are very easy to learn. If I needed to hire someone to do Ruby development, someone with extensive Smalltalk and Python experience who had never even heard of Ruby would be a lot more likely to be successful than someone who read a book about Ruby once. For someone who is basically a good software developer, learning another programming language is just not going to be a big deal. In two weeks they’ll be pretty productive. In two years, you may need them to do something completely different in a programming language which hasn’t even been invented.
The keywords section of a resume can’t be trusted much, anyway: every working programmer knows about these computer programs that filter resumes based on keywords, so they usually have a section of their resume containing every technology they have ever touched, solely to get through the filters.
There is, I think, one exception to this rule. If you’re hiring an architect or head developer—that is, the chief software engineer who is going to have to lay out the initial code and figure out how things work together, you probably want to hire someone with a lot of experience in the technology that you’re using. A team developing GUIs for Windows using C++ and MFC is going to need at least one Windows/MFC guru somewhere on the team who can make sure that the code is organized correctly in the first place and who has enough experience to know how to solve the really hard problems that might come up.
Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on. If you have a choice of platforms, use the one your team has the most skills with, even if it’s not the trendiest or nominally the most productive. Occasionally, this may mean you interview to find a candidate with really extensive experience in a particular set of technologies (not keywords, mind you: the whole stack, such as LAMP or .NET or J2EE). But most of your software developers should not be hired by keyword matching.
Sorting resumes is only one aspect of the hiring process, which includes making an environment that is attractive to programmers, attracting good resumes in the first place, and using a rigorous interview process that helps you hire the programmers who can hit the high notes.
Last year we set the application deadline for internships to February 1st, which was fine, and the deadline did a good job of forcing students to get off their butts and apply, but we made the mistake of not considering applications until they were all in, which we thought would be most fair. It was fair, but it also meant that by the time we even looked at the resumes, some great applicants had already accepted summer jobs at Microsoft. Grr…
This year summer internship applications will be accepted on a first-come, first-served basis, so basically, if you’re a college student looking for an internship, you pretty much should just apply now, instead of puttering around indecisively.
If you are trying to install Windows Vista RC1 in VMWare Workstation, you may see setup appear to hang on the text-mode screen that says “Windows is loading files…”.
Actually what has happened is that Vista Setup is already in graphics mode trying to do things, but something about the way it switches the display adapter into graphics mode is not working right on VMWare.
If I were VMWare I’d be pretty ticked off at Microsoft right now; since Microsoft makes a competitive product, Virtual PC, it is Highly Suspicious that they come out with a major new test release of an operating system that just happens to not work on VMWare Workstation, something which is practically the de facto standard for developers testing new operating systems. Shabby and slimy, Microsoft. They’re probably testing Windows Vista with tens of thousands of applications; not testing with VMWare is inexcusable.
There’s a workaround, for now, while VMWare works on the problem: edit the virtual machine’s .vmx file to include
svga.maxWidth = “640”
svga.maxHeight = “480”
You can get Vista installed in VGA 16 color 640×480 mode (it will look awful) and then when you get everything running, install VMWare tools and take out those two lines and you’ll be good to go. Thanks to anonymous user echelon9 from the VMWare board for this tip.
I’m assuming that the Aero/Glass UI’s heavy demands on the graphic card may mean that it can’t be tested under VMWare, but I’d love to be wrong.