33
top 6 comments
sorted by: hot top controversial new old
[-] thesmokingman@programming.dev 19 points 1 year ago

This sounds like a bunch of drivel.

AI can better analyze the relationship between cycle time, code review time, and code churn... It can determine if longer code review times are actually leading to less code churn… Or, it may find that longer review times are simply delaying the development process without any significant reduction in churn.

This is not something that the numbers tell you. This is something an understanding of the code reviews tells you. The author runs a metrics platform so he’s pushing this hype train that’s going nowhere. Blind faith in metrics without context, ie all an AI can generate, leads to great decisions like the Nova.

[-] meco03211@lemmy.world 6 points 1 year ago

My experience has been management is too stupid to properly employ metrics. If you let them pick, they pick the easiest ones. If they don't get a choice, they just try to cheese the numbers to the detriment of the company. If you present options that make sense, they don't understand them.

Maybe I've just worked for dumb companies, but they sucked hard with respect to metrics.

[-] jungle@lemmy.world 2 points 1 year ago* (last edited 1 year ago)

As an engineering manager who's tasked with manually gathering a whole lot of metrics in the hopes that something jumps out that can then be improved, what would you say are the metrics that make the most sense?

As a former coder, I would say PR size (the smaller the better), automated test coverage, number of prod bugs, toil level (unplanned work, dealing with tools and environment issues) but also things like knowledge of the code base, level of collaboration, ownership of the process, org-wide collaboration and learning... Much of which is hard to measure but can be set as goals regardless.

[-] meco03211@lemmy.world 2 points 1 year ago

Apologies if I misled you a bit. My experience is in manufacturing, not coding. My advice would be to identify issues in terms of cost. That's what the company truly cares about. Talk to your people and find out what their biggest pain points are. Then order those issues in terms of effort to rectify vs return on investment. Problems that are low effort but high return get prioritized. Then just whittle the list down.

This takes a broader approach to metrics. But as I mentioned, metrics can be cheesed. It's hard to cheese overall cost. If you prioritized number of bugs, I'd assume the time would go up. If you prioritized time, I'd assume bugs would go up. Prioritizing either doesn't really solve the problem. You want the root cause of those bugs. Are certain bugs more prevalent (can bugs be categorized even?). Then work those down.

I'd be more then willing to flesh out some more details if you'd like. I genuinely love that kind of stuff. Unfortunately I don't have coding specific experience.

[-] autotldr@lemmings.world 3 points 1 year ago

This is the best summary I could come up with:


Over the decades, engineering management has undoubtedly become more agile and data-driven, with automated data gathering improving performance.

It can automatically set goals based on real-time data, generate recommendations for improving teams’ performance, and process far more information than was possible before.

Even the most capable engineering leaders have some blind spots when it comes to reviewing performance in certain areas, and may miss concerning behaviors or causal factors.

Typically, managers will manually put together reports at the end of the month or quarter, but often that gives a superficial analysis that can easily conceal hidden or incipient problems.

Or, it may find that longer review times are simply delaying the development process without any significant reduction in churn.

By analyzing multiple metrics simultaneously, AI can help identify patterns and correlations that might not be immediately apparent to managers, enabling organizations to make more informed decisions to optimize their software development processes.


The original article contains 424 words, the summary contains 152 words. Saved 64%. I'm a bot and I'm open source!

[-] Kissaki@feddit.de 2 points 1 year ago* (last edited 1 year ago)

Even the most capable engineering leaders have some blind spots when it comes to reviewing performance in certain areas, and may miss concerning behaviors or causal factors.

blind spots - something the AI has too?

A capable manager may make use of known unknowns. Using an AI where you can't follow the process seems risky. Asking the AI to explain itself may be elaborate hallucination.

this post was submitted on 04 Nov 2023
33 points (80.0% liked)

Technology

59340 readers
1453 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS