this post was submitted on 10 Mar 2024
7 points (100.0% liked)

Programming

423 readers
5 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] Kache@lemm.ee 1 points 8 months ago* (last edited 8 months ago) (1 children)

IMO okay advice for specific types of issues, but way too prescriptive to work well generally.

Steps 3-4-5 are good, and breaking it down like that could be helpful to readers, but in my mind, it should be so well practiced and executed so naturally that it feels like a single step. I also think there ought to have been a mention of the fast iterative experimentation where 3-4-5 is repeated.

Break the build (and block other devs)? Is this a 1-team company?

Write a test first? Maybe, if you've already got a well isolated, somewhat understood problem whose solution won't require deeper restructuring.

Immediately "Brainstorm as many hypotheses ... as you can think of"? Inefficient if you already have a good idea of what's wrong (wasting time guessing), and also inefficient if you have absolutely no idea what's wrong (wasting time with uneducated guesses).

[โ€“] fhoekstra@programming.dev 1 points 8 months ago

Still, for those very hard bugs that everyone just hovers around and procrastinates, this is perfect advice!