1. 21
  1.  

  2. 21

    This seems like a good set of things that I’d like to regularly check in on. Posting it here in case anyone is of a similar mind after watching the video. (I had to scrub back through it - maybe item 0 should be: I take notes when watching presentations?)

    1. I can articulate precisely what problem I am trying to solve.
    2. I have articulated precisely what problem I am trying to solve.
    3. I have confirmed that someone else can articulate what problem I am trying to solve.
    4. I can articulate why my problem is important to solve.
    5. I can articulate how much my problem is worth solving.
    6. I have a Plan B in case my solution to my current problem doesn’t work.
    7. I have already implemented my Plan B in case my solution to my current problem doesn’t work.
    8. I can articulate the steps required to solve my current problem.
    9. I can clearly articulate unknowns and risks associated with my current problem.
    10. I have not thought or said “I can just make up the time” without immediately talking to someone.
    11. I write a “framework” and have used it multiple times to actually solve a problem it was intended to solve.
    12. I can articulate what the test for completion of my current is.
    13. I can articulate the hypothesis related to my problem and how I could falsify it.
    14. I can articulate the (various) latency requirements for my current problem.
    15. I can articulate the (various) throughput requirements for my current problem.
    16. I can articulate the most common concrete use case of the system I am developing.
    17. I know the most common actual, real-life values of the data I am transforming.
    18. I know the acceptable ranges of values of all the data I am transforming.
    19. I can articulate what will happen when (somehow) data outside that range enters the system.
    20. I can articulate a list of input data into my system roughly sorted by likelihood.
    21. I know the frequency of change of the actual, real-life values of the data I am transforming.
    22. I have (at least partially) read the (available) documentation for the hardware, platform, and tools I use most commonly.
    23. I have sat and watched an actual user of my system.
    24. I know the slowest part of the users of my system’s workflow with high confidence.
    25. I know what information users of my system will need to make effective use of the solution.
    26. I can articulate the finite set of hardware I am designing my solution to work for.
    27. I can articulate how that set of hardware specifically affects the design of my system.
    28. I have recently profiled the performance of my system.
    29. I have recently profiled the memory usage of my system.
    30. I have used multiple different profiling methods to measure the performance of my system.
    31. I know how to significantly improve the performance of my system without changing the input/output interface of the system.
    32. I know specifically how I can and will debug live release builds of my work when they fail.
    33. I know what data I am reading as part of my solution and where it comes from.
    34. I know how often I am reading data I do not need as part of my solution.
    35. I know what data I am writing as part of my solution and where it is used.
    36. I know how often I am writing data I do not need to as part of my solution.
    37. I can articulate how all the data I use is laid out in memory.
    38. I never use the phrase “platform independent” when referring to my work.
    39. I never use the phrase “future proof” when referring to my work.
    40. I can schedule my own time well.
    41. I am vigilant about not wasting others’ time.
    42. I actively seek constructive feedback and take it seriously.
    43. I am not actively avoiding any uncomfortable (professional) conversations.
    44. I am not actively avoiding any (professional) conflicts.
    45. I consistently interact with other professionals, professionally.
    46. I can articulate what I believe others should expect from me.
    47. I do not require multiple reminders to respond to a request or complete work.
    48. I pursue opportunities to return value to the commons (when appropriate.)
    49. I actively work to bring value to the people I work with.
    50. I actively work to ensure underrepresented voices are heard.
    1. 2

      Thanks for compiling the list. For checking back regularly, I’d prefer to have a copy of the list with the game development related bullets removed. I think this level of obsession with performance is relevant to only certain domains. I’m not saying it’s ever unimportant, but the focus in this list is too much.

      1. 7

        People thinking performance only matters in games is why browsers keep getting slower, why Word takes as long to start now as it does, and why having Slack desktop app open keep you from running anything else.

        We can’t ignore that and still treat ourselves as serious developers.

        1. 1

          As I’ve already indicated, I think performance is important. But as a paid engineer, your first objective is to maximize the metrics that make the business succeed. As a back-end developer I already have to juggle a lot of complexity, and I won’t let performance concerns complicate the code and make the problem exponentially worse. No more than absolutely necessary, at least.

          1. 0

            So, select star order by random limit one then since it’s easier to maintain?

        2. 2

          There’s nothing in the list that’s game development specific. On the subject of the performance related items, there’s nothing saying “I will write fast code and optimise it to within an inch of its life (or my own life).” Just “I measure it” and “I know how to make it faster if I need to.”

          That’s too much?

          1. 2

            I’ve just made peace with the fact that I have to repeat I don’t think it’s unimportant.

            I’m just saying it’s given too much focus. Look at how many of those bullet points are about performance, while there’s only one that’s partially about architecture.

            In some problem domains, your business competes on performance (among other things). In those domains (like game development) you spare a big chunk of your brain to constantly evaluate every decision you take on its performance implications.

            In some other domains (like web applications), performance affects the business only when it’s very costly on the servers or when it degrades the user experience. Businesses compete on their ability to change and adapt. In those domains, you know performance can become an issue if you screw up, but you’re not constantly thinking about it. What you’re thinking about all the time is the architecture.

            And you can turn the argument around. The architecture is important in game development as well, but less so than web, because you spend years building a game, and any change in requirements is a fault of your own. And when you release, most games don’t even try to stay compatible with the save files produced with the previous versions. And the players are OK with it.

            Please don’t turn this into a black and white thing.

      2. 15

        Summary to avoid having only the annoyingly clickbaity title:

        Mike presents some broad, sweeping, and perhaps unfair, generalizations about programmers in the industry. He then shares his expectations for what it would mean to strive to be among the very best programmers in the field. Specifically the technical, individual and team skills required for any programmer to solve the hard problems before them. For those programmers where good enough just isn’t, and that want to take control of their own learning and careers, but just need to know what their next steps should practically be to have a bigger impact.

        1. 6

          I agree with that summary and wish I hadn’t watched the video. It can be summarized as ‘list of things I think, without much justification, that people should do’. Some of those are very reasonable; others, much less so.

          1. 6

            Could you elaborate on that? By contrast, I agreed with all of the 50 or so points Acton makes in his talk, and wished that I worked regularly with engineers that showed that maturity.

            1. 5

              I can articulate precisely what problem I am trying to solve.

              I have articulated precisely what problem I am trying to solve.

              I have confirmed that someone else can articulate what problem I am trying to solve.

              I can articulate why my problem is important to solve.

              I can articulate how much my problem is worth solving.

              Great!

              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.

              Waste of energy, imo, unless you’re time-constrained (like he says, you have to ship a demo for e3/whatever). Absolutely, you should think about if your solution is the best one, but going so far as to implement another one is just a waste. Make a second one if the first one doesn’t work. Or, as joel sposky says, don’t even do that, fix the solution until it works.

              I can articulate the steps required to solve my current problem.

              I can clearly articulate unknowns and risks associated with my current problem.

              I have not thought or said “I can just make up the time” without immediately talking to someone.

              Great!

              I write a “framework” and have used it multiple times to actually solve a problem it was intended to solve.

              Disagree. If you have written a framework, great! If you have written a framework, then you should actually use it and make sure it solves a problem. But no reason to write a framework if you never have any need for one; otherwise, you’re writing a bunch of code but are unable to articulate the problem that it is trying to solve :)

              I can articulate what the test for completion of my current is.

              I can articulate the hypothesis related to my problem and how I could falsify it.

              Great!

              I can articulate the (various) latency requirements for my current problem.

              Very domain-specific, imo. Latency is not relevant to most developers, really only to gamedevs and HFT. Otherwise you’re wasting money (generally, developer-hours are cheaper than server-hours).

              I can articulate the (various) throughput requirements for my current problem.

              Ditto. Throughput is slightly more of a broad problem than latency, but not by much.

              I can articulate the most common concrete use case of the system I am developing.

              Great!

              I know the most common actual, real-life values of the data I am transforming.

              Why? This is useful if tuning for performance, but aside from that you have to correctly handle any values within the range you accept (and generate a type error if passed values outside that range), so what’s the point?

              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.

              He makes reference to filesize exceeding working memory. Honestly—yes, this is good ui, but if I’m a function opening a file then I should assume that I’m allowed to open that file and that the ui has done the job of saying ‘that file is too big’. Otherwise, code tends to get ugly and crashing is actually fine because if that’s gotten past the ui then you already have a bug.

              I can articulate a list of input data into my system roughly sorted by likelihood.

              I know the frequency of change of the actual, real-life values of the data I am transforming.

              Again, why? Aside from performance, there’s no real reason to think about this.

              I have (at least partially) read the (available) documentation for the hardware, platform, and tools I use most commonly.

              This would be great, but lacking it isn’t a deal-breaker imo.

              I have sat and watched an actual user of my system.

              I know the slowest part of the users of my system’s workflow with high confidence.

              I know what information users of my system will need to make effective use of the solution.

              Amazing!

              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.

              I have recently profiled the performance of my system.

              I have recently profiled the memory usage of my system.

              I have used multiple different profiling methods to measure the performance of my system.

              I know how to significantly improve the performance of my system without changing the input/output interface of the system.

              Again, this is very domain-specific and doesn’t make sense outside of gamedev.

              I know specifically how I can and will debug live release builds of my work when they fail.

              I know what data I am reading as part of my solution and where it comes from.

              I know how often I am reading data I do not need as part of my solution.

              I know what data I am writing as part of my solution and where it is used.

              I know how often I am writing data I do not need to as part of my solution.

              Great!

              I can articulate how all the data I use is laid out in memory.

              Domain specific…

              I never use the phrase “platform independent” when referring to my work.

              I never use the phrase “future proof” when referring to my work.

              This is a very nice theory. In practice, it’s about as useful as saying that c isn’t turing-complete—technically true, but really doesn’t tell you anything very interesting about what you can do. ‘Platform independent’ and ‘future-proof’ don’t mean ‘this will work on any platform at any time at all’. They mean ‘this is not so tied to the baggage of one platform that it would be difficult to port it to another platform similar to the ones we know about’.

              I can schedule my own time well.

              I am vigilant about not wasting others’ time.

              I actively seek constructive feedback and take it seriously.

              I am not actively avoiding any uncomfortable (professional) conversations.

              I am not actively avoiding any (professional) conflicts.

              I consistently interact with other professionals, professionally.

              I can articulate what I believe others should expect from me.

              I do not require multiple reminders to respond to a request or complete work.

              I pursue opportunities to return value to the commons (when appropriate.)

              Great!

              I actively work to bring value to the people I work with.

              I actively work to ensure underrepresented voices are heard

              Seems antithetical to a strong work-life separation.

              1. 4

                I can articulate the (various) latency requirements for my current problem.

                Very domain-specific, imo. Latency is not relevant to most developers, really only to gamedevs and HFT. Otherwise you’re wasting money (generally, developer-hours are cheaper than server-hours).

                I can articulate the (various) throughput requirements for my current problem.

                Ditto. Throughput is slightly more of a broad problem than latency, but not by much.

                This is a game-specific conference talk, but I still feel like these are applicable to most developers, even if performance isn’t important as productivity in your domain. Eventually the attitude that these are irrelevant catches up and you have work to undo problems. Latency can be a problem for the user experience with SPA web apps. Being able to explain how your work might impact the latency of the user experience can be very helpful.

                1. 1

                  In most cases, it’s a waste of time to start off by thinking about this. Sounds like premature optimization. If your SPA is slow, then you can profile it, look for problems, fix it. Don’t intentionally write your code awfully, but latency should be the last thing on your mind unless it becomes a problem.

                  1. 6

                    Well then, it seems like it should be easy to think about then. “I’m writing a non-interactive command line application, latency is irrelevant”. There, you’ve articulated the latency requirements. Knowing what the requirements are doesn’t equate to premature optimization.

                    That said, I’m never going to write ls in clojure, because it would take ten seconds to start and that’s annoying. Latency requirements tend to be hidden under assumptions.

                2. 3

                  In addition to what you wrote, I would actually quite strongly disagree with the seemingly straightforward:

                  I can articulate the steps required to solve my current problem.

                  In the particular meaning he seems to ascribe to this sentence in the video (~t=5:40), i.e. “I’m stuck”: in my understanding, that’s like one of the most important parts of the job! Not knowing how to solve my current problem, but sitting and thinking hard about it, researching stuff on the web, talking with others about it…

                  Even if I look at a broader meaning of the sentence, in many (most?) cases, I would expect to, at best, be able to articulate a list of steps that might, hopefully, take me to solving my current problem. I’ve recently come to see programming as somewhat akin to an experiment, in the nomenclature of the scientific method:

                  • “my current problem”   ~   a physical phenomenon (notably, the better I understand the problem, the more “observations”, or “characterizations” of it I have)
                  • proposed architecture of a solution   ~   the hypothesis (namely: “this solution would solve the problem”)
                  • “a list of steps that might solve it”   ~   a plan of an experiment
                  • actual implementation attempt   ~   performing an experiment.

                  In other words, I only know what steps are really the ones required to solve the problem, after I’ve eventually successfully solved it (implemented a correct solution). Before that, I can only have a plan, which may well fail, and require me to reevaluate/rethink any of my earlier phases. More than that: if I do have such a plan, it means I’ve already completed the earlier phases, so I’m quite far in the process!

                  1. 1

                    The way I read this is that you and Mike are on the same page. The steps aren’t a locked down thing, it’s just the steps of your plan. Things will absolutely change as time goes on and you execute your plan. But the point Mike is making is that too often people set off with no actual plan. They just start typing, paint themselves into a corner, and waste their most valuable resource, time.

                    “Weeks of programming can save you hours of planning”

                  2. 3

                    I actively work to bring value to the people I work with.

                    I actively work to ensure underrepresented voices are heard

                    Seems antithetical to a strong work-life separation.

                    What has work-life separation got to do with this, and how is this antithetical to being a good professional? If you have a junior dev let them be heard. If you are working with a UX consultant don’t dismiss their ideas out of hand because you think you know better. When someone has an imperfect approach, try to get them onto the right track instead of derailing them further. These are all normal elements of technical leadership whether you are a manager, tech lead, or an individual contributor.

                    1. 1

                      If you’re working with a ux consultant yes, don’t dismiss their ideas out of hand. That’s not actively working to ensure their voices are heard, that’s basic professionalism. But you shouldn’t have to be responsible to bring their ideas to someone else.

                      1. 2

                        Ensuring underrepresented voices are heard doesn’t mean that you have any responsibility to actually bring their ideas to anyone else. It can be as simple as actually listening to them, or making space for them.

                    2. 1

                      Otherwise you’re wasting money (generally, developer-hours are cheaper than server-hours).

                      Did you mean server-hours are cheaper than developer-hours here? Because from what I got from your previous statement is that you’re going to spend a lot of developer-hours into latency optimization without even actually needing it.

                      1. 2

                        Err, yeah, mistyped.

              2. 9

                The list is not wrong, but the way it’s framed and presented — showing no empathy, only anger, frustration and desire to assign blame and humiliate — is the reason to fire the manager instead (or the developers will quit themselves first).

                1. 3

                  I think the actual points themselves are good, but the whole talk takes such a self-righteous tone that this does little more than fan the flames of imposter syndrome.

                  1. 1

                    Moreover, it is presented in a tedious way that makes it more difficult to digest the information. I thought it would become a normal talk after a few “thou shalts”.

                  2. 2

                    I prefer the macro level.

                    1. I will make stuff that works.

                    Really gets to the point quickly, and allows infinite understanding of what “working” means in my context.

                    1. 1

                      Slides are available here: https://www.dropbox.com/s/doiq8ovho1k9d4b/fired.pptx?dl=0 N.B. it’s a Dropbox link, so long-term availability is uncertain