It’s support’s job to focus on one thing at a time, meanwhile it’s a coder’s job to try and keep dozens of things in mind at a time. Context switching IS hard regardless, but like you said, one of the roles has it baked into the job description.
The crux here is that Programmer committed to X work done by the end of the week, and Support is effectively subtracting their time to accomplish X. This is a managerial problem, and not an easy one, because it’s not predictable.
My estimate, if you’re a programmer working 40h/wk on a live product, 8h of coding is a good week. Expect the majority of your time to be spent planning, reviewing, and supporting. If you’re sacrificing one of those to get more concentrated coding time, make sure that is communicated. YMMV.
In any case, if you don’t have managerial support to get engineer resources to fix problems, then it’s not support - it’s therapy. Sometimes that’s the best you can do.
I would hardly say it's supports job to focus on one thing at at time.
Most people that reach out to support are calling about a specific question or problem. Yes therapy calls do happen. They're not terribly common, but you'll hear about them because they are funny/egregious examples.
When a customer calls about their 1 thing, I can definitely look up the 1 answer or do the 1 fix for them. This is bad support though.
A good support team will listen to that customer, understand what they're needs are and fix that thing while make sure they are set up for success in the future. This means I'm checking different account/user statuses, feature usage, and billing history. I dot his while talking to them, but never letting them know I do this.
If I can understand their 1 question AND know who they are holistically, I can set them up for success and prevent more support tickets down the road.
If you've ever had a user or a profile sent to you in a bad/extreme state, you can bet that a series of 1-off support solutions could have lent to that.
Maybe other support organizations are different or maybe I am busier than normal, but the concept of one thing at a time is foreign to me.
To outline today:
Left comments on ~15 net new cases to jump start the troubleshooting by the technicians assigned to them
Help led a morning meeting reviewing cases where people are stuck
Researched whether an old (7y) version of the software had a piece of functionality
Made comments helping ~5 different technicians globally on their cases
Helped a colleague craft a SQL query to help replicate an issue then talked over strategy
Logged into a colleagues VM where they had an install problem
Had a call with the pre-sales brass about trends in the support organization
2 walk ups:
- Intermittent reload issue when triggering things via API
- How to setup a reverse proxy with IIS
Assigned cases for initial responses to meet our contractual obligations
- Left 5-10 public facing comments to meet SLA to assist the team
Emailed some devs about whether a customer can run using the latest version of the database which underpins our software
Responded to 3-4 different issues in the Slack for our Consultants on-site with customers
Came up with a PowerShell script to work around a bug for another tech at the behest of our Escalations folks who walked up
Caught up on a case that I'll be covering for next week which has Executive VP visibility (ultimately making things right after the initial tech botched a system)
Personal cases:
- Install problem on a server with FIPS
-- Then get thrown under the bus on a customer facing email about the further issues
-- After bypassing that there was a user rights assignment problem; emailed some devs about why we require it / work-arounds for a locked down government server
- Reload of data problem due to the permissions for the service account
-- On the call discussed:
--- Architecting for high availability
--- Long-term maintenance activity to ensure stability
- Reviewed 2GB of logs for an intermittent issue
- Worked on reproducing a client side bug
- Called / left voicemails / sent emails for 3 customers trying to get a remote session scheduled
- Alleged security vulnerability. Called / emailed the customer asking for more clarity; stood up servers to reproduce and researched how to capture the data needed to confirm
All while constantly monitoring email / 3 slack instances / 1 Microsoft team instance / my queue for fires to put out
In some sense, that's a slew of single things, but it's uncommon for me not to be moving onto the next task as I am winding down the previous one. Nor is the work-flow all in the same vein.
The crux here is that Programmer committed to X work done by the end of the week, and Support is effectively subtracting their time to accomplish X. This is a managerial problem, and not an easy one, because it’s not predictable.
My estimate, if you’re a programmer working 40h/wk on a live product, 8h of coding is a good week. Expect the majority of your time to be spent planning, reviewing, and supporting. If you’re sacrificing one of those to get more concentrated coding time, make sure that is communicated. YMMV.
In any case, if you don’t have managerial support to get engineer resources to fix problems, then it’s not support - it’s therapy. Sometimes that’s the best you can do.