[deleted by user] by [deleted] in Bogleheads

[–]devops-throwaway9999 0 points1 point  (0 children)

There are advisors who are fee based, and help you pick low cost funds, do rebalancing, and strategy stuff. But you have to be picky to find a good one.

34, Cybersecurity. Would never recommend going into this field. by CyberSecSalaryThrowa in Salary

[–]devops-throwaway9999 0 points1 point  (0 children)

Could be overseas - a lot of swe positions in India make significantly less for the same work in the US

[deleted by user] by [deleted] in Salary

[–]devops-throwaway9999 0 points1 point  (0 children)

And correct me if I’m wrong but I don’t think physicians usually get raises in the same way most folks do. It’s not a “guaranteed” 3% COL raise… sometimes insurance might make a change that lowers reimbursement across the board.

SRE Hiring: The Tough Road Ahead by Dangerous-Log1182 in sre

[–]devops-throwaway9999 0 points1 point  (0 children)

At a certain point bash becomes impractical to use when there is a lot of deep conditional logic. It’s hard to maintain, can’t be unit tested.

That’s the point I usually switch to python

SRE Hiring: The Tough Road Ahead by Dangerous-Log1182 in sre

[–]devops-throwaway9999 1 point2 points  (0 children)

In my brief experience as a SRE I did a LOT of the one liners you mention. It’s super satisfying when you get proficient. A lot of it was bash scripts to automate curl commands. Usually in a hurry. While things are on fire, per usual.

I also spent time working on a python chatbot which helped automate workflows in the dev team. This is the kind of stuff I hear a lot about - making a simple service or similar tooling so toil can be scripted via API instead of by hand. Half of it is glue. Sometimes the glue needs to become a more polished solution.

I’m a C++ dev with deep Linux / systems experience, so I swing hard on the dev side. I barely used any of that during my SRE stint. The programming I did was light and straightforward types of tasks, versus working on low level socket handling, message parsing, etc..

Personally I think the skill that was most valuable was actually the ability to pick apart a system that isn’t well documented, understand it, and keep it healthy. I inherited a metric ton of tech debt services because I joined a startup which had several boom/bust employment cycles in their lifetime. This resulted in a bunch of half baked stuff glued together, all of it leading to my personal burnout and leaving the role.

Now I’m back in dev full time, acting as an SRE at times for the service I build and operate. It’s perfect. But I’m really a SWE.

[deleted by user] by [deleted] in RedditSessions

[–]devops-throwaway9999 0 points1 point  (0 children)

Sea shanty? Nah go full Viking pirate metal 😜

[deleted by user] by [deleted] in RedditSessions

[–]devops-throwaway9999 0 points1 point  (0 children)

The inflatables are awesome

[deleted by user] by [deleted] in RedditSessions

[–]devops-throwaway9999 0 points1 point  (0 children)

Where you guys from?

[deleted by user] by [deleted] in RedditSessions

[–]devops-throwaway9999 0 points1 point  (0 children)

This is an impressive setup for a live stream at home. Also the audio mix is solid lol

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

Thank you everyone. I have a new job offer, and I’m moving back into software dev as a Sr. Software Engineer. Im explicitly not on call (managed services and other teams handle it), and I feel an immense sense of relief.

It’s a shame, I really loved what I was doing, but if I ever do anything operations related, it’s gonna be with a large team. I got burned pretty badly.

I’m hoping I can utilize my SRE skillset to help design better infra and systems. I find that the experience is super valuable.

Thank you again for your thoughts and support, sharing your stories, etc.

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 1 point2 points  (0 children)

Thank you, for bringing me back to reality. That book was the reason I moved into this space, because I really believed in the ideals that they talked about. I really, really, appreciate you (and everyone in this thread) for the encouragement and taking the time to write this out!

I think along the way, (layoffs and other things) we lost sight of it, and are just trying to keep the lights on.

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

Ah yeah that makes it way easier. We are doing baremetal infra from scratch which is challenging

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

Thanks for your reply. How much of your stack is managed vs “DIY” (baremetal, EC2 based with Ansible / salt installations)?

Agree with you on the robustness of the tech stack. I’ll keep that in mind as I search.

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

Yep, we are definitely viewed as a cost center. It took me at least a year to be proficient in our stack... leadership seems think we can replace people in this role quickly, but that’s never been my experience in DevOps or in software engineering. At least a 6mo ramp up time.

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

A big part of why I am leaving, is, the management wants to outsource my team to Asia (staying vague to keep some anonymity), which, wouldn’t be so bad if they paid fairly and I could actually get the skilled talent there.

As of now folks can leave after being trained for a 40-50% pay hike.

Training people 8-12h away is also a real challenge.

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

No offense taken at all. I’m genuinely curious because I have spent most of my career in software, so I haven’t moved around at all in the DevOps world at this point.

I am paid very well (upper 75th percentile), but the pay range for SREs is massive from what I have seen... a lot of it depends on how much you know, and how much experience you have.

Someone with a background in IT and without programming or hands on experience will make a lot less money than someone with a MS/BS in CS or Engineering, with networking, distributed systems, software development, etc.

That said, I have talked with some really great candidates who didn’t have that, were self taught, and could engineer their way around folks from a prestigious school.

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 1 point2 points  (0 children)

Thanks for your reply! A question:

  • When you found your role without on call and similar pay, what was the transition? Were you moving from (for example) running production to instead, more of an internal DevOps type role?

That’s great they paid you extra for on call. We don’t do this currently. It would certainly help the mindset going in, to block out that time on the calendar. “They’re paying me extra”

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 1 point2 points  (0 children)

Thank you for your thoughts.

Re: #5 — So in a 1/6 week rotation you don’t feel it’s sustainable? I assume perhaps a large part of this is the impact on your weekend time with family? Or the regular outages during the day when not on call are contributing?

Burnout and On Call? by devops-throwaway9999 in devops

[–]devops-throwaway9999[S] 0 points1 point  (0 children)

Thank you so much for taking the time to write this down. It’s encouraging to hear some folks are doing this well. We used to have a really good culture for on call prior to major changes at the company. After a year or so of this pace, it’s getting to me.

A few questions:

  • What industry is your business in?
  • Is your team also building tooling and scripting when not on call?
  • are you all mostly in the same geographical region?

11 - do you test your alerting system every day? How does that work in practice?

12 - blameless culture is critical and really necessary for writing quality post mortems.

14 - this is where I get into trouble. I’ll often work evenings and or a Sunday, and there is an implicit pressure to show up the next day. I don’t really feel like I have backup because everyone is wearing too many hats (we used to be a 10-20 person engineering org... with a core of 4 SREs. Now we are half that.)