The mention of fear-driven coding strikes me as possibly more important than the process and architecture discussion. The whole concept that your emotions drive

The mention of fear-driven coding strikes me as possibly more important than the process and architecture discussion. The whole concept that your emotions drive the focus of the code you write seems very true to me. As a beginner and student coder, fear struck me a _lot_. I read a lot of the literature, I saw all the "don't do this" guides and blog posts, and so I was always concerned and hesitant about whether the code I wrote would be a good foundation for whatever came next - never mind the fact that my projects were so often left unfinished. I also wanted to work mostly in high level languages(TI-BASIC, Python, etc.) while wrangling as much graphics performance as possible out of them - before I had my full featureset in place - which led me to micro-optimize those languages past the point of maintainability, with inlining and caching tricks all over the place. All of this was a result of fear of the classes of bugs one gets by working with the lower-level abstractions - even though I understood pointers and memory management competently enough. In the end, I've only gotten over these hangups by trying all the methods and seeing which ones slow me down or lead to meltdowns in practice. A lot of it turns out to be domain-specific - so e.g. I could tell you right now that doing string manipulation in C is likely to cause tons of pain, and writing the core loops of a 3D renderer in Python will make it unbearably slow. But there are all sorts of problems where I have no real answer, and will have to resort to failing fast to wrap my head around the problem.