[austin-cheney]

So, this begs a rather obvious question. What makes that team different? Is it the talent, the leadership, the focus on product?

As a long time JavaScript developer I honestly believe, and I really mean this, that maybe 4% of the people employed primarily doing JavaScript work actually know what they are doing. Just 4%.

It seems at the beginning many of the early Valve team had a lot of passion but almost no real experience in that kind of code or product. They got a massive springboard with the Quake code and then figured out the rest. They didn't stagnate on the Quake code, but wildly modified it to fit their needs. Most JavaScript people are not capable of this. They just stagnate at their favorite framework and then just spin around code style and process.

What differentiates that early Valve team from all these various JavaScript teams? It clearly isn't education or professional maturity.

[TheAceOfHearts]

Most developers probably don't care and just want to get paid. Beyond that, I imagine you're not usually empowered to make big changes unless you're relatively senior, and even if you decide to be the kind of developer that's always striving towards self improvement your job is unlikely to reward you for your skill development. I think there's just a lot of diminishing returns.

Have you ever tried playing a competitive multiplayer game? There's people that will play games for thousands of hours without ever improving.

Sometimes I think people encounter bottlenecks and they're not sure how to overcome them.

[red-iron-pine]

> Most developers probably don't care and just want to get paid. Beyond that, I imagine you're not usually empowered to make big changes unless you're relatively senior, and even if you decide to be the kind of developer that's always striving towards self improvement your job is unlikely to reward you for your skill development.

Bingo. I got a release coming up, I just need to ship this -- ain't got no time for fancy stuff, and higher-ups don't want fancy or flourish, just make it work. And even if there is room for trying something new, it probably doesn't matter if the users DGAF about the new feature.

[sbarre]

Valve did have a few key people (not to mention complete access to the best 3D engine source code at the time) who really did know what they were doing.

Keep in mind that building video game levels, models, animations and such back then was dramatically simpler than it is now.

One person did all the texture work for the whole game. One person did all the sound effects and music, and also coded the DSP engine to add real-time sound manipulation based on the environment.

You can do a lot with a few very talented people who are willing to guide a whole bunch of smart, eager and motivated folks.. which I think is what happened at Valve.

[scriptkiddy]

To me it seems like their passion drove them to learn as much as they could. They knew enough to get the job done, but not enough to know that they "couldn't do" the things they wanted to do.

More experienced devs may have thrown out a lot of the ideas the Half Life team ended up implementing as "too time consuming" or "practically impossible". Valve's devs at the time weren't experienced enough to make those assumptions, so they just worked their asses off to figure out how to do it.

[deckard1]

There are lots of reasons why Half-life was a success. You shouldn't discount stupid luck, as well. Their first iteration was awful, as mentioned in the YouTube video. They essentially had to start over with a "cabal" and pull the game together with the good scraps of work they had already done.

Here's a more detailed article on the cabal process (starting on page 2):

https://web.archive.org/web/20210823181232/https://www.gamas...

From 1999 and much more detailed than the video.

Now, game development is inherently waterfall. You work for years and built up to this huge release. Nowadays you might have some agile processes embedded into milestones, etc. But fundamentally it's all leading to a huge waterfall.

That's important. Because what agile does, today, is that it turns autonomous developers into cogs of a large machine. But Valve's "cabal" was entirely free to do whatever they felt best. Gabe Newell probably had final say and input, but ultimately the group had flexibility. The developers had full system awareness. They weren't pulling Jira tickets off a board like a blind man in the elephant parable[1]. They knew how the pieces fit because they put them there. And if the pieces weren't fitting, they had the authority to make them fit.

Perhaps more interesting is how the story of Half-life can be viewed through The Mythical Man-Month[2]

> When designing a new kind of system, a team will design a throw-away system (whether it intends to or not). This system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system.

Their cabal has a bit of overlap with the "surgical team" concept and usage of formal documents. The rest of the employees did nothing while this group operated. Thus, they reduced manpower that actually allowed them to move forward. Slow is Smooth, Smooth is Fast (from the US Navy Seals). Most companies do the opposite. They crank up the number of employees to hit deadlines, which creates more bugs and more work.

[1] https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

[2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[droptablemain]

You really can't compare game dev with web dev. These are truly distinct tech cultures that share surprisingly little.

[snickerbockers]

>maybe 4% of the people employed primarily doing JavaScript work actually know what they are doing. Just 4%.

Because it's JavaScript. It's a language specifically designed for people who don't care about how anything actually works.

[clnq]

I think it's at least five elements:

1. Hacker-tinkerer culture, where you want to build new things that haven't been built on new hardware for fundamentally non-commercial reasons. This could be called Carmack-style hacker culture in my mind, which produced Quake.

2. Genuinely extensive programming expertise.

3. Not partaking in the current and quite toxic VC-funded game development culture, where funding dictates rushed deliverables (through schedules, and the constant race to attract funding with demos). It's feature factory or die in a lot of VC-funded scale-ups.

4. Lucky circumstances - knowing someone who could get you Quake source on "just have it, we'll work something out eventually" terms back then was exceptionally lucky. Quake was very far ahead of it's time. Most companies that produce such work now would work very hard to make sure no one else gets it. And that goes back to the hacker culture of just building cool things to share with people that was more common in games then.

5. Time - the games industry was young, before Quake there were no proper 6 DoF generalist 3D game engines, so it was an auspicious time for game development.

I'm a game developer and I am a bit old school, so I'm not the best person to speculate on why JavaScript programmers seem less able to build cool tech. But I have seen many young people approach programming differently now, probably because it has become a lot more commodified. The mindset of a "clock-in clock-out" programmer wasn't common in game circles in the 90s and 00s. Also, there was much less focus on using "correct" idioms and beautiful code as the end goal in hacker circles, and a lot more focus on building something that others haven't built before and working out the details later. Moreover, business viability was rarely the first thing you would think about and work backwards from when you worked on a game project. Business success was a byproduct of building cool games.

If you would remember game trailers from early 00s, like Half-Life 2 (since we are talking about Valve), you would pick up that they show off cool tech like physics simulation, which is quite janky and imperfect. Carmack also has spoken many times about how in his early games (pre-Quake) the graphics would initially be quite bad and he would be worried about getting everything fixed in time. Cool over safe, cool over perfect, and showing off cool things that were not polished was normal.

Nowadays, things are different in some ways. The game development has become methodical and focused on the exploitation of passion for money in a repeatable way. You get as many features as you can for marketing (you only need to have them, they can be whatever quality, it's only for the Steam page and trailer). You cut all the awesome new things as they are a risky waste of money, you instead funnel all the passion into velocity for delivering that bundle of features as quickly as possible for as cheap as possible, and that's it. If you can strike a deal with a nice IP, that will make the game sell a lot more. So will striking a deal with a publisher with deep pockets for marketing. But the "do cool things" hacker culture is gone in AAA and blockbuster games. It's now relegated to indies where quite a lot of janky but incredibly cool games are made. But they have a funding access problem as their business is too risky for most publishers and VCs. And that's probably why we don't see many new and big id and Valve-type companies anymore.

Although with VR, there are some companies that I believe could be like that. And they attract senior talent quite well. With the right management and timing, I think we could see another Valve in VR. Even Carmack played a big role in VR until recently, before he moved on to the next new thing in tech. Being on the precipice of new tech is important for people of that culture.