11–20 of 75 posts
2. run the code and purposely try to break it with all the edge cases you can think of;
3. run the code as if you are an end user who knows absolutely nothing about it;
4. have your colleagues try to break your code before you commit it.
https://wiki.illumos.org/display/illumos/On+the+Quality+Deat...
https://davepacheco.github.io/se411/release/fcs-quality-all-...
I have the exact same problem as you. The reason why I behave like that is always due to some sort of anxiety in finishing the task at hand, together with a flawed protocol to design and review it. So what seems to help me is: - slow down, more time equals more time to think - write specifications as neatly as possible and review it with the requester (even if it is only your self, review it many times). The more bul…
I'm gonna start writing more, i giving myself more time to code and review. Do you have any recommendations on TDD books?
His advice for learning from mistakes is basically to look for the cues or patterns you missed that caused your mistake. That way you find the hints that would've helped you catch it in time.
I've been doing this myself, and writing up results in a weekly email (https://codewithoutrules.com/softwareclown/) and it really improves how much I learn from mistakes. As in, I go from "well that was stupid of me" to "ohhhhh, I should've noticed that."
Example: early in career I submitted code with bad variable names (foo, bar) to customer who requested I write a library. She pointed that out as bad practice, I was super embarrassed over my bad code. My takeaway in one of initial emails was obvious one of "write readable code."
But later I revisited using the cues/patterns approach, and realized deeper mistake was not listening to what she wanted—in this case, source code. If deliverable wasn't source code then variable names wouldn't have mattered and it would've been fine.
How to make fewer mistakes.
This may not be what you want to hear. Making mistakes properly is progress. Make the exact same mistake multiple times? You might need to write them down as you find them. At one startup we had a motto: Measure once, cut twice. Being fix the bug, then write code to mitigate that risk in the future. Fix it twice. Now in critical systems like traffic lights and the like, mistakes kill people, so you test the everlovin…
Thank you for your comment, sometimes im bit to hard on myself; I can learn from my mistakes, but some of them are really trivial, i can find better examples in math, like: In a calculus question, I need to find the volume inside some functions, this type of question is not new, i know how to solve, but somewhere deep in the calculation i change 'integral of sin' to be `cos` instead of `-cos` making the everything mo…
Nobody's memory is perfect - so it becomes a question of "How can I tell if I'm going down the right route, and how can I test to spot the mistakes I know I'm going to make?"
If you aren't embarrassed by the code you wrote 6 months ago, you haven't progressed enough.
Double-checking. To take an example: say you take the integral of `sin x` and get `cos x` instead of `-cos x`. You can double-check this by differentiating `cos x`, which will give you `-sin x`. Not only does this tell you you're slightly off, it suggests exactly how to fix the problem. Many problems can be double-checked: you get a result, then run the steps backwards to see if you can get back to the starting point.
Incremental testing. I've recently been learning basic robotics / electronics as part of a side job. One thing I found enormously helpful was to build up progressively larger circuits on a breadboard - I'd even test the breadboard itself (e.g. do the two halves of each row connect? Well, there's an easy way to find out...) to make sure I had the correct mental model of how my components were working.
Isolation. When confronted with a problem, try to find the minimal example that reproduces the problem. I do this a lot when building out interfaces / applications, where I need to add some non-trivial piece into a larger application. I'll build a test page that contains just that piece, get it working, then figure out how to integrate that working example with the application as a whole. As a side benefit, I've broken my seemingly hard problem down into two smaller, easier problems.
Informed questioning. You will inevitably hit something beyond your level of expertise. Half of experience is learning when to identify that this has happened, and knowing how to coherently explain your mental model of the problem. Your mental model doesn't have to be right, but it should exist, and you should know how to describe it to someone who can pick it apart and improve it. Part of this is a sort of "egolessness" mindset: having the humility to admit you don't understand everything, and to seek expert help once you've tried what you can. (We're all bad at this last step, myself included; developing this mindset is itself a learning process.)
Finally, and IMHO most importantly: failure normalization. Failure is normal when learning a new tool, framework, language, skillset, etc. In this situation, one of the first things I do is to explore what failure looks like. I'll deliberately introduce syntax / logic errors: what sorts of errors does the compiler / toolchain spit out? How can I use the debugger to step into the problem, and what does that process look like? Do my tools give me any kind of visual / tactile / etc. feedback on my error? (If not: where can I find better tools?)
Since making that final walk around a habit, nothing. I started doing final everythings, one last check of the radios, one last check of the instruments, etc, etc. It's amazing how many times you pick up on something so obvious that is wrong.
The key is to change your mindset before doing the final check. Acknowledge you are done, go get a tea, and go through the motions.
Somethings I do related to code.
Use `git add -p` to go through changes one by one. Remove stuff that shouldn't be there.
Do a self code review before submitting the code for others to review.
Obvious one, but always run tests.
For what it's worth, I find the same things with maths. I've been working on SLAM systems, so lots of differential geometry and matrix calculus. I'll spend a morning with my notebook trying to figure something out, go to lunch, then come back and go over what I've done.
In university I was horrible at maths exams, because like you I knew everything but made so many stupid mistakes. I think the problem was that during an exam, I could never dial down my mindset from OMG I need to triple check everything right now!