Reading a lot about platform engineering kept reminding me about the concept of the paved road (I’ve also seen the term “golden path”) in software engineering. It’s easy to understand why – if you do platform engineering correctly, then you end up with a paved road. Spotify probably has the best definition of a golden path (emphasis mine): “The Golden Path — as we define it today — is the ‘opinionated and supported’ path to ‘build something’ (for example, build a backend service, put up a website, create a data pipeline).” For all practical intents and purposes, a paved road is essentially the output of platform engineering. But why should we be trying to pave these roads? Shouldn’t we just build a stack and incorporate toolsets specific to each project, app, or service? Surely that way we can optimize for the specific problems each was built to solve, right? Wrong.
So after taking a brief break to write about Twitter, because that’s everyone’s new favorite hobby, I wanted to revisit part of my central thesis in my posts on platform engineering – that it’s hard to find places with actual cross-functional teams capable of doing everything needed to build and run an application or service from concept to being used in production. I’m not totally sure why this is something that organizations don’t want to do, but I still don’t platform engineering is the solution (or as I’m sure some companies will try to spin it, “compromise”). Continue reading »
So apparently there’s this hot new app that just released called Mastodon, and everyone’s leaving Twitter to join that. It’s OK if you haven’t heard of it, it’s that new. Snark aside, people are stumbling onto Mastodon because they’ve been told it’s the biggest Twitter alternative (it probably is), which isn’t really saying much – there aren’t a lot of Twitter alternatives that anyone would really think twice about. It does a good job of replicating the basic Twitter experience, type some things into a box and click the post button to publish. But there are important, non-obvious (to general users) differences between Mastodon and Twitter, and people seem to be struggling with them.
Will platform engineering be the mass-reproducible secret to great software development?
When people talk about the “death of DevOps,” platform engineering is brought up as its successor. That’s probably overstating things. The practices associated with platform engineering certainly look like they have a lot to offer, but getting platform engineering right is difficult. And getting platform engineering right is important, because that’s the only way platform engineering is going to work. Otherwise, what you’re going to end up with is a mashed-up team of random engineers desperately trying to keep infrastructure afloat while developers wreak havoc on everything.
I came across an article titled “Devs don’t want to do ops” that started with the premise that developers managing their own production infrastructure is stressful (it is), questioned whether development and operations should be separated again, and settled on declaring “DevOps is dead,” and that platform engineering is the future. It was quite a ride. It also raised some good questions about DevOps, and the ideal approach to building and running code. Is DevOps really dead? Is platform engineering really the future? What does it mean to “own your own code in production?”
If you see any sort of headlines about CEOs and remote work, then you likely heard that Malcolm Gladwell does not like remote work. I had some thoughts on why I think his position (and others like it) is stupid. My position is hardly uncommon – most of the arguments for returning to the office revolve around saying either a) people can’t collaborate unless they’re in the same room (the fact that team-based jobs kept up just fine since Covid happened thoroughly disproved that), b) we need it for the “culture” (“culture” has nothing to do with physical proximity, and isn’t as valued as some people think it is – although looking at that meme makes me miss the days when we at least got cubicles), or c) people aren’t productive working from home (they weren’t productive in the office either, you just thought they were because you saw them sitting at a desk). In my tweet thread, I brought up a personal hypothesis that you can group most people into 1 of 2 groups, “true believers” and “mercenaries,” that I thought warranted more details than you can get on Twitter.
So a (semi-) local coding boot camp is going to be trying something that I really hope works out – partnering with a local company to sponsor and ultimately hire the graduates. I love this idea because of the way it shifts the financial risks in training people for future careers, the direct contrast it puts colleges in, and the fact that a set up like this is inherently designed to make the “graduating class” more successful, and not just because a higher percentage of them got their first job quickly.
Something broke with our approach to disagreements. We went from simply arguing with people who were wrong on the Internet to to demands that people be deplatformed because they’re wrong, according to people who seem to be right equally rarely. Thanks to the aggregation of content onto a few major platforms, a few people have the arbitrary ability to make other people vanish from public discourse. At this point, it’s impossible to tell who’s right, who’s wrong, and who’s been disappeared for having views deemed “unacceptable” by people who have no business making that determination. It’s starting to seem like the reason you can’t trust just anything you see online has moved from “anybody can post anything on the Internet” to “because publishing anything too contrarian will get you kicked off.” That’s not good.
From the “stuff I screwed up” files – the missing email link test
I was working on hotfix that turned hotter than I wanted during the deployment, all because we missed an important test case that left us scrambling to resolve an issue during the deployment that we should have caught earlier. We got lucky and fixed it during the deployment, but we shouldn’t have been in that position because the scenario that failed was a known requirement, which means we should have tested it. So what happened? Well, point blank, we forgot a test case.