Synopsis
I’m a career-professional Ruby on Rails specialist who has been working with tech startups for over 20 years, peaking at serving as Chief Technology Officer at Mable.
I’m passionate about using data-driven decision making to create meaningful, enduring value through the relentless pursuit of quality over quantity, embracing constraints, and straight-up hard work and pragmatism.
As I enter my 50’s, I look forward to what promises to be the most prolific decade of my career, building on many years of experience, and hopefully tempered by wisdom gained along what has been a pretty amazing journey working with some wonderful companies and people.
Profiles
Projects
My go to toolbox on a Mac includes a combination of Alfred for automation, NotePlan for personal task and knowledge management, and Obsidian for more a more complex PKM.
- Alfred Audio Switcher - Alfred workflow for quickly switching audio output between speakers and headphones without having to unplug them
- Alfred Noteplan Actions - Alfred workflow for handy Noteplan actions
- Alfred Obisidian minimal them checklist icons - Alfred workflow for inserting extended checklists into Obsidian
- Connection Monitor - Ruby script to monitor the Internet connection on a Mac with verbal alerts and system notifications
- DiUS tennis exercise submission - My coding exercise submission to implement the surprisingly complex tennis game rules in Ruby
- Dwarven Stronghold - Ruby implementation of the the Dwarven Stronghold game from The Giant Book Of Games For The VZ300
- Page Headings Obsidian Plugin - An Obsidian plugin for populating the heading of new pages from the filename.
- Text Case Tools - Convert text into various cases
Power laws
The “pick two of three” power law appears to manifest in more than just the classic project management pyramid.
I made these as practical examples of enforcing two of three:
- Company focus survey - do you want your company to be profitable, ethical, or risk free?
- Product requirements survey - do you want your product to be high quality, low cost, or delivered quickly?
In reality, it’s not quite that clear, it’s a more nuanced intersection of all three.
Conservation of “foo”
We know that we can’t create or destroy energy, only convert it from one form to another, so it really should come as no surprise that this manifests in software development as the law of conservation of complexity.
There is a certain amount of complexity in any system which is inherent to the problem being solved, and cannot be reduced, only moved from one part of the system to the other.
We’ve all used systems where the complexity has leaked out into the user interface, or have worked on systems with a beautiful user experience but a back-end architecture that is the stuff of nightmares.
It is possible to optimise for the right two of three, during right phase of a project’s development, but without conscious effort, entropy does have a tendency to pick one of the three for you.
My values
My team at Mable had this artwork commissioned as a farewell gift, and I was blown away by how well they know me:
Thank you so much Winnie, Zak, Chris, and Rodney.
They’ve captured my personal values in this wonderful image:
- The great outdoors: taking a sneaky Friday off to go on hiking camps is a great way to decompress and recharge
- Personal fitness goals: while I haven’t been cycling as much as I used to, it’s a great form of exercise and mindfulness, although I don’t expect to be getting any more PRs on Strava.
- Health & wellbeing: I keep my brain fuelled on ketones and caffeine, and would usually have a stash of nuts and dark chocolate on my desk, along with a Keep Cup which I keep charged with long black coffee.
- Deep focus: to me, having a difficult problem to solve is an opportunity to put my headphones on, go deep, and achieve that highly prized flow state that leads to holistic problem solving, before coming back and sharing my discoveries.
Looking closely at the laptop screen, we find “Mark’s lessons”, which I must have banged on about enough for them to have been able to record them for posterity:
- Doing less things better: my preferred path to success is not to keep doing more and more things hoping something sticks, but instead to do less things, and be clear that they’re the most important things through both qualitative and quantitive data.
- Strict on vision, flexible on execution: this is a quote from Jeff Bezos that I’d often incite to remind us that it’s the “why” that motivates us, the mission and purpose that we must all be clear on in order to achieve success in implementation more than which tools we use, or systems, processes etc. Not that they don’t matter at all, just not as much as a strong vision and purpose.
- Balancing speed, cost, and quality: as mentioned above, I’m big on the two-of-three power laws, and differentiating between optimising for early learnings during discovery, and high quality during delivery.
- Be pragmatic, not perfectionist: I hate dogma, and can’t stand letting perfect get in the way of good enough, but instead prefer to start small and rapidly iterate.
- Climb the hill: this is a reference to the hill-climbing analogy from Shape Up, which I love, and ties in with the great results I’ve seen from differentiating between discovery and delivery.
- Stay DRY: I’ve actually softened my stance on Don’t Repeat Yourself at risk of it becoming dogma and leading to premature optimisation or the wrong abstraction, which as the great Sandi Metz says can sometimes be worse than duplication. It’s a good starting point to avoid getting into the habit of arbitrarily duplicating code, but a more nuanced approached is achieved with the wisdom to know when it’s cheaper than making wrong assumptions about an abstraction. I talk a lot about abstractions…
- YAGNI: it’s more often than not true, you probably ain’t gonna need it, so instead of coding it up now just in case, put a ticket on the backlog and see if it floats up. (it probably won’t)