Book: The Pragmatic Programmer: From Journeyman to Master
Author: Andrew Hunt and David Thomas
When you accept responsibility for an outcome expect to be held accountable for it. Make plans for the risks and if things don’t work out provide options to salvage the situation rather than provide excuses.
Don’t leave “broken windows” in your code. Fix them as soon as they are discovered or board them up. People who find themselves on projects with pristine code are less likely to make a mess or go against the grain with code that doesn’t fit the standard.
It can be better to show people a glimpse of the future then try to lead them to it directly. If you’ve got a great idea it might be worth subtly nudging a discussion focusing on the problem and letting others come to your same conclusion.
All systems must meet users requirements but user should be given an opportunity to decide when software is good enough. Great software today is preferable to perfect software in the future for many customers.
Treat your programming knowledge like a portfolio; invest, diversify, manage risk, review and rebalance. Learn new languages and find other ways to broaden your knowledge.
Every piece of knowledge must have a single and unambiguous authoritative representation within the system. Don’t repeat yourself. Don’t have multiple constants referring to the same thing, or multiple functions which calculate the same result. Don’t cache values until it’s optimization time, and then have systems that verify the cached results.
Keep dependencies between systems minimal.
Tracer bullet programming involves making many small steps to try to hit your target. Not the same as prototyping – you should intend to keep the code. Don’t always expect to hit your target the first time. Don’t spend months of time calculating the trajectory, determining wind speed, lining up the shot. Make small iterative adjustments to get your code closer to its goal.
The ability to accurately estimate project timeline is really important.
There are a lot of advantages to keeping your data in plain text format. Don’t underestimate human readability for maintenance and debugging. Other formats can be used at optimization time.
Be familiar with the shell commands.
Be very familiar with your IDE and ways it can save you time.
Always use source control.
Embrace the fact that debugging is just problem solving and attack it as such. It’s not a blame game.
More to come later…