Introduction

A tranquil haven away from the hustle and bustle of pressured modern life, development is performed in a small stone room in the corner. The only fortifications are the firewalls, and the stone walls, just enough to think creatively. Here I ponder the intricacies of coding, sometimes complex distributed systems, othertimes the more mundane, and in my spare time the personal coding and pet projects. You don't have to like it.

About Me

I've been developing software (or programming as we used to call it) since 1982, in the rough order: Basic -> 6502 assembler -> APL -> Pascal -> C -> C++ , and ending up with Java, C# and PHP. The last three are my preferred languages, the choice depends on the requirements of any given task. Add in database design and the ability to write efficient SQL.

Site Mission Statement

Apparently, according to management consultants, its important to have a Mission Statement, so here it is.

This site is primarily my place to keep track of ideas and concepts, the journal is there for the same reason, it tracks my thoughts and rather like a diary or one of those reassuringly navy blue Engineering Notebooks that we were given at certain companies to fill in with all our thoughts and then leave behind as an eternal record for whoever followed.

Disclaimer

I'm probably not as clever as I'd like to think I am, so so don't expect everything to work

The trouble with developers is that it's always in a state of development

Rules of thumb

  1. Any given non-trivial project will take no less than three months full time.
  2. Don't change anything without a compelling reason; c.f. "If it isn't broken it doesn't need fixing"
  3. HTML for content, CSS for layout
  4. You don't need to write a framework
  5. You do need version control from day one
  6. Simple is efficient, keep it simple and avoid fancy stuff that makes you feel like you're doing things right
  7. Optimisations are only to be done when a genuine performance problem has been found
  8. Optimise first by finding a better algorithm. Optimise last by optimising code.
  9. You haven't just found a bug in the compiler
  10. If you haven't tested it then there is a 5-sigma certainty that it won't work
  11. Coding standards are about the code and should not be about the amount of whitespace or indentation
  12. Do not be tempted to rewrite something because you don't understand it. This will not end well or quickly
  13. If the folks at CERN can find the Higgs Boson, you can find your heisenbug - just be creative with your approach
  14. Only use third party libraries for which you have the source code.


profile for Richard Harrison on Stack Exchange, a network of free, community-driven Q&A sites