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.
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.
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.
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.
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
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 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.
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.
JavaScript: The Good Parts is one of my favorite computer books ever written, not just because it’s an excellent primer on JavaScript, but also because the title alone provides guidance to a way of living that’s worth pondering.
This week, PHP: a fractal of bad design is making the rounds. It’s a lengthy list of thoughtful criticism of PHP as a programming language (and Web development platform). The PHP core team should read it, although the truth is that most of the problems can’t be addressed without breaking old PHP applications, and the PHP folks are generally reluctant to make those kinds of changes. PHP has a massive installed base on shared hosting servers — breaking old applications reduces the adoption rate of new versions.
Here’s the deal, though. For all of the complaints about PHP, thousands of businesses rely on it, and millions of people use it with varying degrees of expertise. I personally have spent thousands of hours hacking on PHP applications, sometimes with much frustration. None of the problems listed in that blog post have prevented me from getting my work done in that time.
The secret to using PHP effectively is the same as it is for JavaScript … focus on the good parts. It turns out that works out for most everything in life. When I eat at a restaurant, I don’t have to like everything on the menu, there just has to be one dish that I enjoy. The number of bad dishes on the menu don’t really matter, what counts are the good dishes, at least if you willing to be an educated consumer.
We all choose the set of tradeoffs we’re willing to accept. I’m happy to take advantage of the opportunities working with PHP provides and do my best to stick to the good parts.
Today we learned that Jack Tramiel, the founder of Commodore, died at age 84.
The first computer I owned was a Commodore 64. It was the best Christmas present I ever received. I still remember typing in program listings from computer magazines by hand just so that I could see them run. The next summer I saved all the money I made from mowing lawns to buy a Commodore 1541 floppy disk drive so that I could copy games. If Commodore hadn’t offered an affordable alternative to the Apple II at the time, I probably wouldn’t have had a computer at all.
I’m very grateful to Commodore and Jack Tramiel.
© rc3.org. Powered by WordPress using the DePo Skinny Theme.