The document discusses tools used at Etsy to simplify, empower, and automate processes. It describes several homegrown tools like Virtual Madness, Deployinator, and Supergrep. It highlights that tools are a product of company culture and reflect underlying beliefs and values. At Etsy, tools manifest beliefs like "just ship", "if it moves, graph it", and optimizing for developer happiness. The talk argues that culture and tools inherently influence each other over time through implicit assumptions.
31. nishan@etsy.co
m
Beliefs & Values @ Etsy
• Just ship.
• If it moves, graph it.
• Optimize for developer happiness.
• Don’t be an a**hole.
• Engineering with a captial E.
43. nishan@etsy.co
m
References
• Notes on the Synthesis of Form by Christopher Alexander
• Cognition in the Wild by Edwin Hutchins
• Organizational Culture and Leadership by Edgar Schein
• https://www.thekua.com/atwork/2016/04/12-years-12-lessons-working-at-thoughtworks/
• https://learn.chef.io/skills/tools-for-devops/
• http://thehypertextual.com/2013/01/29/21st-century-management-and-the-virtues-of-operational-subculture/
• http://thehypertextual.com/2013/01/17/edgar-schein-organizational-culture-and-leadership/
• https://developer.ibm.com/urbancode/2014/09/22/curious-relationship-culture-tools/
• http://mathplugged.blogspot.com/2012/03/first-we-build-tools-then-they-build-us.html
• http://oncommit.tumblr.com/post/46298334333/no-bull-chaos-monkeys-cap-triangles-and-conwa
• http://laughingmeme.org/2015/08/31/five-years-building-a-culture-and-handing-it-off/
• http://sciencepolicy.colorado.edu/students/envs_5110/tecnics_and_civilization.pdf
• http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/
• https://saltworks.stanford.edu/assets/zv585py2131.pdf
• https://codeascraft.com/2012/05/22/blameless-postmortems/
Hinweis der Redaktion
Blameless postmortem
- situational aspects that lead to failure
- engineers that were involved
accounts of:
- what actions they took at what time,
- what effects they observed,
- expectations they had,
- assumptions they had made,
and their understanding of timeline of events as they occurred
without fear of punishment or retribution coz this disincentives them
we’re seeing a lot of newer usages of the tool
how do you know what the parts the abstraction matter?
which is why just implementing solutions that have worked elsewhere may not work in your case.
you find that some of the assumptions you made during development don’t hold in the production context
anyone in the room that has written code that has always worked in production on the first try?
technical decisions you make influenced by
- tools available to you
- solutions that have worked in the past
- commonly held beliefs
for example,
might want to use redis datatypes
- but memcache in production
- handle complexity elsewhere
- past decisions will affect ones you make in the future
famous german physicist Heisenberg
a lot of the decisions and thought processes of the developer are captured in the tools
so, in addition to all the utilities we’ve seen earlier, tools are a window into the culture
Schein, former professor at the MIT Sloan School identifies 3 levels of culture : artifacts (visible, might be difficult to decipher), beliefs and values (ideas, goals, values, aspirations, rationalizations) that are taken up and basic underlying assumptions (unconscious, beliefs that are taken for granted, so basic that people would not even question these).
want to highlight that it might be hard for newer employees to map out implicit assumptions
wanting to enable engineers to get code out:
- get to see the finished product - see what they were building - get feedback
ended up with continuous deployment - deploy small changesets
graph of deploys per day
used when you’re deploying
see if your changes affected the site
make sure your feature works the way you expect it to
Solutions that worked in the past that have been transformed into shared beliefs.
E for empathy - we try to be empathetic to other people, teams, functions & our users
deployinator - helps us get stuff out there,
statsd - made it easy for us to graph
we see how beliefs and values affect the tools you invest in
example - assumptions can be different for the same thing
The part we haven’t talked much about is the implicit assumptions.
New hires kind of go through this exercise:
They’re trying to understand the culture
- How does a particular tool work
- Why things are done a particular way
To help people develop these assumptions
They go to the channel for deploying
See how others are deploying, how the instructions map with what they’re seeing
we have bots that manage batches of deploys
Ask questions if things don’t make sense
Conversations at the watercooler can become great areas to learn and develop our implicit assumptions since we have shared context
The deploy today was kinda scary, I wasn’t sure what graphs to look at…
One of the basic assumptions that is shared across Engineering
But ultimately, we learn what we see
Unless you have a culture that makes learning a collaborative effort, people spending a large amount of time covering up their mistakes instead of learning from them
so if there are things you value in your organization, make them explicit
this can help build shared and more correct mental models instead of having people operating in silos
Want to emphasize here the tooling and culture are really two sides of the same coin