• Commit to deliver, to help, to learn, and to improve
• Be honest, be reliable, work hard. But work smart too - minimise loop time on repeating tasks
• 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!
• K I S S - simplicity is ALWAYS an objective - for ui, code, design, test, process, delivery, documentation
• Think for yourself: challenge bad decisions, escalate if necessary - stay calm and polite
• Make sure you really understand the project objectives/targets, from the customer and user p.o.v.
• Keep a log (paper or digital) and use it every day
• Always keep your own backups, and make sure you can restore

• Code LESS: every line creates a work-chain. Code is a liability, not an asset
• 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 and often (work-in-progress too, at least daily). Push your commits!
• 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
• Use a test suite. Know when to add, replace or remove tests when the codebase changes
• 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

• 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...

© Paul Sherwood (et al) 1996 - now