When we talk about devops we often focus on tools, processes and the 'how' of engineering practice. What's missing is the 'why'. Why do we use a particular tool? Why do we share techniques across fields of specialty? Why do we do what we do as engineers? I suggest that the engine driving devops practice is human potential, and discuss 'people-first' approaches that improve the quality of our work and teams.

1. People-first Engineering

2. Who am I?

3. Blake Irvin
! 🖊 🖥

5. First, a story about making someone’s life
better through engineering…

8. Upgrades are exciting…right?

9. “F**k. I hate change.”

10. Empathy

11. “The ability to understand and share the
feelings of another”

12. Empathy is a central motivator for the best
engineers and the best engineering
practice

13. Patterns towards empathy in practice:
Give autonomy to implementers
Use the Socratic method
When there’s debate, let the passionate lead
Say “I trust you”

14. Patterns towards empathy in implementation:
Empathize with your future self
At the CLI, self-documentation
In code, ‘repo-first’ architecture
Give your system ‘tree’ a discoverable ‘trunk’
starting point

15. What did I just do there?

16. I used a metaphor

17. “A figure of speech in which a word or
phrase is applied to an object or action to
which it is not literally applicable”

19. Metaphor is our most powerful tool for
reasoning about abstractions (especially
new ones)
It's our mental map of the abstract world

20. for example…

21. an object is an object
an object is not an object
an object is an object

22. Names are perhaps the most common
metaphors we use

23. gem
github
docker

24. There’s a joke about the two hardest
problems in computer science, but I’m not
going to tell it

25. Naming is hard partly because it requires
empathy

26. Patterns for naming:
Name things what they are
Be mnemonic
AA (avoid acronyms)
Descriptive/long flags, class names, variables, etc.
(Remember, empathy!)

27. I’m talking about empathy again—why?

28. Why is empathy so important?

30. “You can always get more money, but you
can’t get more time”

31. “Do nothing because it seems good to do so;
do only that which you must do and which
you cannot do in any other way”

32. What must we do?

33. K.I.S.S.

34. Patterns towards simplicity:
Embrace simple tools
Mimic natural systems
Invest now in simplicity, get flexibility later
Watch Rich Hickey’s “Simple Made Easy” talk

35. But real projects are messy!

36. Patterns for handling complexity:
Accept the Bazaar as you learn
Iterate towards task-specific Cathedrals
Your future Bazaar project can be
populated by Cathedrals

37. One more story…

39. This CTO understood that the team’s
potential was more valuable than playing
executive

40. Humility

41. Patterns towards humility:
(Pairing is a great place to practice
humility)
Let the less experienced drive
Ready to help > knowing everything

42. Patterns towards humility:
Working-hours deployments
Self-documenting programs
Clear code comments

43. Patterns towards humility:
Make systems user-interruptible
Study how we use knobs & levers and then
automate
Let machines do repetitive tasks
Let people make choices

44. Patterns towards humble leadership:
If you’re leading, be extraordinarily humble
Embrace compromise
Embrace experimentation

45. “Let me sum up”

46. We’re here to help people
We have a multiplier effect as engineers
We’re only human, so…
…protect and maximize human potential

47. Rockstars and ninjas are not, if we are
honest, what we really need

48. We need to think more like gardeners,
painters, farmers and teachers

49. Adam
Adil
Apple
Arash
Ashley
Bonnie
Bryan
Canonical
Dan
Emily
Eric
Farshad
Geoff
Jacob
Jake
Joyent
Konstantin
Leslie
Mimmi
ModCloth
Patricia
Paul
Pivotal Labs
Rachel
Richard
Sarah
smartB
Sun Microsystems
Vivisimo
Wanelo