Take this on-call rotation and shove it
scottsmitelli.com
scottsmitelli.com
You can only do this for so long though, when two or three problems come in simultaneously it can cause issues as you drop something halfway through when something more important comes in. I once executed an SQL update query without a where clause under this kind of pressure, and ended up working until the next morning to recover, only to start again at 6AM. I have even had land-line calls at 2AM to bypass my mobile restrictions. The rewards are great, but don't let anyone tell you it is always easy.
My current system is 16 years old now and I know all the ins and outs so it has been pretty easy to keep on top of things the last several years, however I am glad the replacement system is nearly written and it will be somebody else problem in 2026.
In your case, you're the only employee of your business. And if you're not there the business will literally go under. And you also get directly rewarded for being there. I would guess that being 'on call' in this manner is possibly less draining on a person's soul (depending on how well they tolerate the risk of owning a business).
Contrast that with being 'on call' for your megacorporation, who isn't giving you anything extra for your on call time because they 'already pay you enough'. And where the only negative consequence for the company if you fail to immediately respond within 15 minutes is that some executive in the company is kept waiting longer than 15 minutes, or some ads aren't being shown for 15 minutes.
But if you aren't there, your boss is going to get a phone call and that's definitely not going to look good on you. And there's no bonus for fixing the problem, that was already your job in the first place. Sucks that you had to do it outside of scheduled hours, oh well.
I'm with the author of this article. Take your on-call rotation and shove it (if you're a large corporation). I'm fortunate enough to be able to take a firm stance on this point, and do so happily.
I'm really not seeing the distinction here. If a company offers a salary and includes on-call as part of the deal (and communicates that up front so it's not a bait and switch), how is that different than running your own business and getting compensated for your on-call time as part of a package that you sell to a client? In both cases you agree up front that you will be part of an on-call plan. In neither case are you getting a bonus for doing a good job at on-call, because either way you're just doing your job that you committed to ahead of time!
I'm totally sympathetic to people who don't want to be part of an on-call. Jobs that have on-call aren't for you, that's fine. But I don't get this idea that it's uncompensated labor, unless there are tons of people out there who somehow ended up in jobs that sprung on-call on them without warning.
The only job I worked that didn't have a formal on-call rotation ended up with me unofficially on on-call, with the same expectations as though that had been set up up front: boss calls whenever he calls and expecting an answer, and I'm left deciding how badly I want this job. Turns out management there sucked and I ended up on on-call after all.
If you find a company that actually has a good story for why they're able to get away with no on call, that might be a good signal. But if they're out there I'd love to hear from them, because most people here are just speculating about better alternatives, not speaking from experience with ones that actually worked.
Let's say I'm a business owner and I'm frustrated with the current state of the on-call system. I have options.
I can try negotiating with my clients to lessen the load in some way. Obviously this isn't always possible but it often is. I once had a freelance project that required 24 hours of on-call after a release. I negotiated release days that were convenient for me (never Fri/Sat/Sun). One time the client pushed back, I pushed back harder, and I won. In order for my push back to work I ensured that I had enough negotiating strength to do that which I planned for ahead of time.
I can upgrade my systems. For example if my current paging system is insufficient I can choose to pay $10/month more for another system that makes my life easier. I can set aside time to refactor my alerts code to make my life easier and I don't need to justify it to anyone but myself.
I can straight up refuse to do on-call and deal with the consequences to my business. Freelancer developers do this all of the time. We choose which client work to do and not to do. We can make these choices arbitrarily. Sometimes it's seasonal. Sometimes it's just based on vibes. Doesn't matter; it's our company.
Meanwhile the average on-call engineer at a large company has none of these freedoms. The underlying systems are chosen for them and they just have to deal with it.
In most cases they have all of those freedoms, and the only barrier is one that's shared with the self-employed person: not liking the consequences of choosing those options.
They could negotiate with their manager to lessen the load. They could upgrade the systems. They could straight-up refuse on call.
They don't because they don't like the consequences of taking these options—and neither does the self-employed person!
Correct. "Shove it" is usually preceded by not liking something.
> They could negotiate with their manager to lessen the load.
Most of the time the manager will simply refuse. As a business owner it's my decision.
> They could upgrade the systems.
At big companies this is usually outside the scope of an on-call engineer. The on-call engineer often doesn't even have commit rights to that repository.
The specific example I gave was paying $10/month more. That can be a very hard sell at a large company because their service contracts are much more complicated/expensive.
> They could straight-up refuse on call.
A business owner has much more negotiating power than an employee does.
> They don't because they don't like the consequences of taking these options—and neither does the self-employed person!
In the vast majority of cases making changes to the on-call infrastructure has very little (if any) measurable impact on the business. Like spending a week making the systems better. Or changing deploy/release dates to be more convenient.
As a business owner I can take advantage of this and make my life easier.
As an employee I have layers of bureaucracy to wade through and will probably be refused. Not because it affects the business but for other reasons.
That's the difference.
I have the enviable situation where I am on call for half of every month, I get paid significantly extra for this, and there's maybe 1 emergency call per year.
The only time I made significant money on call was early in my career as a contractor.
Salaried tech employees do not get extra pay for being on call, generally.
It also depends on the nature of the alerts I suppose. For us, the majority of the alerts could be checked and resolved from a mobile phone (they are alerts that could strictly speaking be resolved in an automated fashion, but the automation would get complex enough with dependencies on other service's metrics that we wouldn't be sure of not having bugs in _that_ code). About once a week or two weeks we would get an alert that needs us to look at the logs and so on.
In general people joining Amazon should be aware that they're joining a company that is fiercely and proudly opposed to work-life balance.
This goes back to Shabbat/Sabbath.
It's like demands from tech executives for long hours: "I worked long hours to make myself rich; why won't all of you work long hours to make me richer?"
> I work alone and only have one reputation. I don't want to be that contractor forever known for destroying a clients business.
> I am currently supporting four wineries that are processing thousands of tonnes of receivals 24x7... I don't want to be that contractor forever known for destroying a clients business.
If the 'clients' being referred to are the wineries, then it sounds like a self-run company. IE: the company is operating as a contractor to the winery clients, for whom (the wineries) a failure of the contractor (the company) would be a disaster for their business (the client, the wineries).
OTOH if "clients" refers to the business (the company) that in turns does the support for the wineries, then yes - an individual contractor.
The distinction would seem to me to really change the entire tenor of the comment. I'm curious which it is.
What shocks more is these are the companies that can "follow the sun" w/o breaking a drop of fucking sweat!
I have lost too many interviews just because I clearly asked for this, I always do, and I am doing it even now while I have been without a job after taking a year gap (which makes getting calls already difficult esp. with this AI and vibe onslaught). I am not giving up on this. I personally have never agreed to this which has caused lots of confrontations and stress(!!); a major source of my burnout WITHOUT ever doing the 24x7 on-call - so by just fighting it and keeping it away from me alone I was burnt out to the bits. It took me finally seeking medical advice to realise I was burnt out.
I hope this is not sounding like dramatic but even now when I have been resting, travelling for a year the mere mention of words like Splunk, VictorOps (same as Splunk iirc), PagerDuty give me minor trigger attack kinda sensation - make me very agitated.
But this is so common here. So common that it is considered one of the realities, truths. Yet, I have never understood, how, how can one agree to this? How? Is it some kind of social (if not racial) slave mentality? Is it some kind of grand coercion that they have no escape from? Or maybe it's just generation after generation subjecting the next generation to what they were subjected to while the stakeholders in the richer countries (because that is the structure) demand of this implicitly as they are stopped by health and safety laws from subjecting their underlings in their own developed home nations maybe.
The way this works in most unionized jobs is that there's a stand-by rate paid for on-call hours, plus a minimum number of hours at full or overtime pay, usually four, when someone is called to duty. This is useful to management - if the call frequency is too high, it becomes cheaper to hire an additional person.
For one particular occasion , once we took blame out of the equation (at least within the engineering team) and started doing Post Incident Reports, the incentives finally became clear for the business as we were able to compile a list of recurrent issues during every issue, calculate a financial loss and present it for inspection each and every time they either began a witch hunt for downtime or refused to allocate time to backlog. Small wins.
It’s even worse when the system isn’t business-critical: a reporting service, a manual intervention tool, something that quietly supports a process. When it fails, everyone is affected, but no one is accountable.
Ironically, these are often legacy systems that have been rock-solid for years — so reliable they’re forgotten… until they break.
Be vocal and say "I will no longer respond when system XYZ goes down unless serious efforts are made to fix it."
If you get push back explain that you will also call the person telling you it's not important enough to fix each time it pages, and be willing to do so. What can they say?
Yes you will, or can. "At will" employment in the US.
https://lbl.referrals.selectminds.com/jobs/site-reliability-...
"Work 5 shifts per week to monitor the NERSC HPC Facility, which includes 2 - 3 OWL (midnight - 8am) shifts. Some days may be onsite, some may be offsite. The schedule will be determined by staffing needs."
40 hours per week, full salary, full disclosure about the night shifts, but none of this 24x7 wake up in the middle of the night on top of your regular job bullshit that the tech industry insists on.
I think the problem isn't on call itself, it's that a lot of companies suck at on call. If your rotation is every 3 weeks and you get woken up in the night at least once per rotation, then yeah, that's awful. But the problem you have in that case is that stuff is always on fire and you don't have enough people on the rotation, not with on-call as a concept.
I think the real answer here is to have team members on multiple continents. Have some team members NA/EU/Asia then it's always reasonable hours for someone to deal with the production problem. High priority issues can be worked on around the clock without anyone working overtime.
Look at it this way:
If I work a job where I'm expected to be on 9-5, 46 weeks per year, 40 hours each week, that amounts to 1840 hours of scheduling my life around my employer.
If I work a job where I can schedule my work however I like and also have on call 1 week out of every quarter, the worst case scenario there is 672 hours of scheduling my life around my employer (and in practice the demands of on call in my current rotation are far less than that). The rest of my life I can schedule as I please, so long as I do my job.
I would rather take the option that minimizes the number of hours where my employer gets to tell me where to be.
Some people can handle it better than others. I'll never do it again though.
A good counter balance to this might be to offer even more compensation for no incidents, or otherwise well handled incidents that go on to squash types of that incident now and into the future.
I guess the ultimate goal is to keep everyone happy right? Everyone has different ideals, you can probably assume the business wants everything to work by spending as little as possible, employees want to be paid as much as possible while enjoying their job. Striking that balance is always a challenge.
But would I be as motivated to stop the root cause of the recurring issues that keeps giving me an extra $3k every shift? Well, I probably would, but my coworkers already need to be goaded into fixing root causes, and they're not getting paid extra!
In general, I think conflicts of interest must be handled carefully, and ideally avoided. Paying 10x wages when incidents happen is a clear conflict of interest.
> If on-call engineers were to receive compensation for each incident they resolved, it would incentivize them to intentionally build systems that fail so they could increase their pay by increasing their on-call load.” My guy, that is sabotage and fraud. You are hypothesizing a scenario where your subordinates are committing actual crimes. If somebody is doing criminal acts at work, fire their ass! Not to mention that anybody who deliberately self-inflicts on-call load is a goddamn idiot and should be sacked just on that basis alone.
That way, by taking longer on any but the hardest issues, you are instead removing your ability to make more money on other, faster issues.
If you call out a master electrician to flip a circuit breaker, they are going to charge you a lot more money than for the half second it took to flip the switch.
Also, if the reason they have to come flip that switch is that they screwed up the job they did earlier that week, you don't get charged at all.
This thread is full of people acting like highly experienced trade workers are idiots who have never thought of how hourly work might be gamed for more money. All of this has been long since solved by the industries that actually operate this way.
That's how it works for the occasional on-the-side server/printer tech jobs I occasionally take (long story short: I took a temp IT job years ago, resigned to go somewhere else, but the company never took me off their payroll so I get the occasional call to go install some number of printers or some number of servers/switches/etc. for some customer of HP or Dell, respectively). The usual rates are pretty abysmal for someone of my experience and skill level, but the 4-hour minimum means that if I can bang out one of these jobs in an hour or less I'm making more per-hour than at my day job. Nice bit of occasional money to blow on craps or penny stocks or shitcoins or whatever, and it keeps my fingers on various industry pulses.
The general shape of it at least makes sense. You get paid when you’re on the road. More if you’re driving than if you’re parked, and more if you drive for more than your 40 hours a week.
If it's better to spend the least amount of time doing on-call work then the logical conclusion is that it's best to snooze as many alerts as possible until they either go away on their own or roll over past your rotation. Fixing the underlying problem might be worthwhile if it's something that you can fairly easily fix but if the on-call rotation is more than 2 people, the underlying problem is mathematically unlikely to be of your making and is it really a good idea to make a habit of fixing other people's broken code?
What's crazy is that I've never seen anyone with on call duties acting in this worst case bad faith manner. Companies basically abuse the work ethic of their employees because it's the cheapest possible way to check that box.
In my experience at least if you're oncall during a sprint you would have less work assigned to you than otherwise (2 week sprint and 1 week you are oncall? 50% allocation) as the expectation is that week you will spend responding to alerts, or investigating issues, or even improving alerting and dashboard and fixing bugs. If this does not happen, devs don't push for it and management is completely blind to it you have an organization issue. If leadership does not care about the problem it's time to jump ship ASAP.
But I've seen people stubbornly defending an alert on >60% CPU usage of their 1 CPU allocated kubernetes pods where there was no impact in p99.9 latency (which was measured and was the actual metric that mattered as agreed with the rest of the business and internal customers of the service). Or alerting on each single pod restart. That is self inflicted pain.
As a kid the first few weeks were kind of exciting as it felt like you had been elevated to a new level of responsibility. Once that wore off it was obvious what a cage it was.
I don’t miss pagers.
I saw how they freaked out about things outside the team’s control during business hours. The first time someone called me after 11 pm I was going to get myself fired talking to them.
WTH?? I guess this person has never heard of backup generators? Every broadcast TV station has them.
But more importantly, *this* is what you noticed from that article?
I'm not talking about low budget UHF channels, but TV stations I've been in and around all have multiple studios. If the switcher in Studio-A goes down, the signals can be routed to the control room for Studio-B. Also, Alex the know-it-all is such a forced thing that is just ridiculous and eye roll inducing. Anybody that is a jack of that many trades is a master of none of them. The entire forced analogy just got to be too much and I lost interest before a point was ever made.
Like this exchange happens all the time:
"and now we're going to our on site reporter, Onda Premises"
<45s silence>
"Oh, it appears we've lost them for now, we'll cycle back later. In our next story...."
I've worked at a few FAANGs in the US, and every single one after 2010 had an on-call rotation.
1. Uncompensated oncall is legally tricky in many EU companies, so a lot of midsize companies look at the cost of paying for oncall, or sometimes just the time of administering paying for oncall, and decide they can do without. High frequency oncall is also often restricted (e.g. more than 1 week in 6 is not legal here)
2. A lot of the smaller companies are europeans selling to europeans, and are much more used to a business culture of availability during office hours. Especially there's a bigger share of like b2b back office stuff in europe compared to like, restaurant POS systems.
3. Larger companies do seem more into follow the sun. A lot of the big tech in europe are subsidiaries of US companies, so if they're in Europe it means they've already opened one remote location, and therefore are more likely to have another (California, Europe, India is a super common arrangement)
Mind you, I interviewed for a Yahoo Mail job that would have included wearing a pager (back in '05). And I know it's pretty common - I've been fortunate to not have that be an issue. Hoping for another ~5 years at the current job until I can retire.
The way contracts are worded, time working on on-call is work-time. Kinda obvious if you write it like that. As such, bad on-call weeks easily cut into the normal duties of the employee. This means team leads have an incentive to reduce time wasted on on-call.
You have mandatory rest-times. If an on-call activity takes an hour or so to fix, the person is suddenly not allowed to work for 10 hours due to these rest-time and maximum work time laws. Suddenly, "some little fixing at night" means the person isn't allowed to work the whole morning.
With a few rules like that, pages become really painful to the company. When a bad application kept pinging on-call every night for a few days, the entire normal work ground to a halt with people being unavailable, other team members dropping project work from sprints to pick up daily business slack. Some product managers got really pissed off and things in that product improved - I'm kinda curious what happened behind closed doors there. .
If there's an actual alert you need to respond to, your pay goes to 2x hourly rate, or 3-4x if it's the weekend and there usually is a minimum amount of billing you do if you have to do any work, usually 30-60 minutes. So if you get an alert and you fix it by pressing the "fix it" button on the dashboard on a Sunday, you just got paid hundreds of euros.
On the other hand you most likely saved the company from losing multiple times that in revenue, so it's worth it to the company.
I have a bunch of friends who were single and/or child free in their 20s and have fully paid apartments/houses because they could be on call at any time because they didn't have any commitments.
I also know a good amount of incidents that were fixed in a pub corner table after a few drinks. I may or may not have contributed to that number. =)
My two personal lows... I had to pull the laptop at my own birthday party, in a restaurant. And at a funeral (not proud on that one).
So sad.
I have been on call 24/7/52 in SRE roles most of my career. It has either sucked hard, or not at all. And the time it sucked the most was because every single practice was bad. And now, I build better things because of if. Paying me more for on call wouldn't have changed how much it sucked. It wouldn't have made any material impact on my actual quality of life. But it would have done two things: 1) made me feel like I can't complain 2) give me less motivation to fix it
Paying for on call doesn't seem like a win. I want happy employees, not disgruntled but silent ones.
Not that there aren't other ways to fix that. But fixing the erroring service isn't practical in all cases.
If oncall burden is light, then everyone volunteers because it is an easy way to make a bit of money.
However, it is a huge systemic change to move towards a voluntary model. Not sure how feasible this really is.
"Really? I volunteered for 15 hours of on call"
"Well, 15 is the minimum ok? Now it's up to you if you just want to do the bare minimum, or uh..well look at Brian for example, he volunteered for 37 hours of on call"
Can't this be simpler? If your system needs to working at night, and it pays (if it doesn't then what are we doing at night?), then you need to hire someone to look after it specifically at night (if possible from a geography where it is not night when it is others' nighttime.. and so on)? i.e follow the sun.
There are at least two problems with this thinking. The main problem is it's not generally true. The system is created by the entire organization. The people who raise money and allocate capital, the people who set development policies and priorities, the people who design and assemble the components, the people who sell it to customers and negotiate service levels and the people who operate and maintain it all collectively built the system.
Another problem is that it encourages moral hazards. Not paying fair on-call compensation allows unethical managers and sales staff to reap short-term rewards and bonuses by oversubscribing customers, promising more than can be delivered and rushing things to market before they're ready.
If you want happy employees, treat them fairly.
I see normally in oncall threads people complaining about "I got paged by an alerts because of another system X" - but in at least in a big enough organization this should not happen and it's an organizational failure. There should be an operations center on 24h/24h able to triage, escalate and evaluate, possibly not staffed only with L1 techs and given enough freedom to actually improve and automate. I know there are places where that is not true, and I ran away screaming from some in my career once I understood tech leadership had no understanding why it was needed.
But you would be surprised how much of the oncall pain is actually self inflicted by application teams themselves (some examples I encountered in the last year: TCP connect timeouts in the minutes and with no retries, no retry policies in general and things that should be idempotent that are not, no circuit breaker strategies, connection pools churning as they're shared between 10+ remote endpoints, wrong expectations about transaction isolation levels and how to handle conflicts at least in simple scenarios).
I believe the problem is the way devops is often practiced. I've worked as a developer, a manager and an operator and I've occasionally carried a pager. I think there is value in rotating between those roles at different times since it enables engineers to gain knowledge and insight they often won't get any other way. But assigning engineers to after-hours on-call duties when they're simultaneously responsible for product development "because they built the system" is just a stupid unethical and unsustainable practice that needs to end.
Good companies hire and train engineers to develop, manage and operate systems sustainably.
I want to know in which company you've reworked at where that's even remotely true. There's always financial and time constraints that force you in trading off system resiliency for actually putting out a product.
My first experience with this was Groovy Blue: https://youtu.be/WCbyp_UuyoM?si=s0ZpfcXZKw7dP17i
> I suffered through a particularly acute week of on-call pain. At one point I was in my third or fourth video call about the same long and protracted smoldering SEV and, in a moment of frustrated weakness, I made an offhand comment about just being tired of repeatedly handling the same problem. [...] With the utterance of a single sentence, I opened a rift in the relationship with my manager that remained until the day I left that job.
It's possible that the manager dropped the ball in two ways:
1. Perma-haranguing an employee, when manager should instead have had a talk with employee about what was bothering the employee. (And split it, between the little that really needs to be said right now, while employee is already overextended, and what can happen after they recharge.)
2. The root cause of the recurring problem might be something management should've tackled already. Which is additional reason not to blame the employee, for calling out the problem in frustration.
best practices usually come from giant companies with tens of thousands of engineers like google (who doesn't seem to be keeping up with competition btw) and amazon (which is notorious for burning out people).
what science or evidence drives the best practices?
management "science"
With the exception of companies like PagerDuty, the sooner this practice is ended the better off we'll be.
So, this is just plainly bad leadership, right? Totally believable too, of course, but just really bad. Bad for the employee, but also self-defeating for the manager.
It seems like this would be an awful manager reaction to anything short of a quasi-fireable offense. If that's your response to an employee to not being enthusiastic about a part of work that sucks, what are you even doing as a leader?
(Then I wondered when would be a sufficiently good occasion to say "Kafkaesque" regarding the software, since that's not something you want to waste.)
When something wakes me up, the next day I start a process to ensure I don't get that same alert again: bugfixes, adjusting thresholds or time-to-critical, detecting problems and auto-remediation, determining it can be a "business hours" response.
This also requires buy-in from development. Literally yesterday I had an education opportunity with one of the developers about a ticket slated to go into production that evening that would have immediately eliminated one of our leading monitoring indicators, because it would have started creating hundreds or thousands of Sentry issues an hour. "I was thinking it was more like logging, where more information is better, where with monitoring we want the fewest messages possible."
Always, always, look at every pager hit and ask "what can prevent that from happening again?"
if you want fewer incidents: ensure better QA, monitoring, smaller rollouts
usually developers start becoming more conservative after they do few oncall shifts and suddenly prioritize important reliability improvements, instead of shiny new features nobody will use
For 3rd party APIs, if they're not critical, you start to develop kill switches. So yeah, someone has to wake up and handle it, but all they have to do is set the kill switch and go to sleep.
Personally, I did dev and on-call for SMS/Voice verification codes. Most of the time, that's in the nasty corner of it's super critical to the application (users can't use the product if they can't get a verification code) and it depends on 3rd parties that have three nines on a good year. In my case, I got tired of dealing with the disruption and developed automated routing that could manage most providers taking an outage without needing me to take action. Results could be better if a human took notice and action, but it was good enough most of the time, and partial outages were much easier for the automation to handle it.
Even if there's no way to do something like that, at least automation can take care of 3rd party API is failing hard, so mostly return errors quickly without trying the API and only let a small fraction of requests go through to sample if the service came back online. That can keep your servers from getting overwhelmed, as well as drive the alert that helps you wake up, yell at the vendor, and decide if you can go back to sleep while the system takes care of itself.
When on-call is disconnected from development, that's when it gets really miserable. If you can swing a shift-work/follow the sun operator job, that's certainly better than on-call where incidents are common and there's no feedback loop to reduce things. It may well be better even if there is a feedback loop, but the feedback loop in that case requires explicit communication and effort; if I'm on call for my own work, I don't have to tell me to not push shit code right before I leave for the day or go to sleep, I'll get that message from myself right away. If someone else is cleaning up after my messes and doesn't communicate the effects to me, I might never know.
network issues? use a second DC, or some HA SDN setup, or run from a second DC.
3rd party API issues? Change vendor, or send stuff to queue to reprocess later. All of these issues could and should be solved and thats the job of the developer
Rinse and repeat after every incident and you will eventually get paged rarely.
Only when it's the managers that are on call.
These incentives then quickly devolve into a classic prisoner's dilemma. There's huge incentives to "defect" by producing quick-but-dirty work. You get the benefit of looking like you're producing rapidly, but you've made the collective experience a little bit worse.
if your work improving codebase is not valued, then its probably time to change job or just stop caring about code sustainability - let the business accrue technical debt, which is sometimes viable strategy if your runway and planning horizon is limited
* Arranging my whole life around on-call requirements. Bringing my laptop and backpack every time I went out. Designing new running routes that would use every street in a neighborhood and keep me close to home so I could respond within a 15-minute window. And yeah, the drinking thing. It pervaded my life in many ways I hadn't expected.
* Time zones and geography. These were always problematic, but especially during on-call. Often I'd narrow a problem down to a particular component that I didn't know well, so I'd try to contact the sub-team responsible for it, but nobody would respond. Then I'd try to turn the right knobs myself, and as often as not get yelled at for it in the morning. No, my afternoon, because my coworkers were three hours behind and late-commuters to boot. Of course they'd never hesitate to schedule meetings or ping me for trivial things well after my dinner.
I had taken the job, initially working on a project for which I was already a maintainer, because I wanted to avoid becoming an "architecture astronaut" by getting closer to operational reality. Indeed, I did learn a lot about how my own code behaved in real life. I don't have a problem with on-call requirements in and of themselves, but the way people and organizations handle the details is kind of <vomit emoji>.
What are they going to do, fire you? If they make life hard for you, then get another job. The shoddier your work outside of your normal hours, the better. You can have quality, speed and cheapness, but you can only pick two.
i got pages a few times and didnt exactly rush to ack. not slow but didnt rush. the rotations increased more and more (mostly from other US employees quitting) till i quit. scummy company
> We need to talk about Kafka
No we don't, that entire section was irrelevant.