Be Purposefully Stupid(rbrogan.github.io)
rbrogan.github.io
Be Purposefully Stupid
http://rbrogan.github.io/be-purposefully-stupid.html
5 comments
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.
Its important to indicate by the substance of the questions that your knowledge and undertanding is advancing, otherwise you come off as an idiot.
"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.
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.
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.
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.
Hence, languages with a proper macro system.
Application-specific macros make code unreadable, while common and standard ones might as well be a language feature. A well-designed language should offer suitable extension points in a structured way, rather than just allowing code to perform completely arbitrary transformations on the AST.
Hence the value of rubber duck debugging.
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...