Hicks-Wright.net

Career Break

Mon, 14 Sep 2009 15:32:34 +0000

I didn't go into work last week. I won't go in this week either. In fact, it may be a month or two before I go back. I'm on sabbatical.

Well, kind of. Typically, one gets paid for a sabbatical, if only half of the normal income. As Wikipedia informed me, I'm taking more of a career break. Either way, I've decided to take some time off to deal with a few things that have been bothering me lately.

The biggest issue I've been dealing with is burnout. It seems odd to be saying that - for the past six months I've been working on a brand new product that I helped conceive of and prototype a little over a year ago. I got to work with fantastic interns and some of the best developers I know on an interesting, useful project that I know many people will enjoy using. We got to use a modern framework with good tools and clean interfaces. In many ways, it is a dream project. But I left before it was released. The culprit is billing code.

It started right after my first internship in 2005. Copilot had just launched and all of the other interns had gone back to school. I stayed behind, deferring my Stanford admission three months, to keep the product alive and wrap up the few bugs and features that hadn't been implemented during the summer. On the top of the list: a subscription payment system. The idea was pretty simple, a tiered set of subscriptions based on minutes per month -- similar to a cell phone plan, minus the evil. The problem was, we could not find any payment processors at the time that could deal with variable monthly subscription fees. So we had to implement it ourselves, credit card database and all. I did the majority of the work; my econ second-major came in handy. Before I left at the end of the year, the new subscription system was in place and people were signing up.

It did well for Copilot. Sales doubled and doubled again. When I returned, I took over billing again. I help our support team work with customers billing issues, I fixed bugs in the system, and added little features to make some of the small pain points go away. Then about a year ago, we noticed Copilot sales were starting to plateau, so we set out to add new features and restructure the billing system. For my part, this involved a near-total rewrite of the billing system, sending me deep into the details of billing cycles, prorating, plan switching, and other tediously boring subjects. I spent months refactoring and months testing and bug fixing.

The problem with billing systems is that, technically speaking, they are not very difficult to implement, but they must be perfect. New features garner little praise, but errors will easily result in lost customers. And I had became the in-house subscription billing expert. Even after moving to the new project, I could be interrupted at any time if a customer got into a weird state or saw what they thought was an error on their statement. And of course, the new product would need billing code of its own. It had become inescapable.

The other main issue was personal projects. As you know, I put a lot of stock in personal projects. I feel that they are the best way to improve yourself as a developer, and a good way to keep you sane when your work projects head south. Unfortunately, the employment contract I signed as an intern (which still applies as a full-time employee) is ambiguous about IP ownership with regards to personal projects. In other words, it would be possible, though unlikely, that the company could take ownership of something, even though I had worked on it entirely in my own home, with no company equipment or expertise. (Unfortunately, New York does not have provisions like California and six other states, which prohibits employers from taking ownership of outside projects.) While I have no expectation that would actually happen, the ambiguity makes it difficult to justify spending any time on projects that I care about. That limited my outside work to projects I'd had gotten excluded about a year before, when the policies had not been so rigid.

So I took some time off. So far, I've been working on things that I've had to put on the back burner for the past year, including a big new update to the eBay Toolbar. Working from home has been relaxing. I can set my own schedule, and work without interruption. The biggest thing I miss is the social interaction with my fantastic coworkers. I may be returning in a few weeks, or I might take another month off. I'll be updating as I get further into the break.

Thanks to wit for "Fishing at Blenhiem", zzzack for "money roll", and TheGoogly for "Time Card".

How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 3: Programming Interviews

Tue, 01 Sep 2009 12:00:00 +0000

This is the third (and final) installment of a series on how to get a job at Fog Creek Software (and other selective software companies).

Assuming you do well on the design question, you will be scheduled for a second phone interview. This one will involve code. We use our remote assistance software, Copilot, to log in to your computer so you can use the editing tools you're comfortable with. (Of course, if you're not comfortable with that we can always fall back to EtherPad, which is also pretty awesome.)

Before we get into any specifics, make sure you've read the post on phone interviews. Everything I mentioned there carries over to coding interviews, especially the part about talking through what you're thinking. It can be easy to jump into a programming problem and just start writing down your answer without explaining your process. While this may work for actual programming, it defeats the point of an interview. You need to make a point of communicating your solution to your interviewers. It will show them that you have a good, thorough thought process and that you can work with other people.

Speaking of being able to work with people, try to remember manners and common courtesies to everyone you interact with during the process. Our office managers may not be asking you technical questions, but if you treat them rudely or disrespectfully, you can be sure that we'll hear about it. (If you haven't learned it yet, learn it quick: the office manager is, by far, the most important person in the office.) They don't want to work with jerks, and neither do we. Also remember to respect the space you're in. I try to have fun and interesting objects in my office for visitors, but going around, picking up, playing with, and moving EVERY SINGLE OBJECT in my office does not make me want to work with you, no matter how good the solution you're mumbling to yourself is.

Not that a candidate has ever done that...

A programming phone interview will be nearly identical to a in-person interview, so I'm addressing both here. The interviewer will talk with you about your background for a bit, then he will jump into programming questions. Personally, I have one go-to question that I use for both phone and in-person interviews. This allows me to judge candidates based on their relative performance, as well as to help those that might get off track a little. Other interviewers have a few questions that work through progressively. A little hint: if an interviewer asks you several different programming questions over the course of an interview, there's a good chance they're related. See if you can build on your previous answers.

Whether you get one question or several, you will probably arrive at the final solution through an iterative process. Don't spend too much time perfecting the first code you write. Most likely, you've not taken something major into consideration, and are not yet headed in the right direction. It's better to quickly find any fundamental flaws in your code than to have a beautiful, but incorrect solution. As you progress towards a better solution, start thinking about the little stuff like error checking, corner cases, and typos.

When you're done, give it a look over just to be sure. Then, talk your interviewer through the full execution path a few sample inputs. You may think your solution is clear to them -- and it probably is -- the sample input is not for them, it's for you. There are still bugs in your code. Nobody writes perfect code in interviews. You're talking to some stranger who put you on the spot, solving a problem you were just introduced to a few minutes ago, and your solution could determine whether or not you get the job. It's a stressful situation. So run a few sample inputs, find those bugs, and impress the interviewer with your thoroughness. I've interviewed so many people that showed a lot of promise, but fell flat at the end because they refused to test their code, despite several glaring errors.

So what's the best way to prepare for all of this? Programming Interviews Exposed is a good, if somewhat basic primer on coding interviews. Joel's Guerrilla Guide to Interviewing v1.0 and v3.0 have some sample questions that we actually used to ask during interviews. You can also search for "programming interviews" on Google and find a lot of sample questions.

All that will help, but there is one way that you can really improve your chances in an interview: Learn C.

Hey, I thought you guys didn't care what language the interview was in, what gives?!

It's true, we don't really care what language you use for the interview, as long as it's common enough to be suitable for communication. If you want to use Java in an interview with me, go for it.

But here's the catch: most other languages make things easier. While that's good for being more productive, it makes it harder for you to demonstrate your skills the interviewer. If you can sit down and reverse the words in a string, in place, all with pointer arithmetic, I'm going to start thinking you might have an idea of what you're doing. If you do it in Java and forget to mention that the language you chose makes it impossible to do it in constant memory, you just earned yourself one demerit.

If you don't already have one, go find yourself a copy of K & R and read it cover to cover. Once you're familiar with C, find a set of questions (like this one from an MIT course on programming interviews) and work out the solutions in C, using pointers. Treat it like production code, come up with weird inputs, test it all. Then find a CS buddy and challenge them to find bugs. You may not get to the point where you are comfortable doing a real interview in C, but the thought process and preparation will help you regardless.

By being deliberate and methodical, and making a point of communicating your thought process to your interviewers as you go, you eliminate the common pitfalls and increase the chances that the interviewer will help nudge you in the right directions. And try to have some fun; after all, programming is what you love doing, right?

How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 2: The Phone Screen

Wed, 26 Aug 2009 12:00:00 +0000

This is the second installment of a series on how to get a job at Fog Creek Software (and other selective software companies).

So you've wowed us with your cover letter and resume. Your kernel work on OpenBSD shows us that you are passionate and hardcore. Despite marginal grades in college, you've shown us how incredibly bright you are. And we know you care about the job, as your cover letter was witty, well-written, and clearly intended for us. Now it's time for a phone interview.

We generally do two phone interviews. The first will be a design question. While you won't be writing any actual code for this interview, you will be working with some core concepts like algorithms and data structures. Our intent is to test your problem solving abilities given a problem and a set of constraints. To that end, the most important thing to remember is to talk through your thought process. Sitting silently for minutes on end is a great way to convince us that you are currently Googling the answer.

Most interviewers will just have one big problem for you. The problem is always iterative; the intuitive solution will probably work, but it will have deficiencies, and you'll have to improve your answer. This is intentional, so don't get discouraged when the interviewer starts pointing out all the various problems. He is actually giving you hints about what to focus on to improve the solution. Even more importantly, don't get too stubborn about your ideas. It's a fine line. An interviewer might challenge a correct answer to make sure you can explain it well, and you should stick to your guns. But there's also a chance that you're wrong, and while there is no single correct answer to most of the questions, there are incorrect solutions, and more than likely, your interviewer has seen them before and is trying to help you see your mistake. In either case, review your answer with a critical eye. Work through the solution out loud, and see if you trip yourself up. Pay attention to the interviewer's reactions for a little extra help. If you get to the end and neither of you sees and problems, then you're probably on the right track.

So let's say your interviewer asks you a question about designing a data structure to hold passenger information for a train scheduling program. The interviewer wants to know the best way to store how many passengers get on each train (denoted by its number) at each station (denoted by which mile on the track it's at) along each line (denoted by number), and on which day of which year. (Creating good interview questions is actually quite difficult. Please excuse this softball question.)

Immediately, a multi-dimensional array jumps to mind. You put the train number on one axis, the stations' mileage on another, the line on another, and the date on the final axis, with the passenger count as the data. Piece of cake, all the data is in there, easily accessible by any metric in constant time. Done, right? Of course not. Your interviewer will probably ask you to find any problems with your design. If you're quick, in this very poor example (seriously, I don't want to get any comments about it), you'll realize that you've created a very sparse matrix, which gets very big very fast, without actually holding all that much data.

How can you improve upon it? Well, in your excitement about your brilliant solution you forgot to consider how the data is going to be used. Remember to ask questions and try to get all the details and specifications up front. In this case, you probably don't need to be able to access the data from every axis. That would allow you to use a hash table of hash tables of hash tables to keep constant time lookup while decreasing memory overhead.

Of course, most people would probably get to relational databases faster than this (extraordinarily bad) example, but it is the type of iteration that you should be going through. If you happen to know, or stumble upon, the correct answer early in the question, the interviewer will usually be prepared to extend the question by asking about more specifics, corner cases, and enhanced features. Just keep working through each new part, building on your solution.

If you keep the discussion alive, talking through the problem, and revisiting your solution trying to find any pitfalls, you'll help your interviewer understand your approach and increase the chances that you'll work your way to a good solution -- and another interview.

Stay tuned for part three, which will cover programming interviews.

How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 1: Résumés and Cover Letters

Wed, 15 Jul 2009 16:25:31 +0000

This is the first installment of a series on how to get a job at Fog Creek Software (and other selective software companies).

Disclaimer: This article is based on my own personal experiences and preferences in hiring and does not necessarily reflect Fog Creek's official policies. As such, it is meant as a helpful guide. Reading this article will not entitle you to a job. And of course: Fog Creek Software, Inc. does not discriminate in employment matters on the basis of race, color, religion, gender, national origin, age, military service eligibility, veteran status, sexual orientation, marital status, disability, or any other protected class.

My last two articles discussed, if somewhat briefly, why a cover letter is important in our hiring process at Fog Creek. The intent of those articles was to provide a peek into our hiring process; an idea of what we look for and why we find it useful when screening applications. I was surprised at the negativity of some of the responses. Perhaps I was too brief. In the interests of providing constructive criticism and some guidance to all of the commentors that voiced uncertainty about what to write in a cover letter, I'd like to start a series called "How to Get Hired at Fog Creek (and Other Selective Software Companies)".

This is part one of the series: Résumés and Cover Letters.

As I've mentioned several times now, our résumé screening process is broken down into seven areas, as outlined in Joel's article: Passion, Pickiness, English, Brains, Selectivity, Hardcore, and Diversity. I'll talk about each, and what candidates can do to best demonstrate themselves in their applications.

Also, before I begin, I have to say that I wouldn't be talking about any of this if I thought this information would allow people to game the system. I've spent almost four years using these guidelines to evaluate applicants, and I've come to believe that they probably are as objective as you can get with the information available at the beginning of an application process. To game the system, a candidate would have to outright lie about many facets of their background and experience. The only real problem I see with it is that a strong candidate who does not submit a quality application may be passed over. Hopefully this will help.

General Guidelines

Résumé

Your résumé should be a concise summary of who you are as an applicant. It should have the following sections:

Experience: List each of your past, relevant jobs. Include the company name, your title, your start and end dates, and a short list of responsibilities and accomplishments. Some people say that you should write in a particular style for this section. Just make sure you don't get too choppy. Full English sentences are almost always better.

Education: For each college or university you've attended, list the school's name, location, dates of graduation or expected graduation, major, relevant minors, and GPA. Don't include high school.

Extras: Software developers often list their competencies in various languages. While we don't screen for specific languages, it can be useful. Just make sure you're honest; if you say you are an expert in C, we'll expect you to show it in the interviews. Other extras might include such details as honors received, activities you participate in, or groups that you belong to. They may not affect a hiring decision much, but it'll help me get an idea of who you are.

Try to keep your résumé to one page. If you have a lot of experience, going to two pages is acceptable. Three or more pages is overkill, and it usually means you're including things on your résumé that would be better off in your cover letter.

Cover Letter

Your cover letter is where you round out your application and fill in any holes that might be missing on your résumé. At the very least, it should explain which position you're applying for, why you're applying for it, and why you would be a good fit. You shouldn't suck up; instead, take the opportunity to clarify and elaborate on yourself as a candidate. I'll talk more about specifics below.

Application

If you're submitting your application via email, your cover letter should be the body of the email, with your résumé as an attachment. I personally don't have a problem with receiving résumés as Word documents, but some people do. If possible, send a PDF version. It's more universal, doesn't require that the recipient has the latest version of Office, and generally looks more professional. A link to a well-formatted HTML version is also OK, just don't attach an HTML file to an email.

Specific Criteria

We screen applications using the seven guidelines below. Generally, you need to fulfill five of the seven to pass the screening, but we provide plenty of latitude for applicants who show they are smart and get things done. In the four years I've been involved in hiring, I can only think of one or two applicants that have met all seven, so don't worry if you are missing a couple.

Passion

For me, passion is far and away the most important attribute a candidate can show. Every single developer at Fog Creek is immensely passionate about making software. Almost everyone is working on a side-project or two, learning new languages, contributing to StackOverflow. I want to see that same sort of passion from candidates. This is probably where the cover letter is most beneficial. Use it as an opportunity to brag about what you've done, especially about things you did outside of work or school. Open source software, Flash games, your own blog software, anything. What if you were too busy at work to do side projects? Then tell me what had you so engrossed at work.

Besides showing me that you're passionate about software, a good set of side projects show me that you know what you're doing, especially for younger, less experienced candidates. A long running side project is a great way to learn about making real software. Most college and internship projects are too short to really learn about the full process of creating software. Write something, then spend at least a year maintaining and improving it. Even better, get other people to use it, fix bugs, and keep your users happy and coming back.

Pickiness

This is the other aspect where a well-written cover letter is really the only way to show that you're being picky about which companies you're applying to. We're not looking for you to suck up to us; in fact, sucking up is considered a negative. We just want to know that if we go through all the trouble of spending numerous developer hours screening and interviewing you, and thousands of dollars flying you out and putting you up in a nice Manhattan hotel, that you'll be likely to take the job if we offer you one. Hiring is expensive, and screening for pickiness helps us make sure that those dollars are spent most effectively.

The easiest way to show that you're selective about who you apply to is to tell us a little bit about why you're applying. What about the company makes you want to work there? Is there a particular product that interests you, something about the company culture that makes you think it's the right place for you? Don't exaggerate; "I want to work for your company because it is the best company ever" will not get bonus points. Just be honest. I'm genuinely interested in why you're applying. Also, do some research on the company. I don't expect people to have read the entire Joel on Software archives, but you should have a basic idea of what products a company makes before applying.

My previous articles got some push-back on this point. Some people told me that for them, a job is just a job, but that shouldn't be grounds for screening them out. Personally, I disagree. If you want to work for selective companies, it has to be about more than just the paycheck.

English

A lot of software development is about communication. We want to hire candidates with strong communication skills, specifically in English. The easiest way to score points here is to make sure your cover letter is written well. Proof-read it a few times, then get a friend to read it over. A well-written cover letter stands out, but a poorly written one stands out even more. Too many errors and you'll be immediately disqualified. There's nothing worse than getting an application that says "Great comunication skills".

Brains

You've got to be smart. The easiest way to show off your brains is to have had good grades in school. Just put your GPA on your resume and you're done. Good work!

Of course, that's not the only way to demonstrate your intelligence. I know many incredibly smart people who just didn't do well in school. Maybe it just wasn't their thing, or they were working two jobs and didn't have time, or they dropped out to start their own company. If that's you, then you'll have to show me how bright you are. Do you solve really hard problems on a regular basis at work? Tell me about it. Did you apply to MENSA for the fun of it and get in? Impressive. Hold the record for creating the Sunday crossword puzzle with the fewest black squares? Awesome. Exceptional standardized test scores will even do in a pinch (though that might not be as widely accepted).

Selectivity

This is where we get lazy. See, we figure that if you've gotten into other selective institutions, then you're probably a pretty good applicant. It means you've been approved by a similar process. Your résumé is all you really need here. Just make sure you have an "Education" section. Even if you didn't finish college, the fact that you got in can only help.

Hardcore

What I mean by hardcore is that you've worked with a difficult technology, something that not every Bob, George, and Davie could grasp. Lower-level technologies are usually hardcore: things like significant experience in assembly, writing a graphics engine in C++, optimizing JVM load times in C. New technologies also count as hardcore. At one point Python and Ruby would have qualified. Now, Haskell and Erlang make the cut. (And of course, Lisp is always hardcore.) Usually the experience section of your résumé will cover this. A small side project or two aren't really enough to count (though you should still do them); you need several years' experience. This can be difficult for recent graduates, but remember, you don't need every one of these criteria.

Diversity

Now, before I go and get myself in trouble, I want to make it clear that I'm not talking about the usual definition of diversity that has to do with inherent characteristics of who you are. What we are looking for here is diveristy of experience. Software development, at all levels, is about intense problem solving. Having a team with a diverse background of experience means having a team with more points of view. Usually, the "Experience" section of your resume will be enough to fulfill this, though sometimes an applicant's extracurriculars will make a difference. Just show me that you're a well-rounded person.

Summary

Remember, you don't need to hit all seven of these, so don't try to make things up just to fulfill one area. Spend time on your strong suits. Better to meet four really well than stretch the truth to make five.

Of course, not all companies use this particular screening process. Some may not even look at your cover letter. But spending the time to carefully craft your application will be well worth the effort either way. I find that the process of writing my cover letter helps me improve my résumé, and vice versa. For the companies that do read cover letters, you'll have a leg up, and for those that do not, having one certainly won't hurt you.

Update: The second article in the series is up!

Reddit's Entitlement Complex

Mon, 06 Jul 2009 12:00:00 +0000

A couple of days ago, I posted a short article on the importance of cover letters in Fog Creek's hiring process. I was hoping it would be an informative glimpse into how our resume screening works. I have to admit, I'm rather surprised and disappointed at the responses I got about it.

Responses seemed to come from two different groups. One, which was mostly held over at Hacker News, generated good discussion on the value of cover letters in various hiring situations. These were the types of responses that I was hoping for. Some people agreed with me, some disagreed, and both gave good reasons why, which I found informative, and I'm hoping other people did as well.

The other group, from the Programming Reddit, was far more hostile. Some people immediately assumed that I was writing the article because something was wrong with our process, that our criteria are completely unreasonable, and that we should be able to determine everything we need to know from a Word-template resume. Some seemed to think that we were missing all the good candidates because of our criteria. The truth is, we've probably passed over a small few that we would have hired. But that's ok; it's better to err on the side of false negatives than false positives.

Others told me that that instead of suggesting that applicants include a cover letter to increase their chances (which any career counselor will tell you is a good idea), that we should change our hiring process to make it easier for people to apply. For some companies, this might make sense; if they're just trying to find warm bodies to fill cubicles it would be exactly the right suggestion. But we like to be a bit more selective. And I'm personally motivated to be more selective. As a developer, I will often be working, directly or indirectly, with the people that I hire. That means the better developers we hire, the easier and more interesting my job will be. So if I have two candidates in front of me, one that included a cover letter about how he hand-rolled his own blog, comments, and feed aggregator for fun to learn a new framework, and another that just sends a resume with a one-liner in the body of the email, I'm going to be much more inclined to say "hire" for the guy with the cover letter, even if the second guy's resume is a bit better. Similarly, I'll be more likely to say "hire" to the Eagle Scout, triathlete developer than a candidate who bludgeons me with all of their "accomplishments".

Another group of commentors seem to find writing cover letters too tedious to bother with. Instead, they'll find jobs through networking, or the jobs will just come to them. Personally, I would be highly dubious of a company that hires simply based on who you know. That seems like the kind of company where you end up working with the boss's nephew who is "good with computers". A company's hiring process is usually a pretty good indicator of what kind of talent it employs, and thus the kind of quality the company has. The higher the bar, the better the talent, the more interesting the company. I'm sure you can find exceptions, but that's all they are, exceptions to the rule.

Both responses betray some sense of entitlement. They seem to think that a company should cater to its applicants, failing to understand the meaning of the word "apply". Sure, we should also advertise why the candidate would want to work for us, and we do. But good jobs are not hand outs. We want the best developers we can find, and we'll gladly pass over a few good ones to find one great one. As an employee, that's one of the best benefits a company could offer.

Overall, I'm disappointed at the end result. But it did expose some interesting differences in communities. Hacker News took what was intended as helpful advice and created an interesting discussion around it, with good points and information on various views of hiring processes. Proggit, on the other hand, jumped into trolling and name-calling, and the community supported it. Personally, I don't really mind; I've been called an idiot on the internet before and I'm sure I will again. But I think an opportunity to have a good and relevant discussion was missed.

This is becoming something of a series. ~~In a few days I'll have another post ready that goes into more detail about the criteria we use, and possibly suggest some things that candidates can do to show us that they fulfill them.~~ Part One: Résumés and Cover Letters of "How to Get a Job at Fog Creek (and Other Selective Software Companies)" is up!

Your Résumé Won't Get You Hired

Wed, 01 Jul 2009 17:57:39 +0000

I've been actively involved in the hiring process at work for over two years now. Résumé screens, phone interviews, coding phone interviews, lunch interviews, and technical in-person interviews, I get to do it all. Sometimes it's a minor annoyance that keeps me from coding, other times it's a nice break in the middle of a busy day.

But recently I've become more and more frustrated with one section of the process, the résumé screens. The problem has to do with cover letters, or the lack thereof.

In our system, a résumé screen has seven different criteria, five of which must be met for the applicant to move on to the next stage. (Four is sometimes accepted, but only for obviously exceptional candidates who might not fit within the strict interpretation of the system.) Generally, a résumé can only satisfy three of those seven criteria. Sometimes we can stretch it and infer one or two more, but it's rare. So when an applicant doesn't send along a cover letter, I've got to work harder just to give them a fighting chance; it doesn't endear them to me.

On the other hand, a good cover letter can show me that the applicant meets four of the five required criteria. Not only do they increase their odds in raw numbers, they also make my job easier, which can only help them.

But not just any cover letter will do. It doesn't seem like it would be that obvious, but I can usually identify a "Dear [Company Name]," cover letter within a few seconds of opening it. It's better than no cover letter at all, but it almost automatically loses on two of the four criteria, meaning that the applicant has to nail the five remaining. They make my job harder, and the raw odds of them getting in are lowered.

So what makes a good cover letter? There are a lot of resources out there, but for me it comes down to two simple things: tell me why you want to work at my company and tell me why you want to do the job you are applying for. Bonus points for showing me those two things. That's the generic advice. Specifically for programmers, show me your previous work, your outside projects, the blog you wrote from scratch, etc.

Take the time. You can still share a lot of the cover letter between companies. But make sure the company knows you care by writing a paragraph about what draws you to the company. Be specific, words like "interesting" and "exciting" don't add anything.

And try to make my job easier.

Fixing jQuery's Opacity in Firefox

Tue, 02 Jun 2009 12:53:04 +0000

I think jQuery has uncovered a flaw in Firefox's rendering:

This is a screenshot of Postbox's website mid-transition. (Actually, I used Firebug to manually set opacity to 50%.) They're using $.fadeOut() and $.fadeIn() to transition between tabs on their features page. For some reason, Firefox has a lot of trouble with this, and ends up displaying strange green artifacts where there should be partially transparent text. (I'm completely guessing, but it looks to me like it might be related to ClearType.)

Fortunately, it's easy to fix. The problem only occurs when the element being faded out or set to partial opacity has a transparent background, set explicitly via background: transparent; or implicitly by not having a background defined at all. To fix, you just have to specify an appropriate background, often background: white;. In this case:

background: white url(http://postbox-inc.com/-/img/bg-content.png) bottom center repeat-x;

Does the trick:

Much better.

Update: Seems as if Safari 4 on Windows has the same problem, which is also fixed by setting the background. Chrome and, surprisingly, IE don't seem to have this problem.

My Language Features Are Your Libraries

Wed, 20 May 2009 15:25:56 +0000

Today at lunch, a few of my colleagues got into a discussion of the merits of some of the new language features in the .Net family. Unfortunately, I was at the wrong end of the table to participate in the discussion, but it has spawned an article that I want to respond to. Go take a look at it, then come on back.

To distill Ben's thesis, he's "annoyed that many of these 'cool' language features in C# are nothing more than libraries in Smalltalk". I can understand his annoyance. C# is being touted for having new, innovative language features while languages like Smalltalk get relatively little attention despite having similar features (though usually as a part of a library) for years.

Ben goes on to show how C#'s ?? operator (which returns the left expression if that expression is not null, and otherwise returns the right expression) can be added very easily to Smalltalk.

I guess this is why, despite all of its faults, I have a lot of trouble giving up on Smalltalk. C#’s a good language, and .NET’s a good framework; but I cannot help but feel that this isn’t an issue of reinventing the wheel, as much as forgetting that we can provide programmers the tools to make their own types of locomotion.

Unfortunately, I think he is missing the bigger point. I do not disagree that giving programmers the ability to "make their own locomotion" is important. It is, in fact, completely necessary if you want a language to have useful libraries. But it is also a virtue when languages make it unnecessary to create a new five wheeled vehicle.

And we've been there before. There was a time when language designers seemed to think that a good language implemented a minimal set of features. And from that mentality we got languages like C++, which couldn't even go as far as implementing a native string type. In fact, there are so many that people have created comparison pages to help you figure out which one to use.

So while I can understand his frustration that Smalltalk hasn't gotten the same attention as .Net for features that are trivially implemented, I feel that his argument is analogous to saying that I should not be excited about Python having a built in string type because C++ has always had the ability to implement one.

That's a Wrap

Wed, 31 Dec 2008 08:14:46 +0000

Last day of the year. Must be time for a looking back/looking forward post.

Photography

2008

The major theme of the year has been photography. I started in 2007, but I feel that 2008 was the year I improved past being just a guy with a camera to a real photographer. I shot my first wedding, got my first real photo job, got published in a national magazine and started a daily photo blog. I've acquired the equipment to shoot just about anything I'd like.

2009

I would like to continue improving my skills and building my own brand of photography. I want to shoot at least two weddings this year (hopefully paid), and start selling prints of my artistic work. I would also like to continue shooting fashion and see if I can get myself published again.

Personal Projects

2008

The center of my personal projects in 2008 was the eBay Toolbar. I started it at Stanford for a d.school class and then let languish for almost a full year before reviving it. Though the core functionality has not really changed, the internals have been completely refactored to make it comply with Mozilla's quality standards and make it easier to maintain. I tried getting it added to addons.mozilla.org, but it's still an "experimental" plug-in. Maybe I need more reviews (hint, hint) to get it promoted.

I also participated, with Benjamin, in the DjangoDash, which our "Mercurial-based Code Review" tool won. Hopefully, you should be hearing more about that in the coming months.

2009

Priority #1 is to get the ebay toolbar promoted for the simple reason that it's too hard to track how many people have it installed. I know it's probably in the 10,000s, but I know my metrics are flawed.

This year I went to Florida with Iris, Italy with my family and Iris, Boston and Waterloo for work, and back home a couple of times.

2009

I want to do more skiing this year, which plans are in the works for. I'd also like to do another big trip this summer, maybe Asia or Oceania. I need to figure out a way to make travel photography pay for travel...

That's about it; at least what I'll write about here. It's been a good year, even despite the recent meltdown, and I think 2009 will also be a good year. Happy New Year!

Why QA is Important

Mon, 24 Nov 2008 13:19:40 +0000

This is a diagram of most of the code bases within Copilot. Of the sixteen nodes displayed, we actively maintain fifteen. Of those, four integrate with other Fog Creek products, like FogBugz. In our most recent product release, Copilot OneClick, we heavily modified nine components and added two. It was the most complex release in Copilot history, yet it was the smoothest.

Often when we've released new software, it happens in starts and fits. We would push something out only to realize that we'd forgotten a crucial config setting or had left in an extra bit of logging. Sometimes two new components would conflict with each other. To fix it, we would roll back to the previous working version, make our fixes, test them out on the staging server, and roll it back out.

It sounds like we were being irresponsible, like we were pushing new code with many substantial bugs. The reality was that it was always something small and easy to overlook, which got amplified into a much larger problem by the complexity of the many interacting systems. Forget to put a default on a column in a new table and five different components could simultaneously crash.

The problem was that Ben and I were too close too the code. With only two of us working on the project, there was never any way for us to test code without having worked on it, and that made us bad testers. We knew too much about how the application was supposed to work, which made it easy to overlook small but important details. But a couple of those small mistakes would quickly turn into an outright crisis.

We had an outside QA analyst at the time who helped test Copilot's user experience. Her input spurred changes that made Copilot much more intuitive and sleek. But she was usually testing individual components on internal servers, not the end-to-end system on production servers, except for the largest releases.

Then in March our QA superstar, Alison, came on to the Copilot project. For the first time in three years we had a full-time, dedicated tester with enough time to do both targeted component testing as well as end-to-end system tests.

At first I felt a little internal resistance to her feedback. I knew I wasn't writing perfect code, but I didn't really like someone else pointing it out to me. It took a little while to understand that she was not trying to prove me wrong, that our goals were actually identical. Soon, I began enjoying getting assigned cases from her. They were detailed reproductions of the bugs, making them easy – and fun – to fix.

Soon we got into a nice pattern: I would typically work a couple hours later and kick off a build before I went home. Then, in the morning before I got in, she would start testing the new build. By the time I got in, I would have a list of things to fix, which helped me focus my time, making me a more efficient coder. As we got closer to releasing, we would push builds to the staging servers, and in a matter of hours before we knew, for sure, whether the build was ready to go to production.

So did she find all of the bugs before we pushed to production? Not quite. We released OneClick with one significant bug: the installer could not be downloaded from Internet Explorer because IIS injects extra HTTP headers into HTTPS connections, which IE then has trouble understanding. She caught it on the production servers a little after we rolled out. The funny thing is, it's a bug we've fixed before, just one line fix in ASP.Net:

Response.ClearHeaders();

So why did we miss it before going live? Because our staging server doesn't use HTTPS; it's not close enough to the production server. It wasn't possible for her to find that given the testing environment. But that was it. Really. Nine components significantly modified, two new, and only one line needed to be changed in all of it. We didn't even need to cut a new build, we just pushed out one patched file and all was fixed.

Instead of the panic and worry that we'd experienced before, now pushing new code is a calm, steady process. We can be confident in the quality of the code. They key was to get another pair of eyes on the product, someone who could ask the questions that we didn't think of while coding.

Cross-posted at http://blog.copilot.com/

This is how Crazy the Market is Today

Fri, 21 Nov 2008 09:57:51 +0000

From my dad:

If you had purchased $1000 of Delta Air Lines stock one year ago, you would have $49 left. With Fannie Mae, you'd have $2.50 left of the original $1000. With AIG, you'd have less than $15 left. But if you had purchased $1000 worth of beer one year ago, drunk all the beer, then turned in the cans for the recycling refund, you'd have $214 cash. Based on the above, the best current investment advice is to drink heavily. It reduces anxiety too. Even better to buy in a state without a deposit and then return them into a state with a deposit refund.

I think he might be on to something...

Pay It Forward

Mon, 17 Nov 2008 23:20:58 +0000

A while back, Gillian posted a Pay It Forward chain on her blog after receiving a box of delicious looking caramels. Just as the rules stipulated, she payed the favor forward to the first three people to comment on the post. I was the first. On Friday, my treats arrived:

In the paper ~~are~~ were three large, soft, wonderful chocolate chip cookies from the New York Times recipe, and in the jar a stack of Martha Stewart's Thin & Crisp® chocolate chip cookies. It was a wonderful surprise and a great way to start my weekend!

So now it's my turn. The official rules are:

I agree to send something fun, cute, and nice to the first 3 blog owners who post a comment on this entry. In turn, those three will post this information and pick 3 people they want to send something to and so on. ~~Unfortunately, due to postage costs, I can only pay it forward within the United States.~~ If you are interested in participating, be one of the first 3 blog owners to leave a comment!

You have to promise that you will then post about this on your blog, link to me, and then send something to the first three people who comment on your blog so that this continues. When the first three have commented I will email you a request for your shipping address and I will send out something that I hope will make you smile!

Good luck!

Photo Blog

Sun, 09 Nov 2008 14:56:20 +0000

I just finished putting together my new photoblog, check it out! I'm planning on publishing 1 photo per day. I also will be adding an option to buy prints or downloads.

Enjoy!

Election Day

Tue, 04 Nov 2008 13:44:38 +0000

GO VOTE!

Source: CNN

What Happens When Reddit Gets a Little Too Safe?

Thu, 23 Oct 2008 17:50:07 +0000

Looks like they got a little too careful. (First observed at 5:50pm EST)

Fixing iGoogle with User Styles

Tue, 21 Oct 2008 08:31:31 +0000

Recently, Google updated their iGoogle Homepage. As happens with most UI changes, people were not terribly pleased with it. One of the main complains, and my biggest problem with it, was that it added a tab sidebar that ate up screen real estate.

It is useful if you have many tabs for your homepage, but since I only use one tab, I find it obnoxious. Worse, there is no setting to hide it automatically. Fortunately, Lifehacker quickly came through with a Greasemonkey script. It works, but because it uses javascript, there's always a second between page load and script execution where the page still looks off.

So I decided to fix it myself using Firefox's user styles. First, I installed Stylish to make editing user styles easier. Then I added the following style:

@-moz-document url(http://www.google.com/),
               url-prefix(http://www.google.com/ig),
               url-prefix(http://www.google.com/webhp) 
{
    #doc3 td#col1, #footerwrap { display: none; }
}

#doc3 td#col1 is the table column (Gasp! Table layout?! Really Google?) that holds the list of tabs. Hiding it is all you need to get rid of it. There will be a little weirdness at the bottom left over from the curve at the bottom of the column. Hiding #footerwrap will get rid of that, as well as remove the footer, making the page shorter.

Now your iGoogle can take up the whole width of the page.

Democrats = Bulls?

Mon, 20 Oct 2008 21:13:56 +0000

The New York Times has an interesting piece on investing under the two main parties in America:

As of Friday, a $10,000 investment in the S.& P. stock market index* would have grown to $11,733 if invested under Republican presidents only, although that would be $51,211 if we exclude Herbert Hoover’s presidency during the Great Depression. Invested under Democratic presidents only, $10,000 would have grown to $300,671 at a compound rate of 8.9 percent over nearly 40 years.

Looks like Wall Street should be pulling for Obama.

Copilot OneClick!

Tue, 07 Oct 2008 18:00:02 +0000

What started six weeks ago as a Seth Godin inspired three week code sprint ended today as we shipped Copilot Oneclick. OneClick makes it easier to help the people you help most often by installing a client on their machine. You can also install it on your home machine and disable the confirmation dialog to allow remote access as long as the computer is logged in.

Double Extra Latte

Thu, 25 Sep 2008 13:38:24 +0000

What do you call a latte with no coffee? Steamed milk.

Yup, that's right, I paid $3.50 to the cute European girl behind the counter of my local superdeli for a cup of steamed milk. Of course, when I bought it, it was too hot to drink, so I waited until I got up to my office to take a sip.

"Hmm...", I thought to myself, "this coffee is really mild", not wanting to believe that someone could forget the defining ingredient in a recipe that only calls for two ingredients. But, indeed, she had.

This got me to thinking. What makes me willing to pay $3.50 for hot milk mixed with flavored water? I can buy a gallon of milk for $3.50 and brew dozens of pots of coffee for a similar price.

The answer is convenience, pure and simple. Buying coffee means that I don't have to clean the pot, make the coffee, heat the milk, froth the milk (with a whisk, no less), combine the two, and then clean it all up when I'm done. Instead, I just get on the train, make a quick detour on my way from the subway, chit-chat with the cute European girls, and get to my desk with a nice hot cup of coffee.

But all the convenience in the world isn't worth anything if you can't execute on the basics. I know I could probably go down right now and complain and I would get a replacement (assuming they have any sense of customer service). But it's too late. I probably won't go back to get my coffee there. I will tell other people about my bad experience. There are some times that you get only one strike before you lose someone's business.

What's worse, is they have no way to know that I am unhappy. I don't want to go to the effort to tell them they messed up, so they can't intervene in the situation to make me feel better about my experience by giving me a free replacement.

So why am I blathering on about getting stiffed on one little coffee? Because it occurred to me that the coffee business is very much like Copilot. Copilot makes it easy to do remote tech support. You don't have to have physical access to the machine, wait around while your aunt finds the password to her wireless router, set up port forwarding, change her network to static IPs so DHCP won't break the port forwarding, install VNC, go to Starbucks to test it (where you'll undoubtedly get that $3.50 cup of coffee), and then clean it all up when you're done. Anyone can do all that, but few people want to.

But if Copilot's value is convenience, then it is critical that we do it right the first time.

We work hard to do just that. We dog food extensively: we all use it to help our friends and family, and Fog Creek uses it daily to support FogBugz, so if there's ever a problem, we know about it first, before it impacts our customers. We have crash reporting and extensive logging, so if a problem does reach our customers, we know about it promptly and can proactively contact those users. And if all else fails, we make it as easy as possible for users to contact us by putting our email address and phone number right on the website so we can make things right.

Now we just need cute European girls...

Cross posted at blog.copilot.com

Google Transit NYC

Tue, 23 Sep 2008 07:40:04 +0000

Google released Google Transit for New York today. It's pretty much what you would expect from the project, which started over 3 years ago for Portland, Oregon. Here's a sample from a recent (fictional) shopping trip. Kind of an obvious feature, but nice to finally have. I wonder how HopStop will react.

Unfortunately, it's not on the iPhone version of Google Maps yet, which would require a full software update since it's baked into the system. Hopefully they get to that soon.

Chairs and a DIY Boom

Wed, 27 Aug 2008 10:23:49 +0000

As Joel mentioned a few weeks ago, we're currently in the process of moving to a new office. As our influx of interns for the summer filled the current office past its capacity, I and the rest of the Copilot

team moved down to a temporary space in the new building. For the summer, we've been like our own little start up, complete with Nerf weapons (more to come on that), cardboard cutouts of T-Rex and Darth Vader, and cowboy posters.

The one difference is that we are also acting as a warehouse for some of the new furniture. We have stacks and stacks of chairs, an empty minifridge, two shipping palettes worth of desks, and a family of bookshelves, all in various states of unpacking.

Having all this designer furniture around, I just had to make a photo of it. I especially loved these chairs, their bright colors and complex legs. So after work, I walked around the office, chair in hand, until I found a suitible studio: our two glass Ikea lunch tables, set end-to-end. I wanted the lighting to be simple, one big, soft light directly overhead and one on the background for separation, much like the Platon's Putin shot (minus the decidedly evil looking subject).

The only problem was, I didn't have a way to get the light directly overhead. I could get it close, but I could see in the pictures that it was still coming from an angle. I needed a boom. But I do not own a boom; all I had with me was two lightweight light stands, two umbrellas, a clamp, two ball bungies, and some gaffer's tape. I quickly checked the MacGyver handbook, but it seems he'd never run into this problem. I'd have to do it on my own.

I first put the clamp on the top of one of the stands (we'll call it the "stand"), making sure the stud was as far into the clamp as possible, to make sure it couldn't rotate and fall off. If you look closely, you can see it's well past the hinge point.

Next, I lay the light stand with the umbrella (we'll call it the "boom arm") across the back end of the clamp, using one of the knobs to make sure it didn't slip backwards. At this point, the top side of the "boom arm" was much heavier than the bottom, and wanted to fall over. To fix this, I used two ball bungies, one end on a leg of the "boom arm", and the other on a knob on the "stand" to provide tension.

Another important thing to note, especially since the photos don't show it well: the legs on the "stand" are nearly flat to the ground, so they're nice and wide. Additionally, I made sure to keep one of the legs pointed in the same direction as the "boom arm" at all times. This kept it from falling over, since at no point was this rig balanced correctly.

In the final setup shot, you can see how everything was positioned: On the boom arm is a shoot-through umbrella with an SB-800 on 1/8 power, positioned directly over the chair. In the bottom right is the background light, a Vivitar 285HV with a gridspot on 1/16. Camera was at 1/160 at f/8.0 with ISO 200 to kill the ambient.

In post, I just cleaned up smudges on the table and removed the seam between the two tables, as it was distracting. To make the triptych, I just resized the images slightly (I wasn't using a tripod, so there were some slight differences) so they all matched up.

Italy

Sat, 02 Aug 2008 08:01:42 +0000

Quick update:

Today is our 7th day in Italy. We started in Riomaggiore, one of the five towns of Cinque Terre. On Monday, we hiked through the towns to Monterosso, where we cooled off after the hot hike with a swim.

Tuesday was another hike, this time south to Porto Venere at the tip of the peninsula.

Wednesday morning we left Riomaggiore for Gallicano, Tuscany. On the way, we stopped in Lucca to ride bikes atop the city's large defensive walls.

Thursday we climbed the Apuan Alps up to a small peak called Monte Forrato. The peak had full 360 degree views, to the coast, to the surrounding peaks, and back to Gallicano.

Yesterday was another travel day; we left Gallicano, back through Lucca, to Siena. We got a short tour and spent some time wandering around the city.

Today we biked through Tuscany. Very hilly, very sunny, but beautiful all around. I was stopping every few minutes to capture yet another hilltop villa.

Tomorrow we meet Iris in Florence, and spend a couple more nights in Siena. Then we'll hit Naples, Pompei, Capri, and Rome before flying back home.

Trip 50% complete. So far: awesome!

Lightroom Rocks

Mon, 30 Jun 2008 01:29:30 +0000

I've started using Adobe Lightroom more and more lately. It's a change in my usual workflow. For a long time, I was using Adobe Bridge, a very competent photo organizer, for arranging and previewing all of my photos. Then, after reviewing and culling, I would edit the best in Photoshop.

I changed over to using the Lightroom 2.0 beta (which is free right now) after shooting a wedding and realizing there was no way I was going to process 800 images in Photoshop before the end of the decade. Lightroom sits right between Bridge and Photoshop, a very competent organizer, with flags, tags, and ratings, mixed with a comprehensive digital darkroom. Lightroom covers all global changes you might want to make to an image: white balance, exposure, color, contrast, noise, sharpening, and lens correction, just to name the major ones. It also comes with a number of presets with different styles. The 2.0 beta has also added local changes as well: spot removal and a retouching brush that enables dodging and burning, local saturation, and tinting.

This all leads to a workflow built around rapid prototyping. I can play with white balance, boost the exposure, bump the saturation, increase the contrast, and add a slight vignette in less than five minutes, taking the image from the camera's low contrast, slightly underexposed defaults to a nice, rich photo. Along the way, I can try out different options, building on a preset or looking at what presets other people have used. My Photoshop workflow focused on getting everything just right, my Lightroom workflow still helps me get everything right, but with added creativity because I can try things out quickly and see if I like them.

An example:

This is one of my favorite images, which I wrote about back in September. But I've always felt this image was missing something. Really, it's just a little muddy; there's not enough separation between the foreground and background. I've tried using Photoshop to give it a little punch, but I could never find anything I liked.

So tonight I decided to give it a go in Lightroom. Fortunately, I'd kept the RAW file around, so I still had the color information. Since I'd been doing a lot of color correction in the wedding photos I have been processing, my first idea was to try and get the color balanced properly. Before when I'd worked with the color version of this file, everything had been too warm, mainly because the two main lights are flames, with a very orange light. I used the white shirt in back as a reference to get a good color. This turned the background slightly green, from the street lamps, while keeping the skin tones on the performer nice and warm. I then added a style that I am fast becoming fond of: high contrast, slight vignette, strong colors. With 3 settings changed and a little touch up to tone down the background, I got this:

Something about this pops so much more than the first version, the performer is separated from her surroundings by color and tone. It almost has a cross-processed feel. I've worked on this image a number of times, but without the rapid prototyping that Lightroom offers, I'm not sure I ever would have found a post processing that I could be completely happy with. Now, I'm so happy with it, I'm trying to sell it!

Firefox Download Day

Tue, 17 Jun 2008 19:20:15 +0000

Happy Firefox Download Day everyone!

Huh?

Yeah, ok, you're right, it's not a real holiday.

Ummm....

You don't know what it is do you? Fine, I'll explain. The folks over at Mozilla are trying to set the world record for most downloads in 24 hours.

So what is being downloaded?

You didn't click on the link, did you? Firefox 3.0, the new, speedy, less-memory-hogging, more-user-friendly version of the world's most popular open source browser.

What are you on?

I'm a little over excited about it, so sue me. But seriously, you should try it out.

Aardvark FTW!

Mon, 16 Jun 2008 19:38:20 +0000

I should probably let someone else announce this so it's not shameless tooting of my own horn, but whatever:

http://www.djangodash.com/results/

First Place - Aardvarkia (out of 52 entrants)

Benjamin Pollack

Tyler Hicks-Wright

A code review tool with Mercurial integration.

(Aardvark reference for those who didn't get it.)

Some background: DjangoDash is a code sprint/competition to make more apps for the Django Python Web Framework.

Ben and I have been talking about code review tools, and have tried to use a couple, including ReviewBoard from VMWare and Rietveld Code Review by Python inventor Guido van Rossum, both of which use Subversion. We found their workflows to be too tedious to use frequently; you have to manually create a unified diff of all your changes and upload it to the server, while making sure not to accidentally check any of those changes in.

So, we decided to enter the dash with a code review tool based on Mercurial that uses its distributed nature to make the workflow easier. Now you just make your changes, start a new review at the website (which creates a new repo on the server for you), push your changes to your review repository, and assign the review to the reviewer. They can then accept it, in which case it gets pushed into the main repo, or reject, in which case it comes back to you and you have a chance to fix the problems. That way, all of your changes are versioned and periodic merges are done with the main repository so the branch history is always up to date. Moreover, a review history can be added to the check-ins after the review is approved, so the entire history is kept intact.

Right now we're planning it only for internal use, but I will definitely post if we decide to go open source with it.