Very Fancy

When a programmer refers to two factors as “orthogonal concerns”, it means that a change with regard to one factor doesn’t affect the other. We use the term “orthogonal” to mean something like “independent” or “unrelated”.

For example, domain logic, display logic and persistence logic are generally considered orthogonal concerns. Changing one should not affect the others.

“Orthogonal” traditionally means “perpendicular.” It comes from the Greek words for “upright” and “angle”. Our use of it to mean “independent” seems to come from geometry.

Picture a map, with an east-west axis and a north-south axis. If I travel along one of these axes, it doesn’t affect my location along the other. The axes are orthogonal in both senses we’ve discussed: they’re at literal right angles to each other (perpendicular), and changing my north-south coordinate doesn’t necessarily affect my east-west coordinate (independent).

(As an aside: When I hear a word I don’t know, I tend to look it up. But when you hear “orthogonal” the way programmers use it and look it up, the definitions aren’t very helpful. It’s probably more reliable to use words like “independent” or “unrelated”. Although “orthogonal” sure sounds fancy.)

One of the things we do when we design software is decide how to separate it into modules. For any given program, there are multiple approaches we can take to do this. And it’s an important decision, because it can have far-reaching effects on our ability to grow and maintain the software.

One thing we can use to steer us in the right direction is a simple question: What will change?

If we know some aspect of our program is going to change, we can put that stuff into its own module and hide the details from the other modules. Then, when the change needs to happen, we only need to update the one module. This is how our choice of modules helps with growth and maintenance of the software.

Of course, we don’t know what’s going to change. But we do tend to have some idea about some things that we think are likely to change. We do our best with the information we have. (And we don’t let the possibility of future change lead us to add complexity or make constraining decisions now.)

This approach to choosing our modules is called “information hiding”.

(Extra credit: Information hiding comes from a fairly readable academic paper by David Parnas, published in 1972. Parnas wrote two programs with the same external interface, using two different approaches to select modules. Then he compared the two programs and concluded that the information hiding approach was better.)

Does the work meet your own standards for excellence? Did you make or do the thing well? Are you happy with the work?

Does the work meet the expectations of the people who paid for it? Does it exceed those expectations? Are the customers happy with the work?

Does the work make people’s lives better? Does it make the world a better place? Does it make life even just a little bit nicer for even just one person? Is somebody happier because of the work?

Did the act of doing the work give you pleasure? Was it fun for you? Were you happy while doing the work?

Did the work challenge you? Did you learn something? Did you get better at something? Were you enriched by the work?

If you’re looking for a reason to feel like you could be doing more, check your social media feeds.

Say you spent Sunday afternoon writing a great blog post and you feel pretty good about it. Then you check Twitter and you see what everyone else has been up to:

• Cooked a delicious meal
• Tried a cool new restaurant
• Got a new job
• Went to the movies
• Finished a 1,000-page novel
• Took an online course and learned something interesting
• Celebrated a child’s first birthday
• Ran a marathon
• Announced a pregnancy
• Spent the day hiking with a cute new significant other
• Ran a 5K for the first time
• Learned the basics of a new programming language
• Painted their bathroom
• Painted a portrait
• Planted a garden
• Won a soccer match
• Shared a hilarious joke
• Toured a foreign city and posted beautiful photos
• Had a talk accepted at a conference
• Saw the new baby giraffe at the zoo
• Volunteered at a soup kitchen
• Got retweeted by a celebrity
• Found a rare craft beer
• Wrote a great blog post

We forget that social media tends to be everyone else’s highlight reel. We compare our average to the sum of our friends’ highs. There’s no way we can come out looking good in that equation.

The solution to this is perspective: Remember that the comparison isn’t valid. The math doesn’t work. When we let our happiness hinge on how we compare to others, we can’t possibly win.

Features are the things your product does. The ways it can be used.

Benefits are the things your product can do for somebody. The results of using it.

This is a fine distinction but it’s a powerful one. Technical folks tend not to think about the difference. When you’re building the thing, you focus on the properties of the thing.

But when you’re selling the thing, you focus on the reasons someone would want the thing. Customers don’t care about the features of your product. They care about the benefits it can bring them.

We learn about imperative and declarative sentences in English class:

This is imperative: “Make a pie.” Imperative sentences give orders.

This is declarative: “A pie has a crust and some filling.” Declarative sentences state information.

We can think of code this way, too:

Imperative means I’m giving the computer orders, a series of steps to complete.

Declarative means I’m giving the computer information, defining rules and logic.

Of course, making the computer do anything useful tends to require rules and logic and a series of steps to follow to apply those rules. We need both kinds of code.

But when we design our software, we can choose to separate the two kinds of code. We can write declarative code for the rules and imperative code for the steps.

Why would we want to do that? Because when we need to read or to change or to test our code, it’s way easier with a rule than with a series of steps.

We say we’re taking on technical debt when we compromise on software quality to meet a deadline.

Just like with real debt, sometimes taking on technical debt is the best thing to do in a given situation. Sometimes short term needs win.

But we need to be aware of this decision. We have to be conscious of the trade-offs involved and make an informed decision to take on the debt. We should think of the decision as a short-term move and actually intend to pay the debt back down as soon as possible.

Here’s a way to help with this: Every sprint, as a part of your review/retrospective/whatever, set aside time to discuss any technical debt you incurred to meet the sprint’s goals. (If you’re not doing sprints, you can still schedule this activity at intervals.)

Building tech debt review and tracking into your system will help you stay aware of it. Reminders to think about the debt become reminders to stay on top of it, to keep it paid down.

And if you’re not keeping track of your debt, maybe you shouldn’t be thinking of it as debt. Maybe you’re just making a mess.

I made it a goal recently to write for five minutes a day. I’m four days into this as I write this, and I’m pleased to report that I’ve written for well over five minutes on all four days. In fact, I’ve written more in four days than I did in the previous four months. It’s great. (It’s reminded me that I actually like the act of writing, I don’t just like having written.)

This is a way to fight procrastination: Start small. Decide you’re going to work on the thing for an absurdly short amount of time. Once you get started, working more is easier.

It’s much easier to get from minute one to minute two than from nothing to minute one.

Start small so that you’ll start at all.

I’ve read lots of great books in the last few years. And when I go back and look at my highlights, I almost always find something that makes me think, “Damn, I wish I could remember this when it matters.”

Learning a thing means more than just processing the logic of the thing. When I encounter something worth learning, I want to internalize it. I want to make it part of the machinery of me, the stuff that my brain uses to make decisions and reactions.

Just reading rarely accomplishes that. Nor does highlighting. If you want to truly absorb, you need to process the idea. Make time to reflect or apply or discuss it. Chew on it.

Knowledge workers complain about being referred to as “resources”. We don’t want our work to be thought of as a commodity. It’s dehumanizing. And it arouses the fear of being replaced by machines — if work doesn’t require creativity, chances are it can be automated.

So what can we do?

First of all, stop complaining about being called a resource. That doesn’t help. It won’t persuade anyone that you’re more valuable and it won’t make you feel better.

Focus on the value you provide that isn’t a commodity. What do you do that’s creative? Make it clear. Sell it. It’s on you to do that. Nobody’s going to do it for you.