91–100 of 202 posts
I am glad this essay was on the right side of the fence, otherwise I would have written it myself in response.. Our company is currently one of countless, where we just had a "get with the program" meeting with our PMs, where they showcased stuff they had added to our enterprise system in hours and days, and told us that they expected us to start delivering with the same tools techniques and speed.. Meanwhile, my tea…
I think technical PMs or product oriented developers are the future most valuable people.
It's pretty normal for integration projects with big corps to have problems, but if the project has executive interest and the A-team gets called in, it's a joy to work with those people. The lines between the roles are blurred, it's just smart and dynamic people making things work. They don't give a shit about following scrum or pedantic coding standards, only project success, but not in a superficial way. I don't know if they truly care about what they're doing, but they're so far above the baseline that it doesn't really matter.
Text to code is clearly valuable but the code to text capability of LLMs is seriously underrated IMO. I would argue orgs should prioritise giving PMs Claude Code licenses over devs. So much efficiency unlock without the worry about whether vibe code can be shipped to prod.
Earlier quoted context omitted.
I got laid off at a job where this applied, then at another company got rejected because they cancelled the position altogether to use Agentic Coding by Microsoft instead. Then I joined a small consultancy that just lets me build however I want. There's no reviews, no sprint reviews, no evaluation. They trust that you work on what is important. While this is a very messy and unmaintained workflow, it is a lot nicer a…
In my view, Scrum is a way to force dysfunctional teams to have some process, it is not useful for a team that is already delivering and working in a samll-a agile manner.
If it worked someone would say, hey let's use this in more places.
If it worked really well others would say these aren't guidelines they're dogma.
Now we have scrum 2.0.
Hot take: only PMs need to code now. With Claude 4.6 Opus, the engineer skill set is no longer useful. Why are we hiring people with code writing ability when code writing ability has no value anymore?
I love writing software. I love that others are now getting to share this.
I think the issues here are valid. Equally there is lots of hard engineering work to reduce these issues. That's where I'm putting more energy.
My scale is decidedly non-Meta, but we're investing to make the whole team able to get their own PRs up. It's not been without it's bumps, but on the whole I think it's been transformative for everyone.
Meta, and other large companies have been encouraging PMs to code, while I've seen many negative responses from engineers having to code review, debug, deal with production issues, etc. stemming from crappy code they don't understand. Metrics and KPIs are being gamed into stupid incentives like lines of code, commits, and tickets closed. Leadership claims they are aware of Goodhart's Law, but their actions show other…
An easy correction is to only merge PRs from folks who are on the on call rota. Those not on rota can either join or have their PR receive heavy scrutiny
> You are friends with all the senior TLs, so can get them to review your code, but this is not a high-leverage use of time.
And then, tying back to ops comment, the engineer gets pinged for their bad metric, because of this additional review.
Text to code is clearly valuable but the code to text capability of LLMs is seriously underrated IMO. I would argue orgs should prioritise giving PMs Claude Code licenses over devs. So much efficiency unlock without the worry about whether vibe code can be shipped to prod.
Shipping vibe code to prod is like the dumbest and least useful thing LLMs can do.