Here’s where I keep a list of recommended media around leveling up as a programmer. This list was originally put together after I had taught a class at Gusto during the summer of 2017 for a handful of new hires.

The material recommended is great for those just getting off the ground in their career, and are first learning Rails and React.

Simple Made Easy (URL) [Free]

This talk is one of the most concise explanations of why keeping things simple matters. It also provides a few tactics and smell tests for keeping your code simple. As an homage to this talk, I’ve been writing a few posts on my blog to explore the topic.

Destroy All Software Screencasts (URL) [$29/month]

Destroy All Software is a site maintained by Gary Bernhardt. The screencasts might appear to be as if you’re paying to watch someone show off how good they are VIM, but Gary covers a lot of topics in depth but in quick screencasts.

If you’ve ever looked for an honest comparison of Python vs. Ruby packaging, some of the pros and cons of different testing styles, or other knowledge that you won’t find in a blog post or book, these screencasts are well worth the $29/month price tag.

Functional Core, Imperative Shell a.k.a. the Boundaries Talk (URL) [Free]

Functional Core, Imperative Shell is a design pattern designed to reduce the places in which your code inflicts side effects or performs imperative operations. The goal is to push as much of the business or domain logic into a functional and pure part of the code.

Functional Core, Imperative Shell (FCIS) is in some ways similar to the CommandQueryResponsibilitySegregation (CQRS) pattern.

The promise of FCIS is to be a general-purpose pattern for creating easily-testable and highly-maintainable code.

How to Write a Git Commit Message (URL) [Free]

We know that we should eat our vegetables, and we know that we should write good commit messages. But why?

This blog post covers some suggested best practices around git commit messages and specifically the Why’s of each reason.

_why’s Poignant Guide to Ruby (URL) [Free]

“why the lucky stiff” or “_why” is an enigma and was an early part of the Ruby and young Rails community in the mid-00’s. His “poignant guide to Ruby” remains of the silliest and most illustrated books on a programming language to date.

This book is what got the dear author of this document into Ruby in the first place.

Professor Frisby’s Mostly Adequate Guide to Functional Programming (URL) [Free]

In the spirit of _why’s treatise on Ruby is this nice little guide to functional programming using a familiar language: JavaScript. It’s a great crash course into some of the simple and more advanced concepts around functional programming.

Extreme Programming Explained: Embrace Change, Kent Beck (Amazon) [$39]

Although Extreme Programming (XP) was a radical paradigm shift at the time, many of the ideas are at present “in the water” of much of software development.

XP is all about letting programmers do their best work, and involving stakeholders in their process constantly. It prefers smaller, more iterative development cycles with continuous delivery instead of waterfall-style methods of delivery.

This is a relatively quick read (224 pages with large font) on the human side of programming. If you’re still not sold, read my book review.

Practical Object-Oriented Design in Ruby, Sandi Metz (Amazon) [$35]

This book, often referred to as “POODR,” is a slim book that covers Ruby succinctly. Recommended for those wondering why Ruby embraces things like message passing, metaprogramming, and duck typing.

Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin (Amazon) [$33]

Clean Code provides some general purpose styling to create clean code in any programming language. The book itself is a large collection of opinions on what makes for better code. Robert Martin (a.k.a. “Uncle Bob”) nonetheless provides grounded thinking behind each opinion.

Learn You a Haskell (URL) [Free]

Learn You a Haskell is an online book that feels like an echo to _why’s Poignant Guide to Ruby.

Why learn Haskell? I don’t think of Haskell as a particular useful production language, but it is a good language to borrow ideas from. Strongly-typed functional languages can make your brain hurt when first learning them, but contain some strong opinions and sane defaults with regards to function purity and data immutability.

Borrowing ideas from Haskell can make your Ruby or JavaScript code much cleaner and safer.

An Introduction to Elm (URL) [Free]

If Haskell is a bit too esoteric for your tastes, give Elm a try. Elm can be a bit more approachable because it transpiles to JavaScript, and can thus be seen in a browser. Elm is known for its helpful (and impossibly cool) error messages.

Many folks that have a hard time wrapping their head around Haskell (myself included) find it easier to grok Elm.

Fun fact: Elm served as an inspiration for the Redux library, which is one of the popular data storage libraries used with React.

Guide to the Phoenix Web Framework, (URL) [Free]

Ever wondered what Rails would be like if it didn’t sometimes suck? Give the Phoenix Framework a spin.

Phoenix is a web framework heavily inspired by Rails by written in the functional language Elixir. Much like the recommendations for learning Haskell and Elm, kicking the tires on Phoenix can be a great way to steal some good ideas to bring back to Rails.

Refactoring: Improving the Design of Existing Code, Martin Fowler (Amazon) [$47]

Refactoring is an important step in all code development. Refactoring means to change the structure of existing code without changing its behavior. Refactoring is an important step in the Test-Driven Development workflow of Red-Green-Refactor. The goal of refactoring is to make code more readable, easier to understand, or easier to change.

Refactoring can only be safely done with a robust test suite in place.

This book serves as a playbook of different refactoring strategies, sometimes referred to as “micro-refactorings” or tactical refactorings.

Working Effectively With Legacy Code, Michael Feathers (Amazon) [$53]

A bit lower-level than most, but this book still serves as a good playbook for safely changing legacy code. Any organization of a certain will have legacy code around, and the question is usually not “How can we prevent legacy code from being written?” but “How can we deal with our existing legacy code?”

Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans (Amazon) [$59]

In many ways, DDD is the book I wished I had read much earlier. In other ways, young engineers might not quite grok the lessons of this book until having spent many years in the industry. The book stays relatively high level and abstract, but cuts to the core of building maintainable, complex systems.

Still not convinced? Check out my book review.