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.

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.

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.

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.

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.

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.

Go! I’ll wait.

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.