A REFLECTION ON HOW TO DESIGN PROGRAMS

     How to Design Programs took me about a year to read. A year of on again off again trying to convince myself that getting through this textbook would help me reach programming nirvana or something. That didn’t happen, this isn’t even a self-described cure all that we all come in contact all too often. HtDP is a very opinionated book, and it really likes its own opinion, but it knows that it is just an introduction. As someone who has put themselves through way too many introductions, from restarting free code camp a dozen times to never being able to finish CS50, this was a solid, hard, enjoyable introduction. It teaches discipline and gives reason for that theory. Not just ‘you’ll understand when your older’, it reminds you again and again, ‘how shitty would it be to have to understand this code having been given the job to debug it?’ and then teaches you how to avoid that at all cost. Use an accumulator here, write solid comments there. My intro to CS course at UC Denver mentioned comments on the first day, didn’t give reason to their existence, didn’t give a solid outline on how to use them, and then forced their use on every student. Knowing the how isn’t enough, and HtDP gets that, and gets you to get that. Why is right up there with how and I know that now.  

     I don’t think I got everything I could of out of this book. A text that attempts to teach discipline takes discipline to read and that in itself is damning. It’s easy to take the quicker route, to glaze over sections that you don’t really understand, but I did learn the pain of not paying attention the first time. That if you’re going to do something, do it well. I can repeat that over and over in my head but until you have an exercise that you do poorly, that ends up leading into another exercise that required you to do the previous one correctly will that mantra be understood. 

     Also, Lisp is dope. Functional programming and operator first always code is super neat and really fun to write. I think recursion would be much easier to grasp if students were taught Racket over C++, the syntax really feeds itself to cleaner and tighter code. Sure, coming from a more normal looking language can be jarring. Starting out I was lost after spending most of my time with JavaScript, but after a while it is much easier to write and forces you to write well. It’s like having a professor always looking over your shoulder. The lack of bloat is also nice, ditto to the clean docs. HtDP really forces you to be able to look at documentation and that was a skill I am glad to have left with, also an understanding of how I should write documentation for any technical projects I work on in the future. 

     I also learned that just reaching out and emailing people lends itself to many positive surprises. The authors are particularly responsive and were willing to answer any questions I had, making the experience of running into a problem of magnitude a much more enjoyable event than it could have been. 

     Finally, this book taught me that finishing something is a task I am capable of. That this isn’t just going to be difference machines all the way down. That dropping something for a week doesn’t mean I can never touch it again and if I want to, it has to be a reset. This understanding has been a long time in the coming, and I think it has finally lodged itself far enough into my head that it’s stuck. Thank god. I highly recommend this text for anyone who is looking to grow their technological capability, and if they need help, reach out, to me or to the authors. Flourish in this virus infused lag time.