Gamedev

Ten rules of thumb I have honed down over many years working on indie games:

1. Start by aiming to cartoon the screen. Computers are devices known for returning wrong answers infinitely fast - they are only better than doing something by hand when automation can return a similar-or-better answer. Your job when making a game is not to return the highest quality answers for all purposes, but to return a specific quality of wrong answer for the task, because games are within the "magic circle" of social constructs and don't have to exactly match reality. That means dropping down in your initial implementation from "computing things properly" to "use a lookup table" or "use a switch statement" or "return true". There are a lot of ways to cheat, implement a feature in a way that definitely has a form of error, but it's an error you can understand how to move forward from. The classic example of this is to start not by building an actual game loop, but just to demonstrate that you can put things on the screen, then to add movement, then add input and interaction, and then collision...
2. Aim to write code that you can throw away easily. The point of the code is not to be an edifice, but to help you "arrive in the future" in some sense, by giving you useful output. If your design is changing all the time, which is often true of games, you don't want to invest a lot in the architecture right at the beginning. Instead, you want to start with primitive code with obvious redundancies, keep it simple to hack away for a little while by just copy-pasting, and then when you start feeling the pain from having those redundancies and they turn into errors, go back and harvest what you've learned about how the code should work. That lets you avoid a lot of pain from trying to implement some "design pattern" that may or may not be right for this code.
3. When you can't use a lookup table, you might be able to define a state machine. This applies to a lot of gameplay flow and simple AI problems.
4. When you can't use a state machine, you might be able to define a constraint solver. This applies to physics issues like platformer collision, or more complex AI like pathfinding. In both cases there is a need to go from "many possible solutions" to a "best candidate solution". Often you can define a really optimized form of solver for a task and there is a known algorithm that does it well, but if you're just trying to start solving the problem, brute force comparison of the entire solution set against a heuristic is a good starting point.
5. When the problem is about turning one kind of data into another, which tends to happen with loading assets and populating scenes, saving games, etc., knowledge of compilers is very helpful. The algorithmic tools used in compilers let you change the abstraction you're talking to to address the problem, which is extremely helpful for creating higher quality automation.
6. The most straightforward variable name to use throughout your code is "ans" (answer) because you're always returning an answer from a function. (Pascal used "result" but that's more characters.)
7. Sometimes you should use a spreadsheet to automate. Anything with figuring out sizes, you can use it as a calculator and keep the sheet around to recompute it when your design changes. Anything where you're defining a lookup table, you can export a .csv file and compile it down. It's a very handy tool.
8. Jackson Structured Programming is one of the best "programming methodologies" you can use, because it does not rely on being highly abstract. It simply tells you that you can go about organizing your loops differently, and doing so will make it easier to make changes, which helps with 2.
9. Likewise, coding standards used in embedded programming(e.g. MISRA-C) are very applicable to game programming because one of your most pressing goals is to figure out how to synchronize things that are supposed to be happening concurrently - collisions, entities spawning and being destroyed, etc. - and these are things that need a clear understanding of sequencing and "when" things happen, which is also true when you're working very close to hardware and there are various timers and buffers to handle.
10. Sketch ideas using a small 8x5 gridded paper notebook and a color multi-pen. The notebook acts as a second screen, but one that doesn't require any configuration or updating. The colors clarify your thinking by helping you add multiple "views" to a diagram or "comments" to a thought.