Do What You Love

A good third of the mountain of mail I’ve gotten since my first post has been of the general form:

“What should I study in college/learn to do/work at to get hired at Valve/have a good career/have a good life?”

The most useful response I have is drawn from my own life: Do what you love. There are no guarantees, especially in the short run, about where that will lead – but at least you’ll enjoy the trip, and it is likely to lead to exciting things. It is true, however, that it can take a while; consider my own long journey to being a full-time programmer.

In 1975, I was a freshman at Clark University with absolutely no idea what I wanted to do with my life. I was a Geography major, but only because I had taken an intro course and done well enough so that a professor had decided to mentor me. I did my Geography homework and papers the way I did all my homework and papers – under pressure and generally at the last minute; classwork was just what I had to do to stay in college. Then, as part of my major, I took Dick Howard’s FORTRAN course, and something interesting happened.

Dick had the habit of writing each homework assignment on the blackboard (this was before whiteboards) at the start of the class that covered the relevant material for that assignment. So during class, I’d listen to the lecture with half my mind, and with the other half I’d figure out how to do the assignment, then write the code for it in my notebook (this was before laptops, let alone tablets). As soon as class was over, I’d head for the computer center (this was before PCs), type the assignment out on punch cards (this wasn’t before teletypes or terminals, but those weren’t available to normal users at Clark), and see if my code worked. Once I had it working, I’d extend and embellish it beyond what the assignment required, seeing what I could coax our feeble Xerox minicomputer into doing. It was easy, it was fun; in short, it was what I wanted to be doing.

That summer, I decided to stay on campus, so I had to take a class. I picked the one that looked like the least work, a half-credit class in assembly language taught by Andrea Goodman – and unexpectedly got a hint of just how deep the rabbit hole went. I hadn’t even realized there was a native language the computer used, and suddenly I was learning it. I did well in the class, but Andrea told me I had a lot more to learn, and suggested I TA her programming course the next semester, which I did, staying about one lecture ahead of the students, since I’d never had a real programming course myself (as opposed to FORTRAN for Geographers). I started to learn about algorithms, program design, coding for readability, and the like. I even had my first taste of crunch time, going to Andrea’s house with the rest of the TAs and a pile of pizza and spending a whole day grading finals.

I’d say I loved programming back then, but it wasn’t even that complicated – it was just what I did naturally. I was good at lots of other things I did academically, but they all felt like work. More importantly, the material in those other classes didn’t lead anywhere for me; I learned it, and thought about it no further. Programming was different; I remember my roommate Chris Caldwell and I sitting on our beds and trying to figure out as many different ways as we could to convert from ASCII to binary. How’s that for wild dorm life?

Clark didn’t have a programming major, though – in fact, Andrea was half of the entire computer department – and even if it had, programming was not on my career radar or that of anyone I knew. So I remained a Geography major, albeit one who programmed at every opportunity, often to the detriment of my classes.

After I graduated, I eventually wound up as a PhD student in the Energy Management and Policy program at Penn, studying under Steve Feldman. This was near the end of the great oil price spikes of the 1970s, and energy was a hot area. Steve was a brilliant entrepreneur, landing lots of grants and projects, and one of them involved computer-based energy modeling and analysis, a godsend for me, since I had been starved for programming since becoming a grad student. I headed down to the computer center and started implementing the code on an IBM mainframe…

And found out that, unlike Clark, neither students nor professors got free computer time at Penn. Steve’s project would have to pay for its time – but there was no money for that in the budget. We were well and truly screwed.

I don’t remember what made me think of it, but it occurred to me to check out a microcomputer. By now it was 1980, and I had been seeing ads for Radio Shack computers for a few years, but I didn’t know anything about them. I assumed they were toys, but there were other systems around that seemed more businesslike. There weren’t a lot of computer stores around; I finally found a place in Haverford that had a very sharp tech named Richard Beyer; Richard sold me a Vector Graphics VIP CP/M computer loaded with 56K of RAM and dual 320K floppies (quad density; the controller couldn’t keep up, so every sector read required the floppy to rotate twice, which was incredibly slow – but think of all that storage space!) – and one other very important thing, a Microsoft FORTRAN compiler. (This wasn’t before C, but it was before C was widespread on microcomputers; I had never even heard of it.)

The only way to get my work to date off the IBM system (short of retyping the whole thing) was via a serial port; to do that, I had figure out how to write a serial comm program, which resulted in the worst week of my programming life until Richard saved me by explaining the concept of a null modem. Then I finished the project on the microcomputer, uploaded the results to the IBM system and wrote them onto a tape, and delivered the tape to complete the project.

That was just the start for me and the VIP, though. CP/M was pretty lame in terms of built-in utilities, so I wrote a bunch of utilities for it, such as a full-screen disk browser; it was a great learning experience to try to replicate the functionality I had taken for granted on minicomputers and mainframes, and see that I could do it myself. Better yet, the VIP had a button that dropped you into a ROM monitor from which you could dump the contents of memory and do disassembly, which was a revelation to someone who had only ever used computers that carefully sealed users off from the OS and hardware. Best of all, though, was that it had memory-mapped video.

We’re not exactly talking desktop-class RGB bit-mapped graphics here: The VIP could push the grand total of 160×72 black-and-white pixels.

Doesn’t sound like much, does it? In those days, it was magic. I figured out how XOR-based animation works, learned Z80 assembly language, and wrote a Space Invaders-type game; the VIP didn’t have sound, but otherwise it was a complete, smoothly-animated game, complete with levels and high scores. Only a handful of people ever played it – I didn’t even know yet that there was a computer game industry – and none of them understood just how cool it was, but that was okay. Creating the game was its own reward.

As you might expect, the time I spent programming reduced the time I spent doing energy research, and especially the attention I gave to figuring out what my dissertation was going to be. In fact, I did my best to figure out a way I could work programming into my dissertation, with no success. While I was trying to get myself moving on my academic career, something happened that forever changed the course of my life: The IBM PC.

When I read about the new IBM microcomputer, I mentioned to my wife that if I ported my game to the PC, I could probably sell a lot of copies. (By this time I had met Dan Illowsky, who had the best-seller Snack Attack on the Apple II, and I knew that there was money in selling games.) She generously agreed to let me spend half our life savings on a PC (all the more generous since she was the one holding down a real job to support us). I got the PC, ported the game in a few months (to 320×200 – nearly six times as much resolution – with four glorious colors!), and sold it through Dan’s publisher, Datamost. Space Strike shipped in plastic baggies with printed cardboard inserts; I still have one, complete with a floppy that I can’t read on any machine made in the last two decades.

And then one day I came home from Penn, got the mail, opened a letter from Datamost, found a quarterly royalty check for $8,000 – and I was on my way. I immediately dropped out of the PhD program, and went on to write or co-write three more games in the next year. The funny thing is that I never got a royalty check nearly that big again; it turned out that the PC was a business machine in the early days, and apart from Flight Simulator, entertainment didn’t sell nearly as well on the PC as on the Apple II and the like. So eventually I got a real programming job, then moved to Silicon Valley and started writing articles and books; there were plenty of bumps along the way, but it was obvious that I was finally doing what I was meant to do.

If you can read that story and see any master plan – or any planning at all, for that matter – you’re more insightful than I am. The only thread that runs through it is that I did what I loved, even though most of the time it wasn’t what I was supposed to be doing and seemed counterproductive. (My mother was convinced I had thrown away my professional career when I decided not to get my PhD, changing her mind only in the mid-1990s, somewhere around the time of my first meeting with Bill Gates.) The point is emphatically not that you should neglect everything else in order to program; it’s that you should figure out what makes you want to neglect everything else, and do that. It might be video games, it might be repairing cars, it might be starting companies, it might be raising a family. Whatever it is, find it and do it.

Perhaps the most useful way to figure out what you really want to do is to observe what you actually choose to do. Lots of people say they want to write games, and get excited about it and make plans and talk about it, but just don’t find time for it. To be really good at something, you have to immerse yourself in it, and that’s just too hard to do unless it’s what you want to be doing all the time – unless it’s what you have to be doing. Something that seems compelling from the outside may not suit you when you actually try to do it; writing video games is nothing like playing them, any more than writing novels is like reading them. So if you think you want to write games, start doing it, and see what you learn – about yourself, most of all.

In general, try things that seem worthwhile, set goals and work hard to achieve them, and see where that leads and how you respond. It’ll be clear when something becomes compelling, because it’ll be where you choose to spend your time and attention. It may not be what you expected or wanted it to be – but by definition you’ll find it fascinating and satisfying. And when you think about what you could do with your studies/career/life, really, what more could you want?

There’s no universal prescription for such things, but I’ve seen similar patterns with many other people with interesting careers. Your mileage may vary, of course; it’s your own personal journey, and, in fact, that’s the whole point.

This is just my own opinion and experience, offered in response to some major life questions I’ve received; it’s strictly personal, and doesn’t represent Valve’s position in any way. That said – if your journey eventually brings you to Valve, all the better!

What Valve Looks for When it Hires

In my first post, I promised I’d discuss in detail what Valve looks for in people when it hires. Fortunately, I don’t have to, because there’s a great description of that and more in the Valve handbook. I strongly recommend reading it before applying for a job at Valve; it will help you figure out whether Valve would be a great place for you, and whether you’d be a great fit at Valve. Check it out – it’s beautifully written, and worth it for the entertainment value alone.

I’m Not Dead, Just Buried

Just a quick note to let you know that I’m overwhelmed – literally and figuratively – by the response to my first post. Figuratively in the sense that it’s incredible how many people are excited about the possibilities for wearable computing. Literally in the sense that mail is still coming in faster than I’m able to answer it, and I haven’t had time to even start moderating the comments. I’ll read every piece of mail – and do my best to answer it all, although that I can’t guarantee, because I have to get some work done too – and I’ll moderate the comments, but it may take a while yet. Please bear with me.

I’ll also note that I only intend to allow comments that contribute in a substantive way to the discussion of each blog post. If you think Valve’s cool, I think that’s great, but if that’s all your comment says, it’s not going to show up. I want to have high-bandwidth discussions in the comments, the sort that enhances the value of the posts, so please keep that in mind when you write a comment.

Valve: How I Got Here, What It’s Like, and What I’m Doing

It all started with Snow Crash.

If I hadn’t read it and fallen in love with the idea of the Metaverse, if it hadn’t made me realize how close networked 3D was to being a reality, if I hadn’t thought I can do that, and more importantly I want to do that, I’d never have embarked on the path that eventually wound up at Valve.

By 1994, I had been working at Microsoft for a couple of years. One evening that year, while my daughter was looking at books in the Little Professor bookstore on the Sammamish Plateau, I happened to notice Snow Crash on a shelf. I picked it up and started reading, decided to buy it, and wound up devouring it overnight. I also started thinking to myself that I had a pretty good idea how about 80 percent of it could work right then, and wanted to implement it as badly as I had ever wanted to do anything with a computer – I had read SF all my life, and this was a full-on chance to make SF real. So I tried to start a project at Microsoft to do a networked 3D engine.

About the same time that it became clear I wasn’t going to be allowed to start that project, John Carmack, fresh from writing Doom at Id Software, came to Seattle to visit his mother, and we went to dinner at Thai Chef. I had met John in person just once before, but he knew me from PC graphics articles of mine he had read when he was first learning to program the PC, and we had exchanged posts on the M&T BBS a few years earlier. During our one previous meeting, he had surprised me by asking if I wanted to come work at Id; I had said no, because I was in the middle of getting Windows NT shipped, and because Microsoft had been generous with stock options. I knew he was going to ask me again on this visit, and I knew I’d say no again, because I was even more entrenched at Microsoft, and because now I had even more stock options. But John didn’t say anything of the sort for the first two hours. He talked about persistent Internet game servers, about people building their own levels and running them on their own servers, and about how it would be possible to connect them together so players could go from one to another, with the virtual world accreting over time. I realized that what he was really talking about was a Metaverse – less glamorous than Neal’s creation, but, amazingly, gloriously, unbelievably real. And when he finally did get around to asking if I wanted to come work at Id, I realized that I couldn’t pass up the chance to be a part of making that future happen.

Working with John was like the sequence in “The Matrix” where Neo has one martial art after another pumped into his brain. I’d stagger out into the parking lot of Id’s Black Cube in Mesquite each evening stunned from a day of trying to keep up with John as we figured out an entirely new programming world – 3D, Internet client-server multiplayer gaming, mods, scripting, everything since we were the only two programmers – and somehow manage the half-hour drive back to Plano. It all happened at lightning speed, with no time to sit back and digest – Quake shipped only 16 months after I arrived. And it was all worth it – not only did I grow tremendously as a programmer, but Quake turned out to be a seminal game; granted, not one of the best games ever, but truly groundbreaking technically (for which, to be clear, John was the brilliant innovator and driving force), and a game that gave rise to a genre and a community that continue strong to this day. As one example, when I started at Valve I found that dozens of people there had started their careers by modding Quake or working on games based on the Quake engine – and in a way I also created my own job 15 years in the future.

In 1996, Id was visited by Mike Harrington and Gabe Newell, who were leaving Microsoft to start Valve, and wanted to license the Quake source code to build their first game on. No one else at Id was particularly interested in licensing them the source code, or even talking to them, for that matter, but I knew Mike and Gabe from my time at Microsoft (in fact, Mike went far out of his way to help me when I started contracting with Microsoft in 1992 – I doubt I would have survived at Microsoft otherwise – so in a sense that’s the start of this story), so I stepped in and facilitated getting the license done. That turned out to be a good thing for almost everyone involved– Id made a lot of money from the license, and Valve built Half-Life from that code – but I didn’t benefit personally (except in the very long term), because I decided to leave Id shortly thereafter. My plan was to return to Microsoft, but Mike and Gabe asked me if I wanted to be the third founder of Valve. After a lot of thought, I decided that I had had enough of small game companies for a while, and joined the Natural Language Group at Microsoft, where I had a great year or two learning about natural language before figuring out that it wasn’t a problem likely to be solved within my lifetime.

Going back to Microsoft was arguably not the best decision I ever made, but neither was it final. Valve has a long-term view; over the years, many people at Valve stayed in touch with me, and periodically one or another of them would ask whether I was ready to join up. Fourteen years later (did I mention Valve has a long-term view?) my work on Intel’s Larrabee project wrapped up. I knew that Valve made cool games and was very successful, and knew a lot of people there that I liked and respected, and that was enough to make it worth a try. So I went to Valve knowing almost nothing about the company’s culture or organization, expecting something more or less like the other places I’ve worked.

I was in for a surprise.

Valve is different

I’ve worked at a lot of companies and in a lot of situations over the last 30 years. I’ve been a programming consultant and magazine and book author. I’ve worked alone and with a partner and at various companies on games. I’ve worked on operating systems, drivers, firmware, natural language parsing, consoles, and processor design. I’ve consulted and worked at a series of startups and small companies, both hardware and software, I’ve worked at Microsoft, I’ve worked at Id, and I’ve worked at RAD Game Tools. They’ve all been interesting, they’ve all been great learning experiences, and some of them have been truly remarkable places. In short, I’ve seen a lot of what tech has to offer.

Valve is different.

Gabe tells it this way. When he was at Microsoft in the early 90’s, he commissioned a survey of what was actually installed on users’ PCs. The second most widely installed software was Windows.

Number one was Id’s Doom.

The idea that a 10-person company of 20-somethings in Mesquite, Texas, could get its software on more computers than the largest software company in the world told him that something fundamental had changed about the nature of productivity. When he looked into the history of the organization, he found that hierarchical management had been invented for military purposes, where it was perfectly suited to getting 1,000 men to march over a hill to get shot at. When the Industrial Revolution came along, hierarchical management was again a good fit, since the objective was to treat each person as a component, doing exactly the same thing over and over.

The success of Doom made it obvious that this was no longer the case. There was now little value in doing the same thing even twice; almost all the value was in performing a valuable creative act for the first time. Once Doom had been released, any of thousands of programmers and artists could create something similar (and many did), but none of those had anywhere near the same impact. Similarly, if you’re a programmer, you’re probably perfectly capable of writing Facebook or the Google search engine or Twitter or a browser, and you certainly could churn out Tetris or Angry Birds or Words with Friends or Farmville or any of hundreds of enormously successful programs. There’s little value in doing so, though, and that’s the point – in the Internet age, software has close to zero cost of replication and massive network effects, so there’s a positive feedback spiral that means that the first mover dominates.

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.

Now, I can tell you that, deep down, you don’t really believe that last sentence. I certainly didn’t when I first heard it. How could a 300-person company not have any formal management? My observation is that it takes new hires about six months before they fully accept that no one is going to tell them what to do, that no manager is going to give them a review, that there is no such thing as a promotion or a job title or even a fixed role (although there are generous raises and bonuses based on value to the company, as assessed by peers). That it is their responsibility, and theirs alone, to allocate the most valuable resource in the company – their time – by figuring out what it is that they can do that is most valuable for the company, and then to go do it. That if they decide that they should be doing something different, there’s no manager to convince to let them go; they just move their desk to the new group (the desks are on wheels, with computers attached) and start in on the new thing. (Obviously they should choose a good point at which to do this, and coordinate with both groups, but that’s common sense, not a rule, and isn’t enforced in any way.) That everyone on a project team is an individual contributor, doing coding, artwork, level design, music, and so on, including the leads; there is no such thing as a pure management or architect or designer role. That any part of the company can change direction instantly at any time, because there are no managers to cling to their people and their territory, no reorgs to plan, no budgets to work around. That there are things that Gabe badly wants the company to do that aren’t happening, because no one has signed up to do them.

Hardest of all to believe is the level of trust. Trust is pervasive. All of Valve’s source code is available to anyone in Perforce, and anyone at Valve can sync up and modify anything. Anyone can just up and work on whatever they think is worth doing; Steam Workshop is a recent instance of someone doing exactly that. Any employee can know almost anything about how the company works and what it’s doing; the company is transparent to its employees. Unlike many organizations, Valve doesn’t build organizational barriers to its employees by default; it just trusts them and gets out of their way so they can create value.

To be clear, Valve hasn’t magically repealed the realities of developing and shipping products. We’re all human, so teams sometimes argue (and sometimes passionately) about what to do and how to do it, but people are respectful of each other, and eventually get to a consensus that works. There are stresses and more rigid processes when products are close to shipping, especially when there are hard deadlines for console certification (although shipping for the PC is much more flexible, thanks to Steam). Sometimes people or teams wander down paths that are clearly not working, and then it’s up to their peers to point that out and get them back on track.

Also, don’t think that people randomly come in every day and do whatever they feel like doing. It certainly wouldn’t be okay if a programmer decided to move to an empty room and start weaving straw hats (although if they wanted to write a tool to let people weave and sell virtual straw hats, that would be fine). People commit to projects, and projects are self-organizing; there are leads, but they’re chosen by informal consensus, there’s no prestige or money attached to the label, and it’s only temporary – a lead is likely to be an individual contributor on their next project. Leads have no authority other than that everyone agrees it will help the project to have them doing coordination. Each project decides for itself about testing, check-in rules, how often to meet (not very), and what the goal is and when and how to get there. And each project is different.

It’s hard to believe it works, but it does. I think of it as being a lot like evolution – messy, with lots of inefficiencies that normal companies don’t have – but producing remarkable results, things that would never have seen the light of day under normal hierarchical management. The games speak for themselves – and then there’s Steam (and no, Steam doesn’t have formal management either). Valve’s long string of successes, many of them genuinely groundbreaking, is strong evidence that the hypothesis that creative people are the key to success is in fact correct, and that the structuring of Valve around those people has been successful.

And, almost by definition, it’s a great place for the right sort of creative people to work.

What I’m working on

So what has my personal experience been?

As I said earlier, I knew little about how Valve worked when I started here, and my introduction to the company was not at all what I thought it would be. What I expected was that I’d be handed a substantial chunk of technical work to do – something like visibility determination in the Source engine, or fog of war calculation in DotA 2 (which I did in fact work on, but as a sideline – that was a fun bit of optimization that I’ll write about one of these days).

What I got instead was a few suggestions about areas people thought I might find it interesting to look at, and no direct guidance at all. The closest anyone came to giving me direction was when most of the Source engine team was working on Portal 2 optimization; I’ve done a lot of optimization, so I suggested to Jay Stelly that maybe I should work on Portal 2 as well. Jay said, “Yeah, you could do that, but we’ll get it shipped anyway.” After a couple of discussions like that, I realized that he was saying was that I should think about whether that was really the most valuable thing I could be doing – there were plenty of people who were skilled at optimizing the Source engine already working on Portal 2, so it would be more useful to think about what high-impact things I could do that no one else was doing. That, and conversations with various people around the company, kicked me into a different mode of thought, which eventually led me to a surprising place: wearable computing.

By “wearable computing” I mean mobile computing where both computer-generated graphics and the real world are seamlessly overlaid in your view; there is no separate display that you hold in your hands (think Terminator vision). The underlying trend as we’ve gone from desktops through laptops and notebooks to tablets is one of having computing available in more places, more of the time. The logical endpoint is computing everywhere, all the time – that is, wearable computing – and I have no doubt that 20 years from now that will be standard, probably through glasses or contacts, but for all I know through some kind of more direct neural connection. And I’m pretty confident that platform shift will happen a lot sooner than 20 years – almost certainly within 10, but quite likely as little as 3-5, because the key areas – input, processing/power/size, and output – that need to evolve to enable wearable computing are shaping up nicely, although there’s a lot still to be figured out.

Of course, hardware is only as useful as the software running on it, and there’s a vast web of intertwined issues and questions to be resolved about how the combined hardware-software system might work. What does a wearable UI look like, and how does it interact with wearable input? How does the computer know where you are and what you’re looking at? When the human visual system sees two superimposed views, one real and one virtual, what will it accept and what will it reject? To what extent is augmented reality useful – and if it’s useful, to what extent is it affordably implementable in the near future? What hardware advances are needed to enable the software? And much, much more – there are deep, worthy challenges everywhere you look (and I hope to be posting about some of them soon); in fact, what it reminds me of, but on a larger scale, is Quake, where we had to figure out 3D graphics, client-server Internet networking, file formats, pretty much everything from scratch. Indeed, I think this has the potential to be, like Quake, a technological inflection point after which everything has changed.

In fact, this technology is potentially a big step in the direction of Snow Crash. What goes around comes around: I wouldn’t be at Valve doing this – in fact, Valve itself might not be here – if it weren’t for Snow Crash diverting my career to Id in the first place.

After I had thought all this through and done a lot of research, I came to the conclusion that it would be valuable to spend some time to see if wearable computing was an area that Valve should get into as it developed, so I ran my findings and thinking past a lot of people I respect at Valve. The consensus was that investigating wearable computing was an experiment worth running; the main concern was that the experiment needed to be structured so there were clear tests for success and failure, and so that we’d get useful information in either case. But no one told me what to do, and there were no official approvals that I had to obtain; once I had gathered feedback and thought this through to my satisfaction, I just went ahead and started the project.

Think about that for a second, and think about your own job. How cool is it that this project spun up almost overnight, just because I thought it was the most valuable thing I could do at Valve?

To be clear, this is R&D – it doesn’t in any way involve a product at this point, and won’t for a long while, if ever – so please, no rumors about Steam glasses being announced at E3. It’s an initial investigation into a very interesting and promising space, and falls more under the heading of research than development. The Valve approach is to do experiments and see what we learn – failure is fine, just so long as we can identify failure quickly, learn from it, and move on – and then apply it to the next experiment. The process is very fast-moving and iterative, and we’re just at the start. How far and where the investigation goes depends on what we learn.

It also depends on who’s doing the investigation. The team has grown, and we’re making good headway, but there’s a vast amount of stuff to investigate, and we need more smart people. Lots more smart people. Hardware people, software people, firmware people, game people, UI people, just plain great programmers and problem solvers, industrial designers, mechanical engineers, electrical engineers, systems programmers, computer vision people, optics engineers, you name it.

Maybe you

If you’re excited at the idea of diving into wearable computing, and you’re the right sort of person, then you’re why I wrote this post. We want you here – and you should want to be here; read back over this post and see if that isn’t so. Shoot me an e-mail, and we’ll go from there.

Even if my particular project doesn’t excite you, you should think hard about coming to Valve. We’re a great game company, a great digital distribution and community company, and much more as well; we have all sorts of projects going on (the fact that I’m doing wearable computing should give you a hint of the range of things we’re doing), and need all sorts of skills, including but not limited to animators, artists, level designers, sound and music people, writers, web programmers and database programmers and programmers of all sorts, research psychologists, data mining and machine learning specialists, statisticians, user experience designers, account managers and developer relations people, hardware engineers of many sorts, and more. And if you’re a first-class economist, please check us out. You’ll have a sandbox with 40 million users, and I promise you’ll never be bored.

If Valve sounds interesting to you and you think you’re a fit (a future post here will discuss in some detail what Valve looks for in people when it hires), run don’t walk to contact us at http://www.valvesoftware.com/jobs/job_postings.html.

We can’t wait to talk with you.