Here is a summary. * means favourite
Bugs and Fixes
- Don’t touch that Code! – Under no circumstances should a developer have access to a production server
- Two Wrongs can make a right (and are difficult to fix) – Apollo 11 Lunar Module 2 bugs.. 1 which ‘fixed’ the other..unstable.
- *Code reviews – increase code quality, reduce defects. Share knowledge… common coding guidelines. Collective ownership.
- *You have got to care about the code – elegant, discoverable, maintainable, work with others, make stuff better, care about code….be proud.
Build and Deployment
- *Deploy early and deploy often – build server clean env, then on actual server
- Let Project speak for itself – Version Control, CI build, Code Coverage.. eg min 20%.. warning lamp
- One Binary – not multi versions of code. And keep environment information in source control too
- Pair program and Flow – Pair programming helps you keep flow. Solve problems efficiently, reduce ‘truck factor’, faster understand of code, mitigate interruptions, bring new members up to speed quickly
- Start from a yes if people ask app to do something.. then ask why
- *Two heads are often better than one – pairing is good.
- Ubuntu coding for your friends – very rarely do we create code for ourselves alone.. create good code for your friends!
- When programmers and testers collaborate – good things happen!
Refactoring and Code Care
- *Technical Debt. Don’t do short term fixes. Fix things properly.
- Take stock of existing code. Avoid temptation to rewrite. Many incremental changes are better than 1 big one.
- *Boy Scout Rule. Always make things a bit better eg improve 1 variable name, split 1 long function
- *Don’t be afraid to break things. Refactor and care about the general health of the code.
- *Improve code by removing it. Less is more.
- Keep the build clean – should be no compiler warnings
- Know your next Commit – work on 2 hour chunks and commit at the end..
- The Longevity of Interim Solutions – provide a more elegant and useful solution. Accept the things you cannot change, courage to change things you can, wisdom to know difference
- A Message to the Future – write something beautiful so can understand it in the future
- *Only the Code Tells The Truth – strive for good names. Refactor mercilessly. Simple as possible to read and understand. Keep sanity.
- Own (and refactor) the build – code quality, testing, easy to deliver working software
- Simplicity comes from Reduction
- Write code as if you had to support it for the rest of your life
Performance, Optimisation and Code Quality
- * [explore this]Functional programming principles. Referential transparency. Fewer defects, easier to debug as functions depend less on mutability
- Know your limits – people, budgets, complexity.. optimal marriage of software and systems.
- The Road to Performance is Littered with Dirty Little Code Bombs. Dependencies are bad. “Man’s got to know his limitations” – Dirty Harry
- Code Analysis Tools
Professionalism Mindset and Attitude
- *Hard Work does not pay off. Act like a professional – prepare, effect, observe, reflect and change
- *The Professional Programmer – Never rush, responsible for own career, responsible for code, team players, do not tolerate bug lists, pride
- Step away from the keyboard – sometimes best thing to do to solve a problem
Programming Languages and Paradigms
- Know well more than 2 programming languages
- Unix tools are your friends eg sed (awk or perl), grep, tail etc.. text processing
Design Principles and Coding Techniques
- What would the user do – spend time watching users. Better to provide 1 really obvious way to do something than multiple shortcuts.
- *Code in the language of the domain eg if (trader.canView(portfolio))..
- *Style – avoid global variables, objects immutable wherever, divide code into short sections e.g. a screen full
- Prefer Domain Specific types to primitive types
- Resist the Singleton pattern – causes dependencies, persists state. Hinders testing
- *Single Responsibility Principle – gather things together that change for the same reason
- Thinking in States – make code simpler and more robust
Tests, Testing and Testers
- Test data, comments and error messages – ask yourself what will happen if any of it becomes public
- Make the invisible more visible – release often, unit tests, debugging waste of time.. release as gives confidence that progress is genuine
- Test for required behaviour, not incidental
- Test while you sleep – run full testing, perf testing etc.. overnight
- Testing Is the Engineering Rigour of Software Development – like structural analysis for bridges
Tools Automation and Dev Env
- Automate your coding standards
- *Don’t Repeat Yourself. Less duplication leads to cleaner code. Less manually duplicated testing leads to better code. Build server good… If-then or switch case logic is a smell. use abstract or factory patterns.
- Know command line tools ie look under the hood of GUI’s
- Learn how to say hello world – ie keep things small..little tasks.
- *Put everything under version control – commit each logical change, use a succinct message saying what's changed and maybe why
- Automate, Automate, Automate – eg build/tests/deployment
- Don’t ignore that error – makes better code to always handle errors properly – less brittle
- Verbose logging will disturb your sleep
Learning Skills Expertise
- *Continuous learning – technology changes fast. Read, write code, mentor, frameworks, podcasts, learn new language
- *Do lots of deliberate practice – repetition.. about improving ability to perform task
- Learn the language and its culture – ie force yourself to use the bits of a language that are unfamiliar and get a feel for its culture
- *Fulfill your ambitions with Open Source. Learn a lot by reading code. Network. Find a project. Investigate code. Offer to write test code? Find fixes.
- *Read code
- *Beauty is in simplicity – maintainable, clean, simple, testable are side effects
Reuse vs Repitition
- Beware the share – if by sharing you increasing coupling and complexity.. then beware.
- *Reinvent the wheel often – education and skill
Schedules Deadlines and Estimates
- *Learn to Estimate – estimate is approx calc, target is a desirable business objective, commitment is a promise… targets and commitments are based on estimates
Users and Customers
- Make Interfaces easy to use correctly, and hard to use incorrectly
- Testers are your friends