Ummm, no. The skills required to be a good engineer are not the skills required to be a good manager of engineers. There's some overlap, sure, but you can be an outstanding engineer but have poor leadership skills, or be an amazing and revered leader but terrible at actually designing the stuff your people are working on.

You should be in charge of exactly as many people as you are good at being in charge of. That's unrelated to how good you are at being one of the workers.

Or Go, which looks a lot like C Done Right, was designed for systems programming, and has a positively minimal learning curve compared to C++. I get why C++ exists and what problems it aims to solve, but I don't think I'd want to have to use it to solve those problems when there are more programmer-friendly alternatives.

I have Comcast, and have native IPv6 over my home-grade Internet connection. I can ping6 www.google.com from my autoconfigured laptop without problems.

I don't doubt that they're slow rolling it out everywhere, because when has Comcast ever been in a great hurry to upgrade their network? But here, at least, it works as advertised.

Wow, your setup sucks. My ISP offers native IPv6 and all our laptops, tablets, etc. come up with both protocols live. I have literally never, not once, zero times, ever had a problem that traced back to having IPv6 enabled. Maybe we just buy better equipment or have a better ISP or something, because it Just Works for everyone in our household.

Note that I'm not actually complaining about faster-than-needed Internet. :-) Comcast had 50Mbps service for a small price bump over 30Mbps when I signed up, so we went with it.

OP said the problem of form timeouts was because they're using HTTPS. That is absolutely not the case, any more than it's because they're using Java or Python or Intel or CAT-5. None of those have anything to do with the real reason, which is that the server is programmed to time out idle connections after a set length of time.

I get a choice between Comcast (who works decently enough, as much as I detest their policies) at 50Mbps, or AT&T U-verse at 3Mbps (that's all they could get the modem to train up at). One is more bandwidth than I actually need, but the other isn't enough to handle my telecommuting needs.

Comcast is literally the only ISP available to me with greater than 3Mbps of bandwidth. Given that even the FCC thinks maybe broadband starts at 10Mbps, and that I work in tech and legitimately need decent transfer speeds to do my job, I'm stuck.

That's right. They don't say "we might be recording this conversation". They say "this call is allowed to be recorded". Well, thanks!

Perhaps not; I just write this stuff for a living.

As I said: "What you're seeing is a combination of client- and server-side timers that have nothing whatsoever to do with the transport you'll be using to upload your information."

It has zero to do with HTTPS and everything to do with the webapp having a line of code somewhere like if((current_time()-last_posted_time)>900){logout();}.

You realize that normal forms only open a connection to the HTTP{,S} server when you click the "Submit" button, right? You can sit there for infinite time because there's no open connection to time out until such time as you request it. What you're seeing is a combination of client- and server-side timers that have nothing whatsoever to do with the transport you'll be using to upload your information. And yeah, I'd mildly prefer my HR information to be encrypted en route, TYVM.

I sailed past Peleliu in 1994, the 50th anniversary of the battle. It was horrible to see that insignificant hunk of rock where so many young men died for... what, exactly? It was dubiously important in the first place and looked an awful lot like other rocky islands I'd seen, which drove home the utter futility and waste that it represents. It was a very emotional experience and I'm getting choked up now remembering it.

I'd be perfectly happy never seeing another battlefield in my life.