Interview of SOLID Principles

June 17, 2020

I recently did an interview with local DC dev community Hatchpad about the dangers of blindly applying patterns, and how not-helpful the SOLID principles are.

One thing mentioned that isn’t in the SOLID book is that we all need to understand not just the advice we’re given, but who is giving it. What is the actual experience of the person telling us how we should code?

If someone is giving out advice I want to know – “Have you done that? Have you experienced this problem, or is it just theoretical?”

I try very hard to only give advice based on my actual experience, and I try to contexutalize that experience as much as I can to avoid it being mis-applied. It’s not easy and I don’t always do a great job, but I’m very aware of it. Even if my advice boils down to “it worked for me, anyway”, that’s better than “I haven’t tried it, but it seems neat”.

Names matter

June 11, 2020

Names of things matter. How we react to the realization that some names of some things offend some people is important. Unlike the names of countries, towns, or Army forts, computer software can actually be renamed relatively easily, yet we still struggle to have even basic conversations about it.

I want to share the way I think about it: acknowledge a person’s feelings, understand who might feel excluded by a name, decide if excluding them is OK, and, if not, figure out how to change the name.

Docker on Mac for Development with Fast Disk Access and Webpack Dev Server

May 13, 2020

I am somewhat obsessed with clean, repeatable, maintainable dev environments and Docker has all the pieces to create one. For the past several months on several projects, I’ve been using Docker (and docker-compose) to not only run services like Postgres and Redis, but also as a virtual machine in which to run all my dev commands. My Mac is only running Docker and vim.

The problem is that Docker on Mac has very slow file system access. Running bin/rails server on a fresh Rails app can take almost a minute to come up. I recently discovered that, by using NFS, file system access is way faster. This creates a bit of a problem for webpack-dev-server, but this, too, can be fixed. I want to write out what I did in case it’s helpful.

The One Strategy for Working Remotely

March 12, 2020

I worked remotely for Stitch Fix for six and a half years, originally as an engineer, then as a manager, director, technical project manager and architect. With all the tips and tricks going around, I want to talk about the one strategy to be successful working remotely. This strategy should be the basis for everything you do, and any productivity hacks that don’t roll up to this strategy should be set aside. The strategy is to build and cultivate trust.

The Law of Demeter Creates More Problems Than It Solves

January 22, 2020

Most developers, when invoking the “Law of Demeter” or when pointing out a “Demeter Violation”, do so when a line of code has more than one dot: person.address.country.code. Like the near-pointless SOLID Principles, Demeter, too, suffers from making a vague claim that drives developers to myopically unhelpful behavior.

SOLID is not Solid: The Book

January 14, 2020

As of now, you can buy my new 70-page snarky take on the SOLID Principles (containing all new material, I swear) for just $4.99 with code NDNOTSOLID. It was originally a re-packaging of the five posts I wrote last year, but I decided to rewrite the entire thing in the snarkiest way possible in a book called “SOLID is not Solid: Five Object-Oriented Principles to Create a Codebase Everyone will Hate”:

Do you know what I had to do to write and publish this? The hardest part was figuring out how to change fonts in LaTeX. 20 years ago the hardest part would’ve been to find a publisher and decide to be OK with a 10% royalty rate. Today, I don’t need anyone’s permission to make a book. On paper!

It turns out that almost everything you’ve been told about how to design software went through the same vetting process (by which I mean learning LaTeX).

There’s also a chapter of six quick takedowns of some of Agile’s silliest catch phrases:

“KISS” is often used when code is complex. KISS stands for Keep It Simple Stupid. You know what? I’m not stupid. I’m just not. And neither are you. I don’t need to be insulted in order to discuss code.

Buy it now!, and don’t forget code NDNOTSOLID to get a dollar off at checkout.

Dependency Inversion Principle…is a Tradeoff (SOLID is not solid)

December 02, 2019

As mentioned in the original post, I’m realizing that the SOLID principles are not as…solid as it would seem. In that post, I outlined the problems I see with the Single Responsibility Principle, and in the second, I recommended ignoring the Open/Closed Principle, since it is confusing and most reasonable interpretations give bad advice. In the third post, I talk about how the Liskov Substitution Principle is too narrowly focused on the wrong problem, and doesn’t really give usable design guidance, and the fourth is about how the Interface Segregation Principle isn’t the right way to approach problems with coupling.

Now we get to the last one, the Dependency Inversion Principle, which could also be called “The Reason 2000’s Java is Equated With Writing All Your Code in XML Principle”. The principle says that code should depend on abstractions, not concretions. Because it is a principle, the implication is that all code should depend on abstractions. No. No it should not. Depending on abstractions has a cost which the principle largely ignores. Let’s see how.