151–160 of 168 posts
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…
The quoted section is about stepping in early with the right knowledge to fix an incident that's in progress. That is, putting out the fire.
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…
> I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or…
> willingness to ensure that work is formally recorded under your name Where I work the title "Principal Engineer" is a coveted, well compensated, and rarely achieved. Those I've worked with are all highly effective and personable, but I interviewed one about how he achieved the title at his previous company. His strategy had been to help people and actively give away the credit. In 1 on 1s or in meetings with multip…
Earlier quoted context omitted.
I know a guy who did all what you've listed and the only thing he received was a burnout.
Now you know two, hello. I'd take those nights back, the credit (hah) , and peace of mind in an instant. Short of the learning experience, I regret nearly every bit. The good will I built was... useless to say the least. I got the bump in the end. How? Finding new company, both literally and figuratively. Overextension/sacrifice played no part and I'd like a refund, were it possible.
The result is that I often know what I should do better than I would have. Make a point of talking to the people you solve problems for, get your hands dirty, and create that domain understanding that you need. You'll likely produce less code, but it'll be more useful.
Or, in some cases, you'll write more. But it'll be for something you never would have realized you needed had you not 'done nothing'.
The key for me was allowing myself to get out of the engineer mindset and into the mindsets my coworkers need to do their jobs, being less interesting in fixing and solving, and more interested in getting a holistic understanding of the required work and how it fits into our team and org and with our partners and so on.
I'm fortunate enough to work somewhere where this isn't only permitted, but it's encouraged. The problem spaces are often highly niche and complex too, so the need for developers knowing what their users are doing is especially important.
I do think it applies anywhere, though. Even in my own personal projects. Do less, observe and experiment, use the software, let things incubate. Then do the work once the mental model has settled in a way you know is better than it was.
This is written as if you have actual control over the volume of work given to you and/or deadlines.
You control how fast you work and what you tell your manager(s) about how long the work will take. 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…
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…
The person who made the breaking change is often diligently following instructions to get it done as soon as possible.
The metaphor that changed my perspective came from the book, "The Power of Full Engagement", paraphrasing "you're behaving as if you're a world-class endurance athlete without an off season - stop it."
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…
That’s an extremely game centric point of view. Game devs more than just about anyone else are strongly identified with their code and have an artist attitude about. In a non game environment the psychology is different.