Measuring software development productivity is really complicated. That’s in large part what makes it so interesting.
Product sense (and taste) are so important but so hard to pinpoint and teach to others. Lenny here unpacks what goes into it but even then there are very few shortcuts to getting it.
People want local development but I feel a lot of the reasons and movements described here are valid.
When I try to unpack it, it’s usually not even very clear what ‘local development’ means but I think it’s something along the lines of: 1. Being able to manipulate the system under development immediately using the command-line. 2. Not being able to break an unrelated system and not having somebody else break your development environment. I get that those two things are essential but there’s nothing in them that requires them to take place on your physical laptop.
A short guide of how a team can turn around the work they need to do on a legacy system and come out the better for it. I’ve seen lots of teams struggle with this but as described here a lot of it is in the approach and the praxis of doing it and working together.
Nice to read a project we worked on a long time ago (web application concept and initial set of user stories to hand off to development) is still going strong. This project and others like it support my thinking that it’s possible to solve problems definitely in a product agency context.
A relevant and nuanced complication of agile by Dorian Taylor seeing it as a trauma based response where the core practice has gotten stuck and is preventing the industry from solving more fundamental issues.
Pretty much each of these 20 systems thinking tips, I’ve had to learn the hard way so seeing them all in one place is good but also difficult.
People see this kind of talk about self-governance and think there is no process or management in such a setup while usually there is more (and higher quality) than in a traditional organization. It’s also some of the best work you will ever do.
A lot of very uncomfortable questions in this list of staff engineering program dysfunctions. It seems this is quite widespread and we’re collectively figuring out how to shape this path.
Some ways to improve the quarterly prioritization tussle between engineering and business that focus on facilitating the conversation and reducing the number of things under immediate consideration.