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 video was a mixed bag for me. I've been programming for a long time. I'm probably around this guys age and I recognize his gripes. You get tired of the BS, I get that. With that said, in my opinion, you must understand not everyone is where you're at. As with anything scientific or artistic , it is a process. We learn from our mistakes and our successes. It's a journey. I think he missed that point. Based on his scoring system I would have been 'Fired!' and thankful for it. I think he would have asked Thomas Edison: "Can you articulate the need for LED lights?" when Edison was still inventing the first light bulb. Sometimes you're just breathing life into a system or idea. That's how innovation happens. I understand he meant well. Glad I don't have work with the guy.
"With that said, in my opinion, you must understand not everyone is where you're at." Which is precisely why he has held this GDC talk - to inform people on how they can become a better developer. Coming across a talk like this and working on your shortcomings is definitely more comfortable than finding those things out the hard way at your actual job.
Yeah, becoming a respected craftsman is a journey. Don't give up on yourself or someone else if they/you score bad on his tests. But do know your weaknesses, and be open for criticism and change. First step in growth is being able to see the issue. He is pointing out a lot of them, and will hopefully inspire for growth. (But agitate you if his way of talking is not your learning preference)
@@Xorgye Yeah, I completely agree! I hope that I didn't come across as angry or discouraged by his lecture. I was hoping to encourage others as you are to not give up but that it's a journey :) As ThePC007 mentioned (sorry, couldn't get his name to show up as a mention), it's good to find these things out now and not in an actual job where it could be devastating.
@@scottsmith1652 Yeah, I like your positive approach to this a-bit-depressing talk. I have been in this field of work for 8 years now as a backend software engineer, and made a leap the last 2 years in a lot of the things he is mentioning. I did score 100%. But not on my own, only when part of a team and when the team is mature. When I was doing this kind of work 3 years I thought I could be called senior by then. Only finding out at 5 years that I had so much to learn. And now I have stopped counting years, and are kind of doing the checkups he is doing. But then waaaaay more easy on someone if I find out there is room for improvement.
@@ThePC007 He didn't say "these are things you need to think of to become a better developer" he said they were *bare* minimums. If you have had a wide variety of jobs, (which mike *hasn't* which is painfully obvious) this is not good leadership. We can all agree that the points he brings up all have value to them, but if you actually want to reach those standards, the process has to be *entirely* different than what he proposes here (i.e. bare minimum)
As others have already pointed out, this applies to software development in general, and most of it also any kind of work done as part of a team. Some of you seem to be missing out on that bit of nerd humor when he tells you you're fired if you don't get a clean 100% score. These are really just good questions to ask yourself on a day-to-day basis to get your bearings straight.
It's not nerd humor, I am not sure you understand the sincerity of what he is saying. He repeatedly says in the end that "this is not an unreasonable bar to set, this is the bare minimum to require of someone, I am not setting the bar too high". He is literal when he says what he says here.
@@simonfarre4907 This is why we need unions. These corporate nerds hijack people's lives and they have no choice because they need their salary and are ultimately a slave to it.
I love it when someone feels the need to educate others on what they missed, when in fact they themselves missed the key point the speaker is making. Please watch from 25:42 where, without any 'nerd humor' he sums up the talk with: "I'm not trying to set the bar too high, these are basic expectations, really simple things that we should expect from everybody". Personally I think 100% for these is a goal, not a requirement and some points are more/less relevant depending on the type of dev work. But at no time during the talk does this guy say that. In my experience a dev with this blunt, black and white attitude is often very good technically at their job, but is painful to work with and overall disruptive and negative to the productivity and morale of a team.
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.
Sounds fishy to me. Mike Acton comes from a small-medium sized team that delivered AAA content on blistering time-scales (I'm talking about Insomniac). They did this while certainly training new employees at times. Unless you want to claim they did that without 'constant pressure to deliver' somehow...
All the more reason to be disciplined about how you go about doing things. As @churchianity points out, at the time when Mike was working at Insomniac they did amazing work in finite amount of time, consistently, over several years. When the stakes are high, the last thing you want to do is to freak out. “To recognize that the greatest error is not to have tried and failed, but that in trying, we did not give it our best effort” ― Gene Kranz
@@clustertheory Well, to me it sounded like a business minded person. He wants you to always think of a plan B, always think about a less-optimal solution. Because in real life, where time and money count, you can't build perfect things all the time.
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.
You think Mike Acton is a manager? You think he's not aware of how difficult it is? If you actually paid attention, he did not at any point require anyone to magically know how long something would take.
It's not poor communication, it's intentional misdirection and gaslighting. A great many people know they are in over their head, they rely on half truths and charisma. They backscratch and brown nose and they hide in the confusion created by others relying on "white lies". Not everyone knows the jargon, not everyone knows the pipelines. There are always multiple factions in a tech company, the doers, and the tribalists. The triblists will band together to create falsehoods and confusion within the ranks so they can cruise along as long as possible. And what's the harm? They're just pocketing the money of big headed nerds chasing delusions of grandeur anyhow is how they rationalize it. The cubicle farm is a nightmare of conflicting interests and politics, it's sickening the way we deceive and exploit each other from every angle.
Okay. He also lists 50 things you could do to improve on that poor communication based of 20+ years experience of doing that. That's something tangible you could act on.
Some who watch this may be put off by Mike's abrasive and brash way of speaking, but I think it's pretty clear he's not being 100% serious when he says that anyone who doesn't follow these rules exactly should be immediately fired. He worked as the engine director for Insomniac for nearly 11 years, and from what I've heard is fairly well respected in the more engineering-related circles of the game industry. And after watching this I have no issue with any of his points, especially in the context of the talk being directed to a room full of industry professionals working for AAA companies. On the multi-million dollar projects that he and many others in that room work on, many of those mistakes that he list could end up incurring major financial costs or even possibly tank the project if enough programmers habitually make them. If you're a professional in the industry then the standard of quality is (and should be) a lot higher than if you're an indie doing it solo or even a medium sized team. (Maybe he seems unhinged to even some industry folk, I don't know. But I wasn't really put off by it.) So while he could probably take a more agreeable approach to explaining his gripes and annoyances (having only 30 minutes to do it probably didn't help), I don't think how he was that unwarranted in the way he gave this talk. If you're discouraged by it, I'd instead encourage you to not take it that seriously, and simply think critically about some of the issues he raises, and see if you agree with any of them.
Part of the communication *should* be to explore these. If you know the answer to everything before approaching anyone else about a challenge, then you have probably wasted a *LOT* of time. Otherwise the talk makes good points, albeit mostly re-iterations.
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".
This is the difference between a programmer and an engineer. It's not just about communication, but thinking things through, rather than running on autopilot all the time.
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
Didn't realize I came here to listen to someone pretty much complain by reiterating the same point with slightly different context for 26 minutes (ironically an argument about communication). Yes, communication is a problem in the workplace. I've summed it up in one sentence for you.
Your take is not wrong. However, his points aren't just about communication. It's about self-reflection on what you are working on and why you are working on it. He goes through phrases with overlapping semantics, but this doesn't mean that they mean the same thing. I concur his delivery is harsh. But still, this presentation in my view is valuable for a lot of different roles by providing a reflection on how people are currently solving problems and working to actually help the team.
How is knowing the common n input for a function communication? Feels like a lot of you watched for 1 minute and left making a reply, which is ironic given some of the points.
@@ShinDMitsuki I only watched the video until 10:28, so perhaps he later expands onto more interesting topics further in the video. Feel free to think that is hypocritical. Almost every point he had made from that point had been about articulation (except that one thing about implementing your Plan B before your Plan A, which then makes turns Plan B into Plan A and absolutely accomplishes nothing???) and had just become dreadfully boring to watch, and I had assumed the entire talk would go in the same direction. I am not an employed programmer, I am just a random hobbyist, so perhaps I completely missed the point of the talk; or maybe this talk has more meaning to someone in the thick of it, as @Languor has pointed out, working a team environment.
@@NeekoMonster You have no right to comment on something when you admit you didn't even watch more than a third of it. What he said about 'plan A' vs 'plan B' made perfect sense if you made even the slightest attempt to understand it. It's very simple: you want to implement something, but it is risky. You need a backup plan: a plan B, for if your plan A fails. Rather than leaving this to the last minute, when you realise that plan A isn't going to be ready in time or isn't going to work, it's better to just implement it first. Put it behind a compilation flag or an option, and keep it around. If plan A fails then you don't need to stress and you won't fall for the sunk cost fallacy and try to justify that work by extending your time frames etc.
I feel like he has good points, but has (ironically) not figured out how to communicate it. It all seems like very common sense points: Communicate with other team members, know what the problem that needs solving and when will know it's fixed, break the problem down before solving it, know the tools available and active limitations, pay attention to what resources are using and how/why, and manage time. Telling people to "implement plan B first" was a bit of a faux pas. It does seem like it should be the ideal to strive for, and a minimal expectation for those who are in senior positions. I can definitely see where people are put off though, as he was aggressive and overly focused on specific examples, and I do not get the impression that the education system or industry really does much to foster the development of the skills he's talking about.
Right? If the thesis of your presentation boils down to "Grrrrr, why can't programmers communicate better?", then it would seem like your presentation should meet the standard it is demanding. The points he brings up are not particularly novel or controversial. In fact they're such familiar talking points that it was actually frustrating to watch him stumble through trying to explain them. This presentation gave off the energy of a passive-aggressive rant aimed at some unseen coworker rather than a senior engineer sharing his wisdom.
@@rossvolkmann1161 The catch here is that this presentation is actually his backup presentation, he implemented plan B first, then figured it was "enough" and did not bother implementing plan A, which was a well developped and thought out communication version of the talk.
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 👍
Ask me a question and I will happily fill in the blanks. I can comfortably say that I know what this is about and happy to resolve any ambiguities or misunderstandings.
I mean, Mike Acton is known for being against object-oriented programming, so that's not surprising. And even if you use OOP, you should still know about most of these things.
@@ZeroZ30o It's hard to know what your memory layout looks like and how much of your cache line is wasted, when your programming language manages that on its own behind the scenes. It is even harder to try to optimize those aspects when you have little control over what is actually happening on a lower level.
@@ZeroZ30o OOP has nothing to do with programming language runtime abstractions, e.g. if your language doesn't really _give_ you access to the heap trivially, forcing a garbage collector on you and what not, or worse, having the whole language be interpreted on-the-fly or after compilation to bytecode, then you can't do all the stuff Mike is talking about. Basically if you want to understand stuff deeply enough, you either should just understand your language's huge runtime inside and out, or just use C/C++/Rust/etc so you have a lot more insight into what's really going on without jumping through the hoops of a fat runtime/vm/interpreter/etc.
"Put your Plan B in first" wouldnt that just be Plan A then? and would plan A become plan B then and would i need to infinitely swap out the plans? am confuse
This part was reasonably clear: he's advocating for Worse Is Better, or YAGNI. The assumption is that Plan A is a more correct, clean, maintainable approach, and Plan B is the complete and utter hack that would presumably be faster to implement. Except if it turns out you really did have time to do it the Right Way, you're going to have to clean up after Plan B's technical debt. And with this guy's attitude, when will he ever budget time for paying down tech debt?
@@dvol I think it works though, IF you're doing Plan B first for small parts of a system, rather than for the whole galdang thing. Then it's more reasonable to upgrade to Plan A.
Plan A is much more ambitions and bold. It is what you'd like to see happen. Plan B is boring and straightforward. It is the minimum amount of work needed to make it work. It is not where you aim should be at but it is a safer bet.
@@dvol I imagine he is not talking about more correct, "clean", maintainable vs hacky solution but more about how complete, fancy it is. This should probably have a lot of overlap with the Game Design / Product Management side. Like the implementation for 500 NPCs in a Level takes only 10th the time as it. would for 5000 since you can just iterate over them so let's start there and see if that maybe is good enough. Numbers completely pulled out of my ass of course. Going for the simplest solution first also should create less technical dept than more
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."
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.*
Seriously, just use Trello/Jira to describe the issues, and let an experienced programmer determine how long they should take. Edit: also, don't blame everyone else for every problem. You're likely making your fair share, like failing to enable communication.
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.
Unless you can articulate exactly what problem you are trying to solve, Plan B, doesn't sound like a solution to your problem. Plan B is about being less ambitious and humbling yourself in the event that you cannot complete a more ambiguous task on time. A realistic Plan B will still solve the problem, in the most straightforward way possible. If it doesn't solve the problem then it isn't a plan at all. Plan B is about compromise, what comprise can you make to get going now. Maybe you can revisit Plan B later. In this sense, it's just about breaking up the work in incremental units. A sensible and responsible thing to do. The point is that you are doing it, fully aware that you are moving towards a complete picture. It's not random or haphazardly.
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
On the contrary, these things are all very practical. You gain 'room for experimentation' by making sure you have a backup plan, for example, which is one of the things he mentions in the talk.
This is anxiety inducing. I would never work with this person. He sounds like he loses his cool over the smallest thing. I’m all for communicating and standards, but this is insane. I literally want to stop breathing. I could never, in a million years of dedication and bootlicking, survive under this sort of animosity. If anyone wonders why I work alone, I’m going to show them this video. Now, if you’ll excuse me, I’m going to spend the rest of the morning listening to Doctor Who audio dramas while I work. GDC was always my Monday Morning Pick-Me-Up... Update: Yeah, TMI here, but I just spat up some white stomach stuff that tasted like aspirin. This video needs a trigger warning... definitely needs to be removed from the category of “Inspirational,” and put in the category of really messed up videos like bums fighting for food with toothpaste in it, or a compilation of George Costanza’s Greatest Hits. If you hate someone and want them to quit so you never have to work with them again, tell them to watch this video. If you know someone who is too happy in life. If you know an aspiring young student you’d like to crush. If you just want to do your part to spread a little more misery.
IMO you're way too serious about yourself. Distance is a healthy thing. This is a confident industry vet having a rant, perhaps in front of an audience with similar experience. You may question the quality of his sense of humor, sure, but the rest is rather uncalled for.
I'm not sure that many of these are actually small things, though. In particular, all the points on being able to articulate what your problem is, being able to articulate how you're going to solve it, and being able to articulate why the problem has to be solved in the first place are spot on. The difference between "engineering" and "tinkering" is that everything that is engineered has a purpose. A reason to exist. If you can't articulate why the code you are writing needs to exist, why are you spending time writing it? Of course, if you're a hobbyist, "I want to have fun by writing code" is a perfectly acceptable answer, but for those of us getting paid to write code to solve *other people's problems*...
He didn't lose his cool over anything. It's a polemic rant about incompetent and lazy people coasting along and not being held responsible for the way their incompetence affects others (customers AND coworkers). I have no idea how you could come out of watching this video and think that he would talk to you like this on a day to day basis. He's not talking to you, he's giving a FUNNY and EXAGGERATED talk at a conference. Your obvious lies about having a physical reaction to this talk don't paint you in a good light. They make you look like a neurotic freak that can't handle even the slightest pressure to perform and wants to laze around all day doing nothing of any value.
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...
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.
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.
If your customers absolutely *require* you to use haskell or Javascript for some reason I think the most you can be expected to do is keep up to date with the implementation details of the compiler/vm and how they relate to performance. A pet peeve of mine is when people say webassembly is fast, because Javascript is actually way faster in most cases. Developers should absolutely know this kind of stuff.
@@pokefreak2112 It really depends on the workload. In raw compute, WebAssembly can be *a lot* faster. But even in things like frontend frameworks, if you look at js-framework-benchmarks, and then select some common JS frameworks like Svelte, Vue, and React, and compare them to some Rust-based frameworks, like Dioxus, stdweb, and yew, you can actually see that most are faster in updates, some are faster in startup, and some use less memory. However, all of these have their own tradeoffs of course. It just goes to show that even at things that WebAssembly is traditionally considered to perform badly at (because of the marshaling overhead), a lot of improvements have been made over the years. Of course, there's still many things that don't have robust solutions in WebAssembly, such as code splitting, but in terms of performance, it's pretty good, and only getting better.
Sure it is, there's asm.js, wasm and a lot of nifty tricks that you can leverage to make the whole thing a lot more predictable. The real question is, what are the surrounding constraints that is causing you to have these requirements? Are they the right requirements? I understand that this is just a mental exercise but as a person who has spent a decent amount of time writing highly optimized JavaScript I can at least say with some confidence that it is possible but it is a very different game. There are walls that will just get in your way but those are important constraints to know about if you wanna know if it is feasible or not, to do a particular thing well or not.
Obtuse delivery and too-subtle humor. He is aggressive and annoying, which is essential to ranting. Not everyone finds it charming, and ranting inevitably invites irritation. Comedians keep the rants funnier, and often shorter with relief segments. Some of the points, particularly the inherent purpose, are communicated poorly. Such the Plan B point. What he literally says amounts to non-sense, but what he likely means is implement the cheaper solution sooner, or both sides of an A/B test. Many of the things he says have a good reason, but are presented in the form common to biased opinions, like the "I will not use phrase X" points. This raises red flags for most reasonable people on the quality of said opinions until they fully reason them out on their own, and he takes too long to address this apparent lack of rational foundation , or doesn't bother. The pace of the talk also doesn't allow much time for a viewer to fully get to the point before presenting another biased-seeming piece. A cocktail of mild communication flaws that collectively create distracting and useless anger/irritation, in a talk that is mostly about poor communication. TLDR: poor presentation & offbeat humor
Of course, I'm not disagreeing with you, but I would like the content to be presented better and with less distractions. Or at the least with more entertaining distraction.
@@jasoneads6825 It was well-presented. I suspect you are just not intelligent enough to understand it. What he said about plan B does not amount to nonsense. It made perfect sense: the new experimental way of doing things is risky, and you should hedge against that risk by making sure you have implemented the simple and well-understood way of doing things first. The talk was presented excellently.
Instead of 50 points, it should be less than 5. Its really hard to follow someone’s stream of thoughts without articulating why it’s important, etc. it’s like listening to a sermon with 50 points.
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.
I think it's because he didn't say "this is what an ideal engineer should be", he said that this is bare minimum. So a bad engineer must have at least these qualities to still have a job.
I disagree, creating something with software is typically considered software engineering unless you're just scraping something together for purposes other than quality and maintainable software.
@@beskamir5977 Isn't engineering just creative (or artistic) application of scientific principles? Duds, still come out of the process. And maintainability doesn't mean it's good or fitting to a purpose. There are plenty games that sold well and are still playable that were "hacked" together. Video games are interactive toys, not operating systems for jet fighters. As long as its fun its purpose is served regardless of the technical achievements or lack thereof under the hood.
@@KryptKicker5 Its science and art, you guys are just talking past each other. I will explain clearly I hope: th-cam.com/video/S530Vwa33G0/w-d-xo.html The above video is 3d fractals with some minor visual enhancements like color and ambient occlusion etc. (which is also math by the way). Fractals are pure math through and through. so is that video a math video? well, yes, but its also art. Like a poet takes words and chooses certain ones in a certain orders to make something more that just words, fractal artists take their knowledge of math and make something beyond just math. Those choices made are called art. Programming is the same. There is many ways to accomplish a single goal many times, and how a person chooses to go about solving a problem is artistic, at lest sometimes. If I give someone a simple programming problem and they solve it, I wouldnt probably call that art, just like if I gave someone a paintbrush and told them to draw a line between two points I wouldnt call it art, or if I gave someone a simple math problem. But the more possible ways of going about something, the more human creativity comes into play. Heres someone programming music: th-cam.com/video/KJPdbp1An2s/w-d-xo.html Is that art?
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.
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
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...
On the contrary, the problem with the software development industry is that developers are basically treated like in fallible gods. The idea that out of all industries software is somehow magically special, immune from any constraints that apply to EVERY other industry like deadlines, being expected to give estimates, being expected to be able to explain what you are doing and why, etc? It's bizarre.
He has a previous talk where he talks about the video game company he worked for, where they released 2 games a year, and knew the deadline down to the day the entire project, without missing it.
Man, this guy is annoying. You would waste more time coming up with an answer to every single one of his questions than you would just sitting down and writing the damn code. Everything here is either common sense communication skills or just plain pointless nitpicking. Also that NYPD shirt, ew.
Maybe you'd write the code faster, but these questions ensure that you need the code, that the code will work or have an alternative for it, and that it won't cause you problems in the future. And while it's pretty obvious that most of these are considered "common sense", if he mentions them, that's because it's not "common sense" in his experience.
Diving head first into the code without thinking about the problem at hand first is how you end up with a sloppy, unoptimized and unmaintainable mess. I've often found myself in a situation where I wished I had thought about the problem I'm trying to solve for a minute before writing myself into a corner.
@@Girugi Is he? The way I understood it is, know what your (most common) use cases are, and be mindful of them, so that you can optimize your code accordingly. Trying to fit as many use cases into a single piece of code is not what I got from his talk at all.
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.
@@milesrout Obvious statements are not worth a 30 minutes of time of any half-baked pedestrian. Here is a CTO (-like) figure of a mayor IT technology company. Sure.
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.
It's not what he said - it's how he said it. His insights are great, but they're being delivered by a smart programmer who's also an a-hole. If I had to work with him everyday - or worse, if he were my boss - I'd be updating my resume immediately. Who needs that kind of energy in their life? (I kinda figured the whole thing was a setup for some kind of joke at the end... something like _Well, okay, 49 out of 50, and maybe we'll just put you on a PIP_ ... or at least something. But no, it was straight a-hole all the way through. So he's humorless too. What a nightmare.)
@@lawthirtyfour2953 He didn't say "if you're not perfect you're fired". He said "if you don't meet this very low minimum bar you are fired". Being able to do these 50 things is NOT perfection. It is a MINIMUM standard that any competent experienced programmer should be able to meet. Of course you need to learn how to do a lot of these things, and nobody is saying that juniors should be expected to be able to do all of them.
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.
This is not a 'checklist for communicating with people'. I have never heard of such a thing. It's a list of things that everyone working in a particular job should be able to do. It's not exhaustive. It is not autistic to be able to list 50 things that everyone should be able to do to do their job.
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 ):
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.
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.
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.
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.
Thanks, you are definitely vigilant about not wasting others' time!
I feel like the people that most need to hear this are not the people that are going to take this seriously.
This video was a mixed bag for me. I've been programming for a long time. I'm probably around this guys age and I recognize his gripes. You get tired of the BS, I get that. With that said, in my opinion, you must understand not everyone is where you're at. As with anything scientific or artistic , it is a process. We learn from our mistakes and our successes. It's a journey. I think he missed that point.
Based on his scoring system I would have been 'Fired!' and thankful for it. I think he would have asked Thomas Edison: "Can you articulate the need for LED lights?" when Edison was still inventing the first light bulb. Sometimes you're just breathing life into a system or idea. That's how innovation happens.
I understand he meant well. Glad I don't have work with the guy.
"With that said, in my opinion, you must understand not everyone is where you're at."
Which is precisely why he has held this GDC talk - to inform people on how they can become a better developer.
Coming across a talk like this and working on your shortcomings is definitely more comfortable than finding those things out the hard way at your actual job.
Yeah, becoming a respected craftsman is a journey. Don't give up on yourself or someone else if they/you score bad on his tests. But do know your weaknesses, and be open for criticism and change.
First step in growth is being able to see the issue. He is pointing out a lot of them, and will hopefully inspire for growth. (But agitate you if his way of talking is not your learning preference)
@@Xorgye Yeah, I completely agree! I hope that I didn't come across as angry or discouraged by his lecture. I was hoping to encourage others as you are to not give up but that it's a journey :) As ThePC007 mentioned (sorry, couldn't get his name to show up as a mention), it's good to find these things out now and not in an actual job where it could be devastating.
@@scottsmith1652 Yeah, I like your positive approach to this a-bit-depressing talk.
I have been in this field of work for 8 years now as a backend software engineer, and made a leap the last 2 years in a lot of the things he is mentioning. I did score 100%. But not on my own, only when part of a team and when the team is mature.
When I was doing this kind of work 3 years I thought I could be called senior by then. Only finding out at 5 years that I had so much to learn. And now I have stopped counting years, and are kind of doing the checkups he is doing. But then waaaaay more easy on someone if I find out there is room for improvement.
@@ThePC007 He didn't say "these are things you need to think of to become a better developer" he said they were *bare* minimums. If you have had a wide variety of jobs, (which mike *hasn't* which is painfully obvious) this is not good leadership. We can all agree that the points he brings up all have value to them, but if you actually want to reach those standards, the process has to be *entirely* different than what he proposes here (i.e. bare minimum)
As others have already pointed out, this applies to software development in general, and most of it also any kind of work done as part of a team. Some of you seem to be missing out on that bit of nerd humor when he tells you you're fired if you don't get a clean 100% score. These are really just good questions to ask yourself on a day-to-day basis to get your bearings straight.
It's not nerd humor, I am not sure you understand the sincerity of what he is saying. He repeatedly says in the end that "this is not an unreasonable bar to set, this is the bare minimum to require of someone, I am not setting the bar too high". He is literal when he says what he says here.
@@simonfarre4907 This is why we need unions. These corporate nerds hijack people's lives and they have no choice because they need their salary and are ultimately a slave to it.
@@andrewherrera7735 Agreed.
@@andrewherrera7735 moronic take.
I love it when someone feels the need to educate others on what they missed, when in fact they themselves missed the key point the speaker is making. Please watch from 25:42 where, without any 'nerd humor' he sums up the talk with: "I'm not trying to set the bar too high, these are basic expectations, really simple things that we should expect from everybody". Personally I think 100% for these is a goal, not a requirement and some points are more/less relevant depending on the type of dev work. But at no time during the talk does this guy say that. In my experience a dev with this blunt, black and white attitude is often very good technically at their job, but is painful to work with and overall disruptive and negative to the productivity and morale of a team.
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.
Sounds fishy to me.
Mike Acton comes from a small-medium sized team that delivered AAA content on blistering time-scales (I'm talking about Insomniac). They did this while certainly training new employees at times. Unless you want to claim they did that without 'constant pressure to deliver' somehow...
All the more reason to be disciplined about how you go about doing things. As @churchianity points out, at the time when Mike was working at Insomniac they did amazing work in finite amount of time, consistently, over several years. When the stakes are high, the last thing you want to do is to freak out.
“To recognize that the greatest error is not to have tried and failed, but that in trying, we did not give it our best effort”
― Gene Kranz
There is an irony that a talk that is ostensibly about poor communication skills is poorly communicated.
Jason Storey
Ah yes, eloquently put, my fellow intellectual. How rather droll if I may say so.
Half-way through and I scrolled down to see if anyone mentioned this. Spot on!
@@colin-campbell shit sorry dude. I'll words small in next time write so not seem like try smart be
It's very well-communicated.
I would absolutely hate to work with this man.
For sure he has some points, but sometimes things are not that easy as he makes it.
Can't really say - couldn't find a reason to watch the talk till the end. Quite boring.
@@ivanatanassov6542 Not every talk can be "1500 slot machines walk into a bar" ;)
I was thinking the exact same thing. "Execute Plan B, first" sounds like such a douchebag thing to say. It's easily to criticize after the fact.
@@clustertheory Well, to me it sounded like a business minded person. He wants you to always think of a plan B, always think about a less-optimal solution. Because in real life, where time and money count, you can't build perfect things all the time.
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.
You think Mike Acton is a manager? You think he's not aware of how difficult it is?
If you actually paid attention, he did not at any point require anyone to magically know how long something would take.
It all just sounds like poor communication. You could say it about every profession in most industries.
Which doesn't mean he's wrong.
judging from the furious comments it very badly needs to be told to programmers specifically
It's not poor communication, it's intentional misdirection and gaslighting. A great many people know they are in over their head, they rely on half truths and charisma. They backscratch and brown nose and they hide in the confusion created by others relying on "white lies".
Not everyone knows the jargon, not everyone knows the pipelines. There are always multiple factions in a tech company, the doers, and the tribalists. The triblists will band together to create falsehoods and confusion within the ranks so they can cruise along as long as possible. And what's the harm? They're just pocketing the money of big headed nerds chasing delusions of grandeur anyhow is how they rationalize it.
The cubicle farm is a nightmare of conflicting interests and politics, it's sickening the way we deceive and exploit each other from every angle.
Okay.
He also lists 50 things you could do to improve on that poor communication based of 20+ years experience of doing that. That's something tangible you could act on.
This tal helped me become a better developer and choose better engineers to work with!
Some who watch this may be put off by Mike's abrasive and brash way of speaking, but I think it's pretty clear he's not being 100% serious when he says that anyone who doesn't follow these rules exactly should be immediately fired. He worked as the engine director for Insomniac for nearly 11 years, and from what I've heard is fairly well respected in the more engineering-related circles of the game industry.
And after watching this I have no issue with any of his points, especially in the context of the talk being directed to a room full of industry professionals working for AAA companies. On the multi-million dollar projects that he and many others in that room work on, many of those mistakes that he list could end up incurring major financial costs or even possibly tank the project if enough programmers habitually make them. If you're a professional in the industry then the standard of quality is (and should be) a lot higher than if you're an indie doing it solo or even a medium sized team. (Maybe he seems unhinged to even some industry folk, I don't know. But I wasn't really put off by it.)
So while he could probably take a more agreeable approach to explaining his gripes and annoyances (having only 30 minutes to do it probably didn't help), I don't think how he was that unwarranted in the way he gave this talk. If you're discouraged by it, I'd instead encourage you to not take it that seriously, and simply think critically about some of the issues he raises, and see if you agree with any of them.
this was great! good points for engineering in general really. it would be pretty awesome to work with people like this one day
Part of the communication *should* be to explore these. If you know the answer to everything before approaching anyone else about a challenge, then you have probably wasted a *LOT* of time. Otherwise the talk makes good points, albeit mostly re-iterations.
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".
I wouldn't hire or keep someone who is incompetent
i think it's reasonable to assume that he doesn't talk to teammates as if he's delivering a polemic GDC talk
He's very obviously not suggesting anyone should actually be fired.
This is the difference between a programmer and an engineer. It's not just about communication, but thinking things through, rather than running on autopilot all the time.
"Know the unknowns for your estimates"
The known unknowns, not the unknown unknowns
That means "know that there are things you don't know, and put a bound on how much that could affect your work"
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
Didn't realize I came here to listen to someone pretty much complain by reiterating the same point with slightly different context for 26 minutes (ironically an argument about communication). Yes, communication is a problem in the workplace. I've summed it up in one sentence for you.
Your take is not wrong.
However, his points aren't just about communication. It's about self-reflection on what you are working on and why you are working on it.
He goes through phrases with overlapping semantics, but this doesn't mean that they mean the same thing.
I concur his delivery is harsh. But still, this presentation in my view is valuable for a lot of different roles by providing a reflection on how people are currently solving problems and working to actually help the team.
How is knowing the common n input for a function communication? Feels like a lot of you watched for 1 minute and left making a reply, which is ironic given some of the points.
@@ShinDMitsuki I only watched the video until 10:28, so perhaps he later expands onto more interesting topics further in the video. Feel free to think that is hypocritical. Almost every point he had made from that point had been about articulation (except that one thing about implementing your Plan B before your Plan A, which then makes turns Plan B into Plan A and absolutely accomplishes nothing???) and had just become dreadfully boring to watch, and I had assumed the entire talk would go in the same direction. I am not an employed programmer, I am just a random hobbyist, so perhaps I completely missed the point of the talk; or maybe this talk has more meaning to someone in the thick of it, as @Languor has pointed out, working a team environment.
Most of what he said was not about communication at all.
@@NeekoMonster You have no right to comment on something when you admit you didn't even watch more than a third of it. What he said about 'plan A' vs 'plan B' made perfect sense if you made even the slightest attempt to understand it. It's very simple: you want to implement something, but it is risky. You need a backup plan: a plan B, for if your plan A fails. Rather than leaving this to the last minute, when you realise that plan A isn't going to be ready in time or isn't going to work, it's better to just implement it first. Put it behind a compilation flag or an option, and keep it around. If plan A fails then you don't need to stress and you won't fall for the sunk cost fallacy and try to justify that work by extending your time frames etc.
I feel like he has good points, but has (ironically) not figured out how to communicate it. It all seems like very common sense points: Communicate with other team members, know what the problem that needs solving and when will know it's fixed, break the problem down before solving it, know the tools available and active limitations, pay attention to what resources are using and how/why, and manage time. Telling people to "implement plan B first" was a bit of a faux pas.
It does seem like it should be the ideal to strive for, and a minimal expectation for those who are in senior positions. I can definitely see where people are put off though, as he was aggressive and overly focused on specific examples, and I do not get the impression that the education system or industry really does much to foster the development of the skills he's talking about.
Right? If the thesis of your presentation boils down to "Grrrrr, why can't programmers communicate better?", then it would seem like your presentation should meet the standard it is demanding. The points he brings up are not particularly novel or controversial. In fact they're such familiar talking points that it was actually frustrating to watch him stumble through trying to explain them. This presentation gave off the energy of a passive-aggressive rant aimed at some unseen coworker rather than a senior engineer sharing his wisdom.
@@rossvolkmann1161 The catch here is that this presentation is actually his backup presentation, he implemented plan B first, then figured it was "enough" and did not bother implementing plan A, which was a well developped and thought out communication version of the talk.
@@AlixRocheleau Exactly! But who are we to blame him since it’s worked… or at least it should… “arrrrghh (waving arms) f**k off” 😂
Love your rant Mike!
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 👍
Ask me a question and I will happily fill in the blanks. I can comfortably say that I know what this is about and happy to resolve any ambiguities or misunderstandings.
11:25 Object-Oriented Programming in a nutshell.
EDIT: 19:44 Yeah, and that, too!
EDIT 2: 21:06 And that one!
I mean, Mike Acton is known for being against object-oriented programming, so that's not surprising. And even if you use OOP, you should still know about most of these things.
@@ZeroZ30o OOP is going to happen somewhere, probably, but it at least helps to know why it's being used, when it is used.
@@ZeroZ30o It's hard to know what your memory layout looks like and how much of your cache line is wasted, when your programming language manages that on its own behind the scenes.
It is even harder to try to optimize those aspects when you have little control over what is actually happening on a lower level.
@@ThePC007 That's the point. That's why he hates OOP: these are things that should be easier to access and control.
@@ZeroZ30o OOP has nothing to do with programming language runtime abstractions, e.g. if your language doesn't really _give_ you access to the heap trivially, forcing a garbage collector on you and what not, or worse, having the whole language be interpreted on-the-fly or after compilation to bytecode, then you can't do all the stuff Mike is talking about.
Basically if you want to understand stuff deeply enough, you either should just understand your language's huge runtime inside and out, or just use C/C++/Rust/etc so you have a lot more insight into what's really going on without jumping through the hoops of a fat runtime/vm/interpreter/etc.
"Put your Plan B in first" wouldnt that just be Plan A then? and would plan A become plan B then and would i need to infinitely swap out the plans? am confuse
It's not confusing at all. That's exactly what would happen!
This part was reasonably clear: he's advocating for Worse Is Better, or YAGNI. The assumption is that Plan A is a more correct, clean, maintainable approach, and Plan B is the complete and utter hack that would presumably be faster to implement.
Except if it turns out you really did have time to do it the Right Way, you're going to have to clean up after Plan B's technical debt. And with this guy's attitude, when will he ever budget time for paying down tech debt?
@@dvol I think it works though, IF you're doing Plan B first for small parts of a system, rather than for the whole galdang thing. Then it's more reasonable to upgrade to Plan A.
Plan A is much more ambitions and bold. It is what you'd like to see happen. Plan B is boring and straightforward. It is the minimum amount of work needed to make it work. It is not where you aim should be at but it is a safer bet.
@@dvol I imagine he is not talking about more correct, "clean", maintainable vs hacky solution but more about how complete, fancy it is. This should probably have a lot of overlap with the Game Design / Product Management side. Like the implementation for 500 NPCs in a Level takes only 10th the time as it. would for 5000 since you can just iterate over them so let's start there and see if that maybe is good enough. Numbers completely pulled out of my ass of course.
Going for the simplest solution first also should create less technical dept than more
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."
Git gud scripter soyboy
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.*
The talk is very well-communicated.
Seriously, just use Trello/Jira to describe the issues, and let an experienced programmer determine how long they should take.
Edit: also, don't blame everyone else for every problem. You're likely making your fair share, like failing to enable communication.
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.
Unless you can articulate exactly what problem you are trying to solve, Plan B, doesn't sound like a solution to your problem. Plan B is about being less ambitious and humbling yourself in the event that you cannot complete a more ambiguous task on time. A realistic Plan B will still solve the problem, in the most straightforward way possible. If it doesn't solve the problem then it isn't a plan at all. Plan B is about compromise, what comprise can you make to get going now. Maybe you can revisit Plan B later. In this sense, it's just about breaking up the work in incremental units. A sensible and responsible thing to do. The point is that you are doing it, fully aware that you are moving towards a complete picture. It's not random or haphazardly.
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
On the contrary, these things are all very practical. You gain 'room for experimentation' by making sure you have a backup plan, for example, which is one of the things he mentions in the talk.
This poor guy must have to do a lot of cat wrangling to get useful answers from people.
This is anxiety inducing. I would never work with this person. He sounds like he loses his cool over the smallest thing. I’m all for communicating and standards, but this is insane. I literally want to stop breathing. I could never, in a million years of dedication and bootlicking, survive under this sort of animosity.
If anyone wonders why I work alone, I’m going to show them this video.
Now, if you’ll excuse me, I’m going to spend the rest of the morning listening to Doctor Who audio dramas while I work. GDC was always my Monday Morning Pick-Me-Up...
Update: Yeah, TMI here, but I just spat up some white stomach stuff that tasted like aspirin. This video needs a trigger warning... definitely needs to be removed from the category of “Inspirational,” and put in the category of really messed up videos like bums fighting for food with toothpaste in it, or a compilation of George Costanza’s Greatest Hits.
If you hate someone and want them to quit so you never have to work with them again, tell them to watch this video.
If you know someone who is too happy in life.
If you know an aspiring young student you’d like to crush.
If you just want to do your part to spread a little more misery.
I'm truly sorry about the anxiety this may have caused but the statements you made at the end were priceless.
IMO you're way too serious about yourself. Distance is a healthy thing. This is a confident industry vet having a rant, perhaps in front of an audience with similar experience. You may question the quality of his sense of humor, sure, but the rest is rather uncalled for.
I'm not sure that many of these are actually small things, though. In particular, all the points on being able to articulate what your problem is, being able to articulate how you're going to solve it, and being able to articulate why the problem has to be solved in the first place are spot on. The difference between "engineering" and "tinkering" is that everything that is engineered has a purpose. A reason to exist. If you can't articulate why the code you are writing needs to exist, why are you spending time writing it? Of course, if you're a hobbyist, "I want to have fun by writing code" is a perfectly acceptable answer, but for those of us getting paid to write code to solve *other people's problems*...
The guy's a bit brash but you are entirely too dramatic. You don't work for him, who cares?
He didn't lose his cool over anything. It's a polemic rant about incompetent and lazy people coasting along and not being held responsible for the way their incompetence affects others (customers AND coworkers). I have no idea how you could come out of watching this video and think that he would talk to you like this on a day to day basis. He's not talking to you, he's giving a FUNNY and EXAGGERATED talk at a conference. Your obvious lies about having a physical reaction to this talk don't paint you in a good light. They make you look like a neurotic freak that can't handle even the slightest pressure to perform and wants to laze around all day doing nothing of any value.
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...
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.
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.
If your customers absolutely *require* you to use haskell or Javascript for some reason I think the most you can be expected to do is keep up to date with the implementation details of the compiler/vm and how they relate to performance.
A pet peeve of mine is when people say webassembly is fast, because Javascript is actually way faster in most cases. Developers should absolutely know this kind of stuff.
@@pokefreak2112 It really depends on the workload. In raw compute, WebAssembly can be *a lot* faster.
But even in things like frontend frameworks, if you look at js-framework-benchmarks, and then select some common JS frameworks like Svelte, Vue, and React, and compare them to some Rust-based frameworks, like Dioxus, stdweb, and yew, you can actually see that most are faster in updates, some are faster in startup, and some use less memory.
However, all of these have their own tradeoffs of course.
It just goes to show that even at things that WebAssembly is traditionally considered to perform badly at (because of the marshaling overhead), a lot of improvements have been made over the years. Of course, there's still many things that don't have robust solutions in WebAssembly, such as code splitting, but in terms of performance, it's pretty good, and only getting better.
Sure it is, there's asm.js, wasm and a lot of nifty tricks that you can leverage to make the whole thing a lot more predictable. The real question is, what are the surrounding constraints that is causing you to have these requirements? Are they the right requirements? I understand that this is just a mental exercise but as a person who has spent a decent amount of time writing highly optimized JavaScript I can at least say with some confidence that it is possible but it is a very different game. There are walls that will just get in your way but those are important constraints to know about if you wanna know if it is feasible or not, to do a particular thing well or not.
I don't get it, why is this so disliked? Seems like a lotta sensible goals, even if they can be a bit stiff.
Obtuse delivery and too-subtle humor. He is aggressive and annoying, which is essential to ranting. Not everyone finds it charming, and ranting inevitably invites irritation. Comedians keep the rants funnier, and often shorter with relief segments.
Some of the points, particularly the inherent purpose, are communicated poorly. Such the Plan B point. What he literally says amounts to non-sense, but what he likely means is implement the cheaper solution sooner, or both sides of an A/B test.
Many of the things he says have a good reason, but are presented in the form common to biased opinions, like the "I will not use phrase X" points. This raises red flags for most reasonable people on the quality of said opinions until they fully reason them out on their own, and he takes too long to address this apparent lack of rational foundation , or doesn't bother. The pace of the talk also doesn't allow much time for a viewer to fully get to the point before presenting another biased-seeming piece. A cocktail of mild communication flaws that collectively create distracting and useless anger/irritation, in a talk that is mostly about poor communication.
TLDR: poor presentation & offbeat humor
Of course, I'm not disagreeing with you, but I would like the content to be presented better and with less distractions. Or at the least with more entertaining distraction.
@@jasoneads6825 Yeah, that's fair.
@@jasoneads6825 It was well-presented. I suspect you are just not intelligent enough to understand it. What he said about plan B does not amount to nonsense. It made perfect sense: the new experimental way of doing things is risky, and you should hedge against that risk by making sure you have implemented the simple and well-understood way of doing things first. The talk was presented excellently.
I want my 26 mins back
Instead of 50 points, it should be less than 5. Its really hard to follow someone’s stream of thoughts without articulating why it’s important, etc. it’s like listening to a sermon with 50 points.
I watched the video at 2x speed and I had no trouble following it.
I need more like buttons for this video.
Mike Acton is my spirit animal.
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.
zeluqa
Guess again, Freud.
It's far more efficient to make people strive to be their best without trying to make them feel like idiots for not being perfect.
They don't like it because they don't like being reminded that they're skating along with no idea what they're doing.
I think it's because he didn't say "this is what an ideal engineer should be", he said that this is bare minimum.
So a bad engineer must have at least these qualities to still have a job.
Programming itself may be "Computer Science" but actually creating something with it is still "Computer Art".
I disagree, creating something with software is typically considered software engineering unless you're just scraping something together for purposes other than quality and maintainable software.
@@beskamir5977 Isn't engineering just creative (or artistic) application of scientific principles? Duds, still come out of the process. And maintainability doesn't mean it's good or fitting to a purpose. There are plenty games that sold well and are still playable that were "hacked" together. Video games are interactive toys, not operating systems for jet fighters. As long as its fun its purpose is served regardless of the technical achievements or lack thereof under the hood.
@@KryptKicker5 Its science and art, you guys are just talking past each other. I will explain clearly I hope:
th-cam.com/video/S530Vwa33G0/w-d-xo.html
The above video is 3d fractals with some minor visual enhancements like color and ambient occlusion etc. (which is also math by the way). Fractals are pure math through and through. so is that video a math video? well, yes, but its also art. Like a poet takes words and chooses certain ones in a certain orders to make something more that just words, fractal artists take their knowledge of math and make something beyond just math.
Those choices made are called art. Programming is the same. There is many ways to accomplish a single goal many times, and how a person chooses to go about solving a problem is artistic, at lest sometimes.
If I give someone a simple programming problem and they solve it, I wouldnt probably call that art, just like if I gave someone a paintbrush and told them to draw a line between two points I wouldnt call it art, or if I gave someone a simple math problem. But the more possible ways of going about something, the more human creativity comes into play.
Heres someone programming music: th-cam.com/video/KJPdbp1An2s/w-d-xo.html
Is that art?
programming itseld has nearly nothing to do with computer science
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.
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
damm, i thought he would have mellowed down
So... I guess he actually fired the entire team of programmers working on Unity engine?!
The last one is a bit suspicious. 🤔
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...
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
On the contrary, the problem with the software development industry is that developers are basically treated like in fallible gods. The idea that out of all industries software is somehow magically special, immune from any constraints that apply to EVERY other industry like deadlines, being expected to give estimates, being expected to be able to explain what you are doing and why, etc? It's bizarre.
Most of this falls under project management.
None of it is project management at all.
@@milesrout that might be part of your problem
Common sense, the video.
This guy doesn't want programmers,he just want communications majors posing as a programmer
There's no "deadline concept" in software. It's beyond human nature to estimate this correctly. Mike, you are fired!
Only software developers are delusional enough to think that they, and they alone, are immune from the concept of a deadline.
He has a previous talk where he talks about the video game company he worked for, where they released 2 games a year, and knew the deadline down to the day the entire project, without missing it.
@@jessevos3986Without missing it? What he used to do to accomplish that?
In sort. Squeeze every single life cell out of a developer until he is burned out. Nice culture
this guy? Alright, I work again as a construction worker, gaining 25€/h without nagging.
Man, this guy is annoying. You would waste more time coming up with an answer to every single one of his questions than you would just sitting down and writing the damn code. Everything here is either common sense communication skills or just plain pointless nitpicking. Also that NYPD shirt, ew.
Maybe you'd write the code faster, but these questions ensure that you need the code, that the code will work or have an alternative for it, and that it won't cause you problems in the future. And while it's pretty obvious that most of these are considered "common sense", if he mentions them, that's because it's not "common sense" in his experience.
@@ZeroZ30o Why should I come up with two ways to solve every problem? Just takes twice as much time, and you only need 1 way.
Diving head first into the code without thinking about the problem at hand first is how you end up with a sloppy, unoptimized and unmaintainable mess.
I've often found myself in a situation where I wished I had thought about the problem I'm trying to solve for a minute before writing myself into a corner.
@@Girugi Is he? The way I understood it is, know what your (most common) use cases are, and be mindful of them, so that you can optimize your code accordingly.
Trying to fit as many use cases into a single piece of code is not what I got from his talk at all.
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.
None of them are non-obvious.
@@milesrout Obvious statements are not worth a 30 minutes of time of any half-baked pedestrian. Here is a CTO (-like) figure of a mayor IT technology company. Sure.
Old man yells at clouds... for 26 minutes.
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.
It's not what he said - it's how he said it. His insights are great, but they're being delivered by a smart programmer who's also an a-hole. If I had to work with him everyday - or worse, if he were my boss - I'd be updating my resume immediately. Who needs that kind of energy in their life?
(I kinda figured the whole thing was a setup for some kind of joke at the end... something like _Well, okay, 49 out of 50, and maybe we'll just put you on a PIP_ ... or at least something. But no, it was straight a-hole all the way through. So he's humorless too. What a nightmare.)
What a sad man.
I wonder if he has a perfect score in his system.
Consistently.
this just in only perfect people allowed to give advice
moron.
@@tabula_rosa Well "if you're not perfect you're fired is more moronic"
@@lawthirtyfour2953 He didn't say "if you're not perfect you're fired". He said "if you don't meet this very low minimum bar you are fired". Being able to do these 50 things is NOT perfection. It is a MINIMUM standard that any competent experienced programmer should be able to meet. Of course you need to learn how to do a lot of these things, and nobody is saying that juniors should be expected to be able to do all of them.
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.
This is not a 'checklist for communicating with people'. I have never heard of such a thing. It's a list of things that everyone working in a particular job should be able to do. It's not exhaustive. It is not autistic to be able to list 50 things that everyone should be able to do to do their job.
If plan b is good enough.. is plan b plan a or plan a is plan a?
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 ):
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.
"my lack of basic reading comprehension says things about someone else and not myself"
His communication skills are absolutely fine. The title makes perfect sense. Did you watch the video all the way through?
He's right, this should be the minimum bar - it isn't though, which is why not all software developers are paid equally
Wtf this video contain a lot of fluff
Well. That's depressing.
A good developer follows these rules. A great developer knows why he shouldn't follow these rules.
i am indian sir please help me sir
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.
Unity 3d is so dumb. They literally took this guy from insomniac games and he built them the DOTS technology.
I jumped to a section of the video and it sounds like he's having a panic attack.
Ugh, wearing a NYPD shirt, even in 2019 is kinda icky.
It's admirable.
this guy seems awful to work for.
On the contrary, I would love to work with someone who knows what he wants and how to get there.Too many project managers are clueless bafoons
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.