Another resume tip 02 Jan

Are you a software developer applying to a small company?

Here’s a tip from someone who has read thousands of resumes. When you’re applying to a startup, or a software company with less than, say, 100 employees, you may want to highlight the Banging Out Code parts of your experience, while deemphasizing the Middle Management parts of your experience.

When a startup CTO sees a resume that says things like:

• Responsible for $30m line of business
• Architected new ERP platform
• Managed team of 25 developers
• Optimized business processes

they think, “Spare me, that’s all we need, somebody running around trying to manage and optimize and architect when we just need someone who isn’t afraid to write code.” Here’s the stuff CTOs at startups want to see on a resume:

• Single-handedly developed robust 100,000 LOC threadsafe C++ service
• Contributes to OpenBSD file system in spare time
• Wrote almost 75% of the Python code running IsIt2009Yet.Com

If you’ve been in a large company for too long, you may feel that you put in your time, with all those years working your way up the hierarchy from the $50,000 coder jobs to the $250,000 Senior Vice President in Charge of Long Meetings With Other Senior Vice Presidents, and you’re kind of enjoying the nice parking space and the personal assistant and stuff, and coding? not so much, so now you’ve found a cool startup or small company, and you’re thinking, maybe now’s the time to jump ship? So you send your resume with your ERP stuff and SAP stuff and Vice President stuff to the startup, and it gets tossed.

Those VP jobs just don’t exist at startups, and the few VPs they have are the founders and a key early hire or two. Not you. And startups certainly don’t need extra middle managers. To a startup founder, middle managers just seem like added expense without more code getting written, and the only thing we REALLY need is

• code to be written, and
• customers to be called on the telephone.

Now, there’s a lot of resumes I see where, actually, I suspect that the candidate may have been (ahem) slightly overemphasizing the management/leadership/“architect” parts of the job, and slightly underemphasizing the banging out of code. And that’s fine if you’re looking to jump to a management position at a big company that, inexplicably, doesn’t have anyone to promote from within.

But for startups, everything about your resume has to scream getting your own hands dirty. Otherwise your resume makes you look like you’re looking for the kind of job where you can call meetings that take people away from coding all day long, which, to a startup, is about as useful as a one-legged man in a butt-kicking contest.

(More resume tips, and, if you’re really looking for a job, don’t forget the job board).

Animoto 02 Jan

Tom suggested that I use Animoto to jazz up the slideshow of Fog Creek pictures. Here’s what came out of that:

Animoto is very simple: you give it a bunch of pictures and choose a soundtrack, and it gives you a video presentation. The part I liked best was how easy it was to get your pictures... you just point it at one of the five most popular online photo sharing services, and it shows you a list of your albums on that service. One click and all your pictures are imported:

The service is free for 30 second videos (about 15 pictures worth). For longer videos, it’s $3.00, which gets you a low res version. To upgrade to high res is another $5. There are all kinds of packages available if you plan to make a lot of videos. I was pretty impressed by the simplicity of the whole thing. It does take quite a while to render the video, though, so unless you have all day, you can’t make very many adjustments before you get tired of fooling around.

The new Fog Creek office 29 Dec

Remember the Bionic Office? Fog Creek moved in there in 2003. After a couple of years we had outgrown the first office so we expanded to take over the whole floor. By the time our lease ran out in 2008 we had about 25 people in a space built for 18 and we knew we had to move. Besides, the grungy midtown location, perfect for startups, was starting to get us down after five years. We had a little bit more money, so we were looking for a place with about twice the space that cost about four times as much.

It bears repeating that at Fog Creek our goal is building the best possible place for software developers to work. Finding a great space was not easy. Our ideal of giving every developer a private office is unusual, so it’s almost impossible to find prebuilt office space set up that way. That means we didn’t have much choice but to find the best raw space and then do our own interior construction.

We knew it was going to take a while. After the first office, I knew that you should always plan on ten months from the day you start looking at space until the day you move in. And I also knew that if I wasn’t intimately involved in every detail of the construction, we’d end up with the kind of life-sucking dreary cubicle hellhole made popular by the utopian workplace in “Office Space.”

After a tedious search, we signed a lease for about 10,600 square feet on a high floor at 55 Broadway, almost all the way downtown, with fantastic views of the Hudson River, Governor’s Island, the Statue of Liberty, and Jersey City.

We found a landlord with his own construction crew who was willing to do the interior construction for us, at no charge. The only problem was that his idea of a nice office was a lot closer to Initech than Fog Creek. So we had to chip in about a half million dollars of our own to upgrade just about everything.

Building great office space for software developers serves two purposes: increased productivity, and increased recruiting pull. Private offices with doors that close prevent programmers from interruptions allowing them to concentrate on code without being forced to stop and listen to every interesting conversation in the room. And the nice offices wow our job candidates, making it easier for us to attract, hire, and retain the great developers we need to make software profitably. It’s worth it, especially in a world where so many software jobs provide only the most rudimentary and depressing cubicle farms.

Here are a few of the features of the new office:

Gobs of well-lit perimeter offices. Every developer, tester, and program manager is in a private office; all except two have direct windows to the outside (the two that don't get plenty of daylight through two glass walls).

Desks designed for programming. Long, straight desks include a motorized height-adjustable work surface for maximal ergonomics and comfort, and so you can stand up for part of the day if you want. Standard 30” monitors. Desks are straight instead of L-shaped to make pair programming and code reviews more comfortable. There are 20 electrical outlets behind every desk and most developers have small hubs for extra computers. Our standard-issue chair is the Herman Miller Aeron. Those guest chairs are the famous Series 7 by Arne Jacobson. The pedestal storage is on wheels and incorporates a cushion-top for additional guest seating.

Glass whiteboards. Easy to erase, look great, and don’t stain.

Coffee bar and lunchroom. There’s an espresso machine, a big fridge full of beverages, a bottomless supply of snacks, and delicious catered lunch brought in every day. We all eat lunch together which is one of the highlights of working here.

A huge salt water aquarium which brings light and color into the center of the office.

Plenty of meeting space. The lunch room has a projector and motorized screen (most frequently used to play Rock Band, thanks Jeff Atwood); there are several smaller meeting tables around, two conference rooms, and a big S-shaped couch.

A library, fully stocked with obsolete paper books and two reclining leather chairs, perfect for an after-lunch nap.

A shower (floor to ceiling marble), so you can bike to work or work out during the day.

Wood floors around the perimeter, so you can use scooters to get around. Carpet in the offices to make them quiet. Concrete in the lunch room because it’s bright and looks cool.

I can’t quite fit in enough pictures in this article to really give you a feel for the space, but I put a bunch of photos of the new Fog Creek office up on Picasa. If you’re interested in learning more about the rationale behind spending so much money on building a great workspace, read A Field Guide to Developers.

Stack Overflow is a Wiki 28 Dec

Stack Overflow launched about three months ago, and is already serving 8.3 million page views per month. The growth has been incessant.

Most of the criticism I’ve heard of Stack Overflow reminds me of the early criticism of Wikipedia: “I went to this article and it was wrong.” By the time you read the criticism, the article has been fixed. There was that year, not last year, but the year before, when every traditional journalist wrote a funny thought piece in their newspaper about something they looked up in Wikipedia and just how wrong it was. By the time their column appeared in print, the Wikipedia article was corrected, making a liar out of the journalist. Eventually they learned to stop writing that story.

Stack Overflow works the same way. Voting is open forever. It’s a wiki, so anythin
Stack Overflow data from Google Analyticsg can be edited, and it is.

Most topics get most of their traffic not in the first few days, but by the Google traffic that comes in for people searching for the same exact problem. Search engines now account for 81% of Stack Overflow traffic: people searching for specific questions, not asking them directly. And that's where it's really working. Answers DO get better. If they don’t, it's a wiki: fix them. Instead of complaining about good answers with few votes, vote down the top answer and vote up the better answer.

My criterion for whether Stack Overflow works: when you type your question into Google, and you’re happy to see a Stack Overflow result rather than a result at another one of those Q&A sites where you have to sign up and pay a monthly fee to see the answer.

From the Department of Badly Chosen Defaults 22 Dec

Alert reader Chris S. emailed me to point out this post by a developer at flickr about how to make IE scale images more smoothly. All you have to do is add

img { -ms-interpolation-mode:bicubic; }

to the stylesheet. It worked!

Note that all the other browsers use bicubic interpolation for scaling by default, because that’s the only thing that make sense, but IE requires a non-standard CSS extension. So, pictures on this site should be a little smoother for those of you determined to use Internet Explorer.

Happy Hannuka!

Future of Web Apps 21 Dec

I’ll be speaking at Future of Web Apps, in Miami, the last week of February. If you’re going, and have any ideas for what I should talk about, drop me an email!

Snowy day in New York 19 Dec

I’ve been debugging the new site. The first problem: hopelessly messed up rendering on IE6. The best way to fix CSS problems with IE6 is to generate random mutations on the style sheet until it looks fixed. That’s really the only way to approach these kinds of things; CSS is nondeterministic, and many better minds than mine have gone completely stark raving mad trying to understand the rhyme and reason of IE6 rendering bugs.

Once that was fixed, people who read this site in an RSS reader reported that included images with captions weren’t showing up correctly. To fix that one, I had to move the style information from the style sheet right into the tag, but only for the RSS feed. I think that should fix it for the most popular RSS readers (Bloglines and Google Reader) but many RSS readers strip out CSS aggressively and I can’t do anything about that.

Waffle Wednesday at Fog CreekTo test the fixes, I’ve thrown in a picture of Waffle Wednesday, showing our fabulous director of QA attacking a waffle iron with PAM in the company kitchen.

Finally—many readers noticed that the images appear slightly pixelated. This is a result of relying on the browser to scale images. In my testing, it seems that Firefox and Safari do a very nice job scaling the images and there’s no visible pixelation. Internet Explorer: not so much. If you use a better browser, you get better results.

A new design 18 Dec

I’ve redesigned Joel on Software. Here’s why.

Amnesia 10 Dec

Mysteriously, about a week ago, Dan, the program manager designing most of the new features in FogBugz 7, came to ask me what features I thought should go in the timesheet reporting plug-in.

The timesheet reporting plug-in? What’s that?

It sounded dangerously close to a feature that could be used by managers to see reports on developers’ timesheets. Like, something a weak manager would use to figure out who is the best developer on the team or to make sure everybody is pounding away at the code at a suitable pace.

We have a theory, here, that this is a bad idea. Using timesheets as a performance metric can lead to only one thing: bad data in timesheets.

The first time your boss comes into your office and gives you grief because it looks like you only did 7 hours of work yesterday, you’re going to make sure that never happens again. And then, suddenly, behold, the timesheets show everyone working 12 hour days, and all the data in the timesheets becomes instantly bogus. And EBS, our statistical technique for predicting ship dates, suddenly stops working, because you’re feeding it data that is meant to get your boss to stop bugging you, not accurate data.

Now, this theory may be completely off the wall, but it is our theory, and until we hear something better, that’s the one we’re going with.

So our policy has been that if you want to get the timesheet data, well, yes, you can, we’ll give you a way to get it in CSV format or XML format or something and then you can abuse it all you want... go ahead, hang yourself, but we’re sure as heck not going to make it easy for you with a pretty report all tied up with a bow that you might click on by accident, as you browse around, because thou shalt not put a stumbling block before the blind.

Anyway, I said to Dan, “What the heck? Who on earth approved that feature?” and walked down the hall to the FogBugz team to beg them not to do it. Correction: I razor-scootered down the hall. It’s extremely undignified; I’m way too old for childish toys; but jeez it’s like a whole city block from my office to the FogBugz team’s office, so, OK, it’s pathetic, but razor scooting is the fastest way to get there.

I am not sure what the FogBugz team will decide... it’s their call, not mine. Apparently nice people email us and ask for that exact feature and offer to give us little green rectangular things that can be exchanged for other goods and services if we do the feature. So it’s a dilemma, and I’m the one who knows the least about it, so I hope they won’t listen to me. Well, secretly, I hope they will, but don’t tell them that. Sometimes they do and sometimes they don’t.

But anyway... that’s not the point of the story. The point of the story is that today I was reviewing some video footage to see if there was anything worth including in the next documentary Lerone is making about software development. And the footage I was reviewing was of a meeting several weeks ago to go over the final list of features for FogBugz 7 and make sure they all had the right priorities assigned to them.

And there, on the video, I had to watch myself listening to Babak explaining the timesheet reporting plug-in, and the record shows that I appeared to understand what was being said to me, and, I’m afraid to admit, I appear to have given my tacit approval to the feature.

AHEM.

In short, I’m turning into one of those crazy bosses that approves things, and then gets upset when you do them. This keeps happening. I must be driving people crazy.

In my defense, usually what happens is that the thing is described to me in general, vague terms and it sounds great, and I say, “sounds great!” and then I see the thing a little bit closer, and it’s awful, and by this time, I’ve forgotten about the time I said it sounds great. Just assume I have amnesia or something. I can’t form new memories. Did I tell you about the razor scooter yet? OH IT’S FUN.

The solution, of course, is what I’ve been saying all along. STOP FRIGGIN’ LISTENING TO ME. I don’t know what I’m talking about. If you work for me, you’re welcome to get my advice, but you have to make your own decision because chances are you’ve thought MUCH MORE about the issue than I have and in fact we probably hired you because you’re smarter than I am.

Stack Overflow Podcast #32 03 Dec

This week Jeff and I talk about software piracy, some performance improvements on the site, dealing with criticism, great programmer’s offices, and more, in Stack Overflow Podcast #32.

Old News >>