Matthew "Queso" Niederberger

I see programmers of all levels fall into the trap of solving problems they don't have. This tends to make more problems, instead of less. This is usually well meaning. Most commonly, it's trying to solve problems that might happen in the future. Anyone that has ever been taught or studied programming has done this. It's so ingrained that abstraction is good programming, that good programmers make robust code. You end up writing a system that works perfectly in theory, and then the actual need cannot be forced into all that theoretically ideal structure. And we see companies write business to business software, for use cases they can only predict, that end up failing to be usable in reality. And it makes sense, because almost all programming is already an abstraction. We write in languages that are abstracted away from the machine code. Machine code is an abstraction from the pulses of electricity that runs through a processor. Processors are abstractions that mean we no longer have to manually rewire a circuit.

Say you need a circular dowel rod that is 5 feet long. So you make a 5 foot long circular dowel rod. Why on earth would you make an entire production line capable of producing variable length circular dowel rods? Because you suspect in the future you might need a 10 foot long circular dowel rod? Well here's the thing about the future. Turns out you need a 5 foot long square dowel rod. You're replacing all 2 of your dowel rods with square ones actually. Your factory can't make those.

Programmers are constantly building fantastical solutions to simple problems and feeling they've done something right. And sometimes they are! Sometimes you really did need that adjustable dowel rod factory. But so much more often I see people justify massive structure and complexity because they think that's what it means to build something well. And all that investment becomes self sustaining. You can't cut thousands of hours of work out of the system! Think of all the waste!

But the point of building yourself better tools is to have better solutions to your problems.

And sometimes... you can just solve the problem.

normal person:
this product needs a better interface

engineers, for some fucking reason:
this product needs a better interface story

idk man maybe stop being so scrumbrained and jirapilled

Agile Manifesto: The most important things are individuals, interactions, working software, collaboration, and responding to change. All process, tooling, documentation, and planning is entirely subservient to those ideals.

People that have learned "agile": Agile is when you use a very rigid process using extremely specific tools to compress all problems, interactions, and planning into a single abstracted workflow that we apply without thought to all problem sets.

you should not be a 10x engineer or whatever, you should be focusing on the vision and ideas and emotions that make your project interesting and beautiful and touching. some of the greatest indie games of all time have absolutely nightmarish codebases because the creator was rightly focused on the player experience

Code that is beautiful, code that is elegant, code that is efficient, code that follows standards, code that is well commented, code that is well organized, is all meaningless if it does not deliver the intended experience.

There's an incredibly fascinating disconnect in the software world between game programmers and most other software disciplines. Game development is super weird, because we tend to be writing open ended stuff, developer hours seem much more valued because of scope and timelines, strict behavioral requirements are almost nonexistent, performance is always a massive pressure, we're highly suspicious of external code and code reuse, and we literally can't unit test anything because intended behavior is usually changing daily.

I can't imagine working in a world where multiple people are programming against a single spec from multiple directions and be expected to converge in the middle in any sort of usable or timely fashion. I barely know what the skill set of "frontend" and "backend" developers are supposed to be. I don't know how to unit test. Every time we try and use some external library or plugin it usually costs us more time than it would have saved. I can't imagine a world where we have external software dependencies. (We look at the left-pad incident as a scathing indictment of how software is done at all on the web.) Most "software patterns" are usually a mistake to try and use in games because they tend to restrict possibility rather than create it. Almost everything is global state. Multithreading is frequently impossible because all operations happen in real time and are deeply interconnected.

So little software advice actually makes sense to apply to games and would result in unusable codebases and leave you in dev hell for decades, and all the things we do in games sound insane and like things that would get you fired in the rest of software.