Get Paid For the Code You Don’t Write

Do the Right Thing

It’s always interesting to write about the newest coding language or platform, focus on the software side of new wearables, or check out the latest “shiny thing.” There’s nothing wrong with looking ahead to see what the next big thing might be and prepare for what clients may be asking for. But once in a while it’s good to also think about the basic coding best practices software developers follow, no matter what platform or language we use. Some fundamental rules and practices apply across the board and it’s good to take a moment and make sure we follow them as often as possible.

Success Inverted

Often people will say they’re successful in terms of what they DO. Such as, “I was able to improve productivity 50%,” “I was able to reduce caller wait time by 20 seconds,” etc.. But another way to look at success is by focusing on the bad things you DON’T do.

Chris Rock once said, “I don’t get paid for the jokes I tell, I get paid for the jokes I don’t tell.” Meaning that in preparing for a comedy special, he’d spend weeks on the road finding out what jokes work and what jokes don’t.

Mario Batalli said the same thing about “the food I don’t serve.” His years of training and practical experience ensures he doesn’t serve bad food and consistently delivers good dishes, in a consistent and reproducible way.

The Code You Don’t Write

As software developers, we focus on writing good code, following best practices and using frameworks, etc. to help us be more efficient. This is what we DO. Another aspect of developing quality code is to occasionally focus on what we DON’T do.

• Don’t copy/paste the same code over and over.
• Don’t reinvent the wheel and write code that’s fully tested in a framework.
• Don’t use crazy abbreviated variable names that are hard to understand.
• Don’t use ten levels of indented conditional code that’s hard to maintain.
• Don’t think a project is too small to follow good coding standards.

Always Follow the Rules

It’s easy to fall into a scenario where you think you’re just writing throw-away code, so who cares how bad it is? Or you’re just trying to prove out how something works.

Unless I’m just testing out a function that takes fewer than 10 lines of code, I try to follow good coding techniques, even on personal pet projects or a simple POC for “official” purposes. Frequently, the work you put into something you think is going to be thrown away ends up being the starting point for a client engagement.

I also use git for any software I write over 10 lines. Often you think something is going to be minor, but it keeps growing and growing. Using (at least) a local version of git and doing commits at smart points lets you backtrack to a working version of your code if things go off the rails.

Coding Best Practices Exist for a Reason

About six months ago I started writing code to build up a small framework for a new technology I wanted to experiment with. Nobody was going to look at my code, do code reviews on it, or even know about it since it was more of a personal growth project. But I still followed the rules and tried to write well-structured code that would encourage reuse across the board, used libraries instead of writing functions from scratch, included common functionality from a single point in the codebase, etc.

As the project grew, I found that by following the rules—using small functions as building blocks I could string together as needed—I was able to accomplish quite a lot, quickly. In the end, writing well-structured, reusable code actually makes a developer’s life easier. These aren’t just rules for the sake of rules. Following these rules results in better code and makes everything else go more smoothly. Take care of the bits and the bytes take care of themselves.

As it turns out, my little pet project grew into a nice utility that will be used by one of our clients. All the work I put into it over the past months, and all the bad things I DIDN’T do, made it easy to transition my pet project into an official utility that conformed to company coding standards. And I didn’t have to endure a time-consuming refactoring since I was able to use my existing code (with some small tweaks).

When you’re ready to explore new opportunities, tackle an existing issue, or need to refresh an application or an entire digital multi-channel ecosystem, please don’t hesitate to give Anexinet a call. We’ll impress you by the things we DON’T do as much as the things we DO.