Author: Austin Parker

Like several of the tech twitterati, I've recently been going goblin mode over at Bluesky, a federated social network in private beta. As a long-time crypto and blockchain skeptic, I decided to take a look at the published documentation for the protocol that underpins Bluesky and write some thoughts.

Caveat, before I go into this too much - the public docs are pretty good, but there's a lot of TBDs and under-defined terms. That said, I applaud the team for what they've been able to put together here -- it's pretty cool.

If I get something wrong, let me know! Would love to correct this or do a followup -- again, this isn't my area of expertise.

Continue reading "The Blockchain Haters Guide To The AT Protocol"

"It's not going to happen."

A friend of mine (@mononcqc) turned me on to an essay titled 'Unruly Bodies of Code in Time' the other day, and skimming through it made me consider a phrase I like to use when introducing observability concepts to folks. I give a talk every week or so to new cohorts of employees at Lightstep, talking them through our concept of what observability is, why it matters, etc.

If you're familiar with my work at all, it shouldn't surprise you that it takes about 30 minutes until the word 'trace', 'log', or 'metric' ever escapes my lips in these talks. Over time, my understanding of observability has matured and grown into something that, frankly, is rather disjoint from the innumerable 'observability solutions' that are marketed and sold to software developers.

Continue reading "Stop Trying To Make Observability Happen"

By any scientific metric, the risk of COVID-19 infection is greater than it's ever been, while mitigation efforts have regressed to a shrugging emoji. Being offered an alcohol wipe by a smiling, unmasked flight attendant before spending hours breathing other people’s air in a narrow metal tube is panglossian, to say the least.

If your eventual destination on that airplane is to a developer conference or other in-person event, well, you’re in good company. The events industry has also attempted to return to normal, gladly welcoming us all into packed conference rooms. To their credit, many organizers are taking public health seriously and continue to require masks and encourage social distancing. Sometimes it took a little public pressure, though, for them to get there. Even so, there hasn’t been an in-person event I’ve attended this year that hasn’t had people come down with COVID-19.

Like some of you, I don't have much of a choice -- going to events is part of my job. Indeed, one thing I've noticed is that the people that are happiest to be back are the sponsors, and boy there's a lot of them. I've been to multiple events where sponsor attendance is fully a quarter (or greater) of all attendees. Indeed, sponsors saw major negative impacts from the last two years of 'virtual events', as lead capture from virtual events was far lower than in-person _and_ lead quality dramatically dropped, so it’s not surprising they’re happy to get back out there. It’s just harder to have conversations in a virtual booth about what you’re selling, and it’s much more difficult to stand out in a sea of logos.

Virtual events have also been tough on speakers and attendees as the lack of attentiveness (which I’ll get into later) makes it hard for both to engage.

So, what gives, anyway? I've been thinking a lot about this as I plan the next installment of Deserted Island DevOps. In doing so, I've come up with a theory of developer conferences and events, and why they're obsolete on their current trajectory. We’re shifting the focus to creating an event around the speakers to in-turn give virtual attendees a better experience.

Continue reading "Virtual Events Are Dead, Long Live Virtual Events"

I wrote a post a little while ago about how SRE is really just sneaky anarchism, and this is somewhat of a followup.

Let's briefly synthesize that earlier blog post. Essentially, my argument is that there exists a vicious cycle in software engineering which derives its power from radical ideas on how to apportion power in the workplace between "labor and management", for lack of a better word. Labor - developers, operators, whoever - chafe under the strictures and taylorized systems implemented by a slate of managers. These strictures and systems exist, primarily, to justify the value of the managers to the productive enterprise. Over time, radical elements of the labor pool will band together and codify some of their values into a term like 'agile', 'DevOps', or 'site reliability engineering' in order to claw back the power to organize their productive labor in a way that makes more sense to them. As these codes crystallize into movements, they are commodified and credentialed, then repackaged and sold to managers at other firms who seek to reap the procedural benefits. Meanwhile, the radicals have been fridged and the fruits of their labor firmly divested into a hundred eager consultant pockets.

I think this is interesting if you view problems from that context. The problem isn't, after all, that "developers don't know how to code" -- given our industry's attachment to whiteboard interviews I think we can discount that possibility -- but that developers don't have ownership. Not necessarily ownership over their code, but ownership over the results of their code. Your individual labor is rather atomized and packaged into Jira tickets so that managers can justify their role in the delivery of software.

"Wait, we need tickets and acceptance criteria and so on in order to coordinate and maintain a record of changes!" Well, no shit, that's not the problem. The problem is the disconnect you have from the productive work that you perform. Think about a feature you worked on, maybe even the first feature you worked on at your current job. Do you still maintain that code? Do you even know if that code is still running? I'd suspect the answer is no, especially if you've been somewhere for a couple of years. You've probably been re-orged at least once, maybe even several times, and the "thing that you do" has long stopped mattering. It's all just an endless set of tickets and feature requests, prioritization and sprints. You're a part of a larger whole, because the system is too complex and unwieldly for anyone to carry it all on their back anyway.

This doesn't have to be the case, I'd argue. Your individual contribution has been deliberately divorced from its productive value to the whole, because that's a "more efficient" way of doing things. What if we didn't optimize for efficiency to shareholders, however? What would a truly responsive product look like?

Continue reading "Incentives and Power"

"We are uncovering better ways of developing software by doing it and helping others do it."

The Agile Manifesto, 2001.

It's been quipped more than once that most amazing Silicon Valley innovations are simply a bunch of nerds poorly recreating a service that already exists, but with an app. While I find this to be in some ways a truism (after all, there is nothing new under the sun), it's a fairly trite observation. What's far more interesting is how the organizations that build and deliver these 'innovations' themselves develop, and the process of that development is especially interesting due to the pressure-cooker of free money and labor elasticity that has characterized the 'startup economy' over the past twenty years or so. What's any of this have to do with DevOps, you may ask? Simply this -- DevOps is a reaction to the commodification of Agile, and the rise of SRE is a reaction to the commodification of DevOps. To reduce the thesis further, many of the trends you see in software development and delivery can be understood as a cyclical reaction to anarchists running headlong into the invisible backhand of the free market.

Continue reading "The Commodification of DevOps"