A long time ago in a far away land (9 years and 1500 miles to be exact), I got my first full-time job in the technology industry. I was fresh out of college with an excellent education and lots of experience building and fixing home computers while running a small business out of my home office. I had almost no experience writing code for clients. Luckily the company who hired me trusted me to learn how to do what I was doing while I was doing it, which was a very lucky opportunity. I quickly became the lead programmer and director of technology.
The main goal in my first position was to ship client projects. There were no code reviews, no distinguished set of coding standards, no internal library or framework. Just me, the features, and the deadlines. Each project evolved on it’s own without too much consistency. I became really good and getting things done fast and hitting deadlines. I’m slightly embarrassed to admit that the code quality was sub par at best.
My next position was strictly for programming. My first project was a large WordPress plugin which was tailored to a client’s needs but was also going to be offered as a product after completion. I worked with the CEO of the company as my project manager who started the project by saying, “Code like you are going to be presenting the code at a WordCamp”. This statement set the tone for everything I wrote for that company for the next few years. Every feature I worked on was code reviewed, written with industry best practices, followed set patterns, was profiled for performance, etc. I wrote every line of code like I was going to be representing the company to the world.
It was not until many months after I left the company that I learned the statement, “Code like you are going to be presenting the code at a WordCamp” only applied to that project because it was going to be a product. The rest of the time, what they actually wanted was me to focus on getting things done on time and not focus on perfection. Whoops……
This realization got me thinking, “Am I spending too much time on perfection for one-time use code?” I set out on a mission to find the answer…
After mass research and data collection during actual projects, I concluded that I am spending too much time on perfection and not completing as many projects and I should be. I also concluded that perfect code does not actually have a benefit when writing one-time use code. As long as the code is clean, organized, performant, and follows a standard pattern, it is just a easy to extend later as perfect code.
I came up with the following rules to implement what I learned:
- When working on a framework or mass used plugin, always over-engineer it.
- The code should be perfect.
- 100% unit test code coverage.
- Follow patterns exactly.
- Code must be self documenting and extendable.
- When working on a personal project or a project for fun, over-engineer it.
- Try new things.
- Explore new tools and frameworks.
- Build A/B testing.
- Code with re-use in mind.
- When working on a project with a deadline, under-engineer it.
- Re-use existing frameworks.
- If you can’t extend the framework to meet your needs, make a note of it for later, and fork it.
- Only document non-intuitive code.
- Skip unit tests in favor of integration tests and only test complex data interactive pieces.
The main takeaway here is that you use personal time to enhance your tools and frameworks. That way when it comes time to ship a client project your tools and frameworks are at their best. By over-engineering your tools you increase the chance they may be used as is for client projects. By making notes of areas they may be approved and not getting side tracked during the project, you increase your focus time for the task at hand which improves efficiency for both items.
My data collection from a three month sample, suggests an increase in efficiency of approximately 30% using these new practices. I’m still completing projects on time, contributing to open source, shipping more plugin features than ever, all while working less time than before. I have also seen a slight improvement in server performance (which may just indicate an improvement in my coding skills which is natural with experience).