#23 Improvement Sprints
sponsor
Learn about SRE with Nathen Harvey from Google and Jamie Dobson from Container Solutions.
WTF is SRE? It’s about delivering what you promised while incrementally improving your service with new features. SLIs, SLOs and Error Budgets exist to balance and help guide decision-making. A main principle of SRE, these budgets give teams more autonomy and allow them to make calculated decisions based on estimated impact. Join Nathen Harvey from Google on another WTFinar brought to you by Container Solutions. 9th February, 15:00 CET
this week's favorite
Nothing worth doing is easy and anything worth doing is worth doing well … or so the sayings go. My personal experience certainly proves to me that these are more than simple soundbites and I am fairly confident in those sayings having more than a ring of truth to most IT professionals. So then why do we so often see innovation and professional development limited to the occasional day or Friday afternoon?
Service Level Objectives for On-call Peace of Mind
We framed our work to make CI “better” as an experiment with defined questions and metrics from the beginning. Could we use metrics to improve the experienced quality of CI? Once we knew that we were meeting some threshold of quality, could we use these metrics to prioritize future work? We gave ourselves a month to answer the first question and hoped that we’d have a while to test the second.
Engineering productivity can be measured - just not how you'd expect
From each of our two experiences starting out as introductory-level engineers at Box, to becoming first-time managers overseeing five-person teams, then directors overseeing 30-50, and ultimately VPs managing hundreds, we've experienced software engineering from every angle.
6 Lessons I learned while implementing technical RFCs as a decision making tool
As an engineering leader, I value trust and believe that individual contributors should be involved in architectural and high level technical decision making. I consider every line of code to be a decision made on behalf of someone else (including your future self) and having a fast-growing distributed team makes technical decision making particularly difficult to manage.
All software teams have technical debt — parts of the code that weren’t created with today’s challenges in mind, or were written poorly, or were expedient hacks that are now problematic. Having tech debt isn’t necessarily a bad thing; if people spent all their time making code perfect, nothing would ever get done. But too much accumulated debt makes it slower to deliver new features and is a source of bugs and quality issues.
newsletters
Would you like to become a sponsor and advertise in one of the issues? Check out our media kit and get in touch.