Programming: Doing it more vs. doing it better
Someone who&#x27;s been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I&#x27;d been programming for only three years.<p>I do find that a lot of programming stuff that used to be hard is easier for me now that I&#x27;ve been progrmaming for 38 years.  But that doesn&#x27;t mean I spend all my time doing things I can do without thinking, and it certainly doesn&#x27;t mean I write code that doesn&#x27;t need refactoring.  Maybe my designs are better than they used to be — I think so — but often that&#x27;s because I developed the design <i>more</i> incrementally through refactoring, rather than <i>less</i> incrementally by planning.<p>I do avoid a lot of errors by thinking through the consequences of a choice before taking action, in a way that I couldn&#x27;t always do.  But often that choice is specifically the choice to plan out a big design at the start of a project.<p>Also, though, what counts as &quot;big&quot; has changed for me.  What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago.  So I can explore alternatives with less risk, in a way.<p>The author describes a lot of anxiety and guilt about doing things imperfectly.  I think that&#x27;s a big obstacle to improvement — other people can pick up on that and will be reluctant to give you feedback, and feedback from other people is a really fast way to improve.  Also, it tends to shunt you into tasks that don&#x27;t challenge you enough — it pushes you to avoid risk, and pushes other people to not ask you to do things that are at the limit of your abilities.  This is precisely the dynamic Atwood was trying to combat by telling his story.