Hacker News new | ask | show | jobs
by dundercoder 3068 days ago
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 everloving crap out of everything, then another person does, and another.

If your code doesn’t kill people, ease up on yourself a bit.

3 comments

Agreed. We learn by making mistakes. Also you have only 3 years experience. It takes more like 10 years to become a "good" developer in my opinion. And even they still make mistakes, they are just less obvious ones.
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 more hard to solve and obviously getting the wrong answer.

This kind of thing is currently my biggest problem and i cant find a real way to improve.

This is the sort of thing that reviewing other people's performance can really help with. Offer to teach classes, grade homework, or whatever.

Second thing that helps me pretty well is doublechecking through another path. You know, figure something like this out, check if the angles of the triangle still add to 180, check if substracting half the equation from the previous step still yields the same, that sort of thing. For the problem you said, find an "easy" definite integral that is easy to calculate (e.g. a sine is 180 degrees of the unit circle, so integral(0,1,x->sinx) is p/4).

So take a "trivial application" of the mathematical expression (like calculating the area of the unit circle), and execute it on every step, calculating what should be the area of the unit circle. As long as you replace expressions with equivalent expressions the outcome should stay the same.

And for coding, unit tests, but more than that, running the code, using a debugger or so.

Look at your intermediate steps, and ask "Does this look like the right answer?" at each point.

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?"

Everyone makes mistakes, the trick is catching them before you release to QA. In your math example, you should have some sort of test harness that tests your method against known inputs and outputs. It can be as simple as a throwaway console app.
In critical systems like traffic light and elevators the key is to have a simple system so you don't need to test the crap out of it. Using something like a finite state machine.

Part of making fewer mistakes is going for simplicity over complexity.