Work-life balance and Google

I’ve seen this Lockergnome article about what it’s “really” like to work at Google linked to from a lot of places, most recently by Marco Arment. The article, apparently based on an interview with current and former Google employees, describes the supposed pressure on Googlers to work unhealthy long hours at the expense of family and personal life. The most damning snippet, the one that Marco highlighted in his own commentary, is the following:

While he says there is no direct pressure to conform to “crazy hours,” he hints at the reason he lives a Google-centric life: His pay is directly related to the amount of time he spends with Google. For those who can’t keep up with the demand, they simply have no choice but to leave, as previous (and notably older) Google employees have done when they must make the choice between raising a family or getting a raise. (I personally know at least one former Seattle-area Googler who quit under similar circumstances after being forced to either choose seeing his newborn less, or receive a demotion if he didn’t travel more.)

I can’t claim that this description is untrue—it apparently came from someone’s direct experience, and I have to assume that they were telling the truth—but what I can say is that it doesn’t resemble in any way my experience of working for Google at any point in the last five years. Not only that, but everyone I’ve spoken to about it is as surprised as I am to see this kind of picture painted of our workplace. If that paragraph is true of some Googlers, it certainly isn’t true of most of us.

Certainly there are times when I’m in the office until late in the evening, sometimes as late as 10PM. But my impression, without having any data to back this claim up, is that these long evenings are at least made up for by corresponding late mornings, early evenings, and flexibility to leave the office during the day to do things that can’t be done (or can’t as easily be done) outside of normal office hours.

Many of the people I work with are married, and a decent number have children. They have just as much freedom to work a regular 9–5 day as I have to work wildly irregular times. It’s whatever suits the individual. If your life is set up such that regularity and structure are beneficial to you, because you have commitments to your spouse or because you want to see your kids before their bedtime, you should have no problems living by those hours in all but exceptional circumstances. And if you like to be able to leave early one day to go to an event and stay late the next to make up the time (not that anyone’s counting the hours, but you need to get something done some time) then that’s an option too.

In a company the size of Google, there are bound to be some people who don’t get on as well as they’d hoped to, or teams that aren’t as forgiving or as welcoming as the rest of the organization is. But it’s important to me for people to realize that that’s not the majority experience. It’s certainly not my experience.

Learn to code: addendum

In the spirit of the new year and the acquisition of new skills, and in the unlikely event that my last post inspired anyone to take a look at learning to code, have a look at Code Year. This site aims to teach people how to code, in weekly installments over the course of the year.

Learn to code

There’s a lot of talk happening right now, in Twitter and elsewhere, about whether coding—programming computers—is a skill that should be learned by most people as a basic tool to make their lives easier, or whether it can happily remain a skill restricted to those of us who do it for a living.

Daniel Jalkut, creator of MarsEdit, suggests that current levels of programming literacy can be compared to a period in the past where literacy itself was rare. He extrapolates from there, and concludes that the ability to program could become a similarly fundamental skill.

Literacy isn’t about becoming a Hemingway or a Chabon. It’s about learning the basic tools to get a job done. I think programming — coding — is much the same. You don’t have to be the world’s best programmer to develop a means of expressing yourself, of solving a problem, of making something happen.

There’s no question that a lot of people would benefit from knowing how to code. If you’ve ever done anything repetitive at a computer you would have been better off knowing how to get it done automatically. Every programmer I know has tales of seeing people slog through monotonous tasks that could have been accomplished by a computer in a matter of moments. Think of things like renaming files one-by-one, or copying snippets of data from one file to another file in a different format.

If that sounds familiar then you’re probably doing work that a computer could do much faster and more accurately than you can. If only you knew the right way to instruct the computer to do it for you.

There’s another side to this coin though. Sure, knowing how to code might have helped you out once in a while. But similarly there have been times in my life that things would have gone smoother for me if I’d known the Spanish for, “No, I’m not in the market for a donkey right now.” And yet I’ve never learned Spanish. It’s a matter of choosing to learn the skills that will be useful often, versus those that will be useful only occasionally. (I’m ignoring here the motivating factor that coding can be a lot of fun.)

My justification for not learning Spanish is that I’ve spent only a matter of weeks in Spanish-speaking countries in my life. Can you say the same about the amount of time you’ve spent in front of a computer? Most of us now spend our entire work days, and in many cases also a lot of our free time, interacting with a computer in one way or another.

Maybe learning the computer’s language will turn out to be worth your while if you’re in that situation, even if we never reach the point where young kids learn the “3 Rs and 1 P” in primary school.

Better Comics Feeds

Have you ever tried reading the XKCD feed on a mobile browser like Android Browser or Mobile Safari? Doesn’t it annoy you that you can’t read the comics’ title text (the additional joke that pops up when you hover the mouse cursor over the comic in a desktop browser)? Try the improved XKCD feed, which uses Yahoo! Pipes to put that text in a more readable format. It also provides links to comic explanations and XKCD forum threads if you’re into that kind of thing.

Similarly, are you bothered by having to click through to read Cyanide and Happiness instead of reading it right in your feed reader? Enter A Better Cyanide & Happiness Feed, another Pipes feed, which embeds the comics in the feed.

My life has been improved immeasurably by these feeds.

Lose the 10¢ — it’s worthless

Inspired by this analysis of coin efficiency at the Freakonomics blog, I’ve written a short Python script to calculate the efficiency of the Euro coin set. Like in the blog post, efficiency here means the lowest average number of coins needed to sum to any sub-Euro total (where all totals are assumed to occur equally frequently). For example it requires five coins to sum to 48¢: two 20¢, a 5¢, a 2¢, and a 1¢.

It turns out the average number of coins you’ll need is about 3.43, given the current set of six coins (I exclude the Euro and two Euro coins, since they’re no help in reaching sub-Euro totals). The maximum number of coins you ever need to reach any total is six. Note that we get this efficiency, much higher than the US’s 4.70, by cheating. We have six coins to play with, where they have only four.

The interesting part is in figuring out which coin would have the least negative impact on efficiency if it were removed. You might like to take a moment to ponder which is your least favourite coin before I reveal the answer. If you’re anything like me you probably hate the one cent coin, but sadly that’s the only one this analysis won’t let us remove: it’s required to form the total of 1¢, obviously. Every other coin is expendable, but with differing effects on the efficiency of the coin set.

Or so you might think. In fact, the coins barely differ at all in their effect. The 2¢, 5¢, 20¢, and 50¢ coins would each reduce the efficiency of our coinage by 0.81 if they were to disappear overnight. Only 10¢ differs, having a smaller effect of reducing efficiency by only 0.40.

So if we wanted to reduce the number of different coins all of us have to deal with (the principals are the same for me in the UK with Sterling, having 1p, 2p, 5p, etc.) with the minimum impact on efficiency, we should get rid of the 10¢ and 10p coins.

Beware Math.abs()

If the title didn’t tip you off, this is going to be a technical post. So you might want to skip it if you’re only here to read about how my thumb is doing (very well, incidentally).

Anyway, onto the subject at hand.

I recently had cause to look at the list of bugs that FindBugs looks for when analyzing your Java code. If you haven’t heard of it, FindBugs is a free software static analysis tool. In a nutshell it looks through your source code trying to find coding patterns that it knows can be the causes of bugs. It’s not a replacement for testing by any means, but it is a useful addition to your quality tools.

What’s especially useful is the fact that FindBugs tends to uncover bugs that you might not even know are possible—and thus probably haven’t tested for. Have a look at the list of issues it looks for to see what it can do. There are a few hundred issues listed there, so this could take you some time. I’ll wait.

Assuming you didn’t bother to read about all of those bug types, I’m going to call out one that I found particularly interesting. It’s what FindBugs calls, “Bad attempt to compute absolute value of signed 32-bit hashcode”. As the tool’s documentation describes it:

This code generates a hashcode and then computes the absolute value of that hashcode. If the hashcode is Integer.MIN_VALUE, then the result will be negative as well (since Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).

The interesting point here is that last parenthesized statement, that the expression Math.abs(Integer.MIN_VALUE) is equivalent to Integer.MIN_VALUE. It’s a surprising result, and one that can cause real problems if the programmer responsible for the code was expecting that call to always yield a positive value.

Recall that the range of integers that can be represented in 32 bits is -2,147,483,648 – 2,147,483,647. That is, the true absolute value of Integer.MIN_VALUE can not be represented as an int. The possibilities—from the perspective of the person who designed the Math library—are to have Math.abs() throw an exception when passed that argument, or to just return the number as-is. Neither of these are particularly useful to the developer,  since the error condition only shows up only one time in over four billion.

The FindBugs blog has more on this potential bug, including some examples of when it might occur. Author Bill Pugh explains why the case of calling Math.abs() on the result of a hashcode computation is a particular source of trouble.

Now that you’re aware of the potential for this bug to crop up in your code, what should you do about it? Well it would certainly help to run FindBugs against your codebase periodically to look for this bug and others. It really is amazing how many issues can show up even in well-tested code. The potential for human error in complex systems is almost limitless.

If you’re not happy with relying on static analysis and want to test for the bug in a unit test or regression test, you might find use for a string whose hashcode happens to be Integer.MIN_VALUE. Examples of these, again from the bug’s documentation, are “polygenelubricants” “GydZG_” and “”DESIGNING WORKHOUSES”. Take your pick.

Waiting for the Mac Version

If you’re unlucky enough to use Windows, there’s some faint light—not at the end of the tunnel, but at least slightly illuminating the squalid darkness. Pick yourself up a nifty new browser at some point today or tomorrow (depending on your time zone, and whenever it actually comes out for real). Sadly, I have to wait for the Mac version.