Sometimes the brunt of my education of developers is a constant reminder to be nice to the future them. Future you, or Drunk You if you’re Otto, loves you most when you take the time to prepare things for them. A little bit go foresight and planning will make life so much better for future you, and I’m going to break down six tips to make you love yourself in the future.
Document, Document, Document
Yes. Document everything. Did you make an API for your system? Document it somewhere everyone can get to. For my LezWatch TV project, I painstakingly documented out all of that, plus how the git repositories worked, how they deploy code, and how to get access. This is for something that two people work on. But by documenting it, we all know what to do! The better my documentation, the less likely I get a panicked message from my cohorts in crime.
Make Good Commit Messages
I’m terrible at this when it’s for personal use (the number of commits that are ‘I am stupid’ cannot be counted), but at work I’m pathological about a good subject and a descriptive summary. I want someone down the road to know what the patch does, but also why I did it.
icons: Add new icon set
Add 17 new icons from LIBRARY. This adds support for iconography with job descriptions, as well as better defaults for taxonomies and categories.
It’s not complicated, but it’s helpful when someone wonders “When did we add those new icons?”
Inline Document Weird Stuff
One of my coworkers is great at this. Ben litters his code commits with them, and I’m sure some people find them annoying but I see them as helpful and amusing. Sometimes he puts in “I hate that we do this, but I needed to pass X.” That tells me two things: First, this code could be better. But second, I know what he’s trying to do and generally why. He’s given context to the situation, and future us will hopefully be able to make this better.
Make Note of To-Do Items
Another great habit is to put in notes, as inline comments sure, but also in the documentation. I’ve been using Trello in addition to inline comments (usually things like “To Do: Add in a check for foobar”) to make sure that my future plan is known. You want to make sure future you knows where you were going, and those to-dos are your sticky notes.
Follow Existing Project Standards
Okay. I hate this one. But. If your project has a standard, keep using it. The other day I ran into a problem where a new version feature wasn’t behaving the same way as the old one, but only in very specific situations. I walked backwards through the code until I determined a parameter didn’t exist on the new version. I had two options. One was to edit the code to check “If this new version, also…” and the other was to add the parameter to the 500 or so impacted items and then fix my code so it was always fixed going forward.
The project had been using the parameter method for years, so that was my solution. It followed the standards.
If You Have A Plan, Use It
This sounds weird, doesn’t it? It came up when I was reviewing a plugin and noticed that some code looked very ‘generic’ while still being specific. I thought that it had to be a library the company had made for themselves, and asked if that was the case. I explained, if it was an original library they planned to reuse, they should use an if-exists check.
What Are Your Tips?
What tips do you have to make life better for future you?