And the devs are responsible for finding a good technical solution under these constraints. If they can't, for communicating their constraints to the rest of the team so a better tradeoff can be found.
What's the mistake here? Shouldn't an incident report start with this and then continue with an analysis of the process, without too much "internal perspective"?
In my mind, the internal perspective might be useful to jot down when doing the analysis, but is too noisy to be useful to disseminate.
So I know it's a little bananas to answer this with a link to material the length of a novel, but my feeling is that the real spirit of a postmortem is best carried across by:
> The constant zooming-out is key here: it’s not enough to find out why things broke, but find out why “why things broke”. In theory you’re supposed to keep doing it: if someone skips a step because of managerial pressure, you ask why the manager was pressuring them in the first place. If the manager was worried about production quotas, find out how the quotas were decided. You just keep going and going and going.
There are different procedures folks can use to capture bits of this to different degrees, but I think this write-up illustrates well both how exhausting it is to do this right and what the value can be. Even if your goal is to get to Action Items, this kind of understanding of your event is what should generate them.
If a person doesn't understand the value, I would imagine they would write something very close to TFA's
> when something goes wrong [...] they explain why they made the decision, and then explain the contextual factors that influenced that, and then explain why those contextual factors existed, and then explain why it would have been unreasonable to expect them to anticipate the downstream effect of those factors, and by the end you have some fat five paragraphs that contains maybe one sentence worth of information and reads like a legal defense brief written by someone who knows they are guilty.
Well, there are so many more lower hanging fruits that LLMs can actually replace before they get to developers -- basically every middle manager, and a significant chunk of all white collar jobs.
I'm not convinced software developers will be replaced - probably less will be needed and the exact work will be transformed a bit, but an expert human still has to be in the loop, otherwise all you get is a bunch of nonsense.
Nonetheless, it may very well transform society and we will have to adapt to it.
Not all software development will be automated immediatly. But I've noticed that many skills I've built are lessened in worth with every model release.
Having a lot of specifics about a programming environment memorized for example used to be the difference between building something in a few hours and a week, but now is pretty unimportant. Same with being able to do some quick data wrangling on the command line. LLMs are also good at parsing a lot of code or even binary format quickly and explaining how it works. That used to be a skill. Knowing a toolbox of technologies to use is needed less. Et cetera.
They haven't come for the meat of what makes a good engineer yet. For example, the systems-level interfacing with external needs and solving those pragmatically is still hard. But the tide is rising.
The capitalists and industrialists have waited for centuries to get rid of paid labor. Imagine the profits once the cost of human work gets out of the loop!
Of course the question that is left unanswered is how the economy will work there's no one left with purchasing power. But I guess the answer to this is, the same way it works now in any developing country without much of a middle class.
I don’t see middle managers taking the initial brunt unless they truly are just pushing papers around. At companies of sufficient size, they do play a role of separation between C suite and the grunts. To me, certain low-performing grunts will be the first out. Then a team reorg to rebalance. Then some middle managers will be out as fewer of them can handle multiple teams.
> probably less will be needed and the exact work will be transformed a bit
My guess is the opposite: they'll throw 5–10x more work at developers and expect 10x more output, while the marginal cost is basically just a Claude subscription per dev.
>I'm not convinced software developers will be replaced
Most of us will probably need to shift to security. While you can probably build AI specifically to make things more secure, that implies it could also attack things as well, so it ends up being a cat-and-mouse game that adjusts to what options are available.
But you only $200/month for the productivity of what used to cost monthly salary for 10 software engineers. Doesn't this democratize software construction?
The resources to learn how to construct software are already free. However learning requires effort, which made learning to build software an opportunity to climb the ladder and build a better life through skill.
This is democratization.
Now the skill needed to build software is starting to approach zero. However as you say you can throw money at an AI corporation to get some amount of software built. So the differentiator is capital, which can buy software rather cheaply. The dependency on skill is lessened greatly and software is becoming worthless, so another avenue to escape poverty through skill closes.
You might be right but it's common to see that take as short sighted since there is zero evidence it's ever happened before. The common example is the loom. The loom didn't democritize cloth making, it put all the weavers out of business. But it did democritize everything that needed cloth because cloth became cheap. 1000s more jobs were created by making cloth cheap. In a similar way, 1000s of different jobs might be created by making software creation cheap, but just like cloth makers, software makers have no purpose when making software is easy.
I've got to ask. Is this kind of violent crime common or perceived as common in the US? If a stranger asked me for a ride home here my first thought wouldn't be that they want to attack me.
The US has a pervasive culture of fear. It's a big part of why guns are so popular.
I have had countless discussions with americans about guns that go along the lines of "What happens if (insert extremely rare violent incident) happens?" and they all literally seem unable to comprehend that these are just not things I even think about at all, and they really shouldn't either given how extremely rare they all are.
But a huge percentage of the population does worry about being victimised constantly.
It is the main reason that despite the obvious financial benefits and my love for certain landscapes/areas of the US I've never had the slightest desire to move there.
Maybe this video[1] helps you understand this better: a lot of Americans live in constant fear. They live in one of the safest countries on Earth, but if you see the discourse around safety there, you would think that USA is a big cartel neighborhood.
Maybe the 24 hours news cycle is responsible for that, I don't know. It's pretty weird, though. And I say that as someone who has lived in unsafe neighborhoods in my native country.
Depends on the area. I grew up in a bad neighborhood and everyone was grifting. If you gave a random stranger a ride you would get to take a tour of the roughest places in your city and maybe a "friend" that sees you as a free taxi driver. It was rarely malicious, mostly just people were poor and didn't have access to transportation. But their friends and family can sometimes be pretty dang nasty.
Agreeing to say, forced arbitration with a company, because you signed up for say, their streaming service, is obviously unconscionable. What would be even worse if those TOS said that you have to go into arbitration in matters unrelated to the streaming service.
Yet, this is what's happening. Disney used such an agreement (obtained through Disney+ TOS) when a man sued them on behalf of his dead wife, who died in their parks. It's common practice now to have these clauses in TOS, e.g. Discord has it too.
[0]: https://man.archlinux.org/man/tc-netem.8.en
reply