Send mail to the author(s) E-mail

# Tuesday, 09 July 2013

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.

Coding Guidelines

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

  • DSL’s
  • 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
| | #