A team without proven observability and on-call strategies will invariably suffer from reactive disruptions; mitigating outages will be painful, like finding a needle in a haystack while blindfolded.
The book’s core thesis is minimizing complexity in software development by adopting complexity-eliminating approaches. The upfront investment in learning and adopting better designs pays off because it leads to high-quality software. Recommended read for software developers and line managers.
Most teams struggle with removing friction because they concentrate on surface-level reactionary fixes instead of addressing the fundamental causes of inefficiency.
The issue with systems that do not 'fail' is that they have no fixes when they eventually fail.
Excellent documentation leads to efficiency gains, insufficient documentation leads to bottlenecks, while poor documentation sprouts confusion.
Multipliers make or mar engineering organizations - teams that invest in boosting the right capabilities at the right time will get more done with less. Teams that neglect these capabilities will eventually get bogged down – they’ll get less done with more.
When most teams complain about poor quality, they usually mean reliability woes; however, quality spans a more extensive spectrum and can mean many things. If you complain about your software being of low quality, what dimension do you mean? Use the Maslow quality hierarchy to identify the pertinent challenges and make the right tradeoffs.
This post focuses on steps to take during the first 3 months of forming a new team. It is the second post in the "How to onboard teams" series which covers lessons and techniques acquired from ramping up many teams.
There is a high chance that you attend or have attended an inefficiently-run stand-up. I have seen various stand-up styles over the years. Sadly, most of the roughly 2000 stand-ups I attended were unproductive. Mildly put, most were status reports for some manager or higher up.
Less can be more - remove, don't add: say less, delete code, write tersely. Find the smallest things with the highest impact. The end
Are you working on the right problems? If no, then focus all your energies on identifying the right problem with the biggest impact.
How to brilliantly deliver on seemingly impossible projects
That is the question I like to ask nowadays at the beginning of anything: a sprint, a project or a book.
5 important ideas that engineering teams need to keep in mind to optimize value delivery.
Constantly factoring deletes into your iterations keeps your code base healthy
My heuristic is to green-light full adoption only if the long-term benefits outweigh the costs and risks
Tips for running services at scale with minimal toil
A couple of months ago, I needed to create backups of a database dump on one of my VMs. I initially thought it would be a difficult task but was pleasantly surprised to find it easier than I thought. Despite the excellent documentation; I still needed to do some research to get my automated pipeline … Continue reading How to backup files to Azure Blob Storage from VMs using managed identities
Some engineers believe they have to go to great lengths to eliminate every single piece of technical debt in their codebase. This focus on perfection ignores the cost of fixing debt, the risk of introducing new bugs and contagion (the chances of debt spreading).
These are a few strategies I employ to be more efficient at work.
Habits die hard It is hard to focus in a fast-paced work environment: there can be live-site incidents out of the blue; bugs to fix and meetings to attend. I have always struggled with coping with incessant demands and distractions; the urge to drop whatever I am doing and hop on the next fire is hard … Continue reading Less Work, More Impact