31–40 of 75 posts
If you aren't embarrassed by the code you wrote 6 months ago, you haven't progressed enough.
Does that actually happen for really senior developers though?
When I was getting my pilot's license, multiple times I started up without unchaining the tail. I joked about it with another instructor, and he basically said that it had literally never happened to him and that I should be doing a final walk around. I'd done even more embarrassing things, sitting at the runway ready to go and the tower tells me my baggage door is open. Since making that final walk around a habit, n…
If you learn to fly, you will learn to follow checklists. Many, many checklists.
A good instructor will tell you that while you do need to follow the checklists, it never hurts to do one last check. One final walk-around before getting in the cockpit, one last check of radios/transponder, one final scan across your engine instruments before takeoff, etc.
If you do these things enough times, you'll find the occasional instance where you forgot something obvious, or accidentally skipped a checklist item.
To OP, as you miss each edge case or QA thing you should have found, you add it to your checklist. Before you check in a new piece of functionality, run it through your checklist. Also, do one last walk-around of the code. How will the user interact with it, what are the API dependencies, etc.
You're not second-guessing yourself, but you always verify even your own work before calling it done. Over time, you'll learn to follow both the best practices, and your own intuition built from years of learning from your 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…
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.
Earlier quoted context omitted.
I'm gonna start writing more, i giving myself more time to code and review. Do you have any recommendations on TDD books?
Hands down the best book. Plus the authors are really nice guys! http://www.growing-object-oriented-software.com
Earlier quoted context omitted.
I'm gonna start writing more, i giving myself more time to code and review. Do you have any recommendations on TDD books?
Hands down the best book. Plus the authors are really nice guys! http://www.growing-object-oriented-software.com
I've noticed that some developers rely way too much on tools to do their job and they just don't spend a lot of time thinking. Think about the big picture as well as the details. Think about how your code interacts with its surroundings. Think about what you know to be true at any given line (and write an assertion), and whether or not that thing may ever change. Think about what every line means in isolation, and what it means to the surrounding code. Think about the names you give things.
Maybe it's because of my age, but when I started there were barely any tools to help. Even syntax highlighting wasn't readily available. Debuggers were pretty crap, or didn't exist at all. The best thing we could do to prevent bugs was to really question every bit of code. "What does this line do if x is not what we think it is?", "Can x ever not be what we think it is?", etc
I feel like a lot of developers today don't think enough about what they're doing, and care too much about their stack and their tools. Instead of moving fast and breaking things, perhaps instead try moving carefully, and try not to break things.
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements" - Brian Kernighan (replace print with assert for my interpretation!)