Balancing Communication and Interruptions.
Wrong formulation. Interruptions need to be held to a minimum, and this should be management's highest priority. Back in 1989 it was exactly that and we flourished; we were more productive, we had fewer bugs. We had one recurring meeting per week (that is not a typo) and it often let out before its hour was up. We had single-occupancy private offices with doors we were expected to close and we loved our work.
We didn't have scrums. We didn't have sprints. Everyone from the first-day QA guy up to the CEO had written code before. We didn't write unit tests, we didn't have morning standups that required us to drive in rush-hour commutes.
We also had stock options and signing bonuses.
We were each issued a sign for our office doors, "DND," Do Not Disturb. We weren't interrupted all day.
Now software is written by gamers who can't concentrate well enough to finish reading a book, they can't write documents and they don't read them. Software development is seen as a social activity (it is not) and burdened with sports metaphors and bad nomenclature (what the fuck does "refactor" actually mean?).
If you want to ready how much wisdom has been lost you might read this.
Keeping Up With Technologies
But learning a new language is nothing for a senior developer. I had to learn three on one recent gig and even this was lost in the noise of learning the existing code base. If I have a body of code to work with and it’s in a new language I will be comfortable in that language within hours, expert in a month or two. And no I am not a Newton.
And a lot of companies are using way, way, way too many tools. It’s not uncommon to share informationa nd design in four different pieces of software, like Slack (which isn’t even searchable)