April 2012 – rc3.org

Month: April 2012 (page 1 of 2)

How the University of Florida spends its money

This is the sort of thing I’d normally just tweet about, but hey, I have a blog, so I can add stuff to the permanent human knowledge base by posting it here.

People are justifiably outraged that the University of Florida is eliminating its computer science department. As Alex Tabarrok notes at Marginal Revolution, this is an example of how the institutional incentives for universities are not well aligned with what society most needs from those universities. This story is complicated. The state government is cutting funding for existing institutions even as it creates an entirely new polytechnic university carved out of the University of South Florida.

Cutting the computer science department will save the University of Florida $1.7 million. Many people have noted the size of university’s athletic budget, and that that budget went up by $2 million this year. The athletic budget, managed by the University Athletic Association (Inc.), is available online. UF’s athletic department is financially independent from the rest of the university and in fact pays the university for general services that it uses. So while it has a huge budget, it’s not as though Florida could cut athletics to save the computer science department.

Obviously we justifiably argue that it’s a shame that people care so much more about sports than they do about sustaining important academic programs. But you can’t say that UF is funding sports over computer science.

Applying judgement and influence

April 22, 2012 / Rafe / 3 Comments

I’m just going to keep posting stuff about Valve until I get tired of it.

Did you read the Valve employee handbook? If not, you should. To catch you up, at Valve, the corporate structure is completely flat. They have no managers, and everyone decides what to work on for themselves. The handbook explains what is expected of Valve employees and how people should adapt to that corporate structure.I’m sure some people find it intriguing and others terrifying.

Succeeding at Valve depends on two things, the application of one’s judgement and influence. Employees use their judgement to decide where they can add the most value for Valve. They use their influence to recruit other people to help them build the things that they have decided are valuable. Find a problem to work on, convince other people to help you solve it. Nobody is empowered to order anybody to do anything.

What occurred to me after reading the Valve handbook is that you or I can work in the Valve style regardless of where we work. If you work anywhere but Valve, you probably have a manager and you may have people who you manage as well. Within the constraints of your job, though, you should be relying on judgement and influence rather than hierarchy in your work, just like a Valve employee does.

If, in your judgement, there’s something more valuable you could be working on, you should be convincing people (like your boss) that your time could be better spent working on that other thing. Just be sure that you’re open-minded enough to accept that your judgement could be mistaken. If you’re right, though, it ought to be easy to convince people that your time could be better spent on a more valuable project.

At the same time, rely on influence rather than authority to get the help you need to get your work done. People generally do better work if they believe in the project they’re working on, and the ability to recruit volunteers is a good sign that whatever you’re working on is worth doing. People sometimes mistake interesting for valuable, but it’s always better to work with enthusiastic volunteers than with people who are doing something just because someone told them to do it.

Obviously if you work on an oil rig or at Burger King, this approach may not work. However, the field I understand best is software development, and if you’re working on software, you should the Valve philosophy to heart. Use your judgement and influence to make sure you’re adding as much value as possible at your job. If that gets you into trouble, maybe it’s time to use your judgement and influence to land a job more suited to your talents.

The Valve employee handbook

April 21, 2012 / Rafe / 0 Comments

Apropos of yesterday’s post, today someone has posted a leaked copy of the Valve employee handbook (a PDF). Here’s an except from page 8:

We’ve heard that other companies have people allocate a percentage of their time to self-directed projects. At Valve, that percentage is 100.

Very much worth reading.

Harnessing serendipity

April 21, 2012 / Rafe / 4 Comments

Lane Becker and Thor Muller have a new book out about the importance of harnessing serendipity — making your own luck. Becker explains why startups are better positioned to do so than established businesses in an interview with the New York Times’ Nick Bilton:

It’s a problem for start-ups as they grow and become a traditional business, because most businesses succeed through repetition, process and routine. But all of those things are designed for rote predictability. So we engineer our businesses to squash the role of serendipity inside their organizations. Even start-ups, when they get big, and they stop listening to your users, fall into a process of repetition.

I was struck by this explanation because today I also read Michael Abrash’s blog post on what it’s like to work at the game company Valve. It sounds like Valve is structured to cultivate serendipity in exactly the way Becker describes:

If most of the value is now in the initial creative act, there’s little benefit to traditional hierarchical organization that’s designed to deliver the same thing over and over, making only incremental changes over time. What matters is being first and bootstrapping your product into a positive feedback spiral with a constant stream of creative innovation. Hierarchical management doesn’t help with that, because it bottlenecks innovation through the people at the top of the hierarchy, and there’s no reason to expect that those people would be particularly creative about coming up with new products that are dramatically different from existing ones – quite the opposite, in fact. So Valve was designed as a company that would attract the sort of people capable of taking the initial creative step, leave them free to do creative work, and make them want to stay. Consequently, Valve has no formal management or hierarchy at all.

It’s brilliant when it works. I think that Becker is wrong, though, when he says that repetition, process, and routine are the enemies of serendipity. Building the wrong kinds of structures and processes have been responsible for crushing serendipity in many organizations, but the right kinds of processes (or if you prefer, habits) are necessary parts of maintaining the possibility for serendipity as a company grows.

For example, from an engineering standpoint, Etsy’s core practice is continuous deployment. Regardless of whatever else is going on, developers are always testing code, checking it in, and pushing it to production, many, many times a day. It’s that process that enables the company to continue to rapidly iterate even though the engineering team is growing. The process for pushing code is rigid and everyone follows it every single time they need to deploy something. It’s that process, though, that liberates people to be creative as individuals.

I’d be willing to bet that Valve has any number of processes or ingrained habits that serve the same purpose. People there obviously understand how to form teams without being told what to do. They have a common understanding of how Valve writes software that enables them to contribute to any project that the company is working on. Valve creates software that ships in big monolithic releases — engineers there clearly understand what’s expected at each phase of the project so that they can ship.

Of course, I’m responding to one short paragraph from the interview — I haven’t read the book. I think, though, that from a distance people look at creative companies like Valve or GitHub (which I plan on writing about some other time) and think mostly about the liberties people are allowed to take. My guess is that in large part, their success derives from the adherence to norms that are deeply embedded in the cultures of those organizations. Because the team members voluntarily adhere to those norms, they don’t stifle individual creativity.

If this sort of thing interests you, check out the book — Get Lucky.

The benefits of transparency in engineering

April 19, 2012 / Rafe / 2 Comments

For a long time, I was shocked by blogs like Etsy’s engineering blog, Code as Craft. I had a sort of old-school “information is power” mentality that led me to believe that letting competitors know about your technology stack would put a company at a disadvantage. Building scalable systems is hard, and I thought it was foolish to give away your secrets. I also prided myself on being able to sleuth the details of a company’s technology stack using URLs, HTTP headers, and page source.

I have long since come around to the opposite point of view, but general attitudes about this stuff hasn’t changed much once you get past the most progressive organizations. Stephen O’Grady explains to the recalcitrant why hiding your technology stack is a bad idea.

The other day I said on Twitter that all problems are user experience problems, except for scaling. And the solutions to those problems are generally so complex and so specific to a company’s product, staff, customers, and existing code base that slavishly copying one’s competitors at meaningful levels isn’t really possible. At most, what you usually get is an idea of what to try next, or issues you may run into down the road.

The advantages of sharing are real, and the disadvantages are an illusion. Go forth and start an engineering blog.

Getting serious about terminal multiplexers

April 18, 2012 / Rafe / 3 Comments

The biggest change in my work habits of 2012 has been the move from doing most of my work on my laptop to doing most of my work logged into a Linux virtual machine via SSH. I’ve used many editors over the years — Vim, Emacs, TextMate, UltraEdit, BBEdit, but the switch to working on the VM has led to using Vim for pretty much everything. For the past few months, I’ve been working hard to improve my Vim chops, with very pleasing results. I’ll probably write about Vim later.

The next thing I’m going to add to the toolchain is a terminal multiplexer. The two most popular are GNU Screen and tmux.

Terminal multiplexers have two main functions. The first is to enable you to run multiple virtual terminal sessions over a single SSH connection which you can arrange however you like and switch between using keyboard shortcuts. This is not incredibly useful to me because I use a terminal application with tabs and I’m very familiar with OS keyboard shortcuts, but using a multiplexer is more portable, and in some cases the ability to split a window and show multiple sessions adjacent to one another is really useful.

The second is that terminal sessions that are running from the multiplexer are maintained even if the network connection drops, accidentally or on purpose. I’ve used screen for awhile when I need to make sure that a long-running processes doesn’t die because I have to go to lunch or something. Using a multiplexer offers the ability to pick up your work exactly where you left off, all the way down to the scroll back buffer, even if your terminal session is disconnected or you work on more than one computer. My main motivation for picking up a multiplexer now is that my terminal sessions have started spontaneously dropping several times a day, and I’m eager to minimize the disruption.

The thing is, terminal multiplexers are beloved used by hardcore Unix users, so they probably have a large number of benefits I’m not even aware of yet, since I’m just really getting started. To this point all I really know is that you start screen by typing “screen” and that you reconnect to a disconnected session using “screen -r”. That feature alone, though, is compelling.

In the past I’ve only used screen, but I’m giving tmux a try. This blog post makes a convincing argument that tmux is more usable than screen. The place to start out, though, is the tmux man page.

I’m not sure what it says that development seems to be moving more and more back into terminal sessions, the way we did it twenty years ago. For all of the powerful desktop tools we used, these days I’m spending most of my day logged into a remote machine using a Unix shell and Vim. If you’re interested in digging into this more deeply, I highly recommend the Unix as IDE series from the Arabesque blog.

What young people need to learn

April 16, 2012 / Rafe / 0 Comments

Let me be clear: There is nothing more important we can learn as young people than to be kind, tolerant and accepting of others.

Anil Dash, A Note About Panther Pride

Instagram is not about silly filters

April 15, 2012 / Rafe / 2 Comments

The big news of the week is Facebook’s purchase of Instagram. I wasn’t going to write anything about it because it didn’t seem like there’s much to say that hasn’t already been said, but that may not be the case. For general commentary, I would recommend Paul “@ftrain” Ford’s Facebook and Instagram: When Your Favorite App Sells Out. I want to talk about something specific — Instagram’s filters.

I was on the fence about posting about it, but after The Daily Show made fun of it this week, I felt compelled to do so. I’m not in the business if picking apart jokes, but I see the sentiments in the Daily Show piece reflected frequently in serious commentary as well, and for the sake of all of you out there who are about to start building your own photo sharing apps in hopes of hauling in a huge bag of loot, I want to make sure you don’t emphasize the wrong things.

There are a bunch of iPhone apps that enable you to apply silly filters to your photos, and they are popular. Instagram’s filters are a “me too” feature that seemed to decline in use over time. If you look at the “Popular” tab in Instagram on any given day, you’ll find that photos with retro filters were rarely seen.

What works about Instagram is that it fosters deeper connection between people who are friends on the service and makes it easy to “meet” new people through their photos.

The interface encourages people to share photos one at a time, rather than uploading them in big batches, unlike most other services. The prominence of the “like” feature encourages people to compliment other people’s photos and to publish photos that other people will like, driving the overall quality of the photos on the service up. Unlike the photos people usually post to Twitter or to Facebook, photos on Instagram tend to be composed somewhat thoughtfully.

Instagram makes it easy to see the photos that your friends have liked, which facilitates finding more interesting people to follow. Following is also lightweight, as it is on Twitter. The result is that it’s easy to grow your network on Instagram. Looking at the photos a person takes every day feels more personal than reading their updates on Twitter. You learn about the way they see the world.

Why did Instagram sell for a billion dollars? Not because of novelty filters, but because it provided a compelling place to look at good photos taken by people you care about, and to find new, interesting people and develop relationships with them.

The Netflix Prize and the importance of recommendations

April 13, 2012 / Rafe / 1 Comment

The Netflix prize has fascinated me since it was announced and won. Today Netflix engineering has a blog post discussing their recommendations systems that explains why they chose not to implement the prize-winning algorithm. What stuck out to me most was this bit on how important recommendations are to Netflix:

We have adapted our personalization algorithms to this new scenario in such a way that now 75% of what people watch is from some sort of recommendation. We reached this point by continuously optimizing the member experience and have measured significant gains in member satisfaction whenever we improved the personalization for our members. Let us now walk you through some of the techniques and approaches that we use to produce these recommendations.

If you’ve noticed that recommendations have been moved to positions of greater prominence on the Netflix site over time, that’s why. The increased prominence of the recommendations also contributes to the large number of views selected due to recommendations as well, I’m sure.

The rest of the post goes into explaining what factors Netflix feels contribute to an effective recommendations system. This post is pure gold for anybody who’s building similar features.

What a modern front-end developer should know

April 12, 2012 / Rafe / 4 Comments

Here’s a fantastic post from Rebecca Murphey that lists the skill set front-end developers should be working to attain. Here’s her prediction of where things are headed:

Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to valuing tools. There’s a new set of baseline skills required in order to be successful as a front-end developer, and developers who don’t meet this baseline are going to start feeling more and more left behind as those who are sharing their knowledge start to assume that certain things go without saying.

I’m primarily a back-end developer and her list works for me as a way to get up to speed on what’s happening on the cutting edge of front-end development these days. It’s great to see a lot of the techniques and tools that we’ve been using on the back end for years starting to benefit front-end developers as well. It’s no longer the benighted wasteland that I once perceived it to be.

rc3.org

Strong opinions, weakly held