This list is based off Jon's Skeet alternative CV strategy. It's basically my core beliefs as a software developer: I've borrowed and adapted a few of his, but the majority are my own. Hopefully it doesn't read as too self-righteous or pretentious!


  • I will always choose a unit test over manual testing as it saves you time in the future.
  • I write test driven code, but realise you can do TDD code-first as well as code-last (but in my experience writing tests last is often very boring).

Clean code

  • I believe you should keep the camp site cleaner than when you first got there. (Bob Martin)
  • I prefer code which can be read easily over code which runs 5% faster but no-one else understands
  • I don't assume my code is perfect. (Jon Skeet)


  • If I don't understand something I like to spend my spare time learning about it - I enjoy learning new techniques and technologies.
  • I belief you should upgrade to the newest technology and practices wherever possible (but cutting edge over bleeding edge for business).
  • I would rather use a new technology on a personal project first than have to perform a U-turn on a commercial one.
  • I prefer keen developers with much to learn over experienced developers who feel they have nothing to learn. (Jon Skeet)

Peer reviews

  • I like pair programming: one person never knows all the answers, or will catch their own errors.
  • I prefer pairing to code reviews, pairing is the best form of peer-review.
  • I believe every level of programmer benefits from being peer reviewed.

Work-life balance

  • I would always choose a ROWE (Results Only Work Environment) to clock watching, developers only work 60% of their working day (Mike Cohn).
  • I would choose happy developers over slightly less productive developers as happy devs bring passion to their work.
  • I prefer going home at 5 to sleep on a problem over staying at the office until midnight and then being useless the next day. (Jon Skeet)


  • I believe transparency and honest discussion encourages trust and opaqueness produces disgruntled and recentful developers.
  • I prefer agency and trust over command and control.
  • I believe in collective ownership and responsibility over a blame and shame culture.


  • I believe if someone has made a mistake you are wiser to tell them in person than infront of a group.
  • I prefer suggestions for improvements over code-shaming.
  • I think it's often better in an agile work place to beg for forgiveness rather than ask for permission.

Upfront design and documentation

  • You will never create something correctly after one try, and releasing often helps you to iterate.
  • Whenever possible I will choose the Worse is Better approach (New Jersey style, simplicity over complexity).
  • I believe in evolving an API and not obsessing over its dependencies. But I also believe volatile APIs are annoying, you have to be measured but sometimes unapologetic.
  • I prefer whiteboards over Excel, Word or Visio. I choose Markdown to any other documentation format.


  • I prefer close collaboration over the heroic coder mentality
  • I am keen to deferentiate between heroic coder and someone who is really pro-active. Sometimes the two appear the same however one is aloof and the other is trying to help the team.
  • I like Github issues for technical discussions before booking a meeting.