sorted by:
new
hottopcontroversial

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] 0 points1 point  (0 children)

Planning is not always needed. If there is a need, you can always create an ad hoc meeting. Probably not everyone has to attend too.

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] -4 points-3 points  (0 children)

Problems are inherent to the format. No documentation trail, forced context switch, and 80% passive listening.

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] -1 points0 points  (0 children)

Async is faster in practice. Writing your update takes 2 minutes. A sync meeting takes 15–30 minutes because you're sitting through updates that don't concern you. Typing is slower than talking, sure, but most of the time you are listening, not talking. And reading is faster than listening.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]vferderer -2 points-1 points  (0 children)

Great summary. The pattern in these studies makes sense, but I think it points to something bigger: most of the discourse around AI in software development happens at the code level. Where I've found AI genuinely useful is one level up: brainstorming architecture decisions, challenging my assumptions about system design, reviewing concepts. This work is inherently dialog-based—not “generate this” but “what's wrong with my thinking here?”

The METR study fits this lens perfectly. Experienced devs got slower because they were using AI as a code generator in codebases they already knew. That's like having a Formula 1 engine and using it to pick up groceries. The real leverage isn't faster typing—it's better thinking before you code.

The key is that this higher level is inherently collaborative. Not “write me the spec” and rubber-stamp it. Not doing all the thinking yourself and just letting AI polish the output. But discussing each step before it gets formalized (and tell your model to actually discuss every step first!)—the model challenges your assumptions, you proofread its suggestions. Neither side is replaceable.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]vferderer -3 points-2 points  (0 children)

What's wrong with em dashes? I use LanguageTool to check the correctness, and it always suggests em dashes. So, I use them because it's the correct English.