1. Roman empire military

    Image from pketh.org on 2020-09-10 at 1.26.54 PM.png

    Rome military diagram.

    Most company structures are based on the Roman empire military. CEO Caesar says he wants something, and the lieutenant managers below him on the org chart break it down into smaller tasks for the soldiers to accomplish.

    On a development team, programmers are the soldiers of these shitty new armies. They open their Jira issues and add whatever feature it says to add, or fix what it says to fix. If I can save time by adding another dependency, or skip a meeting by implementing a mockup exactly as designed, why should I care?

  2. Building is never a straight line

    Image from pketh.org on 2020-09-10 at 1.27.43 PM.png

    You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes.

    Building like this is never a straight line. Ideas and code get left on the cutting room floor because part of innovation is questioning whether what you made should exist. The process is cyclical and iterative, looking something like this.

    1. ​Follow the fun​
    2. ​Engineers who love their work​
  3. Conversations, not commandments

    Good software comes from a vision, combined with conversations not commandments. In a craft-focused environment, care for efficiency, simplicity, and details really do matter. I didn’t leave my last job just because I wanted to make something new. I left because I wanted to make it in a way I could be proud of.