1 – If you’re going to start something, you have to finish it.
Seems obvious, but managing a project has a typical “long tail” and often ideas are not implemented even though there is significant planning and meeting. “Work” is started from the management perspective, but as the new functionality or change is not implemented (due to the various spikes that inevitably arise) many times it simply dies out. When you’re fixing or writing new code however, leaving something unfinished or for later means leaving the stream of consciousness that you had while working on it, making it harder to resume work. Often this leads to unstable or unusable code or at the very least adding to the pile of technical debt.
2 – Bugs are inevitable. Test early and often to know about them.
Yes people say it all the time, “there will always be a few bugs” so the key is to know what they are and be comfortable with them. Discovering a bug after go-live has high visibility, everyone is wondering how did that bug get there? Didn’t they think this would happen? In most cases (I cant think of any where this is not true) you’ll want to have anticipated the issue and planned for it. There will always be a new version.
3 – Limit the number of possible code execution paths and dependencies.
This isn’t just for performance and scalability of the application, its for YOUR performance and scalability while working on it. As a developer, you have at any one time several things to remember – the function that is receiving the callback, the function parameters needed for the query, the loop count inside a closure, etc. Make it easier on yourself and compartmentalize as much as you can. You’re not less of a good developer or “smart” because the code you write is simple – quite the opposite, it means you can write more code that does more things – which is what most people think good developers are good at.
4 – Estimation, the black art.
Having been both a product manager and a developer, I can honestly say estimation of work is a real pain. As a PM I was generally cautious about estimates I was given for a determined outcome. As a PM I was generally apprehensive about giving estimates based on estimates I had been given, and would more often go with my gut. But what if you have no “gut” because you have no experience with the product and its development?
This is the same when you’re a developer. Now I know I know, not all developers, but many. You simply can’t ALWAYS tell the truth because “I dont know” isn’t good enough. The problem then is when you DO know the truth, and have to wonder if the PM/BA/QA/CTO is now believing you.
Don’t let it become a game of “hide the pea” – be 100% honest on every single estimate and when you don’t know you let them know you’ll have to find out more. That goes for everyone in the organization, and it is a property of company culture that must come down from C-Level execs. Trust each other and don’t fudge.