Around Vancouver our heat pump has performed adequately even down to -15C/5F. This may be related to it being a deep ground loop geothermal setup (vertical instead of horizontal), and the type of building (concrete). We do have a gas fireplace as backup, but have not needed it at the temperatures we see in this corner of the world.
I like the Serious Eats format, where they provide both a brief recipe and an optional backstory. Some of the research and reasoning is interesting for certain recipes (like pressure cooker French Onion soup), though when actually cooking the story makes finding the details a bit more work.
Wow, I had forgotten how retro-industrial those Atari language cartridges were. I also forgot how rich the language was, given the constraints. Great memories!
> "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." ~ Rob Pike
I used Markdown for recipes for more than a decade, where UL were ingredients, OL were steps, and you could use as many sets of both as needed. With some CSS and JS it worked pretty well, but wasn't super accessible for family members to add recipes to (but was great for me).
The price isn't even that bad, but it produces so much more packaging waste than cooking from scratch. We enjoyed the recipes, the price was good enough, but our recycling load doubled or more.
I should have said that there is no technical reason for delaying a streaming release, nor does it really affect the quality of the watching experience (assuming people have good streaming setups).
This is the crux of the issue: that cinema hasn't caught up with streaming services. There's no reason to force people to wait to stream a movie, i.e., they could show movies and stream simultaneously, maximizing consumer choice (rather than maximizing cinema profits).
A lot of guys are boring, especially for people who have studied and focused in their specialties for years and years. You have to find common ground, and that can become increasingly difficult unless your friends share parts of your core interests.
I work pretty hard to maintain some normal interests, enough that I can chat with pretty much anyone. I do find deeper relationships difficult though, as there are fewer people who share my real interests in my area (or even in my cohort of long term friends). Finding those people is difficult.
I've never found developers resisted reasonable unit tests, though teams may squabble about what _real_ unit tests are, or may have been burned by poor approaches to unit testing in the past. If you can find the cause of resistance, all teams I've worked with have been happy (even excited) to get better testing in place. It makes them more productive and more successful when done properly.
What I find more common is for the business to be unprepared to make lateral changes to a product. Even rational unit tests are a medium term investment. You need to spend time developing features customers don't see, and apply those tools for some time, to see quality differences. That can be difficult to justify in a number fairly normal business scenarios (low cashflow/reserves, high tech debt/regret, etc.).
To help offset the cost (and delayed benefits), I've always suggested phasing in unit test strategically. Pick a module or cross-section of the product that is suffering from bugs that customers see (i.e., affecting revenue) and add the minimum viable tests to that. Repeat as needed, and within months/years, you'll have coverage that fits the business needs well.
It's not exclusively a benefit, but it does have some powerful upsides:
* Less commute time and cost (I save 8-10 hours a week, plus a few hundred a month in parking, fuel, and insurance)
* More freedom and flexibility (not every gig offers this, but many do)
* A bunch of focus time
* Communications (oddly) are greatly normalized as everyone has the same handicap. I find a fully remote team easier to manage than a mixed one, as no one has an advantage over another (as happens when part of a team shares the same office).
On the other hand, you're maintaining your office space and much of your setup (internet, wifi, heating, desk, chairs). Again, some jobs offer some compensation here, but some of it will be on the employee to maintain.
You're also more isolated, and team culture takes a bit more work to create and maintain.
Personally, I value the option to work remote as a net gain. I love my home office, I save time and money on the commute, and I have more time to focus than in the office. I understand the company benefits too, as they pay less rent, own fewer fixtures, and get more of my time. But I still see it as a net win for me.
Most of these points all relate to having empathy for the developer and being kind, and focusing on the point of code reviews (which is to improve quality and reduce ongoing costs).
Example:
> Unhelpful behavior: overwhelming with an avalanche of comments
Code that isn't consistent to standards absolutely needs to be fixed. And while it's a lot of work to keep code up to standard, the author is correct that the nitpicking approach is unproductive.
A better approach is to review code like this, see that it falls short, and suggest realistic (and in turn kind) ways to improve things. Picking at each missed space is clearly counter productive, and there are more standard and helpful solutions.
I don't think things like minutia fit in code reviews either, but the small stuff does matter.
I feel the same about the other suggestions, they can be boiled down to: don't be an ass; be kind; be constructive. Just imagine that you're reviewing your own code from 5 years ago.