|
|
|
|
|
|
by sclangdon
3066 days ago
|
|
|
In addition to what everyone else has said about just having more experience, my suggestion is slow down and think... and to use assert a lot! 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!) |
|
|
Most language offer a way to run in DEBUG mode, or something like it, use that, along with assert (which only runs in DEBUG mode) to make sure all your assumptions are correct. You're positive a value can never be NULL? assert that! You're absolutely positive an integer addition will not overflow? assert that! You're absolutely sure that your super-fast table returns the same results as the complete algorithm? Run them both in debug mode and assert that!