Are there any books or resources your can suggest? I feel like my accuracy in thinking about corner cases have been stuck around 65% for a while and I'm looking for ways to improve.
I had to learn what we used to call “desk checking” when I started programming, out of necessity. Desk checking is reading through your code and “running” it in your head, keeping track of state on paper. You learn to notice edge cases because at every step you have to think about the next possible states. After some practice you get better at this and it becomes more automatic.
This isn’t practical for large code bases, but you can do it with individual functions and chunks of code. I still work this way but I don’t think it’s a common technique anymore.
You structure the code to minimize bugs, to avoid having to structure your thinking to minimize bugs.
You want programs to have the property that if someone wants to make a change, they need to understand only a small part of the program, and not worry about something breaking mysteriously in the parts they don't understand.
It usually helps to have a systematic mathematical model for the problem you are trying to solve, and systematic mathematical models for the sub-problems into which the full problem is decomposed. It is frequently better to conceive of each step in the program as ensuring some property is invariant rather than conceiving each step as performing some action.
It is probably better not to think of yourself as a coder or a programmer; consider yourself a problem solver with mathematical skills and move on to there.
Always convince yourself that the problem you are trying to solve has a solution.
Thanks for this! This is something I've been practicing of late. I realized that have a lot of problem in arguing the correctness of greedy algorithms. Do you have any recommendation for a collection of proof techniques useful for greedy algorithms?
Kinda depends whether by "correctness" you mean "proof". I always found Social Processes and Proofs of Theorems and Programs by Richard A. De Millo, Richard J. Lipton, and Alan J. Perlis inspirational.
I do not know of any collection of proof techniques that would be uniformly useful for greedy algorithms. If you discover such a collection, please share it with me.
12 comments
[ 3.7 ms ] story [ 38.7 ms ] threadThis isn’t practical for large code bases, but you can do it with individual functions and chunks of code. I still work this way but I don’t think it’s a common technique anymore.
2.Go through existing projects and see if you can structure them differently and the benefits changing the structure will provide.
3.Buy and read The Fifth Discipline by Peter Senge https://amzn.to/30IKxdZ . It is one of the best books on systems thinking.
4.It takes time to build the systems thinking muscle so be patient with yourself.
You want programs to have the property that if someone wants to make a change, they need to understand only a small part of the program, and not worry about something breaking mysteriously in the parts they don't understand.
Experience, testing, formal methods, less fragile tools, and avoiding premature optimization.
Consider Haskell, Idris, Pony, Rust, and Clojure, but these are just some tools in a large toolbox.
Put aside insecurities and constantly look for techniques to minimize errors, maximize readability, and productivity.
Accumulate best practices and apply them with experienced "common" sense.
Consider coding like writing with many drafts. Throw some away and write it again.
It is probably better not to think of yourself as a coder or a programmer; consider yourself a problem solver with mathematical skills and move on to there.
Always convince yourself that the problem you are trying to solve has a solution.
I do not know of any collection of proof techniques that would be uniformly useful for greedy algorithms. If you discover such a collection, please share it with me.