This year was my first year attending ChefConf.
For episode 19 of The Ship Show, we did a joint podcast with the Food Fight Show Crew, and had a ton of fun; if you’re looking for a high level review of the conference, that’s a good place to get a high level overview1.
Even though it wound down over a week ago, it cracked open a world view that I’ve not had a lot of experience with to date, and that experience was pretty impactful, so I wanted to discuss it a bit more after having digested things.
It’s interesting to me that most of the people attending ChefConf are approaching many of the same topics we do in traditional “release engineering” for “native”/”boxed” software, but it’s similarly patently obvious that the dynamics and interactions2 can be pretty different too.
To whit: I found it very interesting that among a sea of developers in talks and in the hallways, I could pick out common themes that wouldn’t surprise any practitioner: version control, deployment, scaling, configuration management… but one phrase I did not hear uttered once by a single person was “release engineering.”
What is especially interesting was having heard bits of pieces of various conversations, it’s clear that the problem space people were tackling had a great deal over overlap with the issues release engineering has been tackling for years.
It’s just no one called it that.
I haven’t quite been able to figure out why that is.
It’s possible that “release engineering” may have a “curmudgeony” connotation to it, so there’s a desire to distance from (any) roles that have traditionally been at odds with “lean manufacturing”3 concepts. Or, perhaps, it’s just that the bulk of the attendees at ChefConf hail from a so-called “[Web]Ops” background, and release engineering (and release engineers) weren’t an obvious part of the Web 1.0+-world?
I don’t know… but no matter your opinion of release engineering, all y’alls are doing it5… even if you don’t know it, or find the concept abhorrent.
Which brings me to the next thing I found fascinating: we did a word association segment for The Ship Show with various conference-goers that turned out not only be a lot of fun, but revealed the wide, often extremely disparate viewpoints on some standard ideas within the DevOps sphere. For instance:
- “Release engineering” prompted responses spanning from “confusing”, “tiring”, and “hopefully a thing of the past” to “sanity”, “frictionless”, “really cool”, and “craft.”
- “Configuration management” prompted “hard” and “Jeezum… yah… no… I dunno” all the way to “good”, “sanity”, and “important”7.
- “Shell scripts” engendered, on the one hand “old school”, “horrifying”, “obsolete”, “the fallback”, and “if you have to” all the way to “kinda awesome sometimes”, “I like ‘em”, “much needed”, and “actually pretty awesome.”
- Our beloved “DevOps” excited utterances ranging from “I don’t know”, “ouch”, “dear God”, “confusion”, and “not-a-Thing” to “sweet”, “cool”, “so cool”, and “fun.”
You can draw your own conclusions8, but as someone who spends his days thinking about DevOps, the people who identify as part of that community, and the problems it faces, I found this illustrates the group’s real heterogeneity.
In attempting to fix broken social and technical systems, I think we can often forget or gloss over the fact that we’re, and the systems we work on, aren’t as uniform as we might think, which is probably something we should all be more aware of.
In the podcast “revue,” we talk at length about the keynote presentations; but the bulk of any conference is the small talks, and the breadth of topics at ChefConf was particularly surprising. There were plenty of technical talks to be sure, but in keeping with Opscode (and the Chef community’s) focus on culture, there were plenty of “soft skill talks” and those turned out to be among my favorite genre of the “short talks”:
- Joan Touzet gave a very post-modern talk on “Coming to Terms with Chef” and her own journey as an “old-school sysadmin” to a Chef-convert; what I liked most about this talk is that it’s applicable to anyone struggling with change in their industry and learning new tools. is being forced to learn new tools.
- Jeff Hackert gave a talk I can’t imagine giving, wherein he basically admitted to be an asshole in the past and went on to describe how he noticed that, came to terms with it, and now helps coach others to not-be
- The sharing of mistakes wasn’t specific to just cultural “soft subjects”; both Julian Dunn and Sascha Bates gave great talks on how to avoid failure as a new help sous-chefs9
(While it doesn’t even challenge the experience of attending the conference, Opscode has graciously put most of the talks online; not only is this great if you couldn’t attend, it takes some of the sting off about attendees missing talks they really wanted to see!)
One other topic I found thematic in a lot of the (especially keynote) talks was the focus on the global economic changes, and how this relates to technology (broadly) and IT, ops, and software development specifically. Adam Jacobs touches on the core issue in his keynote with the discussion on Ubernana.
Hearing that idea from numerous speakers, it really revealed how fundamental the changes in the industry are.
I kept thinking of tectonic plates: they feel like they’re not moving, but if you look at them from space10, you realize they’re floating on top of molten rock flows, which very much move. The shift in those plates is starting to become more palpable.
It is interesting ponder where those lava flows will take the tectonic plates on which our industry is built in this next year.
And I’m sure we’ll discuss it at ChefConf 2014.
1 Plus, hear me having a bit of a potty mouth↵
2 Both systemic and sociological↵
3 What DevOps is really about4↵
4 So I’m told…↵
5 And in some cases, reinventing the wheel…6↵
6 Which makes me sad↵
7 Along, of course, with the winner for the most responses: “Chef”↵
8 if there are any to be drawn↵
9 I originally used that term in episode 19; can I claim to have coined it now?↵
10 They discuss this specifically at 51:30 in↵