When you work with me, my value isn’t just that I can create software (although I definitely can); my advantage is that I understand the business context of software.
I understand business: I have been gainfully unemployed since 2009, occupying my days either as a business owner or as a consultant (sometimes both at the same time). I founded a company in 2010 and was a co-founder and CTO of another between 2013-2017 (it’s still operating as of 2018). I’ve been involved with startups since 2001. I’ve worked for tiny five-person companies, and I’ve worked for a multinational corporation with billions in revenue. I have led software developers, and I’ve been involved in hiring engineers since 2004.
In addition to helping other people develop software they needed, I have built SaaS products, created an enterprise level product for the behemoths of the road construction industry, published and sold my software development books online, and created video courses for Pluralsight, one of the largest online education providers.
I also have a broad perspective on software development. I have created and collaborated on a variety of web applications with a focus on the geospatial domain. I worked on mobile applications before the first iPhone came out. I took part in creating embedded software used for automated control of bulldozers and excavators.
I have learned what works - and what doesn’t work - in a wide variety of business and engineering contexts. Most importantly:
I understand that software I develop is just a tool, and the real goal is growing your business. I will use my experience and skills to help you achieve that goal while managing costs and risks.
To that end, I will look for answers to questions like:
I will not be dogmatic about the development process or test coverage or upgrading to the latest technologies the minute they come out. While many engineers take a purist approach, I understand that these are actually tradeoffs. Sometimes a shortcut has to be taken to get a customer on board before the complete solution is put in place. An internal tool may not need the same test coverage as a customer facing product. It may not make sense to implement automated testing because in many situations, manual testing is far more effective than engineers like to admit. There may not be a business case to upgrade the internals of a solid, reliable product right now, and so on.
I mostly work with the following technologies at present:
Slicing it another way, my most recent areas of focus have been:
I work remotely in the New Zealand time zone which is either UTC+12 or UTC+13, depending on the time of the year.