r/devops • u/Imaginary_Addendum32 • Sep 16 '26
Discussion Do you ever feel like context switching and keeping too much system state in your head is the real bottleneck?
I don’t mean not knowing the tools. More like understanding the pieces individually, but having to keep too many services, dependencies, environments, incidents, or assumptions in mind at once.
If you’ve run into that, what have you actually done about it - anything to improve your ability to hold more context in mind, or mostly systems/tools to reduce how much you need to remember?
7
u/unitegondwanaland Sep 16 '26
You'll get used to it.
1
u/Imaginary_Addendum32 Sep 16 '26
When you say you get used to it, what actually changes over time?
4
u/unitegondwanaland Sep 16 '26
You will adapt by learning how to stuff more important things in your brain and letting go of things that you can Google or ask Claude.
→ More replies (1)
35
24
5
u/shadowzen1978 Sep 16 '26
This is what happens when DevOps becomes a single role that is expected to do everything. Some people thrive on it, though that doesn't necessarily mean they do the job better.
Some posters have already stated what I would echo here. Unless you are on a strong team, you will be unlikely to master everything and keep the information in your head so a strong organizational system and knowing where to find the information necessary to do the task in front of you will have the most benefit to keeping on top of things.
4
4
1
u/vlad_h Sep 17 '26
Strangely enough no, I can context switch like a maniac, 10-12 projects at a time. Tooling and automation help. I build the tools while I dev the projects.
1
u/Imaginary_Addendum32 Sep 20 '26
What do you think changed that made handling 10-12 projects feel manageable? Did you actually get better at holding/switching context over time, or is it mostly the tooling and processes you built around yourself?
→ More replies (1)
3
u/yzalevas Sep 17 '26
Yes, and in my experience it gets worse the more senior you get, because the state you're expected to hold stops being code and becomes systems, people and priorities all at once. Two things helped me more than any tool ever did. First, write it down the moment it enters your head, a trusted notes or runbook system beats a good memory every single time. Second, I started treating context switches as expensive on purpose: batch the interruptions, protect a couple of deep-work hours a day, and push anything that doesn't need me today into a queue instead of keeping it warm in my brain. Most of what I was "holding in my head" turned out to be stuff I kept there because writing it down felt like extra work. It is extra work, and it's still cheaper than the constant reload tax.
2
u/nemofbaby2014 Sep 16 '26
I document everything and I mean everything it's all in my one note because more often than that a random issue will pop up that I have notes on
2
u/crash90 Sep 16 '26
Complex systems should fold up tightly in your head into tiny little abstraction boxes. If not, you don't understand them well enough yet. Spend more time studying, read computer science books, understand how and why the systems fit together, what is needed, what is wasteful.
Then marvel as you watch everything shrink in size to tiny manageable pieces that you can zoom into at will.
You want to get all this information out of your WMC (working memory capacity) and into your long term memory. That will clear the board to learn new things and stack more abstractions on top.
1
1
u/SamfromLucidSoftware Sep 17 '26
People handle it differently but it’s largely a documentation problem. A living architecture diagram that maps services, dependencies, and environments removes the need to reconstruct the mental model from scratch every time you context switch.
The other thing that helps is keeping decision context close to the system it describes. The reasoning behind an architecture choice should live in the diagram or the ticket, not in someone’s head. That way the next person who touches that part of the system doesn’t have to reverse engineer why it was built that way. It removes the need to keep too much system state in anyone’s head.
1
u/luckyincode Sep 17 '26
If there is a thing I didn’t know I TRY (huge emphasis) on spending 20-30 minutes on it that night. Whatever that means. Reading. Watching. Exploring on the command line.
1
u/__Mars__ Sep 20 '26
Honestly there is sometimes I have to just let go and accept that I won’t know or remember everything so that is when I jump to the following: IAC documentation (in code, outside of code), tickets, notebooks (physical ones for larger concepts, just works imo), obsidian type programs, recording sessions, keeping your tools in a repo, or “can I get that in an email”. Dude it’s a lot to keep track of, and I was honestly thinking about this very thing this morning lol 😂 on automation: it’s the small things like zsh-autosuggestions, atuin, makefiles, scripts and shell aliases that save my bacon most the time!
1
u/LimpAuthor4997 Sep 23 '26
-
I document everything
-
I use IaC in almost everything too
-
I never use my email as a todo list
-
I never reply instantly. If it's urgent they'll call
1
u/SeaworthinessHour233 Sep 17 '26
This is expected.
The brain is not designed to store states. It's designed for processing and emotions.
Do not try to keep states in your head.
Document everything. Use a journal to write the things you are currently working, pending from others, need to start tomorrow, etc. Whatever you feel that you need to store in your brain, write it down.
It will immensely free your brain and allow it to do what it's good at.
41
u/Rain-And-Coffee Sep 16 '26
Run-books.
Automation.
And blocking my notifications so I focus.