131–140 of 168 posts
Earlier quoted context omitted.
Efficiency is the enemy of resiliency.
This is only true if you define efficiency as the inverse of redundancy. Sometimes efficiency is gained by reducing waste, not redundancy
Earlier quoted context omitted.
You can't prove that "this work caused us to not get paged" versus "that work is unnecessary and you wouldn't have been paged regardless". Even when you can, you can't prove the impact. As a real example, our team has extensive presubmit infrastructure to catch and block some classes of configuration error that have caused customer data corruption in the past. There have been CLs which were caught by those presubmits…
You can have before and after data and track trends. How did you know the issues was wide spread in the first place. You must have some proof somewhere. The impact is how many outages overall. If you only prevent one outage then maybe it's not that meaningful. Your last paragraph, your right that happens in the short term. In the long term those teams get reputations for being a shit show, there will be high turnover…
Reputations with who? The VPs who rotate in and out every few years (if you're lucky enough to go a few years between reorgs) for a new title and salary bump?
> there will be high turnover, good engineers won't transfer in,
On the contrary, many people want to work on the team that gets visibility where people can actually get promoted rather than having to justify their existence constantly
This is written as if you have actual control over the volume of work given to you and/or deadlines.
You need to learn to manage your manager(s). Google it.
This is a good post, but once again incentives rear their ugly head. > Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts. Time and time again at many companies, includi…
While they’re busy fixing their own problems, the teams that wrote outage-free code get first dibs on writing new systems.
On the (online game) teams I worked on there are an infinite number of new & exciting systems needed, so this approach means that the best developers are the ones building them.
This is a good post, but once again incentives rear their ugly head. > Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts. Time and time again at many companies, includi…
One of the tricks that we can use as good managers is code ownership. The folks who wrote the code are the ones who get to fix the bugs in the code. While they’re busy fixing their own problems, the teams that wrote outage-free code get first dibs on writing new systems. On the (online game) teams I worked on there are an infinite number of new & exciting systems needed, so this approach means that the best developer…
There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without…
> take your estimate of how long it will take to do something and double it before communicating to your manager/users. Yeah, but did you take Hofstadter's Law into account? It always takes longer than you expect, even when you take into account Hofstadter's law. https://en.wikipedia.org/wiki/Hofstadter%27s_law
Earlier quoted context omitted.
I love having no task assigned. Means I finally have time to do code maintenance. Upgrading dependencies, fixing bugs (there are always some), clearing TODOs left in code, improving performance, improving dev tooling or monitoring configuration, cleaning up unused code, improving documentation, ... And the best part is that since it's not an assigned task, nobody is waiting for it, so I'm under zero pressure. Sadly i…
In SCRUM though if that stuff isn't in the sprint you'll probably get backlash from QAs as it needs testing etc, or questioned why you're bringing in that stuff. Easier to sit back and not do anything.
And I work on the backend in a smaller company these days. Our backend code doesn't pass through QA, we just write tests and another backend coder reviews the tests if new tests are written. QA only handles frontend.
When you're cutting trees, sharpening the saw looks like you're not working. When you're doing software or organizational work, figuring out what actually matters can also look like you're not working.
The hard part is distinguishing between thoughtful idleness and ordinary procrastination. [1] https://www.franklincovey.com/books/the-7-habits-of-highly-e...
Earlier quoted context omitted.
One of the tricks that we can use as good managers is code ownership. The folks who wrote the code are the ones who get to fix the bugs in the code. While they’re busy fixing their own problems, the teams that wrote outage-free code get first dibs on writing new systems. On the (online game) teams I worked on there are an infinite number of new & exciting systems needed, so this approach means that the best developer…
Great as long as no one ever leaves, but the second someone does suddenly I’m being punished for owning their idiocy. And people are always leaving