Ask HN: After you ship a feature, what happens to what you learned?

9 points by gaggle_dk 8 hours ago | 4 comments

Closing in on my second decade of programming, and I keep noticing how often we step on the same rake. A change breaks something, and in hindsight we already had the information to prevent it, we just never surfaced it. Or we ship a feature and never circle back to check whether it's used the way we intended, so we keep shipping more on the same untested assumptions.

Does this resonate? I'm fairly sure we all hit this, but I can't tell how many people see it as a fixable pattern versus just part of the job.

- After you finish a feature or project, where does what you learned actually go? Is it your head, an issue comment, a doc or wiki, a retro, somewhere else?

- When you start something new, do you explicitly pull in past learnings, like copy, link, reference, discuss it? Or is it all from shared memory?

- Got an example where remembering something earlier would have saved you real time? What happened?

Trying to work out whether this is a shared pain or just mine. War stories very welcome.

exhaze 6 hours ago |

My best learnings came from mistakes - mine, my team's, my company's, other companies - but almost always, it was when those mistakes were promptly followed up with a thoughtful incident report.

For example, when I launched what is now Uber One, two days later, I got a call that I broke something. It turned out I had forgotten an edge case in a completely different service. Yes, this was 2016 Uber, 3000 microservices, but I don't think the users who didn't get their discount really cared.

The takeaway I still remember from that today is about always looking for "works by coincidence"; I often ask myself about the preconditions that must be in place for some class of mistake to be impossible.

brian-m 7 hours ago |

This is very much a shared pain, though my experience is mostly outside the programming world.

I see it as a fixable pattern, but the inertia is strong.

- Lessons learned and retrospectives don't take place as often as they should

- The sessions themselves sometimes get a bit defensive, so the real nuggets get missed

- Even if a good session takes place, it ends up being static data buried in another archive

Taking an example from the construction world, I saw project after project suffer from poor planning and design. Common enough issues to warrant a moment of investigation, but not, then later being passed off as "black swan events". Because who would have thought the ground conditions would be suboptimal near a swamp?

There's something to take from the Health & Safety world. Talk about stuff. An organisation I worked for had a rule that every meeting, irrespective of purpose, had to start with a safety conversation. Something new, a reminder, a good story - just something safety focussed - and a reminder to look in the H&S system for updates and other stories. There's strong correlation between proactive conversations and reduction in safety incidents.

My thinking is that this approach should work across domains. I've done it with teams in the non-programming space with some success. A few minute knowledge-share at the start of stand-ups and regular meetings seemed to reduce the number of times known issues/challenges happened a third time. Just be prepared to lead the conversation with "I was looking through old lessons learned and saw <thing>... good reminder to <action>..." or something.

eternityforest 8 hours ago |

I have my own personal formal debrief process for larger projects: https://github.com/EternityForest/THUNDERWARS

Usually if I notice anything of interest to others, it just winds up in a group chat.

AnimalMuppet 7 hours ago |

I often kept a personal "notes" file while I was working on a project/feature. I now think that what I should have done is check that file into the source tree, at the top level directory for whatever feature I was doing.