from Hacker News

Be Purposefully Stupid

by rbrogan on 1/25/15, 12:37 PM with 7 comments

• by hotBacteria on 1/25/15, 3:26 PM

  Don't be stupid, be slow [1]

  We take shortcuts when we feel the proper solution takes too long to implement If you purposely take a shortcut, write why you take it, how you take it and how to turn back in case of troubles.

  Slowing down also allows you to share your problem with your team, your friends or your rubber duck Again, don't forget to write somewhere what your rubber duck told you, don't waste his time asking him the same questions over and over again.

  [1] https://ventrellathing.wordpress.com/2013/06/18/the-case-for...

• by marktangotango on 1/25/15, 1:58 PM

  It takes a lot of guts to ask stupid questions. "Talk to me like I'm 5" is often a good way to slow things down. A line questioning that works for me is "how would it look in the ui? What would you see?"

  Its important to indicate by the substance of the questions that your knowledge and undertanding is advancing, otherwise you come off as an idiot.

• by akerl_ on 1/25/15, 4:36 PM

  "Fast is slow, slow is steady, steady is fast"

  Categorizing the good technique as "be stupid" is a gross mischaracterization. Be smart: make sure you have a solid understanding of what's going on before diving in. The issues being described here are a result of charging in headfirst into things without thinking things through.

• by Kenji on 1/25/15, 2:32 PM

  I agree. One of the biggest sources of errors for me is copy-pasting multiple lines of code and then failing to adjust some of the variables or numbers. If I do that it's guaranteed that I lose 2-3 times 15 minutes a day because of stupid bugs.

  Don't be too smart, don't copy paste more than a word. The time it takes for typing is well worth the reduced error rate. Don't let your laziness get the better of you. Don't create circumstances that allow you to make additional errors.

• by agumonkey on 1/25/15, 2:28 PM

  Hence the value of rubber duck debugging.