Career Break
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".
Posted September 14, 2009 - View Comments
How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 3: Programming Interviews
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?
Posted September 1, 2009 - View Comments
How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 2: The Phone Screen
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.
Posted August 26, 2009 - View Comments
How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 1: Résumés and Cover Letters
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!
Posted July 15, 2009 - View Comments
Reddit's Entitlement Complex
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!
Posted July 6, 2009 - View Comments
Your Résumé Won't Get You Hired
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.
Posted July 1, 2009 - View Comments
Fixing jQuery's Opacity in Firefox
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.
Posted June 2, 2009 - View Comments
My Language Features Are Your Libraries
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.
