Ryan Singer

@mattsbjornson Projects also have budgets and timelines.

@rjs You just summed up why most 'product' work is really 'project' work. It's throughput and delivery, there not context around potential impact. Prioritization is an afterthought. You certainly can not get to any sort of investment thesis without understanding the cost/budget.

None of the work trackers (Jira, Linear..) have a concept of underwriting. Take any ticket and try to answer: What budget / capacity is this coming out of? Who authorized spending time on this instead of something else? This is a hugely first-class piece of info, ontology-wise.

@benjaminsehl 🙏 Very nice to hear!

@rjs Honored, Ryan. Incredibly huge fan of your work. This talk you have had a big impact on my early career: vimeo.com/15772341

Code as truth. Good reminder, as some forms of spec-writing return to the design phase, that specs are only intentions and architectural guidance. Readable code tells what the real behavior is.

@bcrussett There are people who care how time is spent. My original post is about the software side of the problem.

@rjs top down or bottom up problem? budget holder not wanting to see how the sausage is made, or the TL not wanting to document it? curious about this too, it makes sense at an org systems level to have it but local incentives seem to get in the way

@miiightymitch That is true if the epic maps explicitly to (a) assigned people and (b) time. Otherwise it doesn't have walls to judge how "full" it is. Beyond that, in practice, a ton of work falls between the cracks of epics.

@rjs In Jira terms, this info would be at the epic level, no? Free-form, process dependent

This is why I often say a ticket board is a sausage machine. You just shove stuff through it. There are no economics. No trade-offs.

Once you start thinking in terms of time budgets and capacity, you can't unsee it. It is impossible to see "available time" to work on something in any of these tools that supposedly account for and track the work.

Interestingly non-trivial example of @foldkit here. Love the explicit tradeoff to render every animation frame as a function of the model and view.

👀

Hard question … My first thought would be to ask: “if I didn’t use remix 3 for this, what would happen eventually that I wouldn’t like?” Then work backwards from that. Like, where’s the point where the difference becomes manifest? A quality problem in the UX that is hard to guard against with typical agent-produced React code? A change that’s harder to make afterward? Etc.

I don't know how to show off remix 3 give an agent a task and show/discuss the code? write it myself and discuss? don't even show code just prompts and product results? such a weird time

@jorgemanru @portforward21 Super curious what you’re trying. What’s an example of a non-terminal-driven approach? Like having the agent in the chat room or automated from a todo?

@portforward21 Quite the opposite from my side! That reflection comes from experimenting with different non-terminal-driven approaches at work lately. I can't be more excited about the whole AI-for-dev thing, and can't shake the feeling that we are just scratching the surface here.

No clue what the future of software development will be, but staring at terminals while consuming a stream of largely irrelevant information (like assorted diffs, used tokens, tools count...) won't be it.

Sound equivalent of SVG.

@GergelyOrosz The problem is made worse because lots of AI-assisted MRs are made without reference to some clear macro picture of the design.

@GergelyOrosz Seeing this too. Also in QA. Making some progress under the theory that the problem is getting context. Most MRs/tickets don't have a clear path from diff -> wider context of what we're trying to accomplish -> intent of this change within that -> actual implementation choices.

One thing I am hearing that is top of mind for many eng leaders "What are we doing to deal with this ongoing increase in code review load?!" Everyone is seeing it, no one seeing a solution, but lots of experiments from better tooling to starting to admit code review wont scale

So many people coming to me saying “I liked scrum. But it doesn’t work anymore. We want to be AI native. A 2-week sprint makes no sense.” So interesting. Used to be only people interested in Shape Up were fed up with scrum.

The latest post from @chriscbs is gold. What an awesome breakdown of situations to trigger demand-side interviews.

Why do I say "propose a design" when asked for an estimate? Because an estimate is the sum of the parts of a design. If you can't see the design you can't sum the parts. If the design isn't right, the parts aren't the right parts to sum.

In other words, "How long is this going to take?" should be treated as a work assignment. And not a cheap one. Because it requires more senior people to dig in, ask lots of questions, and propose a rough design.

Estimating isn't just making up a number. A realistic estimate comes from doing spikes to map out what the work is. Then you sum the work. What people miss is that creating the estimate requires doing actual work to obtain the knowledge.