A empty piece of A4 paper landscape in front of the keyboard. Write all the things you need done in the next n hours onto it.
Tick the boxes for things you did, cross out things you decided not to do.
This is extremely low tech, but the very obvious advantage is that the piece of paper is always in front of you, independent of which window, desktop, monitor or whatever you focus. Paper is always open, you can archive it, you can sketch things, put down notes etc.
You would be more productive if you stuck with one set of tools instead of constantly learning new ones. Exploration for better tools is good, but to be productive you have to master one set of tools at some point, there is no tool so good that it makes up for your lack of mastery.
Learning tools is busywork, it feels like you are making progress. But the time spent learning tools is time not spent learning how to tackle hard problems, learning tools is much easier so it is enticing but you just have to push through and stick with the hard things.
Also, Copilot has been immensely useful in boosting productivity, especially when working with the libraries that I am extremely familiar with; sometimes too much of code is just 'grunt' work.
Don’t worry about immediately responding to every ping.
Reduce the number of items on your plate or delegate them to others.
Don’t always immediately jump to helping someone when they ask for help. Figure out the balance between “is this person actually blocked or are they not applying themselves on this problem?”
My main point is this — there are too many distractions. If you are eager to help everyone else and take on every little thing people throw your way, you’ll never get your work done. The constant context switching will slowly chip away at your soul, in my case leaving me with feelings of disdain towards certain colleagues. And that also isn’t fair to them.
It’s up to you how to manage and set expectations, but prioritize your well being first and then many things will fit nicely in place
Edit: another, related one: use snippets (files or folders) for temporary/sandbox projects. I found it useful to strip down a business logic off a working project and use that as a project template. If you want to test how a feature or a design approach feels before making it a branch or a module, you can just spin up a separate project, spread the mud there, distill, and then use it almost as is in your work project. Of course you can do that on a branch, but sometimes it feels better not to, because in-project testing may damage your development dbs, use irrelevant (or costly) services, etc, i.e. leak some logic to sandbox which ought to be destructive from the beginning.
atoav's comment about using paper also strikes me as being helpful. I often find writing longhand to be more mentally stimulating than typing, and the lack of light shining in my face seems to improve my attention span. Might just be fooling myself, but it seems to work.