Everyone Watching This Is Fired: Tips for Game Industry Programmers

The last one is a bit suspicious. 🤔

This tal helped me become a better developer and choose better engineers to work with!

I agree with the points but I had to rewind a few times to understand what he meant to say. Maybe I'm not at that level yet, but this felt like I was constantly scraping for any possible fragment of context I could find, just to understand what he wanted to convey. Good talk though 👍

In my opinion, the biggest issue with writing software commercially is the constant pressure to deliver. This pressure is most of the time implicit. It takes a lot of time for new joiners to get to the point where all those points are common sense because as soon as they can deliver anything of value, the pressure is on them to do more and more and simply they do not have the mental capacity to also practice and develop their craft. What we need is an apprentice program where a junior is mentored by a senior and his only job is to learn the craft and help their mentor. This should take years not a few weeks/months. But considering the way business is done today, this is virtually impossible.

That's the paradox of experience, it's easy to look back and say: "yeah, I should've done this from the start". But if you had to accumulate all of your experience to actually start, one would've given up a long time ago. Most IT professionals don't even go to college anymore, you can't expect MANY concepts CS students normally learn as a foundation to be there. And a company can't be comprised entirely of seniors either...

Not sure why this talk annoyed me so much. He was stating all the obvious things, if you are having these problems follow you around, I'm not sure what to make of that? If you lay out expectations clearly to your team before a project start, then most of these issues go away. If you don't, well then you are going to face these issues and you're going to be annoyed all the time, and maybe you do need to rant about all the things lol

Also, keep in mind that I do agree with the points made, I believe you do need to ask your self these questions on the daily, but if it become problematic because other people in the company are grinding the opposite direction, then the problem is not the points that are being up held, but the culture in where the work is being carried out.

I don't think he knew all these things 10+ years ago. So what is the point of calling it "basic requirements", like if those are obvious, when those are best work practices he personally discovered?
Also, mixing those non-obvious points with obvious ones like "don't yell at coworkers" comes across as a persuasion tactic and makes this talk more of a tirade than a lecture.

I feel like this list is good for group meetings in business in general. I hate where people just bring up things that are not issues or add unneeded administrative layers and busy work. Or try to change things that are working just fine for God knows why

If plan b is good enough.. is plan b plan a or plan a is plan a?

I wonder, if it is possible to achieve score 50 while creating a software solution which runs in javascript inside a browser.
Because that can then run under an ARM cpu as well as an AMD64 cpu, and that would violate the requirement of optimizing it for a certain platform.
The same goes for other interpreted or hybrid languages like python, java, c#. And what about functional languages like haskell? One can never really be sure what haskell does under the hood with the pure functional source code. Hasekell also violates the requirement that i need to know the latency of operations, due to haskell lazy evaluation.

Old man yells at clouds... for 26 minutes.

It's funny how quickly this veers off into "senior engineer" territory. Like... Having a larger problem to solve, being able to articulate why it's important, and listing alternatives are all solidly "tech leadership" traits.

Entry level workers are mostly expected to solve targeted, narrow problems handed to them by more experienced coworkers, for exactly the reasons laid out in this talk.

The way he constantly panting, clearing his throat, the stutters, mispronouncing word while rushing them is making me so anxious. This is awfully neurotic.

Everybody has a checklist when communicating with people. Most have under 10. People usually remember around 5-7.
But requiring 50 from the person you're talking with?
1 - You're a psychopath. 2 - You're just wasting time. 3 - You're being a dick. and 4 - There are markers of autism here, you might not know it. So you might want to get it checked.
If you are this person and still expect these things as a proj mgr, I suggest you take out that checklist on your own and run it for everyones' peace of mind.

Guy comes off as project manager listing many questions that seem fairly impractical with regards to actually building the software. Some make sense in theory, but in real life building sw is more like a combination of brick laying and painting, where you need constant sustained effort and room for experimentation. Being overly engaged in abstract details just make you divorced from getting anything done, but its.something managers types with spam to people doing stuff to sound like they are knowledgeable about development

What a sad man.

this was great! good points for engineering in general really. it would be pretty awesome to work with people like this one day

Unity 3d is so dumb. They literally took this guy from insomniac games and he built them the DOTS technology.

In sort. Squeeze every single life cell out of a developer until he is burned out. Nice culture

Most of this falls under project management.

Ugh, wearing a NYPD shirt, even in 2019 is kinda icky.

This is the kind of guy that just doesn't get why six-month crunches are a big deal. "Stop being human, know everything, and be able to perfectly predict future events to so I don't have to manage humans with real flaws and shortcomings. Duh."

this guy seems awful to work for.

Common sense, the video.

LOL Mike is such a pretentious prick. He rants about people not being able to clearly and precisely articulate ideas while meta-fumbling about with his own words and ideas, holy moly.

So... I guess he actually fired the entire team of programmers working on Unity engine?!

Love your rant Mike!

Main takeaway: Be specific with your communication.
I didn't finish watching this talk because he just came across as a bitter game dev who wants to rant and yell about his negative experiences that were caused by poor communication. Hands down the worst GDC talk I've come across so far.

You know why software companies pay computer scientists that much every month? Yes, it is because they make millions with that stuff. Just be your own boss and get rid of that.

this guy? Alright, I work again as a construction worker, gaining 25€/h without nagging.

damm, i thought he would have mellowed down

Well. That's depressing.

There's no "deadline concept" in software. It's beyond human nature to estimate this correctly. Mike, you are fired!

It would have been fun if at the end of the presentation, in front of "Score 50", he had written "Fired" too,
simply because if you do all the things in this talk, you're basically never programming :D

Meanwhile Mike Acton boasts to shareholders that this was his most profitable E3 talk to date.


Oh, wait. You said Unity. I thought you said EA/Activision.

lots of programmers in these comments furious that someone went to GDC to gave them a very simple list of ways they could be better at their jobs
GDC is for telling ppl that everyone is perfect as-is, ways to improve are verboten here ):<

I feel like the people that most need to hear this are not the people that are going to take this seriously.

I wonder if he has a perfect score in his system.
Consistently.

This must be the worst GDC talk I've watched so far. The speaker is obnoxious, and clearly lacks communication skills which is ironic since most of his talk is about "communication skills". Besides, the title of the talk doesn't make any sense.

I need more like buttons for this video.
Mike Acton is my spirit animal.

Plan B is dangerous. On an algorithm I am working on, the plan B will not work with unicode. I've decided to implement plan B first, and I know myself so well I have just wasted my work kicking the ball down the lane, because I will have to restart the work on the algo. Mike is a good programmer, but a lot of these issues are more complex than being turned into a slide deck. Eg complex cross domain issues has arisen from the new unity concepts, but these were never addressed in slides.

So why did people dislike this so much? It looked like things people should know about when doing any kind of software engineering. I guess people are offended by how it presents how an ideal engineer should be.

The thing about programming is, if it was as easy to forecast, plan and budget as managers would like it to be, then it would be easy enough for managers to do it themselves.

I think this is the 1st GDC talk that i very dislike, this guy is just angry and have bad experience with dev in the past and use it to do morals to everyone...
Sometime things get complicated and you are not aware of 100% of everything...

There is an irony that a talk that is ostensibly about poor communication skills is poorly communicated.

I think the most useful thing to come from this for developers who are not there yet is that he's indicating that there are multiple ways to solve a problem that are all interesting and being able to articulate these might help deepen your own understanding and also your ability to communicate with laypeople;
On the other hand, the actual talk itself falls under the category of poor communication. People are right to switch off.

Here are the points from the talk together with some small notes:


I can articulate precisely what problem I am trying to solve. What benefit does this provide to anyone? (If you can't bring any benefit you are just wasting time)
I have articulated precisely what problem I am trying to solve (you have to be able to say it out loud)
I have confirmed that someone else can articulate what problem I am tring to solve (have you confirmed that they have the same idea of the problem as you?).
I can articulate why my problem is important to solve.
I can articulate how much my problem is worth solving (How long should I spend on this thing? Every problem needs a maximum time assigned where it is still worth 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 (but why would you do that? The essence of this point is that a lower effort solution might be good enough to fulfill all requirements, from what I think. If you discover it is good enough, maybe it should be plan a instead?)
I can articulate the steps required to solve my current problem (You need to know what you are trying to do).
I can clearly articulate unknowns and risks associated with my current problem (multiply your time estimation with a factor of tolerance to give an estimate, weight in the risks involved)
I have not thought or said "I can just make up the time" wihtout immediately talking to someone (If you suspect it takes longer, immediately tell someone about it).
I write a "framework" and have used it multiple times to actually solve a problem it was intended to solve (Have you verified that your tool works well and is tested?)

I can articulate the test for completion of my current problem. What is the "win condition"?
I can articulate the hypothesis related to my problem and how I could falsify it. How can what you try to do proven wrong?
I can articulate the various latency requirements for my current problem. Is your task blocking for others?
I can articulate the various throughput requirements for my current problem. How much do you need to push through? what are the constraints?
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. How does the data structure usually look.
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 (wrapping, overflow, exception?).
I can articulate a list of input data into my system roughly sorted by likelihood. What data will commonly arrive? Solve after the most common things first.
I know the frequency of change of actual, real-life values of the data I am transforming. (Does something change every frame, or maybe just once per second? Could we lower the frequency of certain calculations then?)
I have (at leastpartially) read the (available) documentation for the hardware, platform, and tools I use most commonly.
I have sat and watched an actual user of my system. (watching playtesters is really important, their behaviours and expressions and actions).
I know the slowest part of the users of my system's workflow with high confidence (is there any step in the usage of the app that is really slow for the user?)
I know what information users of my system will need to make efective use of the solution.
I can articulate the finite set of hardware I am designing my solution to work for.
I can articulate how that set of hardware specifically affects the design of my system (e.g. I chose a floating point type because there is a floating point unit in the hardware).
I have recently profiled the performance of my system.
I have recently profiled memory usage of my system.
I have used multiple different profiling methods to measure the performance of my system (FPS measurement is not an accurate measurement, check how many ms specific actions take).
I know how to significantly improve the performance of my system without changing the input/output interface of the system (Latency reduction for common actions is possible without changing external factors and I know how).
I know specifically how I can and will debug live release builds of my work when they fail (failure is most likely to happen).
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 (if there is information that is mostly unused, we could think about stopping to report this kind of information and save bandwidth/memory).
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 (can you reuse or modularize old code, so that you don't have to write it from scratch every time?).
I can articulate how all the data I use is laid out in memory (You are responsible for the memory you use/manage. It has to work consistently).
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 presolve problems you have no information about).
I can schedule my own time well.
I am vigilant about not wasting others' time (Can you find a solution after a few seconds of googling, do you always have to ask coworkers first when it might take them longer to explain? Find a sweetspot, if you are looking for more than 15 - 20 minutes for a solution or approach to a problem, and you can't find it, maybe it is time to ask your colleagues).
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 (if there is a miscommunication or an open issue, try to actively solve it).
I consistently interact with other professionals, professionally (no yelling, no emotional outbursts, mature conversations).
I can articulate what I believe others should expect from me.
I do not require multiple reminders to respond to a request or complete work (after you have yoru work assigned, take responsibility and take care about it and also communicate your status in time)
I pursue opportunities to return value to the commons (when appropriate) (most of us use third party libraries/code, maybe open sourced, that helps us to radically reduce the work and time required to get something to work, maybe we should think about giving something back to provide value to others too).
I actively work to bring value to the people I work with (where can you help them, where can you teach them, where can you maybe learn from them?).
I actively work to ensure underrepresented voices are heard.

this - and this man here- is why i f-kin hate this industry; constantly bashing employees and making you feel like the bug itself in the end

Everything he says is correct, but I would never work with him. There's a way to communicate how your team can improve their individual input to a project that isn't just "do everything all the time or you're fired".

It has been very useful to identify some weak spots in working on my new SaaS product. Although some of the requirements listed are difficult to interpret to a single developer "team".