Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
92250 items (84459 unread) in 19 feeds
Friends
(838 unread)
Build
(58738 unread)
Heads
(589 unread)
News
(24087 unread)
fun
(207 unread)
Heads (100 unread)
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
A few people heard me on This Week in Startups (starting at 15:45) asking Jason if we should take money from the first VC who fell into our laps, or spend time doing the Sand Hill Road rounds, meeting more VCs, and doing a road show for the other firms that might be interested in investing.
Jason (and his guest James Segil) both agree that we should take more time picking the right partner. We’re going to be in bed with these guys for years, they say, and we have to approach this like picking a spouse.
Anyway, people emailed me in shock and surprise that we would even consider VC, considering the things I’ve written.
![]()
flickr.com/photos/niznoz / CC BY-NC-SA 2.0Why are we seeking venture capital for StackOverflow?
Almost ten years ago, I wrote about two kinds of companies, the Ben and Jerry’s type of company, which grows carefully and organically, and the Amazon type, which uses huge amounts of investment capital to get big quickly.
At the time, I had no doubt that I wanted Fog Creek to be a Ben and Jerry’s type of company, and that model has served us well. By staying profitable and growing carefully, we’ve managed to survive two big downturns and we’ve grown into a stable, 34-person company that’s a great place to work and is likely to remain stable, and a great place to work, for a long time.
StackOverflow, though, is a bit of a different story.
There are a few indicators for the type of company that I believe can benefit from, and should take, VC.
There are counter-indicators, of course: signs that you shouldn’t consider VC. Here are just a few off the top of my head:
When I put all these things together the conclusion is that StackOverflow is one of those rare companies for which VC can really work. Jeff and I started out with a goal for StackOverflow of changing the way programmers and system administrators get answers to their questions on the Internet, which was deeply broken. In 18 months we’ve accomplish that: we’ve got 6 million unique visitors every month. Now we’re biting off the bigger goal of changing the way everyone gets answers to their questions on the Internet, and that’s something we can’t do alone.
So, off I go, on a StackOverflow road show. I’ll be in Silicon Valley Feb 24-Mar 3; drop me a line if you want to get together.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
In the early days of a technology startup, you tend to have a lot of software developers, and you feel like you could never have enough. If you hire sales and marketing staff too early, they don’t really get much traction, and you may start to think that sales and marketing are a waste of time. This led me, in the early years, to believe that a healthy software company should have a lot of real software developers and maybe no sales and marketing.
At one point I entertained the quixotic and, retrospectively, stupid idea of requiring every employee at Fog Creek to be a programmer... even the receptionist would have to have done some BASIC programming in high school to qualify. In the US Marines everyone, even the cooks, is a rifleman. Of course that’s because the cooks are in friggin Afghanistan getting shot at so they better be riflemen, whereas our receptionist almost never has to drop into the source code and bang out a class. Almost never.
Over time, though, as your product gets better and better, the more sales and marketing people you hire, the more you sell.
That’s because programmers multiply salespeople, and vice-versa.
I’m a nerd, so I’ll be real math-y about this. Define the quality of your code on a scale from 0 to 1.
0 means your product solves absolutely no problems for anybody so nobody in their right mind would ever buy it. Microsoft Bob.
1 means that every single person on Earth, if they bought your software, would be net happier, even after paying your fee.
Your software starts at 0 and slowly climbs up the hill.
If everybody in the world knew about your software and was encouraged to evaluate it, the number that would buy it would be (Earth population) x Quality.
Sales and marketing functions exist to encourage earthlings to find out about your software and evaluate it. These functions will have no effect on sales if your quality is extremely low. But as the quality gets higher, the value of sales and marketing goes up, commensurately. Double the quality, and the same sales effort yields double the revenue.
The population of the planet is so large, and the effect of sales and marketing so hard to scale, that by the time your product is really great, the optimal ratio might be very heavily tilted in favor of sales and marketing. Large software companies might have 5 or 10 or 20 people in the sales organization for every developer.
This explains, among other things, why US software companies can’t expect to get sustainable advantage by offshoring software development to cheaper countries. If a developer in Russia, India, or China costs 50% as much as a developer in Seattle, San Francisco, or Boston, but software development is only 10% of your costs, you can only get a 5% advantage from offshoring development. The offshoring that does happen is strongly biased to custom software development which, by design, can only solve one person’s problem, so more developers than marketers are needed.
It is not the case (as commonly believed by nerds) that marketing is a substitute for code quality. The best marketing in the world cannot force people to pay for a useless product.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
My sister got her kids a little puppy, and they’ve been trying to train it. To live with a dog in the house, you need to teach it not to jump on people, not to poop in the house, to sit on command, and to never, ever, ever chew on the iPad. Never. Good girl.
With dogs the main trick to training is that feedback has to be immediate. If you come home to discover that, hours before, the dog tipped over the garbage can in the kitchen, it’s too late for training. You can yell at her but she just won’t get what you’re going on about. Dogs are just not that smart.
For programmers, getting better at what you do requires quick feedback, positive and negative, on what you’ve just done. The faster you get the feedback, the faster you’ll learn. With long-cycle shrinkwrap software, it can take a year or more to hear feedback from customers.
That’s one of the reasons we have testers. A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.
Who should be a tester? That’s tricky! Software testing is one of those careers that isn’t that well known, so a lot of people who would be great at testing and would probably enjoy it a lot never consider applying for jobs as testers.
Signs of a good tester:
You don’t have to be a programmer to be a tester. A lot of companies want testers to be programmers who write automated test suites. It seems more efficient that way. This reflects a misunderstanding of what testers are supposed to do, which is evaluate new code, find the good things, find the bad things, and give positive and negative reinforcement to the developers. Sure, automated test suites are a time saver, but testing software covers so much more than that. If you put too much emphasis on those scripts, you won’t notice misaligned text, hostile user interfaces, bad color choices, and inconsistency. Worse, you’ll have a culture of testers frantically working to get their own code working, which crowds out what you need them to do: evaluate someone else’s code.
A particularly terrible idea is to offer testing jobs to the programmers who apply for jobs at your company and aren’t good enough to be programmers. Testers don’t have to be programmers, but if you spend long enough acting like a tester is just an incompetent programmer, eventually you’re building a team of incompetent programmers, not a team of competent testers. Since testing can be taught on the job, but general intelligence can’t, you really need very smart people as testers, even if they don’t have relevant experience. Many of the best testers I’ve worked with didn’t even realize they wanted to be testers until someone offered them the job.
If you:
you should consider being a tester. (We’re hiring! What a coincidence!)
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Steve Krug has written a follow up to his usability classic Don’t Make Me Think. The sequel, Rocket Surgery Made Easy, is a terrific, short, concise, fun guide to running simple “hallway” usability tests to improve the usability of your software and websites. Highly recommended.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
“As companies expand, the people within them start to specialize. At such a point, some managers will conclude that they have a ‘keep everyone on the same page’ problem. But often what they actually have is a ‘stop people from meddling when there are already enough smart people working on something’ problem.”
From my latest Inc. column: A Little Less Conversation
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Microsoft Careers: “If you’re looking for a new role where you’ll focus on one of the biggest issues that is top of mind for KT and Steve B in ‘Compete’, build a complete left to right understanding of the subsidiary, have a large amount of executive exposure, build and manage the activities of a v-team of 13 district Linux& Open Office Compete Leads, and develop a broad set of marketing skills and report to a management team committed to development and recognized for high WHI this is the position for you!”
This is ironic, to use the Alanis Morissette meaning of the word [NSFW video].
The whole reason Microsoft even needs a v-team of 13, um, “V DASHES” to compete against Open Office is that they’ve become so insular that their job postings are full of incomprehensible jargon and acronyms which nobody outside the company can understand. With 93,000 employees, nobody ever talks to anyone outside the company, so it's no surprise they've become a bizarre borg of "KT", "Steve B", "v-team", "high WHI," CSI, GM, BG, BMO (bowel movements?) and whatnot.
When I worked at Microsoft almost two decades ago we made fun of IBM for having a different word for everything. Everybody said, "Hard Drive," IBM said "Fixed Disk." Everybody said, "PC," IBM said "Workstation." IBM must have had whole departments of people just to FACT CHECK the pages in their manuals which said, "This page intentionally left blank."
Now when you talk to anyone who has been at Microsoft for more than a week you can’t understand a word they’re saying. Which is OK, you can never understand geeks. But at Microsoft you can’t even understand the marketing people, and, what’s worse, they don’t seem to know that they’re speaking in their own special language, understood only to them.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Did you backup that server?
Are your backups on a different machine?
Do you have offsite backups?
All good questions, all best practices.
But let’s stop talking about “backups.” Doing a backup is too low a bar. Any experienced system administrator will tell you that they have a great backup plan, the trouble comes when you have to restore.
And that’s when you discover that:
The minimum bar for a reliable service is not that you have done a backup, but that you have done a restore. If you’re running a web service, you need to be able to show me that you can build a reasonably recent copy of the entire site, in a reasonable amount of time, on a new server or servers without ever accessing anything that was in the original data center. The bar is that you’ve done a restore.
Let’s stop asking people if they’re doing backups, and start asking if they’re doing restores.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
The higher someone’s Stack Overflow reputation, the more likely they are to have submitted a CV to Stack Overflow Careers:

This is not entirely surprising, of course: the more time someone has invested in Stack Overflow, the more likely they are to (a) know about Stack Overflow Careers, (b) be willing to invest $29, after all the hours they’ve already sunk, and (c) have the confidence that their CV is going to impress the kind of employers that are using the site.
Still, the participation rate in Stack Overflow Careers is pretty impressive, and it somewhat confirms the claim we’re making to employers, which is that when you search for CVs on Stack Overflow, you are looking at some pretty gosh darn good programmers.
While I’m rattling on about statistics, here’s a little bit of data about Stack Overflow traffic itself that you may not have seen.
We use Quantcast to measure our traffic. Currently, they’re showing us as the 740th ranked site in the world (of all sites), with 6 million monthly unique visitors, 1.9 million from the US. And the growth is pretty steady, except for a couple of weeks at the end there which reflect the holiday season:

Comparing our traffic to our big competitor is difficult because they don’t use Quantcast, so we have to rely on Alexa, which has a reputation for particularly terrible data, but here’s what that looks like:

Are there any sites out there for programmers with more traffic than Stack Overflow? I haven’t found any, using the available data... even msdn.microsoft.com has less, according to Quantcast, but I find that hard to believe.
In either case, having decided that Stack Overflow was the biggest programming site in the world, I thought, “hey, it should be easier for us to get ads.” I asked our ad guy, Alex “DailyWTF” Papadimoulis, if Microsoft had bought any ads. They’re about to launch Visual Studio 2010, which is probably going to have the biggest marketing campaign (in dollars) in the history of developer tools, and you’d think they’d want to spend something at the biggest programming site in the world. Here’s what he wrote back:
“Microsoft is doing huge spends, but they’re going through McCann for the VS2010 launch (IIRC). Agencies really don’t like us. Now if we go to video units with fly-over… oh they’ll start loving us!”
What he’s referring to is the fact that we don’t accept any kind of animated ads on Stack Overflow, because, well, they’re evil, so we lose a lot of revenue from advertising agencies who are looking for the most aggressive possible ways to get in people’s faces. Whatever. Don’t care. We hate animated ads and I’m pretty sure our users do, too.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
“Like most entrepreneurs, Ryan and I are still learning about how to manage people and teams. And we’re both used to hiring very smart and dedicated people who will get things done to a high standard if you give them some general direction and set them free. But on this trip, we started to notice that this style of hands-off management, which works so well with our own staffs, just wasn’t working when we had outside vendors involved.”
From my December column in Inc.: “When and How to Micromanage”
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
For as long as I’ve been in the industry, which is, I think, about 74 years now, the problem I’ve had with hiring programmers was not interviewing them or deciding if they’re smart—it’s been finding them in the first place.
What I’ve dreamed about is a programmer search engine.
The ideal programmer search engine would only include programmers who are actually looking for jobs. If you’ve ever emailed someone based on a resume you found through a traditional search engine, you’ve probably discovered that they’re not actually on the market.
It would only include people willing to work in your neck of the woods.
It would show you CVs right away, and, ideally, it would show you something about their programming skills besides the usual resume blahblah.
Well, OK, that day is here, and I’m like a kid in a candy store. Nom nom. Announcing the other half of careers.stackoverflow.com: the employer’s side!
Right now, there are about 928 candidates on there. That’s a start. What’s more interesting is whether there’s a candidate who meets your needs.
Let’s say you’re searching for a full time Java programmer within 40 miles of Palo Alto. Right now there are 11 candidates listed. All but one are active on StackOverflow... one even has reputation over 4000 points.
Want a bit more choice? Check the box that indicates that you’re willing to relocate. Now there are 80 matches, all of whom have the legal right to work in the states. Candidates have a lot of flexibility indicating where they’re willing to work. Even if you need a Ruby on Rails programmer in Oklahoma City, as long as you’re willing to pay for relocation, you’ve got 7 choices. You’ve got 14 choices in London (with the legal right to work.) If you think that a Python programmer could learn Ruby, you’ve got 51 choices. There are plenty of choices whether you’re hiring in Tel Aviv, Sydney, Silicon Valley, or New York. There are four programmers in Copenhagen right now. No relocation required. All of them highly qualified, actually; any one of them would qualify to interview at Fog Creek.
Stack Overflow Careers is something of a chicken-and-egg business. We have to get a big audience of programmers and a big audience of employers all at the same time, and then it’s like a junior high school dance, with the boys on one side of the gym and the girls on the other side, and for a while you just sit there holding your breath to see if anyone will dance. We invited a few hundred employers as beta testers... these were the companies that have been listing jobs on StackOverflow over the last six months, and so far, they’ve found a few dozen candidates that they liked. Once it gets to that point, we’re out of the loop, so we don’t really know how many people are actually finding jobs, but please email me your success stories and failure stories so we can keep working to make it better.
In the meantime, Jeff and the StackOverflow crew have done something brilliant: they’ve made it possible to do searches and see how many candidates match even before you have to pay. So if you want to try it out but are afraid that there aren’t students looking for OCaml internships in Houston, you can try it, and find that there is, indeed, one. So, try it out right now. There’s no obligation, and we’re happy to give you your money back if you don’t think you got good value.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Do you like your job?
Do you enjoy the people you work with?
Would you want to have lunch with them? Every day? Alex Papadimoulis thinks that Fog![]()
Tyler Griffin Hicks-Wright Creek’s free lunches are “cultish,” but everyone at Fog Creek loves them. Maybe it’s the mandatory brain implant we install in each new worker, but I like to think that we just enjoy eating together because we genuinely like each other and like spending time together. If you can’t imagine eating lunch every day with your coworkers, I hate to break it to you: you might not like them. Is it OK to spend most of your waking hours with people you don’t like?
Do you actually enjoy doing your job? If you wake up an hour early in the morning, do you think, “Yay! I can go in early and get another hour of work in!” Or does that sound ridiculous to you?
Are you learning? When was the last time you had to learn a new skill? Is this year kind of like last year, or are you doing something new, stretching yourself, challenging yourself to be better?
At one of the recent DevDays events, I asked the audience (almost 100% programmers) how many of them were incredibly satisfied with their job, found it fulfilling, and were treated well by their employers. Only about 25% of the hands went up. I asked how many people either hated their job and couldn’t wait to find something better, or were actually actively on the job market. Again, about 25%. The rest were somewhere in the middle: maybe they can tolerate their job, but they’re keeping an eye open for something better.
Who is this DevDays audience? They’re the elite of the elite of the best programmers out there. They’re the people who participate in Stack Overflow, the people who read, the people who are constantly trying to learn more about programming and software development. More than half of them paid their own money to attend a one day conference. They’re the most desirable software developers on the planet. And 75% of them are not delighted with their job.
That’s unacceptable. I’ve been saying for ten years that the top developers have a choice of where to work, and the top employers need to work harder to attract them, because the top developers get ten times as much work done as the average developers.
And yet, I still keep meeting ridiculously productive developers working in shitholes.
We’re going to fix this, right now. Thus, Stack Overflow Careers.
We’re going to completely turn the job market upside down, for the best software developers and the best companies.
This is a talent market. Developers are not even remotely interchangeable. Therefore, recruiting should work like Hollywood, not like union hiring halls of the last century.
In a union hiring hall, downtrodden workers line up like cogs, hoping to make it to the front of the line in time to get a few bucks for dinner.
In Hollywood, studios who need talent browse through portfolios, find two or three possible candidates, and make them great offers. And then they all try to outdo each other providing plush work environments and great benefits.
Here’s how Stack Overflow Careers will work. Instead of job seekers browsing through job listings, the employers will browse through the CVs of experienced developers.
Instead of deciding you hate your job and going out to find a better one, you’ll just keep your CV on file at Stack Overflow and you’ll get contacted by employers.
Instead of submitting a resume, you’ll fill out a CV, which links back to your Stack Overflow account, so that you can demonstrate your reputation in the community and show us all how smart you really are. To a hiring manager, the fact that you took the time to help a fellow programmer with a detailed answer in some obscure corner of programming knowledge, and demonstrated mastery, is a lot more relevant than the Latin Club you joined in school.
Employers can see how good you are at communicating, how well you explain things, how well you understand the tools that you’re using, and generally, if you’re a great developer or not. And they can see your peer reputation, so all that hard work you’ve been putting into helping people on Stack Overflow can karmically come back and help you upgrade your job to the latest, state-of-the-art, great place to work.
Stack Overflow has grown incredibly fast. After a year in business, it gets over a million page views most weekdays and currently stands as the 817th largest site on the Internet, according to Quantcast. It reaches 5.2 million people a month. But Stack Overflow Careers doesn’t have to be massive. It’s not for the 5.2 million people who visit Stack Overflow; it’s for the top 25,000 developers who participate actively. It’s not for every employer; it’s for the few that treat developers well and offer a place to work that’s genuinely fulfilling.
Read the FAQ, then go file your CV now, and upgrade your career.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
My new Inc. column is up. “For a guy who wrote a book on how to hire great programmers, it’s mortifying how incompetent I’ve been at enlarging the sales team, which, right now, consists of one terrific account executive and a dog. (I’m just kidding. There’s no dog.)”
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
What is your company about?
Recently I got inspired by Kathy Sierra, whose blog Creating Passionate Users and Head First series of books revolutionized developer education. She kept saying the same thing again and again: help your users be awesome.
Kathy taught me that if you can’t explain your mission in the form, “We help $TYPE_OF_PERSON be awesome at $THING,” you are not going to have passionate users. What’s your tagline? Can you fit it into that template?
It took us nine years, but we finally worked out what Fog Creek Software is all about, which I’ll tell you in a moment, but first, some backstory.
In the early days, we were all about making a great place to be a software developer in New York City.
Yep, that was all there was to it. Almost every software job in the city was terrible. You had a choice of which kind of terrible. Want to wear a suit and work long hours under crummy conditions? Take a job at a bank. Want to report to a manic-depressive creative who demands that you stretch HTML in ways that would have you put to death, in certain countries? Take a job at a media company. Want to work 24/7 in a basement with water pipes dripping on your head and get paid in worthless stock options? Take your pick of the revenue-free dotcom startups.
Why New York, then? There are lots of great product companies where software developers are treated very well in Redmond, Washington. But I was sick of trying to live in lesser cities. Sure, the Seattle area is beautiful, and green, and clean, and possesses great coffee, and I understand that there are even a couple of grocery stores open late now. But I’m staying in New York, because it’s the greatest city in the world.
I gave up the search, and decided to start a company with my buddy Michael Pryor. Making a nice place to work was our primary objective. We had private offices, flew first class, worked 40 hour weeks, and bought people lunch, Aeron chairs, and top of the line computers. We shared our ingenious formula with the world:

The tagline was “building the company where the best software developers want to work.” It was, to say the least, awkward. It didn’t make for a good elevator pitch. It didn’t really have the right format. “Abercrombie and Fitch: building the apparel store where the hottest teenagers will want to work.” Who cares? Not the hot teenagers, I’ll tell you that.
Anyway we accomplished that goal. Cross it off the list. What’s next? We needed a new mission statement.
And it has to be something of the form, “We help $TYPE_OF_PERSON be awesome at $THING.”
Bells went off. Everything we’ve done successfully has one thing in common: It’s all about helping software developers be awesome at making software.
That includes Joel on Software, Stack Overflow, all the books I’ve been writing, the conferences like DevDays and Business of Software, the Jobs Board and Stack Overflow Careers.
It includes our flagship product, FogBugz, which is all about giving developers tools that gently guide them from good to great. It’s the software implementation of the philosophy I’ve been writing about for a decade, lacking only one thing: the feature to replace exceptions with return values, while adding Hungarian prefixes to all variable names. THAT IS A JOKE, PEEPLE. Put DOWN the bazooka.
Helping you make more awesome software is why I write endlessly about what we’re doing at Fog Creek, despite the fact that people accuse me of shilling. I’m not writing to promote our products. You don’t have to buy our products to get the benefit of reading about my experience designing them and building them and selling them. I’m writing to share some of my experiences in case they can help you make better software.
Our focus on helping developers explains why one of our early products, CityDesk, flopped: it had nothing to do with software developers. And it explains why another of our products, Fog Creek Copilot, only found a market in the niche of software developers doing tech support.
So, here you go, the new tagline: “We help the world’s best developers make better software.”
Going through this exercise made it easy to figure out what belongs in future versions of FogBugz and what doesn’t. In particular, we’re adding source control and code review features to FogBugz, using Mercurial, the best open-source distributed version control system. Everything that helps developers make better software belongs in FogBugz: project planning, project management, bug tracking, and customer service.
It took almost ten years, but I think we finally got the mission for the next ten nailed.
Optional Advertainment: If you’ve got a moment, check out this 4½ minute trailer for Make Better Software, a new video training series we’ve been working on for more than a year. It’s the video edition of Joel on Software and fits perfectly with our agenda of helping developers make great software.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
It is amazing how easy it is to sail through a Computer Science degree from a top university without ever learning the basic tools of software developers, without ever working on a team, and without ever taking a course for which you don’t get an automatic F for collaborating. Many CS departments are trapped in the 1980s, teaching the same old curriculum that has by now become completely divorced from the reality of modern software development.
Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?
Many universities have managed to convince themselves that the more irrelevant the curriculum is to the real world, the more elite they are. It’s the liberal arts way. Leave it to the technical vocational institutes, the red-brick universities, and the lesser schools endowed with many compass points (“University of Northern Southwest Florida”) to actually produce programmers. The Ivy Leagues of the world want to teach linear algebra and theories of computation and Haskell programming, and all the striver CS departments trying to raise their standards are doing so by eliminating anything practical from the curriculum in favor of more theory.
Now, don’t get me wrong, this isn’t necessarily a bad thing. At least they’re replacing Java with Scheme, if only because “that’s what MIT does.” (Too late!) And they are teaching students to think a certain way. And given how much the average CS professor knows about real-world software engineering, I think I’d rather have kids learn that stuff at an internship at Fog Creek.
Greg Wilson, an assistant professor at the University of Toronto, gave a talk at the StackOverflow DevDay conference in Toronto, which was entertaining, informative, and generally just a huge hit. We got to talking, and he told me about his latest brainchild, UCOSP, which stands for “All The Good Names Are Taken.”
It’s a consortium of 15 universities, mostly in Canada, which are organizing joint senior-year capstone projects. They’re setting up teams of a half-dozen undergraduates from assorted universities to collaborate on contributing to an open source project, for credit and for a grade. As soon as I heard about the program I volunteered to sponsor a team to make a contribution to Mercurial. Sponsoring a team consists of offering to pay for a trip to Toronto for all the undergrads to get organized, and providing a programmer to mentor the team.
Browsing around the UCOSP blog, I was reminded of why student projects, while laudatory, frequently fail to deliver anything useful. “One of the points of this course is to give you a chance to find out what it’s like to set and then meet your own goals,” Greg wrote. “The net result is pretty clear at this point: in many cases, students are doing less per week on this course than they would on a more structured course that had exactly the same content.”
College students in their final year have about 16 years of experience doing short projects and leaving everything until the last minute. Until you’re a senior in college, you’re very unlikely to have ever encountered an assignment that can’t be done by staying up all night.
The typical CS assignment expects students to write the “interesting” part of the code (in the academic sense of the word). The other 90% of the work that it takes to bring code up to the level of “useful, real-world code” is never expected from undergrads, because it’s not “interesting” to fix bugs and deal with real-world conditions, and because most CS faculty have never worked in the real world and have almost no idea what it takes to create software that can survive an encounter with users.
Time management is usually to blame. In a group of four students, even if one or two of the students are enterprising enough to try to start early in the term, the other students are likely to drag their heels, because they have more urgent projects from other classes that are due tomorrow. The enterprising student(s) will then have to choose between starting first and doing more than their fair share of the work, or waiting with everyone else until the night before, and guess which wins.
Students have exactly zero experience with long term, team-based schedules. Therefore, they almost always do crappy work when given a term-length project and told to manage their time themselves.
If anything productive is to come out of these kinds of projects, you have to have weekly deadlines, and you have to recognize that ALL the work for the project will be done the night before the weekly deadline. It appears to be a permanent part of the human condition that long term deadlines without short term milestones are rarely met.
This might be a neat opportunity to use Scrum. Once a week, the team gets together, in person or virtually, and reviews the previous week’s work. Then they decide which features and tasks to do over the next week. FogBugz would work great for tracking this: if you’re doing a capstone project and need access to FogBugz, please let us know and we’ll be happy to set you up for free. We can also set you up with beta access to kiln, our hosted version of Mercurial, which includes a code review feature.
I’ve been blaming students, here, for lacking the discipline to do term-length projects throughout the term, instead of procrastinating, but of course, the problem is endemic among non-students as well. It’s taken me a while, but I finally learned that long-term deadlines (or no deadlines at all) just don’t work with professional programmers, either: you need a schedule of regular, frequent deliverables to be productive over the long term. The only reason the real world gets this right where all-student college teams fail is because in the real world there are managers, who can set deadlines, which a team of students who are all peers can’t pull off.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Why does WiFi work so poorly at tech conferences?
![]()
Marcus GriepI assume that WiFi wasn’t really designed to handle a big ballroom with 2000 people, all trying to connect with their laptops and cell phones at the same time. Sometimes I feel like I’m lucky if it works in my apartment. So I never thought it was even possible to get it to work at a large, technically-savvy conference. At Stack Overflow DevDays, yesterday in Boston, the bandwidth seemed OK but the DHCP server ran out of addresses. This didn’t seem to be something that anyone could fix. The conference organizers (er, me and Greg) were incredibly busy trying to, you know, organize the conference, so spending time tracking down the mysterious ISP and making them fix their router was impossible.
It’s almost getting boring to read the conference reports complaining about this. Almost every conference, even the ones put on by fancy tech companies, has trouble. I never assume WiFi is going to work whenever I’m in a room with that many techies.
At the smaller conferences, the ones with, say, 300-1000 people, the trouble is that internet access is something of a black box. If you’re a conference organizer, your first priority is finding a space—any space—because there usually aren’t a lot of options. For example if you want to put on an event for 500 people in Seattle, there are probably 20 hotels that can accomodate you and maybe 10 other non-hotel venues. For the date you want, 3/4s of them are booked. You end up choosing between three options, if you’re really lucky. The venue with the best Internet access would be nice, but there are so many other considerations that you don’t really think about this when you’re booking the space. Besides, all the venues tell you they have fantastic, soo-perb A-number-1 internet access. When you try to ask complicated questions and explain that your conference has a lot of techies, they say, yes, we understand, we have A-number-1 internet access, no problem very good. When you say, “Yeah, but have you configured your DHCP server so that it has more than the default 254 IP addresses available to hand out,” they have no idea what on earth you’re talking about, and of course it turns out that they had some vendor, a company you’ve never heard of, provide their internet access. And half the time, that vendor installed a DSL line from the local telco and hooked it up to a LinkSys WRT54g they got at Costco, then installed some kind of crappola welcome-screen software just to make it even worse, and then disappeared.
![]()
Marcus GriepThere are steps that can be taken. Here’s an interesting study [PDF] done by Intel about making WiFi work at large conferences. The best idea I got from that was that there should be as many hardwired network access points as possible, to get the heavy users off the air, because ethernet has way more bandwidth. There are companies that specialize in making WiFi systems that will support large conferences: one that I found is called Meraki; I don’t know much about them but their website sure makes it seem like they understand the issues at least.
At the very least, though, a venue should be able to tell you how many access points they actually have (if it’s just one, you’ve got problems), whether they are managed access points or not, whether dedicated ports with higher priority can be provided for the speakers and for journalists that do not share bandwidth with the audience, how many IP addresses the DHCP server can provide, the total number of people that can be online at once, and the amount of bandwidth available to the entire site. If you can’t get good answers to these questions before the conference begins, you have to assume that they’ll be running a single, consumer router connected to a DSL line and that’s about all you get.
What are some of the best practices for conference organizers? What questions should they ask the conference venue or ISP to know, in advance, if the WiFi is going to work? What are the most common causes of crappy WiFi at conferences? Are they avoidable, or is WiFi simply not an adequate technology for large conferences? I thought I’d ask on ServerFault, so if you have any ideas, have at it!
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect. He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.
When you are done, you might have a messy go-cart, but it’ll sure as hell fly.
I just read an interview with Jamie in the book Coders at Work, by Peter Seibel. Go buy it now. It’s a terrific set of interviews with some great programmers, including Peter Norvig, Guy Steele, and Donald Knuth. This book is so interesting I did 60 minutes on the treadmill yesterday instead of the usual 30 because I couldn’t stop reading. Like I said, go buy it.
Here is why I like duct tape programmers. Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of templates, and all you have to do is multiply-inherit from 17 of his templates, each taking an average of 4 arguments, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inheritance from different classes and hey, presto, multi-apartment threaded COM. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes constructed entirely from multiple inheritance from templates, without a single implementation body at all, and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.
And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”
You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.
Here’s what Zawinski says about Netscape: “It was decisions like not using C++ and not using threads that made us ship the product on time.”
Later, he wrote an email client at Netscape, but the team that was responsible for actually displaying the message never shipped their component. “There was just this big blank rectangle in the middle of the window where we could only display plain text. They were being extremely academic about their project. They were trying to approach it from the DOM/DTD side of things. ‘Oh, well, what we need to do is add another abstraction layer here, and have a delegate for this delegate for this delegate. And eventually a character will show up on the screen.’”
Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.”
“Yeah,” he says, “At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”
My hero.
Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”
Remember, before you freak out, that Zawinski was at Netscape when they were changing the world. They thought that they only had a few months before someone else came along and ate their lunch. A lot of important code is like that.
Duct tape programmers are pragmatic. Zawinski popularized Richard Gabriel’s precept of Worse is Better. A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.
One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.
Sure, there’s nothing officially wrong with trying to write multithreaded code in C++ on Windows using COM. But it’s prone to disastrous bugs, the kind of bugs that only happen under very specific timing scenarios, because our brains are not, honestly, good enough to write this kind of code. Mediocre programmers are, frankly, defensive about this, and they don’t want to admit that they’re not able to write this super-complicated code, so they let the bullies on their team plow away with some godforsaken template architecture in C++ because otherwise they’d have to admit that they just don’t feel smart enough to use what would otherwise be a perfectly good programming technique FOR SPOCK. Duct tape programmers don’t give a shit what you think about them. They stick to simple basic and easy to use tools and use the extra brainpower that these tools leave them to write more useful features for their customers.
One thing you have to be careful about, though, is that duct tape programmers are the software world equivalent of pretty boys... those breathtakingly good-looking young men who can roll out of bed, without shaving, without combing their hair, and without brushing their teeth, and get on the subway in yesterday’s dirty clothes and look beautiful, because that’s who they are. You, my friend, cannot go out in public without combing your hair. It will frighten the children. Because you’re just not that pretty. Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.
Did you buy Coders at Work yet? Go! This was just the first chapter!
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
This month we’re starting to get organized for StackOverflow DevDays, a series of one-day, mini conferences in ten different cities. Because of the packed schedule, keeping on time is very important, so I want to have a full-screen countdown application that we can run during intermissions warning people when we’re going to resume. We’ll put this up on the main screen and hopefully that will encourage people to sit down and be quiet on time. I thought this would be a great opportunity to showcase the StackOverflow community’s programming talent, so I posted a little contest over on meta.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
I’m organizing a half-day startup workshop in San Francisco. This would be a terrific event to attend if you’ve recently started a software company and feel dazed, confused, or just want to bounce ideas off of someone who’s been there.
We’ll keep it small so everybody gets a chance to be heard. Space is extremely limited.
It’s a bonus supplement to the Business of Software conference, which is Nov. 9-11 in San Francisco.
Although the startup workshop itself is free, you do have to pay for for that conference, which is not free, in fact, it’s kind of expensive (but totally worth every penny!) I know it’s kind of expensive for very early stage startups, but trust me on this, it’s worth it.
Here’s what happens. After the main conference finishes up on Wednesday, we’ll divide up into three groups. Each group will do three 90 minute workshops, moderated by:
The format is very open. It’s a chance to chat, bounce ideas around, ask questions, solve specific problems, get feedback, and learn from each other.
After the workshops we’ll regroup with Jason Calacanis, who will do a live broadcast of his podcast This Week in Startups and take your questions live. Jason is on his third startup. The first, Silicon Alley Reporter, was the flagship magazine of New York City’s short-lived dot com boom; after the crash of 2000 it closed down. His second startup was Weblogs Inc, the first really serious commercial blog network, which sold to AOL for an undisclosed sum (let’s call it $25 million, shall we?) After turning netscape.com into a Digg clone, Jason spent some time at a fancy-pants VC firm, Sequoia Capital, where he hatched the idea for his current startup, Mahalo, which they funded. Anyway now he’s got this terrific podcast and he’ll be doing it live and we’ll be his audience, so you’ll have a rare chance to ask Jason questions in person and hear him pontificate.
Here’s how to sign up.
If you haven’t registered for BOS2009 yet, go do that. During the registration process, you’ll see a checkbox that says “I'd like to come to Joel's startup bootcamp”. It’s not a bootcamp, really. You won’t have to do pushups or work very hard. But check that box anyway.
If you already registered for BOS2009, follow this link. Click on “Already Registered.” Log on, and look for the link that says Event Fees. Why does it say that? I don’t know. After you click on that link you’ll be able to check the box that says “I'd like to come to Joel's startup bootcamp”. It’s still not a bootcamp. Really. Bootcamp is where you run around in circles for 20 weeks without getting more than four hours of sleep a night while drill sergeants barely a year older than you foam at the mouth and berate you endlessly like that time Tom Hanks flips out at Bitty Schram in A League of Their Own. “There’s no crying in baseball!” Anyway, NOT THAT AT ALL. This will be more of a friendly conversation with successful software startup founders. Not bootcamp.
Space is extremely limited: there will be three groups of 24 founders each. No more than two attendees per startup, please. See you in San Francisco!
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
At last year’s Business of Software conference, I gave a talk about designing products that are more than just adequate. How do you make a product that becomes a category-killer, number one, super hit? What is it that gives the Apple iPod 90% market share?
Neil Davidson has the video of my talk online (it’s about 46 minutes).
This year’s conference is going to be great. There are still a few tickets available. It’s November 9th-11th in San Francisco. This is a conference that’s all about terrific speakers: Geoffrey Moore, Don Norman, Paul Graham, Heidi Roizen, Jennifer Aaker, Michael Lopp (“Rands”), Ryan Carson, Paul Kenny, Dharmesh Shah, Kathy Sierra, Mat Clayton, and The Cranky Product Manager are all confirmed speakers. Register now before it’s too late!
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Red Gate Software has launched a startup incubator in Cambridge. Free office space, internet access,
room, board, advice, and pocket money. (I’m one of the people giving advice). For a first,
it’s really free; Red Gate isn't taking stock in the companies it helps. “We think that getting to know smart people doing interesting things will, in the long term,
be good for Red Gate. In the future, we might end up licensing your technology, investing in your company or maybe even buying it.
Or maybe we won’t. Ultimately, all deals come down to relationships. So we want to build them.”
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Seth Godin: “If you’re going to interrupt everybody with an ad, it better be something everybody wants to buy. So what do you end up with? Average products for average people.”
If you’ve ever heard Seth speak, you’ve had your mind blown. Which is why, on the rare occasion, when he runs a one-day seminar, he charges $1650 to attend, and it sells out in seconds.
At last year’s Business of Software conference, Seth’s keynote was the highlight of the show. Thanks to a very generous offer by Seth, you can watch the full hour online.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
“Every single industry was going to be turned upside down! New industries would be created! Start-ups would make people rich! Which is really nice, because it's awesome to be rich! And, bonus: It'll never be winter again!”
In this month’s Inc. column, The Day My Industry Died, I retell the first part of the Fog Creek story.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
A year ago today, FogBugz development was in disarray.
![]()
The original roadmap was too complicatedWe had done this big offsite at a beach house in the Hamptons and came up with a complicated roadmap that involved splitting FogBugz into two separate products and two separate teams. We had done a lot of work on the architecture that made the product much more modular, but we had this goofy plan to do a major release containing virtually no new features, just to let the new architecture shake out, a plan which nobody was very excited about.
So, on July 31, 2008, we reset our plans. We gave up on the idea of shipping a standalone Wiki product, and merged the Wiki team with the FogBugz team. And we nailed down a new vision for FogBugz 7 that’s a lot easier to understand and a much better product: something we could ship in one year.
Then the development team shipped it. Exactly on schedule. Well, maybe a week or two early. They used Evidence Based Scheduling religiously on this large one year project and it worked amazingly well. Yes, they had to cut and trim features as they went along, but the accuracy of the estimates also gave them the confidence to add a couple of major features (like Scrum support) that you’ll love.
One of the best things we did as a development team was to write a short, concise, comprehensible vision statement that got everybody exactly on the same page about what we were going to do over the course of a year. The vision statement made it easy to prioritize. Instead of just telling us what was in the product, it also gave us a way to know what was out.
Here’s the vision statement, in its entirety, which is a pretty good description of what we are actually shipping today. Please excuse the tone of voice; remember that this was an internal document to galvanize the team.
Fog Creek Confidential FogBugz 7As of August, 2008, the entire FogBugz and Weeble teams are working towards a single major new release of FogBugz that will blow away our customers (real and imaginary). When they see it they will grow weak in the knees. Competitors will shiver in fear at the monumental amount of win in this release. As customers evaluate the software, they will simply never find a reason not to use FogBugz to run their software teams. No matter what the grumpy people on their team come up with, they'll find that not only have we implemented it in FogBugz, we've done it in a FULL-ASSED way. No more HALF-ASSED features (I'm looking at you, logo customization in FogBugz 6.1).
This release has three important focus areas with friendly catchnames.
If it's NOT ON THAT LIST it's NOT IN THE PRODUCT. Get used to it.
fruity treats
FogBugz 7.0 will include a long list of simple improvements that will make life dramatically easier for people trying to get things done, especially when they want to do things just a wee bit differently than we do here in the Land of the Fog. Every little feature will be a delight for somebody, especially that person who keeps emailing us because he can't believe that the feature he wants which is obviously only six lines of code hasn't been implemented in FogBugz 1.0, 2.0, 3.0, 4.0, "4.5", or 6.0, and if we don't get it soon he JUST MIGHT HAVE TO GO OVER TO THE AUSTRALIANS.
Collectively, though, fruity treats will make FogBugz friggin' amazing, and they'll help us win more sales because we won't have so many showstopper reasons why people choose another so-called bug "tracker."
What's a fruity treat? It must fit these three rules to get into the 7.0 orchard:
Visit the shared filter FogBugz 7 Fruity Treats to see what's coming up.
customization
FogBugz 7.0 will include our smashingly powerful new plug-in archicture, which, combined with the FogBugz API, will give people complete confidence that if there's anything FogBugz can't do out of the FogBox, you can write it yourself. No more will we tell customers "you get the source code, so you can modify it!" That's BS. They know perfectly well that if they modify our source code, terribobble tragedies will occur the minute we release a service pack. From now on, we can say, "there's a great plug in architecture and a whole online cornucopia of righteous plug-ins available for download."
So you can trick out your FogBugz installation like a lowrider or an off-road dune buggy. You can make it into a Cadillac or a space shuttle. It's up to you.
supersonics
Thanks to the newfangled, all-electronic compilation machine ("Wasabi") that we had installed at great expense, FogBugz will be running on the CLR and Mono for greatly improved performance and compatibility. Whiz zip blip! bleep! You'll be able to run 1000s of users on one server. Long queries will finish faster. Laundry will be brighter.
Nothing else. Go fix yourself an icy lemonade.
The team got pretty excited. Having a sharp focused vision statement like that, and having the whole team working towards a single shared goal, really helped us get our house in order. We scrubbed through thousands of backlogged ideas, feature requests, and comments, and came up with a set of fruity treats that will eliminate virtually every customer objection that we hear during the sales process. We developed a comprehensive plug-in architecture that’s pretty amazing, and had interns develop a slew of slick plug-ins. And the fact that Wasabi is now a genuine .NET language made for substantial performance improvements over running on the VBScript “runtime.”
I’ll let the team give you a comprehensive look at what’s new in FogBugz 7, but here are some of the highlights:
Those are just the big-ticket items. FogBugz 7 is rife with little areas where the development team put a ridiculous amount of attention to detail. For example, the signup process, which is actually very complicated on the backend, became much simpler on the front end, due to a heroic amount of work that every user will only see once. If you do nothing else, check out the signup process to see the effort that went into making signup just a tiny bit faster. Another example: we completely replaced the entire email processing infrastructure, just because there were tiny corner case bugs that simply could not be solved with the commercial class library we had been using.
![]()
Tyler Griffin Hicks-WrightI wish I could take more credit for it, but the truth is, Fog Creek has grown. We have a very professional team with testers, program managers, and developers, and I just sort of sit here agog at what a brilliant job they’re doing. All of the credit for this fantastic new product goes to them. I’m just the Michael Scott character who wastes everybody’s time whenever I venture out of my office.
FogBugz 7 is shipping today for Windows servers and on our own, hosted infrastructure. The Mono version (for Macintosh and Linux) will be in beta soon. To try it, go to try.fogbugz.com.
If you’re currently using FogBugz on Demand, you’re already using 7.0.
If you run FogBugz on your own server and have an up-to-date support contract, the upgrade is free, otherwise, bring your support contract up-to-date and you’ll be good to go.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Clear just closed down.
Here’s how it worked while it was in business. You paid $200 for a one-year membership. You underwent a big, complicated background check to prove that you were extra-super-trustworthy.
In exchange, in a few big airports, you got to skip to the front of the TSA line for screening.
Now, you didn’t skip the screening itself. You still went through the X-ray machine and had to remove your shoes, belt, pocket contents, laptops, and plastic quart ziplock bag of toiletries.
You just got to cut to the front of the line.
A few people signed up. In certain airports, it was, indeed, worth actual money to cut to the front of the line.
This wasn’t Clear’s actual business plan. The actual business plan was that Clear would do detailed background checks on travellers, who would then be trusted to bypass security completely because they were extra-super-trustworthy.
Now, the TSA doesn’t even trust pilots, who go through the same screening as the rest of us to make sure they’re not bringing something extraordinarily dangerous onto a plane like a 3.5 oz bottle of shampoo. Because, of course, with a little bottle of shampoo, they could make a bomb, which they could use to fly the plane they are piloting into a building, something that is impossible for mere pilots sitting at the controls of the jet.
So as it turns out, the TSA never actually agreed to go along with this skipping-the-screening thing, and ultimately, all Clear was allowed to do was get you to the front of the line.
At this point, and here’s the interesting part, at this point, a rational businessperson would say, “Well, does the Clear idea still make sense if we can’t actually let you skip the screening?”
OK, maybe it still makes sense to charge to skip to the front of the line. Maybe there’s a business model in that.
In that case, though, why did they still do background checks? It doesn’t make any sense.
The environment changed. It turns out that Clear’s business model of prescreening wasn’t going to be possible. But they kept doing it anyway. What kind of organizational dysfunction does it take to completely ignore the changed circumstances and keep at a money-losing business?
What’s even funnier is that Clear could probably have been profitable if they had just skipped the one unnecessarily stupid part of their business model: the detailed background checks on all their customers.
Nobody at Clear did any thinking. They had a business model, the business model wasn’t actually possible, everybody knew it, and they still plugged away at it. Thoughtless optimism. I don’t know whether to salute ‘em or laugh.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Dave Winer (in 2007): “Sometimes developers choose a niche that’s either directly in the path of the vendor, or even worse, on the roadmap of the vendor. In those cases, they don’t really deserve our sympathy.”
iSmashPhone: 15 Apps Rendered Obsolete By The New iPhone 3GS
When independent software developers create utilities, add-ons, or applications that fill a hole in their platform vendor’s offering, they like to think that they’re doing the vendor a huge favor. Oh, look, the iPhone doesn’t have cut and paste, they say. Business opportunity! They might imagine that this business will be around forever. Some of them even like to daydream about the platform vendor buying them up. Payday!
The trouble is that only a tiny percentage of iPhone users are going to pay for that little cut and paste application. With any kind of add-on, selling to 1% of the platform is a huge success.
For Apple, that’s a problem. That means that the cut and paste problem isn’t solved for 99% of their customers. They will solve it, if it’s really a problem. And you’ll be out of business.
Filling little gaps in another company’s product lineup is snatching nickels from the path of an oncoming steam roller.
A good platform always has opportunities for applications that aren’t just gap-fillers. These are the kind of application that the vendor is unlikely ever to consider a core feature, usually because it’s vertical — it’s not something everyone is going to want. There is exactly zero chance that Apple is ever going to add a feature to the iPhone for dentists. Zero.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
From my latest Inc. column: “Giant corporations such as Google and Microsoft are like cities full of relatively anonymous people: You don't actually expect to see anyone you know as you walk around. Going to lunch on either campus is like going to the cafeteria at a huge university. The other 2,000 students seem nice, but you don't know most of them well enough to sit with them. Meanwhile, a typical lunchtime at my company is like Thanksgiving dinner: There's a big meal you get to share with a bunch of people you know and like.”
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Andrew emailed to ask why we don’t have a StackOverflow DevDays day in New York City. That’s a fair question! There’s a big software development community here.
There are two reasons New York is low on my list. The first is cost. Hotels, venues, and catering are prohibitively expensive in New York. At a medium-class hotel, say, the Marriott on the East Side, giving everybody one coffee break with coffee, tea, soft drinks, and nothing to eat costs $23 per person [PDF]. It’s simply impossible to do a $99 one-day event in New York.
The other reason is attendance. I don’t know why, but techies in New York just don’t turn out for events at the same level as other cities. When we did the FogBugz world tour we had three times as many attendees in London as New York. Maybe New Yorkers are extra busy. But turnout is always surprisingly thin in the city.
It’s a particularly bad place to do tech conferences, too. Hotels are $600-$700 a night. Everything about putting on a conference is remarkably expensive. And half of your attendees wander off to visit the Statue of Liberty when they should be in your Python tutorial meeting.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Whoa. Less than a month ago, we announced first Stack Overflow DevDays and opened registration to 300 people in each of five cities.
Well, that sold out pretty quickly. Ryan Carson, who is taking care of all the conference logistics, was pretty sure we’d be able to book larger event spaces, so we allowed even more people to register... we’ve got 2388 people booked worldwide so far, including over 800 in London, but it’s clear that with just five events we weren’t going to be able to accomodate all the people who want to spend a day meeting online Stack Overflow friends in real life and learning a little something about some hot new programming topics.
So, we decided to take the show to five more cities. Here’s the new schedule—click on a city to register:
Oct 07 Boston NEW!
Oct 14 Austin NEW!
Oct 16 Los Angeles NEW!
Oct 19 San Francisco
Oct 21 Seattle
Oct 23 Toronto
Oct 26 Washington DC
Oct 28 London
Oct 30 Cambridge, UK NEW!
Nov 02 Amsterdam NEW!
Tickets are $99 in the US, €84.75 in Amsterdam and £85.00 in the UK. A limited number of very cheap student tickets are available. If you already booked but want to change cities, email devdays@stackoverflow.com.
In the meantime, I’ve been working hard lining up speakers. I’ll be speaking myself in all ten cities, as this will be the launch event for FogBugz 7 and a new product now under development by the Fog Creek summer interns, who just arrived and are already coding away earnestly. Jeff Atwood will be speaking in San Francisco. Scott Hanselman will be speaking in San Francisco and Seattle. Jon Skeet will be speaking in London. The basic agenda should, more or less, include: Android, Python, Google App Engine, iPhone development, ASP.NET MVC, jQuery, FogBugz, Mercurial and DVCS, and a different speaker from academia in each city. There will be lunch, two breaks, and we’ll organize some kind of birds-of-a-feather post-conference meetups.
Anyway, at the current rate, it’s pretty clear these conferences will sell out long before the events themselves, so don’t wait until the last minute to decide.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
The Joel on Software Job Board has been working well since we launched it almost three years ago. It logs about 220,000 unique visitors every 21 days, including many passive job seekers who have RSS subscriptions.
But a few employers place ads and just don’t find anyone. I’m pretty sure we’re the only job listing service in the world with an unconditional money back guarantee, so these people call us and we give them their money back. It’s not a lot, usually just two or three a month, but I’d still prefer to have a wider audience for these job listings as long as it didn’t diminish the quality of resumes.
In the meantime, Stack Overflow has been attracting a huge community of smart developers—we’re running over 3.7 million unique visitors a month.
So today we’re launching a new Stack Overflow job board and a Server Fault job board, which will both be linked up with the Joel on Software job board. Any ad placed on one appears on all three sites. This will be a great way to recruit great programmers and a great place to get great jobs.
It’s not much of a secret, but Stack Overflow is already a great place to find good programmers, because you can see how good people really are by reading the answers that they post. I’ve noticed a lot of people putting their Stack Overflow reputations on their resumes, and we’re starting to hear stories of people who got jobs through the site. Jeff and I are committed to building features to make this easier in the next “six to eight” weeks. For example, I’ve always hated traditional resumes, which just don’t give the right kind of information about a candidate. If you wanted to hire an iPhone developer, would you rather know that person’s Stack Overflow stats in the iPhone tag and read their answers to technical questions? Or would you rather know where they went to college?
If we pull this off, getting jobs in the tech industry will be a lot saner.
In the meantime, if you are hiring, do yourself a favor and try placing an ad on Stack Overflow. (FAQ) If you’re looking for a job, check out the listings.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Server Fault is now in public beta!
When Jeff Atwood and I launched Stack Overflow last fall, we really wanted it to be a site for and by programmers. But the engine behind the site, the Q&A engine with voting, editing, and tagging, could obviously be used in a lot of other professions.
The first field we picked is close to our heart: system and network administration; as programmers, we often end up doing system administration ourselves. And it’s the perfect domain for a Q&A engine... there are a million detailed problems that depend highly on lore to get right. There’s no way to accidentally discover aspnet_regiis.exe -I until someone shows you the trick. How much time have you wasted trying to figure out which process is holding a file open preventing you from deleting an otherwise empty directory? Can you use dd to clone a disk drive?
Thus, Server Fault. If you already have a Stack Overflow account, you’re all set up, although your reputation score, badges, and favorite tags are separate. It has all the great features from Stack Overflow which I talked about at Google last month (video).
Jeff: “I am sorry to inform you that you may be a system administrator or IT professional.”
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Stack Overflow has been going nuts—after just six months in business, we’ve had 3.5 million unique visitors per month. We’ve starting thinking about how to get that great tribe of developers together in the real world.
We decided to launch a series of Stack Overflow events: the first gathering of the tribe of great developers making Stack Overflow so successful that over 90% of questions get answered [video].
It’s going to be in October, in five separate cities. In each city, we’re planning a one-day event.
We decided to cram as many diverse topics as possible into a single day event. Like a tasting menu at a great restaurant, we’ll line up six great speakers in each city.
This is not going to be just a Java conference or a .NET conference or a Ruby conference. This will be completely ecumenical. We’ll have somebody to introduce Microsoft’s new web framework, ASP.NET MVC, but we’ll also get someone to talk about writing code for Google’s new mobile operating system, Android. And in each city, we’ll find one local computer science professor or graduate student to tell us about something new and interesting in academia.
For smart programmers who are interested in learning about something a little bit outside of their own immediate field, this is the conference for you. We’re doing it in the spirit of Byte Magazine. Remember Byte? Every issue covered a wide range of topics and technologies. Sadly, Byte disappeared, to be replaced by Mac-only magazines, IBM-PC only magazines, even Microsoft SQL Server-only magazines.
The conference is for programmers. The conversation is going to be hard core. Speakers are going to be writing code.
Putting on these conferences is really expensive—conference centers can charge you $1000 for one urn of coffee. That’s why typical developer conferences can cost $1500, plus travel, hotel, and $73 for the Internet access in your hotel room. With the current worldwide recession, that just isn’t gonna fly. Many great conferences, like SD West, have been cancelled. Attendance is way down at the conferences that survive.
So I got together with Ryan Carson, whose company, Carsonified, has been putting on great conferences like FOWA, and we tried to figure out how little we could possibly charge for this thing. The answer: $99 per attendee.
That’s it. These one day conferences are just $99. You can bring your whole team for less than the cost of a normal conference.
We’re doing it in five cities, so you may not even have to travel. We’ve got room for just 300 developers in each city:
October 19 San Francisco
October 21 Seattle
October 23 Toronto
October 26 Washington, DC
October 28 London
Register for Stack Overflow DevDays right now. Given the huge demand and the limited number of tickets, I expect all five cities will sell out pretty much instantly.
OK, here’s the FAQ:
Who will be speaking?
I’ll be speaking in every city. Jeff Atwood will appear in San Francisco only. We will line up about six speakers in every city.
The topics haven’t been nailed down yet and depend on speaker availability. I’ll do my best to get speakers on as many of the following topics as possible:
Each talk will be fairly introductory but will be intended for advanced developers. If you already know about a topic, say, iPhone development, you can wander outside and hang out with the other iPhone developers in the hallways.
Is this the same in every city?
Not exactly. Some topics will be repeated—my talk will be the same in all five cities—but we may not have the exact same topics and speakers in each city. We aim to have at least one local speaker in each city.
I’m hungry!
Me too. I’m always hungry. Breakfast, lunch, and afternoon tea are included in the price of the ticket. Half of the fun of this conference will be meeting other Stack Overflow members.
Where are the events?
We haven’t booked halls yet. The exact location will be announced. There is a small chance we may have to adjust a date a little bit if we have trouble booking a space.
Note: If your company is in one of these cities, and has a presentation space that is suitable for 300 people, we’d love to have you as a sponsor. Please email devdays@stackoverflow.com.
Make a T-shirt with your StackOverflow identity and reputation (see sample at right). You can order them here or make your own.
Are there academic discounts?
There are a very limited number of subsidized student tickets at $10. Due to the cost of putting on the event, I regret that there are only a limited number of student tickets in each city.
How can I help?
Ah! Thank you for asking. We need lots of help to pull this all together.
I have more questions.
That figures. Email them to (you guessed it) devdays@stackoverflow.com and Natasha at Carsonified will get back to you.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
“Even as competitors like Circuit City go bust, B&H remains packed with loyal customers. And that makes me very happy. For a business owner, there's nothing more satisfying than watching honest dealers expand their operations while the schmucks, with their going-out-of-business markups, go down the drain.”
From my Inc. column: Why Circuit City Failed, and Why B&H Thrives
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.
Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.