Brent Simmons, Reason Number 33,483 to Hate Programming:

Or I could have the superclass expose the appIsTerminating property in its header file, so that the subclass could see it. This also sucks, because a controller class has no business exposing its own copy of global application state.

In the end, though, that’s what I did. (Along with a comment that the property was there for subclasses.)

It reminds me that there are two competing values:

1. Do everything the right way every time.

2. Make responsible and professional decisions about time and expenses and benefits and drawbacks.

My nature is to take path #1. It is so hard for me to take path #2. I have the utmost respect who can work on sprawling, modern software and stay on path #2. But path #1, always pulling me in and sending me down rabbit holes.

Sometimes I wonder which of these paths got me to where I am in my career. Others, I wonder if I think I’m a everything-the-right-way person but really I’m a responsible-and-professional-tradeoffs person.

A brain’s a weird place to live.

By unscientific survey, I think many developers would prefer to work in a “framework world” where many decisions of principle and organization are passed down by a vendor or architecture team. Think Rails/Django/Laravel for backends, Ember/Elm for frontends, Unity for games. These are the Framework people.

Fewer developers would prefer to create their own world, building up tools and libraries to suit. They select a few first principles and build their own world. They’re the bebop jazz musician, eschewing big band gigs and music people can dance to to create their own intellectual world. These are the Library people.

I’m a Framework person. The allure of Library people sometimes tempts me after I look at a beautifully-restored car or a well-structured song. But constructing a library world is thankless and not particularly high leverage, unless you succeed in creating something for framework people. Weird, eh?

Nearly fourteen years ago, I graduated college and found my first full-time, non-apprentice-y job writing code. When I wrote code, these were the sorts of things I worried about:

• Where is the code I should change?
• Is this the right change?
• What are the database tables I need to manipulate?
• Who should I talk to before I put this code in production?

Today, I know a lot more things. I did some things right and a lot of things wrong. Now when I write code, these are the sorts of things I worry about:

• Am I backing myself into a corner by writing this?
• Why was the code I’m looking at written this way and what strategy should I use to change it?
• Will this code I just wrote be easy to understand and modify the next time I see it? When a teammate sees it?
• Should I try to improve this code’s design or performance more, or ship it?

Half of those concerns are about empathy. They’re only a sampling of all the things I’ve learned I should care about as I write code, but I think the ratio holds up. As I get better and better at programming, as my career proceeds, I need more empathy towards my future self and my teammates.

Further, that empathy needs to extend towards those who are less experienced or haven’t learned the precise things I’ve learned. What works for me, the solutions that are obvious to me, the problems to steer clear of, none of that is in someone else’s head. I can’t give them a book, wait three weeks, and expect them to share my strengths and wisdoms.

That means, when I advise those who listen or steer a team that allows me to steer it, I have to make two camps happy. On one hand, I have to make a decision that is true to what I think is important and prudent. On the other hand, I have to lay out guidelines that lead the listener or teammate towards what I think is important or prudent without micromanagement, strict rules, and other forms of negative reinforcement.

It’s so easy, for me, to just hope that everyone is like me and work under that assumption. But it’s much better, and highly worthwhile, to figure out how to help friends and teammates to level up on their own. It requires a whole lot of empathy, and the discipline to use it instead of impatience. Worth it.

Copypasta. It’s the worst. “I need something like this code here, I’ll just drop it over there where I need it. Maybe change a few things.” Only you can prevent headdesks!

It’s not really possible, in my experience, to make it easier to use code through methods and functions than to just copy what you need and start changing it. No amount of encapsulation or patterns is easier than a pasteboard.

Perhaps, copypasta’s natural predator is a well-informed code review. There are tools, like flay, that can detect some kinds of code duplication.

But for the most part, it’s a battle of dilligence.

(Ed. I found this in my draft folder from four years ago. Copypasta; copypasta never changes.)

A problem with double/stub/mock libraries is that they don’t often fail in a total manner. They don’t snap like a pencil when they’re used improperly. Instead, when you use them unwisely, they lay in waiting. At an inopportune time, they leap out.

Change an internal API method name or argument list and your poorly conceived doubles will moan. Rearrange the relationship between classes, and your overly-specific stubs won’t work anymore.

At some point, I felt pretty handy with mocks. Then I wrote a bunch of brittle mocks and decided I needed to go back to square one. I’m through the “just avoid mocks” phase, and now I use them sparingly.

Favor a better API in the code under test, then hand-coded fakes, then stubbed out methods, before finally falling back to a mock. Someone, possibly yourself, will thank you later.

There was an extension point, but I missed it.

I was adding functionality to a class. I needed to add something that seemed a little different, but not too far afield, from what the existing code was doing. So I came up with a good name, wrote a method, and went about my day.

A few weeks later, trying to understand an obscure path through this particular class, I found the extension point I should have been using. On one hand, eureka! On the other hand, why didn’t I notice this in the first place?

Did I not consider the open/closed principle enough? Perhaps my “modification” sense should have tingled, sending me to create a new object to encapsulate the behavior with.

Was the extension point hidden by indirection? Perhaps the change going into an ActiveRecord model through me off; I was doing as you’d normally do in a model. I wasn’t expecting another layer of abstraction.

Were my changes too scattered amongst many files? I had modifications in a half-dozen files, plus their tests. It’s possible I was juggling too many things.

Probably it’s all of these things. Lesson learned: when I get to feeling clever and add a handy extension point to make the next person’s job easier, advertise that extension point and make it clear this is probably where they want to make their change.