Words of affirmation = Use criticism for inspiration
Compilers and interpreters seem to love telling us that things don’t work. This “feedback” can be extremely persuasive when it comes to squashing innovation. But it can also create a canvas for us to craft a new solution. Instead of getting discouraged when we start throwing errors the way black belts in Judo toss their sparring partners, take the opportunity to remake it into something great. Maybe that means making your intentions clearer in the code, or reworking your approach to a hard problem, but it’s a chance to make things better.
Here’s a tip: I have found that I often have to do the most “explaining” when my own thinking is flawed. Ideally, our code should be able to tell its own story without us having to explain it. Challenge yourself by writing code that you could almost read as if it were telling a story.
Quality time = Spend the time to properly curate your code
Time is often considered our most valuable commodity. New Relic founder and CEO Lew Cirne likes to say “life is too short for bad software.” So how do we make the most of our programming time? The short answer is to passionately pursue our software and choose to make it better. More specifically, instead of chasing the latest edgy tech, challenge yourself to spend time on automating pain points or reworking a nagging bit of code. Refactoring, measuring, and monitoring your applications is how you create quality time for your users.
“Life is too shor for bad software” Lew Cirne
Receiving gifts = Deliver your code early, and don’t stop giving new features and performance
My pile of GitHub rubble is full of projects that I didn’t get in front of users early enough—many remain unfinished doing no one any good. I’m not alone: Some of the most grandiose fumbles in software came from too much pointless fine tuning before getting some real-world feedback. The ironically named Duke Nukem Forever, for example, endured years of constant tinkering and was left unfinished until another studio picked it up.
Instead, focus on delivering a Minimum Viable Product (MVP) to your users as soon as you can. Done right with the proper expectations, an MVP can delight users and get you the feedback you need to address issues before they hit production. But don’t stop there: Things like supportability, performance, and reliability can all be seen as gifts to your users as well.
Acts of service = Contribute to open source
Service to others is rarely measured by time spent or the effort invested; rather it’s measured by the impact you had. One of the best ways for software developers to have an impact is by contributing to open source software projects. You can give a little or a lot and still make an impact. Best of all, the impact can extend far past the project you’re working on. Open source ideals, behaviors, and approaches will inevitably leak into your own software and eventually benefit users as well.
Committing to open source helps keep you in the “getting to know you” mindset of the exciting, early part of a relationship. Most of us who contribute to open source make a consistent effort to ensure we have plenty of test coverage, that we fully understand the impact of our changes, that our contributions are clearly communicated and documented, and that the software performs well afterward. We do this out of respect for the people collectively trying to make something great. We should learn to do the same for our own software.
Getting started with open source is just a click or two away. It helps to begin by finding something you are really interested in. I was recently introduced to an open source project called Code Combat that teaches people how to write code using a really cool approach to reduce barriers to entry.
Physical interaction = Go back and touch your code regularly
When was the last time you grepped your code for “todo”, “bug” and “needs to be refactored?” Just like a loved one, your software needs your regular touch, too.
Our applications are not static because the people who use them are ever changing. If you have an old cron job running for years, odds are that when it eventually breaks (and it will) no one will know how to fix it, even if they read the support documentation that was originally written on a papyrus scroll.
The old adage “we’ll get back to this later” usually turns out to mean you’ll never look at it again. To maintain your relationship with your code, make an active choice to rework, update, or add to the things you need to change. You’re wasting mental capital on it anyway, why not use that energy to actually fix it?
Love and coding may not share a lot of similarities, but in both areas taking the time to pay careful attention can go a long way toward creating success.