Hacker News Reader

I think that game studios have the right model: Hire full-time tools engineers and task them with making the tool-users more effective.

Stellar games simply can't exist without stellar tools, and since every game is a little different, everyone's tooling needs are a little different. So you have no choice but to build your own tools (to some extent). Unlike armchair architects designing wheel frameworks or factory factories, the guy building the level design tool has real users (in this example: level designers) he has to build for.

This same model can be applied to web or service development. You just need to involve users from the start, especially so if your users are themselves developers who are especially demanding and critical and whose tools are especially difficult to create.

> I think that game studios have the right model: Hire full-time tools engineers and task them with making the tool-users more effective.

That's one approach, but it's not always the right one. It's only really necessary if your studio's selling point is pushing the limits, tech-wise. If your focus is the gameplay mechanics and engine and art are secondary to that, then focusing on tooling is more of a distraction than anything else. Hence why Unity and the now-quite-cheap UE are sane choices, since they let people focus on the gameplay.

General purpose software has the same pitfall that games do: people see the big studios/development companies spending a lot of time on tool-building, and they assume that's a prerequisite, which changes the mental model from "we need to start building the next cool _____" to "we need to build the tool(s) that will let us build the next cool _____". And that's a much more expensive model.

I think it's easy to get sucked into that trap for another reason too: developers know what developers want more than developers know what users want. That's why I agree with the last paragraph you wrote, that user involvement is key. I just think that companies need to be careful that they're not simply redefining users from "users of our core product" to "developers of the tools that will let us build our core product", since there's going to be some natural internal bias that way.

With Unity, that's a common misunderstanding. Unity provides nothing aside from an engine and a very open, flexible editor. The editor gives you a way to put game objects in the world and add script components to the game objects and that's pretty much it. If you don't build tools for the level designers you end up with a mess of bespoke game objects with random components. It's very easy to end up with messy Unity projects that are hard to debug and don't perform optimally (I've seen quite a few).

If you want to build something of a high quality in Unity you need structure and rigidity, and you need level designers and artists to follow guidelines and processes. So you still need tools and tools programmers. You might not have an entire team building an editor, but you need something (and it's very easy to build custom editor tools inside the Unity editor).

> So you still need tools and tools programmers. You might not have an entire team building an editor, but you need something (and it's very easy to build custom editor tools inside the Unity editor).

No disagreement there. I just meant that you don't need to start from a blank canvas and start in on engine, editor, etc. development just to get to the point where you can do good game mechanics. Obviously even if you use a canned engine you'll still need to do some work to get your asset pipeline squared away (just as how everyone needs to do a bit of scripting/config, etc. specific to their build process for example.)

I guess I didn't explain it well, but I was trying to contrast to the web world where people [seem to] very often look at places like Facebook rolling their own frameworks and saying "we need to do that to be good!" and thus literally go on to start from scratch.

React as Relay/GraphQL aren't from a blank slate either. Hell, nothing really is. How much to invest in what level of tooling is, as it should be, a function of what already exists, what you're trying to build, and what resources you have at your disposal.

The way I read it, the advice is this: Allow and encourage your people to build tools to solve their own problems and if the projects are good, teams will form around them.

This answers the question from a management perspective. Facebook has a lot to gain from a small number of huge success stories like React. This makes up for the cost of all the failed little tooling projects.

That's the way I read it, and no, it doesn't really answer the question -- it just begs the question. Most "good" projects are totally irrelevant to your business. Someone has to pick and choose, or you rapidly end up with the team situation I described: lots of people working on "their own problems", and only a few people working on the core problems of the business.

Your second paragraph is an assertion -- maybe it's true that one project like React makes up for all of the failed initiatives that the author describes (i.e. multiple person-years of effort), but that's a claim that deserves some evidence. Even if it's true, there's a level of management implied, or else everyone would spend their work hours chasing the same, captivating rabbits. My suspicion is that there's a lot more selection happening inside Facebook than the author lets on.

From experience, it's easy to get to a place where you have a lot of smart, well-intended people working on things that just don't matter. Saying "the best projects win" doesn't really solve anything, because you still have to define "best". Either that, or it's true that this is just a "champagne problem", and the Facebooks and Googles of the world can just throw dollars at anything, in the hope that something sticks.

I think your last sentence is absolutely right. The author works on a team whose responsibility is to make programming easier for everyone in the world. That's a luxury most startups don't have.

I call this the "spaghetti cannon" approach. Fire a cannon of spaghetti at a wall, see what sticks.

> Rapidly growing companies tend to over-hire, and then have bored engineers that spend lots of time creating wheel-building framework frameworks instead of working on wheels. Sometimes good stuff comes out of that, but there's a ton of waste, too -- in the worst case, you end up in a company that has hundreds or thousands of people, but only a core team of a few dozen are doing all of the actual work. So you have to ask yourself: would it just be better not to hire hundreds of engineers, and cut away the complexity and inefficiency that comes with an organization of that size?

This paragraph is just a criticism of R&D, and when read that way, I think the counterarguments become obvious. Can large and/or rapidly growing technology companies (particularly Internet companies) afford to not invest heavily in R&D?

"Sometimes good stuff comes out of that, but there's a ton of waste, too"

If you have complex machines that are critical to the business and that take 6+ months before they are running at a reasonable capacity then it often makes perfect sense to have extra "dormant" capacity.

Probably not to the point where 90% of your capacity is "dormant" but IMO that is rare. A much bigger issue is all the companies running at over-capacity who are harming their long term success.