31–34 of 34 posts
Earlier quoted context omitted.
I think the original title is better than the current one, though: "The future of software engineering – [Thoughtworks] retreat findings and strategic insights"
Why do you think it is better?
I thought it was generally interesting but it needs to materialize into processes and tools people can use.
That's kind of the point. These things don't just happen, people start talking about it at a high level (this doc, conversations like this) and then dig in and solve the problems over time.
Earlier quoted context omitted.
The concept of a large organization doesn’t even make sense in this model. How do you make decisions? How do you coordinate? What is Google when you have 50,000 individual silos?
Decisions are less costly. When a swe can take 4 days to do what would have cost 6 months, the math of making sure you are doing the right thing before executing goes away.
There’s so many layers today that can’t exist if this is the way forward.
> The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers It's not clear to me why this is true. If LLMs are writing code, why are developers simply not orchestrating the completion of more features instead of moving up the stack to do product development work? Is there some implicat…
PMs do different things in different organizations. In my last job, PMs were responsible for identifying problems that were worth solving and align with the overall company vision and plans within the owned domain, and design+engineering decided how to solve those problems and what to build. Of course with collaboration w/ the PMs (and EMs). The job before that, PMs wrote jira tickets and nagged engineering when tick…