These are the principles I apply when addressing technical challenges. I’m working on being the old guy. I’m trying desperately not to be grouchy as well. I’ve found these principles to optimize efficiency, quality, and happiness. This could have been titled “Measure twice. Cut once.” or “Work smarter not harder.” Take your pick. Hopefully you can benefit from my experience.
Use standard tools in standard ways.
I like being creative just as much as anyone. It’s half of the reason why I like writing software: It’s equally creative and technical. Customizing stuff is fun and challenging. I get it. But there is nothing that will harm your product and organization over the long term more than bespoke systems and tools. Do they solve a problem today and let you flex a little? Sure. But they create overhead that you don’t want tomorrow. They also make onboarding new people nearly impossible. If you find yourself veering too far off the path of a very standard implementation, take a minute to think about what you’re doing and where it’s leading you.
Write the tests.
Good tests with good coverage make us faster, not slower. You know the saying, “A stitch, in time, saves nine”? It took me until I was an adult to realize that there was punctuation in there that would indicate that a little work today saves a lot of work later. It’s true! Tests feel slow in the moment, but they give us confidence when we iterate. Think about your future self and all the other developers that will come after you. They will all be thankful. They will be able to move faster. And the stock options that you exercised will increase in value as the snowball rolls down the hill.
Document. Document. Document.
I know that you think you’ll remember every decision you made along the way. You won’t. And nobody else on your team will understand why you did what you did unless you spell it out. Comments are a wonderful tool. Thorough READMEs are amazing for onboarding. Wikis are good reference material. Take 15 minutes to write it down. It will save hours later.
Not all that glitters is gold.
Be curious, but don’t be enamored with every shiny object. Every new tool that comes out has the potential to solve a problem, but it’s not guaranteed to be better just because it’s new. Keep up with the latest. Wide adoption by the cool kids is a good indicator. But sometimes change isn’t necessary or even beneficial. And sometimes the thing after this one is WAY better.
Write code as a last resort.
You are unique (and awesome). Most of the problems you are solving aren’t, though. Great artists steal. It’s all been done. Why re-invent the solution? I always tell people that I am not a software developer, I am a professional Googler. The vast majority of “my” code is other people’s code that has been slightly modified.
Outsource solved problems.
You need a blog? Great. Medium is great at blogs. So is Wordpress. So are a dozen other solutions. Use them. E-commerce? Same deal. CRM? There are SO MANY decent CRMs. The list goes on… The money you spend on those outsourced solutions will save you so much time (and therefore money) that it’s a no-brainer. The same goes for infrastructure. Stop trying to experience pain that others have already learned from. You get to benefit from their experience at a reasonable cost. Bonus: You’re exempt from maintenance costs and SLAs!
TL;DR
- Use standard tools in standard ways.
- Write the tests.
- Document. Document. Document.
- Not all that glitters is gold.
- Write code as a last resort.
- Outsource solved problems.
What would you add or subtract?
