The Software Commandments V2.1

General

Commit to deliver, to help, to learn, and to improve
Be honest, be reliable, and work hard
When you mess up, own up! And LEARN from your mistakes
Don't stay stuck, get help! If you're in a hole, stop digging. If in doubt, ask. Keep asking til you're answered
Communicate! Keep colleagues and customers informed - avoid surprises
Write effectively, speak effectively - keep it short and make it matter to the recipients
Finish your project. Know your deadlines, hit them if you can, shout if you realize you can't
Solve problems, and help others to solve problems too – everyone learns faster that way
Never leave a mess behind you: this applies to your project, the kitchen AND the bathroom!
Think for yourself: challenge bad decisions, escalate if necessary - stay calm and polite
Make sure you *really* understand the objectives/target of the project, from your customer's point of view
Keep a log book and use it every day
Always keep your own backups, and make sure you can restore

Code LESS: every line creates a work-chain
Read the documentation, use existing code if possible. Don't re-create what already exists
If there isn’t a spec/definition, write a short one (with constraints, goals, non-goals) and agree it
If it isn’t specified as a requirement, don't code it. If the agreed spec is wrong, challenge it
Understand why code style is important, and comply with existing style
Get someone to review your code. Learn from the reviews, don't take it personally
Use version control - ideally GIT. Commit early, commit often, *with* descriptive comments
Quality code WORKS! All the time
The bug stops here! You are responsible for testing and fixing every line of code you write
Remove uncertainty as fast as possible. Prototype, learn and iterate
Set yourself doable targets every day and every week. If you're not making daily progress, shout

Test behaviour, not structure. Don’t be gentle, break it!
Write down what you need to test before or at the same time as you write the code
Look for difficult, unexpected cases too
If it can’t be tested, it shouldn’t be there
If there's a test framework, use it. Aggressively replace/remove tests when things change
If someone else finds a bug after you’ve said it works, kick yourself and improve your practice!

Establish constraints and write them down
Plan to remove uncertainty fast - prototype and test against realistic scenarios ASAP
Design for testability, and design defensively: garbage in DOES NOT equal garbage out!
Design should be communicated clearly in writing, pictures or both
The first idea isn’t necessarily best: consider alternatives, discuss
Great design (and leadership) is methodology-independent
K I S S - simplicity is ALWAYS a design objective

Discuss the requirement with others – get perspective
If you’re unsure, say so. If you need more information, ask for it
Break the problem down into component tasks – get someone to challenge the breakdown
Compare like-for-like: try to check against previous productivity on similar work
Estimate the whole job, not just the coding. State what's included, what's excluded. State that it's a GUESS
Don’t be over-optimistic. It’s ALWAYS worse than you think

Get the best people you can find/afford, and clear the way so they can be effective
Provide strong leadership – make sure your people know what they need to do, and when
Allow and foster open and honest communication. Listen and learn. React effectively and fairly
Encourage debate where necessary, but if things get bogged down, be a benevolent dictator
Set short timescales for targets and reviews – weekly is probably best
If you're squeezed on time and cost, reduce scope – or it'll be late/broken/over budget
Nail the risks, before they nail you!

In case things still don't work out after all of the above, keep making friends...