Mike Acton 50 rules. -- 05/06/2025

(NON-EXHAUSTIVE) List of 50 things Mike Acton expects from professionals. Sourced from his 2019 GDC talk "Everyone Watching This Is Fired: Tips for Game Industry Programmers" [1]

• I can articulate precisely what problem I am trying to solve.
• I have articulated precisely what problem I am trying to solve.
• I have confirmed that someone else can articulate what problem I am trying to solve.
• I can articulate why my problem is important to solve.
• I can articulate how much my problem is worht solving.
• I have a Plan B in case my solution to my current problem doesn't work.
• I have already implemented my Plan B in case my solution to my current problem doesn't work.
• I can articulate the steps required to solve my current problem.
• I can clearly articulate unknowns and risks associated with my current problem.
• I have not thought or said "I can just make up the time" without immediately talking to someone.
• I write a "framework" and have used it multiple times to actually solve a problem it was intended to solve.
• I can articulate the test for completion of my current problem is.
• I can articulate the hypothesis related to my problem and how I could falsify it.
• I can articulate the (various) latency requirements for my current problem.
• I can articulate the (various) throughput requirements for my current problem.
• I can articulate the most common concrete use case of the system I am developing.
• I know the most common actual, real-life values of the data I am transforming.
• I know the acceptable ranges of values of all the data I am transforming.
• I can articulate what will happen when (somehow) data outside that range enters the system.
• I can articulate a list of input data into my system roughly sorted by likelihood.
• I know the frequency of change of the acutal, real-life values of the data I am transforming.
• I have (at least partially) read the (available) doumentation for the hardware, platform, and tools I use most commonly.
• I have sat and watched an actual user of my system.
• I know the slowest part of the users of my system's workflow with high confidence.
• I know what information users of my system will need to make effective use of the solution.
• I can articulate how that set of hardware specifically affects the design of my system.
• I have recently profiled the performance of my system.
• I have recently profiled memory usage of my system.
• I have used multiple different profling methods to measure the performance of my system.
• I know how to significantly improve the performance of my system without changing the input/output interface of the system.
• I know specifically how I can and will debug live release builds of my work when they fail.
• I know what data I am reading as part of my solution and where it comes from.
• I know how often I am reading data I do not need as part of my solution.
• I know what data I am writing as part of my solution and where it is used.
• I know how often I am writing data I do not need to as part of my solution.
• I can articulate how all the data I use is laid out in memory.
• I never use the phrase "platform independent" when referring to my work.
• I never use the phrase "future proof" when referring to my work.
• I can schedule my own time well.
• I am vigilant about not wasting others' time.
• I actively seek constructive feedback and take it seriously.
• I am not actively avoiding any uncomfortable (professional) conversations.
• I am not actively avoiding any uncomfortable (professional) conflicts.
• I consistently interact with other professionals, professionally.
• I can articulate what I believe others should expect from me.
• I do not require multiple reminders to respond to a request to complete work.
• I pursue opportunities to return value to the commons (when appropriate.)
• I actively work to bring value to the people I work with.
• I actively work to ensure underrepresented voices are heard.

[1] GDC talk on youtube - https://www.youtube.com/watch?v=cV5HArLYajE