Maxims to Code By

This February I went ice climbing up in Bozeman Montana. While I was there I visited my friend Mark. We drove around Yellowstone, which is a very interesting place in the winter. When we got back, we were hanging out in his office, talking about LabVIEW. He proudly pointed to a sticky note on his monitor. It said "Be Kind to Your Future Self". He said he looks at that everyday. It is his reminder to think about how he can make decisions today that will make his life easier in the future.

This encounter with Mark, reminded me  that there are several phrases that I tend to repeat to myself often. I thought throwing up a sticky note on my monitor would be a great reminder. But I couldn't limit myself to just one, so I came up with a handful. Each day I pick one and try to focus on that for the day. Here they are in no particular order. I'll attribute them to people as I can, some of them I can't remember where I picked them up from. If you know where they came from, let me know and I'll make sure to add the attributions.

Be Kind to Your Future Self

I attribute this one to Fab. I don't if she came up with it herself or borrowed it, but she's definitely the first person I heard use the phrase. As I mentioned above it's a reminder to think about the person who is going to have to maintain your code. It's a call to make their life easier. This embodies things like writing clean, well-documented code, writing tests, and making things easier to debug. It's worded as "Be kind to your future self", because that is more motivating than be kind to some stranger you may never meet. There is also a very good chance, that you will be the one maintaining your own code in the future.

Production First

This one came from a podcast episode. I don't remember which one. Basically the idea is to always treat every project from the beginning as if it is already in production. I've also heard Fab talk about Tracer Rounds, an idea she picked up from the Pragmatic Programmer, which is very similar. The idea is that first thing you should do is deploy your project, even if it just to say hello world. This goes further to automating builds and tests. One of the first things I do is set up CI and some tests and automated build system. I've got some articles about that here. It's laying the foundation for everything that is to come. This phrase just reminds me to adopt that mindset.

Red Green Refactor

This is just the basic Test Driven Development (TDD) Loop. It's just to remind me to always write the test first.  Sometimes its tempting to just write a little code first so I need a little reminder to slow down and do things in the right order. Sometimes I also try to skip writing tests by rationalizing that this code is too hard to test, but then I look at this and it's a reminder I need to revisit my design. It's also a reminder to not forget the refactoring step. Sometimes I get so excited, that the test finally passed, I'm like "OK I'm done." This is just a reminder that I'm not quite done yet. It's also a reminder to just do enough to make the test pass and avoid adding unnecessary features and over complicating things.

Test Commit or Revert

A related phrase that I also really like is TCR - Test Commit or Revert from Kent Beck. Write the test and some code intended to make it pass. Then run the test. If the test passes commit the code, otherwise revert it all and try again. It's just a reminder that if I try something and it doesn't work I can just throw it away and start over. I've noticed that prior to adopting this, I used to spend a lot of time debugging. Most of it was chasing down the bug. Now I don't bother. I just revert. It is very freeing.

Many More Much Small Steps

This, from GeePaw Hill, is one my favorite sayings. There are so many benefits to taking smaller steps. I'm not even going to begin getting into it here, because GeePaw does such a great job of explaining it. Let's just say out of all these sayings, this one has had the biggest influence on my development style. I'm constantly trying to figure out how to take smaller steps. I've seen so many benefits from it. Also its not just for software development, but for change harvesting (that's GeePaw's term) as well. Change doesn't happen as a big bang, but rather a series of small changes.

Favor Faster Feedback

I also picked up this phrase from a podcast. It fits really well with the Many More Much Smaller Steps. It's also more than that. It's about figuring out how to get things in front of the customer as quickly as possible. So it's taking smaller steps, but it's also production first and having a CD pipeline setup so it's easy to make releases. It's also about streamlining the tests and CD pipeline as well. It's about making decisions throughout the process that lead to faster feedback.

Make the change easy, then make the easy change

This Kent Beck quote is really powerful. What he's saying is that if you have to make a big change, think about what would make that change easier. Generally that is some kind of refactoring. As an example, say you want to swap out one DMM or oscilloscope for another. The easy way would be if you could just create a child class. Maybe your code isn't using classes, so the first step would be to refactor the code so that it does use a DMM class. That is making the change easy. Then the next step is to create that child class. That is the easy change.

The Simplest Thing that might possibly work.

I don't know where I picked this one up. It's been said a lot. I know Amitai mentions regularly on his podcast. The idea is that as software engineers we often over complicate things. This phrase is about avoiding that temptation. Don't immediately start adding features. Start with the most basic features and see if that works. In that way this phrase is also about experimentation as opposed to Big Design Up Front (BDUF). Don't try to account for everything. Account for the most important things and then see what happens.

What about you?

Do you have a maxim that you use? Throw it in the comments.