I usually find them unnecessary at best, and distracting at worst. Having the "reading time" listed at the top of the article here is enough to give me a sense of how long the article is. But some people really like having them, so maybe there could be a setting for users to turn it on/off per their personal preferences?

I think the reason I don't care for a generic progress bar is that it doesn't really give me meaningful information about my reading progress. I might be halfway through the text of an article, but how much of the remaining article is code snippets, interactive examples, videos, prose, conclusion, etc? The actual progress of me getting through the article may be massively skewed by things that aren't raw text, and so it tends to feel quite arbitrary, generally-speaking.

A better measure of progress might be to enumerate the Headers in the article content, and highlight progress by which headers I've passed. A good example of this is the right-side menu of the Android docs. Seeing that I've got 2 content sections, an example, and a conclusion left until I finish the article is much more meaningful than some arbitrary measure of text. In addition, it allows me to skip directly to a specific section on the page.

I recently became a technical lead and now I have a team of 2 that I am responsible for. At first, I assumed that I, plus 2 more people meant that we would get 3x as much work done as before and it would be a piece of cake. Oh boy, how wrong I was! Leading a team is HARD WORK! Figuring out exactly how much support each member needs and how to best give it to them while also continuing to technically contribute myself is tough. I have had to accept that contributing less is OK because my time is better spent sharing my knowledge and helping others on my team grow.

TL;DR The hardest part of my job is learning how to effectively lead a team.

It is by design: it is meant to interrupt you from whatever you are doing so that you can provide an immediate answer to any question no matter how inane. Being in constant contact over chat will simply prevent you from doing deep work, and ruin your productivity as a software developer. This is a well-understood phenomenon, but there seems to be no industry-wide consensus on what to do about it. We want to be able to jerk the leash of an employee anytime we want, but we also what high quality work produced quickly. I don't believe you can achieve both in a field where productivity is constrained by cognitive efficiency.

My personal strategy has been highly effective, and nowhere near as controversial as you might think it would be in practice. In the morning I answer any questions for me over chat, then I send out a group message that says, "I'm going offline. If you need me send a text message to my phone number and I'll hop back online." I always kept this promise with no exceptions, so I was always easily reachable. I suspect people regarded a text message to my personal phone number more intimate than a chat message, so they did it far less often. This strategy ended up being so effective, that management ended up endorsing this practice, as its value was highly visible: I produced a far higher than average amount of work at near-perfect quality.