The list of 'bot-verbs' that we give to new team members.

bot-verbs.txt

Philosophical:
* writing lines of code is one of the least valuable things I can do
* cultivate your impatience
* reject the status quo, unless we can re-derive it from first-principles 
* engineers imprint on the first languages (techniuqes, frameworks or technology) that we find success with (unconsciously seen as caregivers, which we defend w/o always knowing why)
  * we tend to overvalue the familiar/known; we tend to undervalue the unfamiliar/unknown, this interferes with our receptiveness to new ideas and personal growth
* we're 90% composed of bad habits; many of our best habits become bad as time passes; this allows us to filter for the fundamental; the great
* make doing the right thing easier than any other thing, or we will fail to achieve greatness, or break bad habits
* be conscious, be intentional 
* "is this the highest we can aim?" (I prefer this over "is this the best we can do", the former is aspirational, the latter is judgemental)
* "justice is where high standards and deep devotion meet" <- paraphrasing frances frei
* we must be able to succeed with a scarcity mindset; we fail our teams when we cannot get to an abundance mindset
  * nb: most of these proverbs will feel demanding (in a bad way) if you're in a scarcity mindset; they'll feel more inspirational and thought provoking if you're in an abundance mindset
* idempotency is one of the highest virtues
* referential transparency requires neither our trust nor faith
* build a strong model, demand strong models in yourself and those around you
* I either understand or I don't. I know which state I'm currently in.  It changes with embarrassingly high frequency.  When "I don't understand it" my primary focus is to get back to "I understand it".  
* we get good at what we practice
  * be deliberate and conscious about the things you want to practice
  * focus on re-enforcing the model, don't just re-enforce facts 
  * arrange your world (tools, processes, interactions) to create opportunities for 
    the things you want to be practicing
* small efforts, compounded over time, can have surprising results
* understand the thing for what it is and represents, not just what I happened to expeirence
* the full life cycle goes all the way to the grave (de-commissioning)
* is this bike-shedding?
* it's a sin to lose (or otherwise corrupt) our user's data
* be nice to the programmer, to the operator, to the user
* "not even wrong" - more often than I'd like
* we too often (unconsciously) choose "eternal vigilance" as a solution, it has never worked out
  * if we end up here, the implication it's intentional, a signal that we de-value our people :(
* I've almost never regretted using namespaces from the beginning; I've almost always regretted not using namespaces from the beginning
* Things that are the same should look the same; things that are different should look different - errors and mistakes occurr when these are not obvious and apparent (from Larry Wall)
* Our only hope for enduring code is immutable data types and referential transparency
* Time heals all wounds...if we allow it or help it.  Baggage is a wound time can only heal when you leave it behind.  
* If we can't form a falsifiable hypothesis we don't understand the system, find what's missing.
* Great Engineering is the opposite of / directly in conflict with the philosophy of "I'd rather be lucky than good."
* Reproduceable.  Why does this need to be said?  What else needs to be said?
* "The trick is to fix the problem you have, rather than the problem you want." - Bram Cohen (via https://twitter.com/CodeWisdom)
* "Enthusiasm is contagious, and so is boredom.", aka you are the teacher - Paul Graham (http://www.paulgraham.com/raq.html)
* all our models are incomplete, a model is valueable when it can be used to make a falsifiable prediction, when the prediction is wrong, refine your model
* If you're not actively controlling the boundary between accidental and essential complexity, it's controlling you.
* "When something hurts, do it all the time." - From Stuart Holloway (https://www.youtube.com/watch?v=Qx0-pViyIDU&feature=youtu.be&t=848)
* "Do what I can, with what I have, where I am." From the stoics (I heard this from an NPR segment).  This is how we achieve great things, though we are often mistaken about the limits of "what I can", "what I have" and "where I am" (we underestimate every one of these almost every time, retrospectives help us see how to better estimate these for greater wins in the future).
* Why again didn't I script (automate) that?  When I Fail to script, I fail to scale.
* I'm terrified that my insatiable hunger to be better will one day be satiated.
* If you fixed the issue for your dev environment, you just fucked up.
* Fighting things is a negative sum game while cultivating (or investing in) things is a positive sum game.  You may gain skill or experience, though nothing is created in fighting.
* Seek the council of those who are willing to make you see (and better, understand) uncomfortable truths.
* Courage is showing up and going all in - even when you can't control the outcome.  (paraphrasing Brene Brown about Vulnerability and Courage)
* You become a grown-up when you realize there are no grown-ups", which seems applicable here. There's always plenty to learn and you'll never truly be "ready" for increases in responsibility but being willing to accept that you'll occasionally get it wrong, being open to and solicitous of feedback, and putting in the work to make sure you're constantly learning and improving will get you there.  -- from Ryan Rapp (via his father in law) when talking me through changing my role.
* Being surprised by someone's behaviors or decisions is a gift, when your expectations feel violated, ask yourself "what was missing" (more often than not it's me rather than them)
* I am constantly tempted by the thinking that I must know the "right way" to solve a problem or that I must not begin iterating until I know what the "right way" to do something is.  This interferes with and delays my learning and understanding the problem.  
* Behaviorially, prefer learning over knowing. (from Re:Thinking with Adam Grant - "Brené Brown and Simon Sinek on the leadership skills we need to build")
* Be well-read, this is a continuous investment.  One of the things that drove my success as a software engineer was a continual investment in being well-read in the domain of software engineering, at one point I realized that I was not modeling the same behavior when I povioted my career towards leadership and management ... and it was holding me back.
* "Making a self taught transition to any field is possible. You just have to be interested enough and motivated/disciplined enough to plow through the tough parts of the learning curve." - flimsypremise / https://news.ycombinator.com/item?id=37152659

* How do I release this?
  * I must be able to perform a 'rolling' release this in a live system w/o
    causing a service interruption
  * does it break backward compatability with existing users of the api/system/etc
  * do we need to cut a new XSD?  A new version (URI prefix) of our API?
  * did we make updates to checkouts/SNAPSHOT deps? Do we need to cut new versions of project deps?
  * how do I support existing users?
  * in what order do the affected systems need to be released?
  * are there system or service configuration changes that are required?
* What are the Security implications of my change?
  * does this involve sensitive information or data?
  * does this expose information across users?
  * does this expose information outside our systems?
* What are the data-retention implications of my change (infinities suck)?
* Does this lead to a resource-exhaustion issue?  To unbounded resource allocation?
* Can this return an infinite result set?
* Should I consult with other developers / pairs on my design?
  * The anwser to this is usually yes
* Do other developers need to be made aware of my changes?
  * what are the implications they should be aware of?
* Are there potential concurrency issues when multiple threads are running this code?
* Are there potential concurrency issues when multiple app servers are running this code?
* How do I test this?
* Should I write an automated test for this?
* What are the ways in which this can fail?
* How can this gracefully degrade when it fails?
* Is this internal functionality or public?  In other words should it be protected?
* Who should be able to exercise this functionaltiy?
  * all users?
  * a specific group / role?
* Metrics: how will I know when this is or is not working?
  * how will I measure the performance of the feature?
  * performance means: are users using it as well as how long does execution take
* How will I monitor this?
* Do we bill based on this feature?
  * what do we need to track in order to bill?
* Does any of my code violate CQRS design?
* Does this require a change to our backup process?
* Does this information need to be exported to other systems?
    (Caching Layer, Metrics, Analytics, Reporting, Data Warehouse,
     Client Data Marts, etc)
  * does the data model exist in the destination system?
* Are there implications I should review with product?
* Do I have ideas about this that I should discuss with product?
* What new configuration does this imply or require?
* I understand that this is not a rote / exhaustive list - I will consider
    whatever else needs to be considered to do the right thing for the customer,
    Relay and my team.
* I'm about do embark on production work ...
  * I have a plan because I'm a good person
    * "script it even if you're only going to do it once"
    * what are my check points & recovery points?
    * how do we snap back?
    * at each step, have I recognized the risks?
      * what's the worst thing that can happen when I execute this command?
        eg: test your DELETE's by using the WHERE in a SELECT _first_
        eg: double check those rm -rf's (ask Kyle for the story of Mr Fuzzy)
  * do I have my production buddy?
    * I say what I'm going to do
    * I say what I expect to happen
    * my buddy concurs or we fix the plan
  * is one of us driving and one of us the 'recorder'?
    * the recorder keeps a journal, hopefully this is horribly booring
    * if things get exciting, then we've won b/c we have a record
      of what the plan was & where we diverged, plus once we address
      the unexpected, we can quickly get back onto plan
  * what is our communications plan?
    * who's the audience [internal, customers, public]
    * across what channels [email, slack])


More for me to think about ...
* "In a lisp, boilerplate is always your fault." - Stuart Hollway (https://twitter.com/stuarthalloway/status/1304037449644085251)
   This speaks to accidental vs essential complexity, to the divisions between the problem domain, the solution domain and the implementaiton domain.
 
Antiphorisms, the things that [rightfully] trigger us (speical thanks to Chris Hilbert for starting this section):
* CH: “All things being equal”
* KB: “Not even wrong” - proposals that are either based on faulty assumptions or are somehow simultaneously unassailably showing value yet not impactful in the current context (eg: 100% test coverage as a goal).
* KB: any time engineers get together to discuss coding standards (formatting) it triggers me.  I see this as a concrete form of ‘bike shedding’. (though that’s also one of my aphorisms)

 
 Other Great Resources
 * https://users.ece.utexas.edu/~adnan/pike.html - Rob Pike's 5 Rules of Programming
   
Special Thanks: 
* Nick Canzoneri, who looked me in the eye and asked where these were written down.  You made this list happen.
* Nick Mcavoy, for being an impactful sounding board helping me distil and refine wording and concepts.