3 ms·

> Frankly, the amount of derision I see here and in other tech circles from SWEs against basically every other role in tech makes me think SWEs are the ones wit

by pm90 5y ago

> Frankly, the amount of derision I see here and in other tech circles from SWEs against basically every other role in tech makes me think SWEs are the ones with the ego, for that matter. I can believe this. It’s especially funny when building a reliable system today requires a really basic understanding of few low level system concepts (eg graceful termination, signal handling, healthchecks, DNS) and most SWEs I work with simply refuse to learn these things.

nickjj 5y ago
> most SWEs I work with simply refuse to learn these things Are the SWEs over worked with unrealistic deadlines? Also how did the SRE present this information to them? I think both factors can drastically have an effect on the outcome. For example a small team who is already on the brink of being overburdened getting tossed a few links on Slack that says "please make sure you know about Kubernetes graceful shutdown timeouts and signals" with no other context is going to be met with resistance because now it feels like you're giving them another job. If they have no prior experience with that sort of thing it could take days to partially understand it. That's eating up time for their sprint, etc.. Alternatively, you could write a nice bit of documentation in private explaining the problem and why graceful shutdowns are a good thing, how it aligns with being able to deploy new versions of our apps, how they can create a better user experience for the apps they're building along with prepare anything you can to get as much information about your apps as possible (longest page responses, etc.), then spend a bit of time with your tech lead or someone who knows your applications well to iron out good values for all of your services (this assumes a worst case scenario where you don't have these metrics logged anywhere yet). Then wrap things up with a 5-10 min show / tell to share this knowledge with the devs so they have an awareness of it. In my opinion that maximizes everyone's time, the SRE doesn't even need to know much at all about the app's business domain too since it all boils down to how long an app might take to exit. Knowing a bit about the tech stack can be researched for the document you'll write too, such as mentioning how you can hook into the shutdown process of the app server to potentially execute code during a graceful shutdown, etc.. I've found that after all of that, it was embraced in a very positive way with devs now looking for ways to improve the app to better handle the app shutting down at unknown times without data loss and minimal user disruption. This is now a skill set the devs can take with them anywhere around having experience building robust and resilient applications. Everyone wins (customers, devs, SREs, etc.).
- pm90 5y ago
  I agree with this. Making these concepts easy to understand, with examples on how to do this concretely in the company’s custom setup goes a long way in ensuring that developers both understand these things, and like you pointed out, make them evangelists for implementing these things.

by pm90 5y ago

nickjj 5y ago

> most SWEs I work with simply refuse to learn these things Are the SWEs over worked with unrealistic deadlines? Also how did the SRE present this information to them? I think both factors can drastically have an effect on the outcome. For example a small team who is already on the brink of being overburdened getting tossed a few links on Slack that says "please make sure you know about Kubernetes graceful shutdown timeouts and signals" with no other context is going to be met with resistance because now it feels like you're giving them another job. If they have no prior experience with that sort of thing it could take days to partially understand it. That's eating up time for their sprint, etc.. Alternatively, you could write a nice bit of documentation in private explaining the problem and why graceful shutdowns are a good thing, how it aligns with being able to deploy new versions of our apps, how they can create a better user experience for the apps they're building along with prepare anything you can to get as much information about your apps as possible (longest page responses, etc.), then spend a bit of time with your tech lead or someone who knows your applications well to iron out good values for all of your services (this assumes a worst case scenario where you don't have these metrics logged anywhere yet). Then wrap things up with a 5-10 min show / tell to share this knowledge with the devs so they have an awareness of it. In my opinion that maximizes everyone's time, the SRE doesn't even need to know much at all about the app's business domain too since it all boils down to how long an app might take to exit. Knowing a bit about the tech stack can be researched for the document you'll write too, such as mentioning how you can hook into the shutdown process of the app server to potentially execute code during a graceful shutdown, etc.. I've found that after all of that, it was embraced in a very positive way with devs now looking for ways to improve the app to better handle the app shutting down at unknown times without data loss and minimal user disruption. This is now a skill set the devs can take with them anywhere around having experience building robust and resilient applications. Everyone wins (customers, devs, SREs, etc.).

pm90 5y ago
I agree with this. Making these concepts easy to understand, with examples on how to do this concretely in the company’s custom setup goes a long way in ensuring that developers both understand these things, and like you pointed out, make them evangelists for implementing these things.