Hello! My name is Casey Leask.
I’m looking for a new role as CTO, VP/Head of Engineering, or similar, remote or in Melbourne.
- Proven experience leading teams in highly skilled agile development teams, with a track record of successful delivery in large-scale, commercial software teams.
- Has experience proposing, building and taking proof of concepts all the way to leading the new business initiatives.
- Comfortable taking new business initiatives and providing multiple options for solutions that meet development, operational and architectural expectations.
| Firstname and Lastname at gmail dot com. | |
| @CaseyLeask | |
| caseyleask |
Some things I agree with
I've learnt a great deal from other people. Instead of attempting to rephrase or claim credit, I'm going to list a lot of principles (with links) that I found interesting and changed how I view software.
Happy to talk at length about anything in this list!
(This list may expand or shrink at a moment's notice.)
Asynchronous communication over synchronous communication
Simple over Complex
A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
You have to start over, beginning with a working simple system.
John GallInfrastructure as Code
Apply the same standards of quality, consistency and repeatability of behaviour to your infrastructure as you do to your code.
Autonomy vs. Leverage
Have an agreed understanding of what areas we're interested in providing autonomy, and what areas of common function we should be leveraging.
Work in the spirit of agile
Defense in depth
Don't rely on firewalls or any other single feature to keep you safe. Bake in security practices at every single layer of your infrastructure and architecture.
You build it, you own it
A direct mapping of DevOps principles
https://www.goodreads.com/book/show/26083308-the-devops-handbook
Bounded Contexts
Build services around Bounded Contexts.
Deal with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
Privacy by Design
In dealing with any Personally Identifiable Information, have a Subject Matter Expert on Australian Privacy Laws and Data Retention Laws.
Trust, but Verify
Don't try to be a gatekeeper, instead, ensure that everyone has the skills, knowledge and tools necessary to release changes in a safe way.
Verify with runtime monitoring tools, WAFs and other realtime tooling.
Mean Time to Recovery, not Mean Time Between Failures
In a distributed computing environment, failures are inevitable.
It's more pragmatic to plan for failure and test for it.
Have a single source of truth for all data
For example, if a user's name changes, it should only need to change in one place to replicate throughout all systems.
Security at the start
The most expensive security failure is the one that's already happened.
Understand the 12 Factor Model
Understand the Fallacies of distributed computing, and how it relates to what you build
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Apply Capacity Planning to Cloud Usage
Building in the cloud still costs money to the business, that should be planned and budgeted for.
Collect Raw Events, aggregate later
There's no recovering raw events from aggregates, but aggregates can always be calculated later
Understand your testing options
https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16
For example, personally, I favour Contract Testing over Integration Testing.
With a complex system, production cannot be accurately reproduced.
When relying on Integration testing, every discrepancy from production to the testing environment is an untested venue for failure.
Contract Testing provides better coverage, see https://www.destroyallsoftware.com/talks/boundaries and http://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam
Have a standard way of understanding the health and historical behaviour of every system
If you're awoken at 3 AM, all the information you need to diagnose an issue should already have been collected.
Collect a record of all steps that needed to be taken to stabilise and resolve the issue, and fix any gaps in data collection. SSH is often a crutch for poor observability of a system.
Global Mutable State
Avoid these three wherever possible.
Exploit native strengths and avoid generalising to irrelevant areas
Favour programming languages native to the operating system
Use Cloud tooling specific to the platform unless you have a very compelling reason otherwise
Put all State in Managed Services
Unless you're a database vendor, it's not your core competency. Lean on services who can provide better support than the business could ever justify.
Test your backups
A backup isn't working until you can prove that it works. Think of the consequences of a backup failing, and plan for this as well.
Roll Forward
If you're building fast, reliable deployment mechanisms, rolling forward is the known, working path of deployment. Rollback mechanisms are another venue for failure that's rarely tested.
Base access on Roles, and assign Individuals to these
Roles automatically rotate, whereas indivudual access Keys are long-lived, with weak validation of the source of where they are used.
(If someone leaks a Role name on GitHub, you won't be in danger like a leaked Access Key)
Build a Learning Culture
In a multi-disciplinary team, the specialists are responsible for coaching and training others in their skillset. Use regular gatherings of functional skill groups to reinforce patterns and share learning.
https://medium.com/@jpcontad/building-a-learning-culture-in-tech-organizations-dec03b0924ba
Hold blameless Post-Mortems
Context is king
Keep a historical record of Architecture decisions.
Similar to how we use git history to understand the context behind a codebase, architectures decisions are equally crucial.
https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records
Prefer Services to Vendors
Vendor products seldom neatly match the particular requirements of a business, whereas a service use can be customised to unique business needs.
Understand the guarantees of reliability every services provides to the business
SLAs, SLOs, SLIs, whichever metric you decide on, monitor and adjust behaviour accordingly.
Innovation requires slack time
Hack Days, 20% time, Fix-it Fridays, whichever solutions works for your business in giving engineers dedicated time to work on what they see as high priority.
This may manifest in engineers automating and refactoring problem areas, or it may lead to surprising innovation.
Write all services like they're public
Strict guidelines in how internal service communication happens leads to tighter interfaces and less undefined behaviour.
https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/