Life Beyond Fife

Engineering from the glorious Kingdom

All Posts

Explore all articles from Life Beyond Fife - Page 2

The Slow Path to Everything
essays•

The Slow Path to Everything

Over twenty years in software development, I’ve witnessed an evolution in how code integrates with other code. Each step has enabled more complex and distributed systems capable of progressively more impressive achievements. This comes with the price of understanding each new layer’s abstraction, moving us further from fast, direct execution and closer to slow, human communication. This journey reveals where we could be heading next. It’s all code, in one place My first job as a software developer in the early 2000s was a lesson in how not to do things. The best example I can give is how version...

7 min readRead more →
The Deployment Constraint: Speed, Safety, and Automation
essays•

The Deployment Constraint: Speed, Safety, and Automation

In software deployment, there exists a fundamental tension between three critical factors: speed, safety, and automation. This forms a triangle where engineering teams can optimise for any two points, but something must give on the third. You can deploy fast and safely, but only with significant automation investment. You can deploy fast with minimal automation, but safety suffers. Or you can achieve safety with simple processes, but speed becomes the casualty. This tension plays out in predictable patterns across the industry. Teams prioritising speed and simplicity push code quickly with minimal testing, accepting the safety risks that come with “move...

7 min readRead more →
Why 5 Whys isn't enough
management•

Why 5 Whys isn't enough

5 Whys is a prevalent engineering process in a modern tech company. When your company has operational incidents (and even the biggest and best ones do), 5 Whys is there to find the root cause, which in turn yields the next steps to make sure those incidents don’t happen again. I could tell the engineering culture of the company needed work when an internal team had an outage related to an expired SSL cert. It wasn’t the outage that made me concerned; it was the attitude of the team who had the outage. “What steps have you taken to make...

6 min readRead more →
management•

Convincing or Instructing

To convince someone, tell them why, then how, then what, in that order. To give an instruction, tell someone what, and time permitting, consider sharing the how, and why, in a reverse of the previous sequence. Simon Sinek’s insightful Start With Why TED Talk took about 15 minutes to change how I would give all presentations forever after. Intrisically it’s known that you have to share the motivation of why anyone should care about what you have to say. But based on the evidence of so many terrible talks you’ve both attended, and presented yourself, you know how easy it...

4 min readRead more →
management•

Managing Expectations

“This team isn’t delivering enough.” You’ve had a fully funded team of engineers working on a product for years. It has fundamental issues with quality and completeness, and still isn’t integrated with the core platform seamlessly. As time has gone on, you’re getting further behind, not closer. There is either a problem with execution against the strategy, or with the strategy itself. You reflect. You’re sure that the quality of the engineers is not the issue. The drive and work ethic is there, and they collaborate effectively. Everyone understands the plan, and everytime you question the decision making of the...

5 min readRead more →
essays•

Stop saying Tech Debt

If you gave two options to someone who cared about business outcomes, about what they could have, which do you think they’d choose? new product feature or reduce technical debt fix a bug or reduce technical debt improved sales channel or reduce technical debt more accessible UI or reduce technical debt increased performance or reduce technical debt Technical debt, or more simply tech debt, is the losing horse in every race because only one group cares about the problems caused by it: the engineers on the team supporting the product. A clean, well architected system is easier to reason with,...

4 min readRead more →