[Music]
now in 2005 david foster wallace
delivered this talk in kenyan community
college
and he started the talk with a parable
the parable goes like this
there are two fish swimming in the water
all right
and upon their travels they meet an
older more tired fish and the tired fish
goes up to them and says hey watch the
water out there
a moment passes
and eventually they start parting ways
and uh after
after some time the two fish go to each
other and say hey what the hell is water
welcome to this talk this talk uh was
called engineering kindness but in
hindsight i should have called it
community gardening in tech
i just forgot to change the title my
name is john conted content
i've spent 17 years in sysadmin and
devops 12 of those years contributing
directly in five years in a various mix
from platform to api to enablement teams
i'm currently in service of open
universities australia which is a
non-profit which is a job that i really
really like at the moment i've put some
markers of video games released
around this career milestones
so i started work at around the time
that name 10 dogs came out and yes zelda
was five years ago i'm really sorry if
that causes an existential angst um
yeah i promise there's gonna be only a
few more
what am i going to be talking about
today
i'm going to be talking about a couple
of things
but mainly the stack
of the issues around modern software
development life
the problems that we get with getting
alignment with other people
dealing with a lot of dependencies and
what people
sometimes mean when they talk and say
hey i left because of the politics
i'm going to be proposing a couple of
mitigations to those issues framed
around um the metaphors of gardening
right and finally if there's any part of
this talk that i hope stays with you i
think it's the last part i'm going to be
talking about why this matters
maybe to you as a person
not from productivity or better
communities perspective but just to you
but we're going to start with a little
bit of a thought experiment um so and
the talk experiment goes like this um
let's say you and a friend right in
software development
um
you have different sensibilities things
that you believe to be true
um
and we placed you in a similar team
right in the same team actually for an
arbitrary amount of time let's say three
years and in those three years
you experienced similar things
you had you came in and there was a
really slow
testing suite that took about a couple
of hours to finish you had a bug you had
an incident together
i would pause it that by the end of that
exercise
you would have similar not completely
but similar
sensibilities about
how to do certain things or what's
correct
now let's say we flip it to the opposite
there's now
instead of two different people there's
two copies of you as
derived from the snapshot of you right
now everything that you believe in
everything that you've experienced
everything that you hold to be true
and we placed those two people into
different teams
for the same three years and
those two teams had different
experiences one of you had a incredibly
slow testing suite one had a lot of time
to ship and
the other you had a delivery crash where
people were just like hey we have this
deadline and we gotta hit it and um we
gotta work at it
right
and
only one of you had information
disclosure issues i would pause it that
by the end of that exercise
would be two slightly different
developers
maybe even completely depending on which
cool of thought you follow
and what i'm trying to kind of say here
is a lot of the things that we believe
in are derived from the externalities or
the things that we kind of experience in
fact there's a thing that gets bandied
about
lindsay holmwood if you can hear this
thank you i think you delivered this
about like
uh three years ago and they still
remember it but basically what it talks
about
is
um the fact that the artifacts that an
organization creates the processes or
like the software right
are influenced by the inherent values of
the people that make them and those
values are derived from the basic
assumptions that people have
all right and vice versa
it can flow one of two ways now for
example if you have blameless post
mortems inside a company right um
people can derive the value that it
should be a learning opportunity because
blame is not really useful because the
base assumption is that all software
will go down
it flows the other way and
the artifacts can manifest themselves
differently depending on who's
interpreting that particular set of
values
for example
being safe to fail can mean
comprehensive and long test cases or
quick feedbacks
it just depends on who's parsing it
now i love this this is great um i use
it every time but there's a key
component that's kind of missing here
because it's not as if the basic
assumptions that we have are hard coded
at birth or derived from thin air or
just materialized out of nowhere they
come from experiences
things that we saw
things that have been taught to us
things that we've experienced in other
companies
and so the stack kind of like looks like
this artifacts
are derived from values or derived from
assumptions or derived from experiences
i'm going to be referring to this as the
stack for the rest of the talk just for
simplicity
now the difficulty of course is that
software is made of diverse groups of
people with different
stacks different
contents and
different things that they value and
believe in and we have
a lot of exercises
to navigate those we have a lot of ways
to do those some of them low effort and
some of them really really hard and
sometimes we just take
an intermediary step
just to say hey you know what this is
not what i 100
buy into but this is what's good for the
team
but again a lot of software development
doesn't just rely on the work of one
team in fact a lot of it relies on the
work of multiple teams as part of a
superset each of them having settled on
their own particular trade-offs and
cadences
and some a lot of the time it's actually
supersets of supersets
of which many
are actually highly interconnected and
very dependent on each other
and it really doesn't help
that
the mores that we have for interacting
or unpacking this
stacks of other people within other
teams aren't that well developed because
for all intents and purposes as a
default as a default right when we talk
about things we only uncover a part of
that stack for the other person why do
you believe in this particular thing why
do you create this particular thing what
underlying experiences have informed
that
and so often it breaks down
and sometimes expresses itself in
differences in um software patterns or
even like applications um we're
basically talking about conway's law
here um which isn't all that bad in fact
i think the move to microservice was an
attempt
to remedy some of that but where it gets
kind of dangerous and
a little bit important to watch out for
is when it results in social
bifurcations over time um
people having a default set of beliefs
about a certain group of people mainly
because of the limited amount of
interactions that you have
and this causes friction and it gets
harder and harder to talk
to people who have developed certain
assumptions about you and this is a
thing that will happen
again and again
and again
now i don't need to say that this is
incredibly exhausting
um
and i'm going to be talking about a
couple of mitigations
about
bridging the gap between groups of
people disparate groups of people that
believe in different things within the
software community and it's formed
around the
central hypothesis on and because of the
interconnectedness of the the outputs
that people have to the values and the
experiences the base assumptions that we
have it is entirely possible
to construct better culture
through better artifacts
right
cool
so i'm going to be talking about
community gardening um so what what are
the many ways that we can kind of like
tackle this issue
i'm going to be using a lot of practical
um
things a lot of things actually derived
from real life so there's going to be a
lot of screenshots and a lot of them are
going to be redacted so i i hope that's
not incredibly annoying
i'm also going to be using uh gardening
as a metaphor because like many people
in lockdown um i've over indexed on
buying a lot of plants just to see
something alive
so which is great um so what do i talk
about when i talk about seeding um
when i talk about seeding i'm talking
about positive feedback loops what are
the things that we can do to make more
things similar to that kind of like
happen
and effectively with the target state of
creating inter-team
patterns or formats for inter-team
communications within a shared space
right
um
because for all intents and purposes
slack is kind of like an artifact right
if you think about it it functions
similarly to an event stream where
there's multiple subscribers trying to
pull data
right and actioning it
within their own role or capability
and if you think about it um what a lot
of new people actually do within a
company is that they look at how people
talk to each other what's the patterns
how do i engage support how do i talk to
other people how do i ask questions for
the api team and then they copy it right
um so a lot of the patterns that we have
talking to each other kind of propagate
by itself
and we do this kind of thing
unconsciously
right
through the things that we choose to
surface
or the way we ask questions for even the
way that we respond
right this gets copied by other people
and propagated again and again and again
so here's the question what's possible
if we inspect and create these patterns
with a full awareness
that
they should have a particular intent
and i'm going to use incident reporting
because it's one of the first things
that i personally do
where do you see the stuff that's broken
how do people talk about the stuff
that's broken
nice and easy
um
the
so
here's a question right like you come
into a company you're new it's day one
and you go to the incidents channel and
it's a bunch of posts like this people
just posting screenshots without any
particular contacts and threads and just
indexing on reactions what would you
derive
about the particular values what's
important
to the people
that have created this messaging pattern
about things that are broken
right
example two
you're over the new company um and
instead of seeing that big spray of like
um messages you have this highly
structured
um kind of like format and there's
actually a forum
um on the topic and when when you click
on the topic it prompts you for like
nine different fields that you have to
fill in to be able to interact with it
i'll tell you what i kind of like derive
from it right i would my basic
assumption is that the person who made
this probably has seen their share of
incidents and probably
values a lot of the information points
that is over here
right
there's not a lot
here as an artifact in terms of like how
do you talk to other people or who do
you reach out to which means it's
probably secondary as a priority it's
more there as an announcement piece
this is what i personally kind of like
start with as an artifact
so there's a couple of things kind of
like going on here in that the incident
one the incident channel is separate
because i would like to separate
the use case of announcing and letting
people know what they need to know about
the incident versus the discussion about
remediating it
the second is that
there's um
there's a very very small
set of fields because that's what i kind
of index to do that's what i value
i value simple rules
right and those are implicit in that
artifact but sometimes implicit doesn't
quite cut it we need to be explicit
here's another artifact a postmortem
right um this is a screenshot from a
postmortem that i just did a couple of
weeks ago um and there's an explicit
call out to a set of behaviors that
everybody has to be able to do or
basic assumptions for people who haven't
done blameless postmortems before it's
basically using root cause analyses to
find out systemic
issues that might have caused an
incident
with the very express requirement that
we do not talk about human error as a
root cause
all right individual blame is not a
useful artifact and sometimes you need
to be really really explicit about it
these implications also exist just in
the way that we format um
or the commonly agreed formats by how we
talk to other people you probably have a
support team in your company that you
contact for particular needs for
infrastructure maybe you don't but maybe
you do and
for example this artifact um
this way of talking to other people has
an implication that hey i emoji this
someone owns your problem there's a
thread here which means we value
the attention economy of the other
people in the channel by making sure
they're not notified when it's not
pertinent to them
right
and and this
these small choices exist
um these heading choices access
throughout um just
even the most banal of like interactions
even and even in the most innocuous ones
that we didn't think would have an
impact it's there in the things that we
choose to celebrate it's there in the
conversations that we choose to surface
with the rest of the organization what
do we share
right
because for all intents and purposes the
way that we structure our messages is an
expression of intent it says
a lot implicitly
by
just how it's set up or how it's
structured or how how we think other
people should consume it
i'm going to be talking about um
cultivation and trellises
when i talk about cultivation and
trellises what i mean is that now that
we've set up a couple of norms about how
people should talk to each other in a
productive way how do we make it
actually kind of productive um how do we
make it have impact and the way that i'm
going to frame this is with my favorite
bug bears or least favorite bugbish
which is this communication pattern that
you see a lot in organizations
someone needs to talk to another thing
another team about a shared concern
right person one escalates their issue
to a manager manager passes it on to
another manager and then it kind of gets
passed on and
i i loathe this
um for for
various reasons but mainly the fact that
it's time consuming and it's also very
lossy
it's time consuming because you have to
wait for multiple people to pass on the
message it's lossly because the people
who are relaying
information about the context are not
the ones closest to the problem space
so i generally index a lot of like
organizational communication structures
to enable people closer to the problem
space to be able to collaborate and make
decisions
right without
anyone else being kind of like involved
for example um
in a lot of companies we frequently have
questions of hey what should be the
consistent way of like doing blah right
not the standard but sort of like what's
the default way that we do things
one of the artifacts that i like to use
is
called
sensible defaults
so this is sensible default is basically
repo
and the repo
has a couple of like folders that
pertain to particular concerns and each
of them contain an md file that says hey
this is probably how we should do things
by default in this particular area
it starts with the readme and the readme
looks like this
right always looks like this when i've
set this up across multiple companies
and it kind of starts the same
and
side note whenever you're creating
communication patterns for
disparate groups of people within an
organization it's really important that
the rules are simple
simple rules create complex intelligent
behavior
complex rules create [ __ ] so
which is optimal
um
yeah so anyway yeah so p and and the
rules here is that basically um people
who care about a certain thing make a
pull request
other people discuss it and then sort of
like if people agree they kind of merge
it it looks a little bit like this
it lets people who care about certain
things or really really care about
certain things
drive policy or actually inform people
or or
pass along knowledge right hey this is
probably the way we should consider
doing things there's people who really
care about security um last week
i had the sensible people come through
for accessibility which is awesome it's
pretty sick
it also lets people who
care about the problem space but think
differently
be able to unpack their stack right
why they believe differently and the
underlying reasons for that and to be
able to reason about it in a space
that's reasonably open
available to everybody
and it kind of just grows by itself to
be honest
it's pretty cool um
a couple of bonus points is it's uh
um this is more of a side note it's
given a lot of teams some ability to be
able to like push back on like um
things like hey we should do this as a
tactical fix because um they've been
able to rationalize that hey you know
like this
we have a set of standards pseudo
standards around what constitutes
production software so we really can't
do that as much as we'd like to
um it's also a great onboarding tool we
just hand it to hr and then they they
link it to newcomers and um who knew
like um the default way of doing things
is one of the most important
things that people probably want to know
when they join an org it's awesome
second
pattern um is um decision tech groups
um and decision tech groups are very
very similar to a guild you you
basically have a couple of people
representatives from a team it doesn't
matter how senior they are they just
have to care about it um and then we
just talk about the shared space and
you know it doesn't have to be
synchronous it could just be like a
couple of boards that happen every other
week and talking about what's most
important to everyone and their teams
right
and then we kind of like action those
things um
the
it's it's
different from a guild in that it
focuses
on making decisions about
those things enabling people basically
to make decisions
people close to the problem space to
make decisions about the thing that they
care the most about um
and when the the defaults need to change
they're the ones who discuss it and
discuss what constitutes success for
like a successful spy hey if we want to
add for example honeycomb to all of our
stacks
um this is probably what all of us would
agree on is um is a minimum that we
would like to have
when we roll it out
um it can be async and cheap it doesn't
it doesn't need meetings um i definitely
index on having less synchronous
meetings as much as possible um
it's also open to everyone regardless of
seniority and there's some optionality
and involvement not every problem needs
to have everyone only the people who
care about it
a couple of like bonuses
the fact that it's open right like
people
can attend any decision group that they
want to be in
um empowers people and gives them a
sense that hey
if i'm in this organization and i would
like something to change i have very
very clear mechanisms and groups of
people that i can consult and it's
a single hop it's not this multiple hob
nightmare where we have to like navigate
bureaucracy it's nice and
straightforward
it's empowering
it's also a great pipeline for seniors
because of what happens when people turn
senior sister suddenly allocated a big
amount of like
high level problem sets and it's hard to
navigate if like you're new to it and
what it gives on
people who are
newer to the industry is the muscle
memory to be able to unpack
smaller but wider problem sets and gain
more confidence um and and and and yeah
just just to um have the space to be
good at it
now
i'll talk about pruning um because um
regardless of everything that we do if
we have decision groups or sensible
defaults or github or good norms and
slack sometimes things go bad and
unfortunately this is the thing i have
the least amount of content on because
i'm not even sure if i'm doing it right
yet
once i do i'll be i'll talk to you about
it but
right now i don't know i don't know if
i'm doing this well i will say two
things though um
from a community gardening perspective
if you take on that responsibility
that's a very different responsibility
from participating in
what you call this in the community
and to clarify that what i mean is that
when you're participating in a
conversation your set of
responsibilities is uncovering the
layers of your stack and making other
people understand it or
um
under trying to understand other
people's stack
experiences and you know the underlying
values that they have
when you're moderating your focus is
making sure
that people have the means
to do it and that they do it well um and
asking the right questions and not
making default assumptions about people
the second is don't let things faster
it's particularly important especially
now that um
uh what they call this
um
is
that
everyone's a little bit a tiny little
bit more separated um
when when things go bad or don't go well
between like two people it's it festers
very very quickly at an alarming rate
that's honestly like a little bit
surprising so as much as possible
stamp it out before it gets bad um it
very quickly
gets to the point where it's very very
difficult to repair
now
finally i'm i'm going to talk about
why this matters to you as a person
right kind of important to you as a
person
for
all intents
and purposes
right
trying to unpack or understand um what
other people believe or sort of like why
they why they think a certain way and
trying to accommodate that is basically
for all intents and purposes empathy um
but
while it may be good
from a community gardening perspective
or even facilitating conversations
perspective the real value of it is
actually for you
um and i'm going to frame it like this
let's say you had two systems in a
company right your company had two
servers and only one of them was
publishing logs to your log indexer of
choice
splunk sumo logic what have you
it is entirely possible for someone to
come in to the company and come to the
conclusion
that
the only system that exists is the one
that's
outputting the information
right it's only that one system
now i'm gonna say something a little bit
uncomfortable um
there there's in very much the same way
there's a there's a very fundamental
self-centeredness that comes with being
alive
if you think about it just actually
think about it
this talk is happening at your ears
going through your headphones being
parts per your brain seen by your eyes
and
if we're not careful the default
assumption is that
that that we we would derive from that
is everything is all about me
which seems innocuous and not that not
that critical but let's
frame it in real practical terms
right um within the context of modern
software development life let's say
you're reasonably
successful um ops person in a company
and you know you're tired from the night
before because you were working late for
some reason that you can't even remember
so you know you wake up at a respectable
time let's say seven o'clock
your phone rings
and there's an alert on your pager duty
and it's coming from a system that you
haven't heard of before
and you come to the conclusion
immediately that it's probably a legacy
system and like all
of course like all legacy systems the
alert doesn't specify any means of
identifying where the problem is or
where the documentation is so you say
you have your coffee
you prepare and then you sit down and
you try to find the repository where it
is and of course
it's um
the last commit was three years ago
and the tests aren't there and it's
written in a language that kind of
annoys you by default so
you try and fix it anyway
nine o'clock comes in and your manager
messages you images immediately on slack
and they say hey you know i i saw that
you were working late last night i think
i'm gonna give you like a early day
today you should look after yourself and
say yeah that's cool that's cool
and then they say hey what are you doing
so you try to explain it and now you
have to take the time away from trying
to fix the problem to try to explain it
to someone who probably can't do
anything about the problem space and
it's a little bit annoying but you do it
anyway
and then your manager says oh it's
really great that you're working on this
problem but
we have a couple of cards that need to
be delivered by the end of the week
all right
so you say hey is it a deadline
and your manager says oh no um it's a
but we really need it
so now you're kind of salty that
your manager is giving you a day off but
at the same time asking for something to
be delivered that you need extra hours
to do but
you don't say that of course
and then you proceed the rest of your
day and you finally figure out the uh
the cause of the problem in its
afternoon
and um
you know the card is assigned to you and
you feel some sort of indebtedness to
your teammates so you decide to work on
it and maybe maybe just this one time
i'll do one extra hour instead of going
late
but that doesn't happen
and by the time you look at it it's
already like 9 p.m
and when you go to sleep
it's
your brain's still on so you can't sleep
which leaves you more tired the next day
and this happens again and again and
again and again and within the lengths
of self the lens of us
by default by default having all those
inputs only pertaining to us it is not
impossible in fact it is blameless to
think that hey you know about how deeply
unfair it all is and how hurtful and
tiring and how exhausting it is
the things that are happening right now
right
every single day
and i'm going to propose a different
frame on that that doesn't come with
that default the frame that comes around
interrogating other people's stacks
because it is entirely possible to think
that hey
the person who wrote those
that that that particular alert or um
the particular documentation that
existed
probably was under duress more
significantly than you are and just did
everything that they could with the
information that they had during the
time
right the technology that existed three
years ago and maybe your manager is just
kind of like
really awkward at navigating that space
of reporting to shareholders and
generating capital but at the same time
really caring about you as a person
and it's a little bit weird but you know
fundamentally they really care
or maybe it's a choice of thinking that
hey um by
by working late nights maybe i'm
presenting a standard or a baseline that
not everyone in the team is able to meet
because they have real life
obligations that they can't steer away
from and maybe i shouldn't be doing this
all right
now
none of that is maybe true it's entirely
possible that your manager is just
annoying
but
the only thing that's true is you get to
make a choice on what by default to
think about
right
and
i want to take a step back here because
i'm not moralizing and this is not i'm
not the wise old fish or anything like
that it's this is not coming from a
space where i would like you to do it
because it's good um
this is
because because a lot of times i
actually forget to do this like and some
days i actually don't want to
but maybe just by the virtue of the
awareness that there is a choice
sometimes if you have the capacity for
it the choice sometimes exists to
interrogate other people's stacks
right and to change that default frame
by which we view
um
the outputs the experiences and the
underlying values that kind of exist
out there
maybe
that's more
kind to us as human beings
and maybe it's critical not from a
software development context from a
productivity or not even
from
a
community kind of point of view but just
us
us people being to navigate the trenches
of day-to-day life
thank you so much these are the
references um i'd love
um i'm i'm yeah so that's that's all i
have i i hope
there was a set of things that i wanted
to say and i hope that got through
thank you
hey john thank you so much for your talk
there's so many amazing things in there
that i went ouch oh i'm doing that i've
stopped doing that i need to start doing
that so thank you very much
we did have a question to come through
in the chat um is there a public example
of your sensible default repo
or similar
anywhere you are aware of
um
no not quite um the um i can generate
one actually it's um
the the value of the repo isn't it's in
the contents of the wrapper itself um as
much as it's being able to relay to
people that there is a way um to surface
things that you really care about and
have them
be known across an organization and have
it have impact instead of it just living
in our own heads
so um but i will post a link so yeah
excellent thank you john one of my key
takeaways from all these talks is that
we're all still people
if ai really did exist we wouldn't need
a conference for humans we could just
put the computers together and hey isn't
that the matrix oops sorry cross
promotion there but yes we're people and
we need to remember that um everyone
around us is still people
oh we've got a question tell us about
the guitars
okay
um you know what i love talking about
this
so so this is actually my my side hustle
which is creating weird hipster you know
monstrosities from reclaimed wood um so
this is a franken caster um so yeah and
a lot of them have been modified
slightly so yeah
amazing what's the timber you've
reclaimed
um it's uh
sycamore um i believe
it's the original designation not really
the best um for um woods but it looked
awesome so aesthetics function i don't
know
excellent maybe you'll maybe it'll end
up on a movie set somewhere where it
looks really good but the actual
act is not playing it and then it's a
different uh riff behind it excellent
we've got about another five minutes if
anyone's got another question they
wanted to ask
yeah absolutely um
[Laughter]
the um
that is the gnl um guitar at the back as
well um to answer um tom eastman thank
you so much um yeah so um
plays a song
i'm so nervous right now
it's so my fingers aren't quite up to
the task but but thank you thank you
excellent
i've only just seen two acrylic guitars
on a camera bidding site that i've sent
across to a friend who plays the guitar
saying you need both of these but it
looks really weird that the clear
acrylic with just the strings in the air
yeah i know right but um yeah it doesn't
look quite right but apparently they
sound the same so it's okay
they also have the same advice i'm
holding them in my hands bad
awesome hell yeah
we don't have any more questions at this
point so i i think we should start a
poll for what do you want him to play
um
unfortunately all my guitars have uh
weird tunings um so
yeah the
so this was this was like a weird
project guitar that i i made which is a
woody guthrie um reference by the way
like this sticker um he was a folk
singer in 1945 sue sang about um uh what
he called us the the the struggles of
like people um back in the day and stuff
like i was really into folk during the
time and that's why it looks like that
and um yeah
so
yeah
but that's all i have sorry
that's all right thank you johnny would
put you on the spot there yeah don't
worry it's all good excellent thank you
for your amazing talk this afternoon
john is available too in the post
conference chat if uh john maybe you can
convince him to play over there if he's
not gonna play here maybe he'll play in
the chat
but yeah thanks john for joining thanks
everybody i will now have a room
changeover and we'll be back very
shortly
bye for now have a good one