I highly recommend checking out his YouTube channel [0]. He's an _incredibly_ thoughtful person and provides good lessons in staying focused and keeping scope down. I consider him a mentor and his approach to software is something I really resonate with. He has a keen focus on software quality but understands he can't make everything perfect in one sitting. This approach helped me get away from decision paralysis in…
Ed: i really enjoyed the video, but I feel it could have been even better (and shorter) if he used a proper debugger for the second part. But I don't know if that is available in the os.
The more I use a debugger, the more I realize I should use a debugger, and the earlier I should use a debugger.
Advice/directions to start early with a debugger might be the best part of Zed Shaws "Learn C the hard way". Eg:
https://github.com/zedshaw/learn-c-the-hard-way-lectures/blo...
(not a full featured chapter, but note that this is fairly early - exercise 4).
On a related note, it appears Shaw doesn't use the/any debugger at all in the ruby book, which is frankly quite crazy - ruby has great debuggers and repl. But that's a digression.
For a blog post that illustrate how one might do "debug driven" (or "debug first) development, see: https://nikhilism.com/post/2021/experiencing-smalltalk/
(Smalltalk and lisp does this very well - you can't AFAIK quite go that far with c++, but it's what all systems should aspire to, as a baseline (70s debug experience) ).