Everyone Watching This is Fired

Notes on a talk by Mike Acton of Unity at GDC 2019

  • Met a lot of programmers, ostensibly professionals, didn’t meet the minimum bar for their job
  • Dev skills—”50 things that annoy me”—How many of these do you do? (Score yourself)
    • I can articulate precisely what problem I am trying to solve
      • Easy to get off in the weeds, moving shit around, can’t answer exactly what they’re trying to do
      • Just creating noise
    • I have actually articulated precisely what problem I am trying to solve
    • I have confirmed someone else can articulate what problem I am trying to solve
      • Often you think you have a good idea of what you’re doing, but the person you’re doing it for disagrees
    • I can articulate why my problem is important to solve
      • Who does this benefit?
    • I can articulate how much my problem is worth solving
      • How long should I spend on it? “As long as it takes” is bullshit
      • A day? A month? A year?
    • I have a Plan B in case my solution to the current problem doesn’t work
      • 2 days before it’s due and everything is broken, can you give up and do your backup?
      • You know the deadline is coming, you should be prepared for it
    • I have already implemented my Plan B in case my solution to my current problem doesn’t work
      • Having a safety net is a load off everyone else’s mind
      • Half the time this winds up being good enough, or you learn a reason that Plan A wouldn’t work at all
    • I can articulate the steps required to solve my current problem
      • If you don’t know why you’re stuck, this is probably the issue
      • Figure out the individual steps you need to take
    • I can articulate unknowns & risks associated with my current problem
      • This is why people throw up their hands in trying to estimate, or multiply their estimates
      • What do you need to study ahead to time to give a reasonable estimate?
    • I have not thought or said “I can just make up the time” without immediately talking to someone
      • Something comes up during the week and you push back your important project
      • When it happens, you need to communicate that you’re going to be late—realize you won’t make up the time
    • I write a “framework” and have used it multiple times to actually solve a problem it was intended to solve
      • Suppose you’re building a utility—have you actually verified that it does the intended job?
    • I can articulate the test of completion for my current problem (I know when it’s done)
      • How much faster does it need to be? How much smaller? How much better?
      • How do you know when enough is enough?
    • I can articulate the hypothesis related to my problem and how I could falsify it
      • What are you trying to prove?
      • Is there a shortcut you can take to short-circuit time you’re spending here
    • I can articulate the various latency requirements for my current problem
      • How long until someone else needs this data? “Right now” is not an answer
      • Immediate latency is not needed for everything
      • When do you *actually* need it
    • I can articulate the various throughput requirements for my current problem
      • Do you need 1 thing or 10,000?
    • I can articulate the most common concrete use case of the system I am developing
      • Are you going to be processing 1 or 10 or 1000 things at a time?
    • I know the most common actual, real-life values of the data I am transforming
      • Know what the data looks like in the most common case
    • I know the acceptable ranges of values of all the data I am transforming
      • “It can do anything” is a lie
      • 32-bit int?
      • What are the built-in limitations of the system
    • I can articulate what will happen when (somehow) data outside that range enters the system
      • E.g., a file bigger than 32-bit int file size
      • Does the machine crash? Do you get a nice error message?
      • Don’t just hope it never happens
    • I cna articulate a list of input data into my system roughly sorted by likelihood
      • E.g., a set of static things in the world is most likely; second most likely is a bunch of moving characters
      • Solve for the most common thing first
    • I know the frequency of change of the actual, real-life values of the data I am transforming
      • If it only changes once a second, don’t do work once a frame
    • I have (at least partially) read the (available) documentaiton for the hardware, platform, and tools I most commonly use
      • E.g., x64 hasn’t really changed in a decade, but you’ve never cracked the manual for the assembly
    • I have sat and watched an actual user of my system
      • You can guess, read forums, but until you watch a real user, you don’t know what’s actually happening
    • I know the slowest part of my user’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 the finite set of hardware I am designing my solution to work for
      • Probably won’t work on a 6502
      • What’s it supposed to work on? Desktops within such-and-such range
    • I can articulate how that set of hardware specifically affects the design of my system
      • Has an FPU, has SIMD, etc.—what have you done because of that?
    • I have recently profiled the performance of my system
    • I have recently profiled the memory use of my system
    • I have used multiple different profiling methods to measure the performance of my system
      • FPS is not valid; use milliseconds that stuff takes!
    • I know how to significantly improve the performance of my system without changin the input/output interface of the system
      • Have you painted yourself into a corner?
      • If you immediately return a value, you’ve built in a zero-latency requirement
    • I know specifically how I can and will debug live release builds of my work when they fail
      • If you need to be in a debugger with source code, you’re screwed
    • I know what data I’m reading as part of my solution and where it comes from
      • Are you stuck on the main thread forever?
    • I know how often I’m reading data that I don’t need as part of my solution
      • Is 90% of your cache read wasted because you don’t need that data?
      • Unless you can quanitfy this, you can’t reason about how okay that is
    • I know what data I’m writing and where it’s being used
      • Are you just writing anywhere with no organization?
    • I know how often I’m writing data that I don’t need as part of my solution
      • Does a value never change?
      • Cut away the data you don’t need to write
    • I can articulate how all the data I use is laid out in memory
      • You’re responsible for this; memory manager is not magic
    • I never use the phrase “platform independent” when referring to my work
    • I never use the phrase “future proof” when referring to my work
      • You can’t pre-solve problems you have no information about
    • I can schedule my own time well
      • Don’t know what you’re doing, when you’re doing it
    • I am vigilant about not wasting other people’s time
      • Google it
      • If you spent two weeks futzing with it when someone else could have solved it in 5, you should have asked
    • I actively seek constructive feedback and take it seriously
    • I am not actively avoiding any uncomfortable (professional) conversations
    • I am not actively avoiding any (professional) conflicts
    • I consistently interact with other professionals professionally
      • Low bar: no yelling, no hitting
    • I can articulate what I believe others should expect for me
      • Don’t wait for others to tell you what this is
    • I don’t require multiple reminders to respond to a request or 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
      • How can you teach your team, learn from them
    • I actively work to ensure underrepresented voices are heard
      • “It’s a pipeline problem” is bullshit; do something, anything
      • Make sure other people are heard
  • Evaluation
    • If you do 0-20 of those things, you’re fired
    • 21-40: Fired
    • 41-49: Fired
    • 50: You’re okay; you’ve met the minimum bar
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s