One thing I never see considered in these discussions is the terrible state of high-speed residential broadband in the United States. Whether or not my team wan

One thing I never see considered in these discussions is the terrible state of high-speed residential broadband in the United States. Whether or not my team wants to do constant video calls, I can't. One of the things I did when I first started working from home is set up my router with OPNSense in preference to the ISP-provided router, which gives me some visibility into fine-grained details of traffic. Early on, the defense program I'm working on was big into pair programming. With a distributed team, this meant screen-sharing through Teams for hours per day. I could see turning on HD screen sharing and video feeds causes Teams to eat up 90%+ of my bandwidth, and additionally by tracking the data rates I'm getting through the WAN at different times of day and different times of the week, I can see very clearly that my ISP is throttling me when I'm using that much bandwidth. I may be paying for 400 mbps, but if I actually try to use that, I won't get it for more than a few minutes a day, or I'll get it for Netflix and Amazon Video, which are clearly paying for preferential treatment now that net neutrality is still not a thing (it will be interesting to see if they'll just started getting throttled as well if the FCC chooses to reinstitute net neutrality). Unless and until my employer or whatever acquisition office for the contract we're working on is going to run a dedicated leased line to my house that guarantees me consistent high-speed access, or they're willing to pay the ISPs for preferential treatment like streaming services do, nonstop HD audio and video is simply not going to happen. An hour a day is fine. I don't want to say never have any primarily voice-based meetings. Talking to people is important for many reasons. But at some point, when you've made a design decision, write it down. When you've begun implementing something, write down why you did it the way you did, how it works. It's easy enough to say documentation grows stale, so why bother? Then keep it up to date. Block out time in your work planning to do that. You wouldn't learn how to use the programming language you're learning, the operating system you're using, how TCP/IP and HTTP works, how a browser renders html, by asking the original creators of those tools. They wrote down how those things worked, and committed to a public interface, and you learn by reading as you're doing. I've been bit far too often by organizations that want to deliver fast and scrimp on documentation, and all the knowledge of why a particular design decision was made rest entirely in one person's head, and that person leaves, and the rest of us are left to reverse engineer whatever it is they did. You gain speed up front for your very first delivery, but then permanently cripple yourselves forever after. Maybe the vast majority of developers are just making screwdrivers and it doesn't really matter. The plan is to deliver anything quickly, generate some hype, and get acquired, and they don't care about product longevity because they won't be around for it anyway. But at least some people are making jet turbine engines, or something worthy of being included in that rebuild civilization from scratch archive that documents how to create all of the lasting and essential technologies that enable modern life. That has to outlive you. It's already not scalable or workable to try to contribute to the Linux kernel by asking Linus Torvalds personally how it works. Thankfully, it has great documentation. But imagine if you were at Google trying to work on Android and wanted to ask Robert Love why it is doing a particular thing. He's not even there any more! Thankfully, he not only contributed to the wonderful kernel documentation project. He also wrote books about it! And they won't grow instantly stale because the design decisions were well thought out and the APIs are fairly stable because of it. Writing out the rationale behind your design decisions is one way to force yourself to make sure they are actually well thought out.