Readings

My Entrance into Programming

When I was around 12, I bought and read around 100 pages of [C for dummies] and while I found it kind of neat, I decided programming wasn't for me.

It wasn't until modding Oblivion in high school and then Skyrim (se) in college that I really started getting into programming. I went from the form of visual basic used in Oblivion and Skyrim to Java when I wanted to mod FTL. I found a 13 hour video course on programming Java, and shouted out loud twice while working through it, because I was so excited about how much better Java was than the visual basic I had been using.

The year after college I did a one year graduate program that included creating a 'product'. I spent evenings and weekends creating a terrible [starship game] in Java (and Swing!). I loved doing it, and abused basically every anti-pattern you can run into. I had no formal education or mentor to instruct me, and so I continually burnt myself, and learned how painful bad development practices can be.

Reading Fills a Gap

When I discovered Clean Code, it was a revelation. His advice seemed extreme, but I could identify with many of the problems he listed, and getting to hear someone explain guidelines and why something was dangerous or a better alternative was wonderful. I ended up reading the book again in my first job as a developer and found it more agreeable; to this day I recommend it to new developers. (I read The Pragmatic Programmer much later. While it's heavily recommended along side Clean Code by many experienced developers, I found it to be really dated at this point (It spends a chapter on setting up a good IDE, like the new Vim).)

Reading Clean Code made me realize the importance of supplementing hands on experience with books. As someone who is self taught, I missed the formal lecture of a boot camp or college computer science degree. While I've found that most of the best developers I have worked with were self taught, I think that there is great value in supplementing that apprentice style learning with formal/academic inquiry. Those focused looks help provide mental frameworks that take intuitive lessons and help you reason about and communicate them to others.

Ever since, I've tried to push myself to always be reading a coding book, a book in an adjacent space (Game Design, UX, Business Leadership, etc) and a fiction book (Sci Fi, comics, fantasy). This generally means I get through books very slowly, but every now nad then I hit a month were I code less and read a lot more. In those early days, I found Effective Java fascinating, and its discussion on generics mind opening. Save the Cat!, while about screenwriting, was a great teacher on user engagement.

I was able to get my company to pay for several game design books (before I was even in software development) including A Theory of Fun (which is a breeze and delight to read) and Game Feel, which formed my early understanding of good UX. Later at the same company I was given The Devops Handbook as part of a reading club. While it felt like 50% marketing to middle management, the other 50% felt like great knowledge and a great set of weapons to fight for a more developer empowered world.

Recent Reading

When I joined one of the software companies I've worked for, it was near the end of the year, and I was given a month to spend (or lose) a $500 discretionary education allowance. After that month, we were told that due to the acquisition, we needed to spend next year's allowance (of the same amount) before February, or again lose it. Aside from the ~$100 I spent on Raspberry PIs, I bought nearly $1,000 of books in just a couple months. To do so, I quickly drained my 'to buy and read list' and then spoke with most of my new teammates to find the books that they had found impactful or that they were purchasing. I bought books like Programming Language Pragmatics, Thinking Fast and Slow, Concepts, Techniques, and Models of Computer Programming, Metaprogramming Elixir, An Introduction to Functional Programming Through Lambda Calculus and Mythical Man-Month all of which I haven't started reading yet. I also bought a book that I had read a couple chapters of in college and having read fully now can say its one of my favorite pieces of academic literature (and a comic at that!): Understanding Comics

It was this perfect storm that created my deep backlog of unread non-fiction, but it also taught me another lesson. If you find a person to be competent, be biased towards buying and reading their book recommendations. A recommended book tells you both more about the person who recommended it, and also hopefully provides value to you like it did for them. Books are more money-cheap than time-cheap and if they're good, they seem almost always worth the investment.

In my final days at one of my companies, there was a good deal of downtime due to acquisition changes, and I had the opportunity to read and study on work time. I was finally able to push through and complete Pro Git. While sometimes reading like a textbook or talking about outdated content, I thought it was generally a great read. The author, who was one of the founders of Github, is genuinely passionate about git, and his enthusiasm comes through to the reader. It was also fantastic to get to spend some time really thinking about and trying to grok how git works. With how often we use git as developers (all day long) I thought it was a great investment, and I hope to spend more time bouncing between using git and reading about it, in order to get better at using that tool. It's a free ebook that I highly recommend.

One of the book recommendations that I got was to read The Art of Unix Programming. This non-secure basic html site felt revelatory to me in a similar way to how Clean Code once felt. After finishing Pro Git, I wanted to jump into this book, but didn't want to just read on my computer. This was the beginning of my Site Crawler, which I used to turn the website into an epub ebook, and have gone on to use to download captures from xbox and old sprite sheets. It's a large book, and can at times drift into content that feels outdated or irrelevant. It spends a good deal of time of unix programs that I don't think I'll ever use. Some chapters felt like a slog. That said, the page on philosophy alone is incredibly worth the read.

The book as a whole gives a fantastic glimpse into the history of software development, and I was amazed at how many problems of today where thought through and solved then, only to be forgotten or not passed down to today's software developers. I've heard that 50% of the people in software today have been there less than 5 years, and that that trend continues due to our explosive growth and change as an industry. I heard at a conference that many of the problems of today were solved in white papers in the 50s and 60s, but they didn't have the computer power back then, and today we're the worst industry at knowing our own past, and so we miss those solutions and re-invent the wheel. It was fascinating to start to fill another gap that I possibly missed in college, and to hear an insider talk about what it was like to be their. It excited me to imagine what it was like, and to think about how we are still in an exiting, pioneering time of our industry. The Philosphy of Unix has helped me start to connect and unify the past and present of our industry, and while I have more holes in my understanding than solid parts, it was a really exciting start.

These days, my subtle code insult is to say "that looks clever", and my highest complement is to say "that seems unixy". I love that they recognized in the 60s that developer time was more expensive than computer time, and so many other fundamental lessons that the bulk of coders wrestle with even today. The disciplined focus on simplicity (humility) over cleverness (arrogance that causes confusion) seems now to me to be a fundamental part of software design, and a useful lens for so many situations. Just as Clean Code had given me a framework to reason about how my code should read, the Philosophy of Unix has given me a framework to think about the design and architecture of my code. It's also interesting to see how much of what we call "Agile" today was called Unix Philosophy then, and how certain behaviors and disciplines have stayed consistent throughout the life of our industry.

Reading Now

These days I'm reading Evil by Design, the mildly horrifying look at how UX manipulates people.

I've started (but am hoping to finish Evil by Design before really focusing on) The Design of Everyday Things per a colleague's recommendation. So far it's been both interesting and seems to be creating a great framework for talking about good design. As part of a small book club at work I'm also reading Accelerate, a sequel of sorts to the Devops Handbook (by most of the same authors). It focuses on how and what to measure to be able to understand and predict developer productivity.

At some point I want to read The Cathedral and the Bazaar a hopefully smaller sibling to the Philosophy of Unix. I also have that massive backlist of programming textbooks to start chipping away at. It's exciting and intimidating to think of all the books laying around waiting to be read, and it's hard to balance work, hobby programming, and then spending more time thinking about that same subject, but I'm convinced it's a worthwhile investment.

Ps. If you're in the mood for a laugh, check out MIT's The Tao of Programming