3 ms·
Curiously this made my transition from SRE to SDE somewhat interesting. After I transitioned I kept working the same hours I would as an SRE and would be surpr
by lumost 5y ago
Curiously this made my transition from SRE to SDE somewhat interesting. After I transitioned I kept working the same hours I would as an SRE and would be surprised at the lack of output from my coworkers. It wasn't until later that I realized it was simply the difference in hours worked.
As an SRE, your only option for climbing out of the mess is to work harder/smarter/extra, and you are always lowest on the totem pole when messes happen. You either learn to keep up with the crazy schedules, or get the hell out of dodge.
- aaomidi 5y agoI actually transitioned from SDE to SRE, and you can imagine how awful it was for me doing the opposite. SREs are the hardest working engineers I know, but unfortunately they're not given a lot of autonomy to fix problems. Or one SREs has strong opinions about stuff and blocks fixing things. My conclusion has been that everyone needs to be devops. SDE needs to also own the ops of the thing they've developed.
- dvtrn 5y agoMy conclusion has been that everyone needs to be devops I used to think this way. But time and time again I found that organizations treated Devops and SRE as either "developer help desk" or "hiring some person to do terraform stuff and calling them the 'DevOps Team'" or "we literally failed to hire actual technical specialists for the role we needed, so we're just going to dump these tasks on the Devops 'team'" I no longer think the way I used to about Devops, I also no longer have any real interest in being part of 'Devops transformation' efforts. Go figure.
- dragonwriter 5y ago> My conclusion has been that everyone needs to be devops DevOps wasn't conceived as a new and additional role or org, but as a model, and a model whose main point was eliminating inefficiencies resulting from role/org/knowledge/responsibility separations between dev and ops. Creating a new role, often in its own sub organization, as a distinct knowledge and responsibility silo for “DevOps" is like management instituting a rigid top-down development model without dev team ownership and control or customer participation and calling it “Agile”: Completely missing the point and also exactly how most places do it.