It's very important to realize that some people are working remote by choice. And many more (right now) are doing so by necessity. The latter is basically an invasion of work into their home.
These are not people working at home because they want to, they're camping and coping.
In our house, I work remote by choice (for over a decade). My wife is working remote because her company closed their offices (now permanently). Add in kids needing space for school every weekday and...oof.
Nothing about this is normal. And I'm an introvert who recharges solo.
One cool thing about working from home is I can hang in a video call with coworkers or crank the speakers and heads down on a problem/code/whatever. Except I can't do that last part, for the last 14 months.
Even for remote workers, with family changes...advice differs right now.
You know what I'm thankful for? The culture at @StackOverflow. I have 2 days a week blocked off from meetings to have the kids on those school days.
And not once. Not one a single time in 14 months has *anyone* given me any grief about it, even though it makes scheduling harder.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I still don't think a large portion of .NET developers know that adding optional parameters is a (binary) breaking change.
Requests on details here - fair enough!
Let's say you have a method in a library:
Get(string foo)
Caller: Get("test")
You add an optional param, let's say:
Get(string foo, int bar = 0)
("Type is not important here")
Without a re-compile, that's a missing method exception.
Why? Because the method was Get(string), now the method is Get(string, int).
Optional params, importantly, are baked in *AT THE CALLER*. So if your code is calling:
Get("test")
...what that's actually compiling to is:
Get("test", 0)
(whatever the default was at compile time)
There are no redeeming qualities. None. There’s a hardware shortage everywhere, they gobble energy supply in a completely unsustainable model, and almost everyone involved is only doing this to make money…in another currency.
The entire thing is based around consuming energy and occupying hardware. The value is 100% imaginary. The system is based on a perceived value, and given people are in and out to make money off that perception: it’s basically a pyramid scheme.
Cryptocurrencies are a blight.
Oh look, all the bitcoin fanatics are coming to change my mind!
The last 3 days is one of the longest deep dive debugs we've had in years. We finally got the culprit for some timeouts this afternoon: the compiler. It eats more CPU in a later version, not by much, but enough. Here's a segment of our build with .NET SDK 3.1.402 vs. .NET 5.0.101
Note: we've run builds on our web tier for the past decade. Why? Because they're typically at 5-10% CPU and we don't have a lot of hardware - so we used the spare capacity. Now, with Roslyn pegging all cores in that spike, it finally hurt.
Let's walk through the past few days.
Typically, our web tier is very idle, you could say it's boring. Thread pool queues sit at 0, the largest app sits at 1-4% CPU, and concurrent requests are generally sub-10 (because they're in and out fast). It looks like this (last 7 days - note the spikes the past few days):
We're currently working on a way to dump all threads from the current app pool somewhere when an event occurs to narrow down the blocking issue. This is getting fun, processes dumping themselves.
We are definitely calling this method Dumpster.Fire();
I explained this a few times today, and I think it's important for every dev to know: timeouts are not necessarily what they seem.
A timeout happens when an operation doesn't complete fast enough. But, what does that mean? What are the details of that check? Well...
You almost never check timeouts live, unless doing so is VERY critical and worth being a primary CPU consumer. That's very expensive. Usually, what happens is one of 2 things:
- A timeout event is queued, and if it goes off first: boom.
or:
- Timeouts are checked on an interval.
If you check timeouts "live", well...nothing's "live". It's some period of time, even if it's 1ms.
To queue a timeout with the event and you're checking both: that means another item to track and schedule, which means cost, that scales.