Published: Fri 30 August 2024
In Tech .
tags: events ireland
To avoid taking a year again to (fail to) put my notes together, I decide to do
it quickly and stick to a few thoughts and highlights. The 2024 edition of
ShipItCon happened today. This year's theme was "Flow." Many speakers
mentioned ownership when talking about ways to reach flow.
I haven't attended many conferences in the last couple of years, but maybe 90%
of the people I talked to were also meeting their co-workers face-to-face for
the first time at this event, despite working together for years. At least
three different companies. I found it interesting. It doesn't look like there
are many opportunities for teams to meet outside of conferences at the moment.
DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? (Matthew Skelton)
The speaker kindly summarised his findings both at the start and the end of the
talk: decouple teams and tech (not just defining an org structure, something
more dynamic), but diffuse learning across the company (that can take the form
of Lunch and Learns, blogs, Communities of Practice, guides, etc...)
Reading recs:
Gene Kim's books (the Phoenix Project, Accelerate, ...)
SODOR, the State Of DevOps Reports
Organisation, Flow, and Architecture (Sam Newman)
What an incredibly dynamic and engaging speaker! The theme was generally how to
reduce handoffs, which happens particularly when organisation are siloed.
Conway's law: An organisation design systems that replicate the communication
structure of that organisation.
So if you have Taylorism-inspired silos with e.g. separate
front-end/back-end/DB teams, the system will reproduce that.
The solution is feature-based teams (micro-services are good to enable full
ownership). Durable as opposed to initiative-based teams are also better as
long-lived teams make better decisions about trade-offs (e.g. incurred tech
debt, etc).
Data Driven Decisions to Improve Testing Flows (Heather Reid)
Using data to take risks. Differentiating between reversible and not reversible
risks. The speaker used various examples based on her own experiences to
illustrate the principle.
For example: closing an old bug to remove noise is easily reversible if it
turns out it shouldn't have been closed.
If 1000s of users report a problem, it can feel like millions/all of your users
are hitting the problem. But maybe when you look at the data it's 0.6% of the
userbase, which is still bad but not world-ending.
Or a really bad bug affecting 6 users using that phone model (out of millions)
can probably be closed.
Prioritise accordingly.
Observability 2.0 and other things (Charity Majors)
(The title isn't on the agenda and I forgot to write it down!)
Tip for how to supercharge your career: join a high-performing team.
Engineering should own the code in production.
Observability is a property of complex systems.
Observability-driven development means looking at your dashboards (as opposed
to waiting for alerts/paging to bring them up). It's a constant conversation
with code (including unstructured logs, not just metrics, because they provide
CONTEXT). (Higher level: structured logs with trace ids you can follow end to
end.)
Establishing a culture of ownership and observability at Phorest (Paweł Malon and Paul Dailly)
Interestingly, the speakers use Honeycomb which is the observability platform
of the previous speaker. It was like seeing practical examples of the concepts
detailed in the previous talk.
The theme of engineering owning the code all the way to production came up
again.
And also, of linking engineering workflows to observability: deploying a change
and seeing what difference it makes, and conversely using the insights gained
from observing software behaviour on prod to find new bugs/improvements.
Having a lot of metrics does create issues with the cost of storing all of that
data, which is where sampling helps, although the speakers talked about the
other problems you then have to deal with when sampling and how to manage them.
Go With The Flow? (Vessy Tasheva)
Play is a component of flow. Venn diagram of Play and Environment with Flow
where the circles meet.
Environment: must be safe even if there are constraints/discomfort. E.g. a
leader having your back when working on a challenging project.
Play is a way to be more authentic and creative. "Being" (which respects focus
time) vs "Reacting" (which breaks flows and creates defensiveness).
Flow-etry in Motion: Navigating Cascades of Threat Data (Claire Burn)
Interesting twist to the talk! When the speaker submitted it, it was supposed
to be about how their pivot to using Kubernetes and Google Cloud Platform
enabled better flow in the team. But by the time the conference happened, they
had reverted back to AWS and EC2!
There was no "peak flow" to be found because Kubernetes wasn't the right tool
to solve their problems (they needed finer grained OS control).
Considerations around Learning Curve vs Velocity, especially when working as a
smaller team (4 people). The management debt became too much.
They did end up keeping Kotlin from this experiment, good for integration with
other Java projects in the company.
The impact of Flow on various aspects of work (Panel discussion)
Beat Saber as a way to get into flow 😂
Distributed teams are good for making the implicit explicit. Managing based on
outcomes. The additional flexibility is good for everyone.
Honeycomb has a quarterly "everyone works from home" week, up to the CEO. It's
good to get distance from processes, etc. (I thought that was a refreshing
contrast to all the Return To Office talk from the last couple of years.)
Many problems are socio-technical: need a combination of tech and people
solutions, not just one or the other.
Harnessing Developer Insights to maximise flow (Mihai Paun and Alma Tarfa)
Learned helplessness in companies: "we've always done it this way" "that's
never going to work here."
I really liked the picture of the Iceberg of Ignorance, from Corporate
Rebels :
Papercuts affecting flow tend not to surface in retrospectives.
Solution: Plan - Do (gather data) - Check (target condition) - Act
For example, they found their dev team struggled to reach flow state because of
the number of meetings, so they decided to try setting up two no-meetings day
(Monday, Wednesday) then gather data to see if that helped. Everyone involved
in the four steps.
Small changes toward reaching the bigger goal.
Leaders: be gardeners, not mechanics.
From MLOps to AI Systems (Jim Dowling)
Most AI systems don't ship. This hasn't changed in the last few years.
MLOps, LLMOps. He explained when he teaches a ML course, his students complete
an AI project from scratch in 2 weeks. It doesn't need to be as complicated as
30+ steps diagrams/consultants make it out to be.
While looking for a link to the course, I came across this detailed
article that goes into the details of the talk if that is of interest. And
includes a link to the students' projects.
Finding personal flow (Patrick Kua)
Personal flow usually comes from:
adding value
learning
having a lot of ownership (with support)
a sense of progress
applying the team's strengths
The speaker used past experiences to illustrate various kind of very different
environments that can lead to good flow. This actually linked back nicely to
Vessy's earlier talk as well: challenging projects but in a safe
environment/with support.
One of the anecdotes I liked was when he was trying to remove himself as a
bottleneck in a large project, he broke down the features, and asked if anyone
would step up as feature leads for each of those. People had no problem
volunteering and that also links back to ownership again. And feature-based
teams.
The disadvantage of putting up notes early is that the recordings are not yet
available!