ctroein89's comments

Good error messages are hard. You want to tell the user what to do, but if you knew that the error could be thrown, you probably should have been gracefully handling the problem. You don't know what information is useful to a hacker and you don't know how your error will be propagated. Meaningful errors at one level ("incorrect parameters passed" when calling an API) is perfectly useless at another level ("incorrect parameters passed" when interacting with a React UI). And if you respect all of the above, at some point you'll end up with an error message that basically says "I can't tell you what, why or how something went wrong, but it did."

We still default to Objective-C in our SDK. We still support iOS 11, and I don't think we've been bothered enough by Objective-C to check which versions of Swift can be used on the versions of iOS that we support (I last checked a couple of years ago when we supported iOS 8, where the compatibility matrix was a problem for us). However, the examples are in Swift, and we're using Swift wherever the language doesn't matter. iOS's Objective-C support and Objective-C/Swift interoperability is good enough that there aren't business pressures to switch, and the code isn't changing frequently enough that refactoring to Swift would save us in overall time/effort.

That being said, we are going to refactor from Google's Closure Compiler to TypeScript on the JS side of the project: surprisingly, we've seen more discomfort with developing with Closure Compiler than we've had complaints with developing with Objective-C.

Objective-C is a really neat, old language. Initially I was very gungho about switching to Swift, but all of my pain points are with the Apple APIs that we're accessing (and not Objective-C itself). If Objective-C had dot-syntax for calling methods, some more modern typing, and the less verbose Apple APIs, I would have been very happy sticking to Objective-C.

Twitch should have offered a merchandising business via Amazon. It feels like Twitch should have understood how their streamers make money, and ensure that all of that monetization happens via Amazon in some way shape or form, whether that’s a print-on-demand business or facilitating product placements.

Video is expensive, and streamers don’t like ads.

Amazon has for years been saying that they think that Twitch is under monetized. In their minds, 20% of watch time could be ads, just like regular TV. Streamers don’t like ads: it kills the vibe when your audience gets a 2 minute timeout. So streamers aren’t running enough ad breaks, and try to support themselves via memberships, merch and other alternative monetization methods. And for some, Twitch is only advertising for the real money-maker on another site. So Amazon doesn’t get the ad money they think they should get, and they only get a cut of memberships.

So then it’s a question of how many servers and engineers are needed to support Twitch, because that will determine profitability.

Mechanical ventilation refers to just using fans. The comment you’re replying to is suggesting that heat recovery ventilators (HRV) be used to transfer heat from the warm exhausted to the incoming outside air via a heat exchanger (or cools incoming outside air in hot climates). It reduces the need for heating or cooling while still getting fresh air into the building.

That distance is London to Stockholm by road, which is going to be unfathomably far for most Europeans. Maybe that could be a road trip across the full length of Norway or Sweden, but generally that’s a once-in-a-lifetime multi-country road trip that one will want to enjoy.

I’ve travelled London to Stockholm before, and the only reason to do it is to travel with a family pet. Otherwise flying or taking the train will be faster, and cheaper.

> While you are not wrong, those requirements are the same for all houses.

Not every house needs triple-pane windows and R25 insulation in the walls, sitting on a 8-ft deep basement, with a steep roof pitch for snow to slide off of. Generally, you want to cut corners, because building to code in New York would be overkill in Texas.

You could have unique plans for each climate zone, but then the slope of the land and the shape of the lot also matters. Ideally, you'd want to be situated on a southward facing slope, beneath the road, so you could have huge windows towards the back of the house to taking in winter sun, natural insulation from the hill, and smaller windows facing the street. If you can't, you'll have to compromise on something that makes the house less pleasant to live in and/or harder to heat/cool.

At this point, we might actually have 100 distinct home designs, for each climate zone and slope. If you're lucky, these standard might actually be compliant with zoning for your lot, and maximize the allowable use of the lot. Every town is different, and who knows what silly rules your town requires.

At this point, you still need a design that local builders know how to build. Builders talk about "communities of practice", where they know how to build a certain way in response to how all of the other contractors in that area will also build, so that a subcontractor doesn't ruin another subcontractor's work. If you hire builders to build in ways they're not familiar with, they'll make mistakes. Most mistakes will be fine, but they could add up to failing to meet the code or standard for which the house was designed.

Ideally, you want to find an architect and a builder who have worked together before, to design and build the kind of house that you want using the techniques appropriate for that design, with the builder having crews of subcontractors that he/she has worked with before. If you've reached this point, you might as well take the extra step to building the perfect house for you, and customize it just a little more.

I love my DF64. I found it on sale, and informed my wife that it'd be her Christmas and birthday present to me: totally worth it. Even with a $100 DeLonghi EC155, the difference from the grinder is incredible.

Sweden abolished inheritance taxes because the cost of enforcing the tax was greater than the taxes raised, and was passed by a left-wing coalition. At the time, it was considered a success of social democracy to not need inheritance taxes (and in fact, everyone, including the law, referred to dödsskatten - the death tax). 20 years isn’t ready enough time for wealth to consolidate like that via inheritance alone, and similar countries (like Norway and Germany) are seeing similarly rapid raises in their Gini Indexes for wealth, without chances to their inheritance tax systems. Something is broken in Western economies, but unfortunately, inheritance taxes in Sweden aren’t the problem.

> Ironically, this tells me some... awkward things about how the author relates to their kitchen.

It also says a lot about how the author relates to restaurants, where a faster dishwasher is a selling point. Faster is separately important from throughput, because if it the takes 3 hours to run the dish washer, that’s a lot of plates that need to be washed and stacked all at once for a restaurant, and a lot of dishwashers needed to handle that volume.

> and no build server

Personal experience is that a build server normalizes deviance. "But it works on the build server" we used to say, as, with time, it become harder and harder to build locally. "Just fix your environment!" we used to say, when it was the build system that was actually at fault. "It's all so fragile, just copy what we've done before!" we then said, repeating the mistakes that made the build system so fragile.

Eventually, the build system moved into a Docker image, where the smells where contained. But I'm still trying to refactor the build system to a portable, modern alternative. If we hadn't had a build server, we'd have fixed these core issues earlier and wouldn't have built on such a bad foundation. Devs should be building systems that work locally: the heterogeneity forces better error handling, the limited resources forces designing better scaleability, and most importantly, it prevents "but it works on the build server!".

I have two heat pump window air conditioners installed in my apartment, with cooling, heating and resistance electrical heating: https://www.frigidaire.com/Home-Comfort/Air-Conditioning/Win.... The problem is that the tech is so poorly advertised, that I had to double-check the specs on manufacturer's website that this model was, in fact, a heat pump. Most people don't know that heat pump window units already are an option.

I'd love for NYC to mandate that ACs must function as heat pumps: the additional parts are cheap, and as America's largest market for window AC units, the NYC market would force competition for much cheaper heat pump window units.

For all their faults, Games Workshop is really a miniatures company that has a ruleset, rather than games company that sells plastic models. I recall seeing a statistic that the majority of their customers don’t regularly play, and a shocking number have never played a game. Those customers are buying models because they think the models are neat, and are deriving fun from the act of assembling and painting.

From that perspective, the business is as sustainable as Star Wars or Marvel: as long as this Thor offers a better fantasy than generic Thors, the brand will last (and accumulate the advantages of a deep, lasting history), and therefore will outlast competitors.

It’s reasonable to have tickets that are “is this API interesting to us?” or “how do clients use this new system?” It’s not a “problem”, and there aren’t definite goals. The task is open-ended, and it’s ultimately up to the developer’s judgement to decide that they are done.

To define terms, “the problem” is the issue faced by the client or the customer. The task isn’t the problem. A team should tackle tens or hundreds of tasks while still learning to understand the full problem. This is the motivation behind iterative processes like Scrum.

The author’s message is that if you don’t fulfill all 50 requirements _at all times_, you don’t even deserve to be a software developer (not even a junior). I disagree. I think I get the message that these rules are trying to send, but I think they are, as a whole, unreasonable in a professional, business environment. Everyone should be a product engineer, but being product-focused necessitates speculative activities that exist for no other reason than figuring out the boundaries of the problem being solved. And those activities need to be repeated as the problem is being solved, to evaluate if the problem is correctly understood. Someone, whether that’s a junior or a senior, needs to be spending time doing things that aren’t articulateable so that everyone else can articulate exactly why they are working on their current tasks.

As I become more senior, I’m starting to appreciate all of the tasks that don’t go onto the sprint board and aren’t articulateable. They exist because I need to know enough about Product’s or Account Management’s job to communicate with them, and I won’t know what exactly “complete” is until I’ve reached completion on those tasks. That’s part of the job, and I reject any list of rules that leaves no space for those activities.

> 1. I can articulate precisely what problem I am trying to solve.

> 6. I have a Plan B in case my solution to my current problem doesn’t work.

> 9. I can clearly articulate unknowns and risks associated with my current problem.

These rules imply one of 3 things about the author:

* That author only encounters problems that have been fully solved before

* The manager gives zero weight or value to discovery

* The manager expects the whole project to have been fully specified before starting

Yikes, that's toxic! I think it's important that engineers have the mindset of understanding the problem, but that means that figuring out the problem is part of the work! Which then means that engineers should definitely have periods where they don't understand the problem, where they don't have a Plan B yet, and don't know what the unknowns are, because they can't know what the solution will be until they've started the work.

Drafty houses are not healthy houses: timber needs to be able to dry out to stay rot-and mold-free, but draftiness is associated with weakened immune systems and therefore poorer health. The draftiness rule only holds for older houses constructed before insulation, where the draftiness is needed to counteract the cool, stone/brick basement collecting moisture. A modern house design for insulation should be tight and mechanically ventilated, both for the maintenance of the structure and for human health.

> As a cross-platform compatibility layer

We use docker in this way for work, and it’s merely okay. We use docker to bundle the environment (which changes rarely) separate from the code and build system (which changes often). For this, docker has been great for 95% of all our internal users: way more than a makefile helped, but the remaining 5% were a huge pain. The most recent issue was the in-docker user having a different id from the local user, which isn’t a problem on macOS but is on Ubuntu.

At the point where docker made sense as a compatibility layer, it was trivial to convert the whole system into a service running on Kubernetes.

Mind expanding a little on your complaints about Helm? I’ve only used Helm as a templating solution (and even then only to differentiate between local, staging and production), so I’m curious what problems I have to guard against.

> The thing is, just like a car can travel on any road a computing device can execute any software. Apple deliberately breaks this functionality.

But in this analogy, the hardware is the road, not the car. The road is the literal platform on which everything else runs. And Apple's argument is that they aren't quite building a "road", they're building a bespoke people-mover system that they continue to maintain (like the Boring Company's Las Vegas tunnel system).

Just to nit-pick the analogy some more, real cars don't run on just any road. Roads have weight limits, height limits, and speed limits (and most places make it illegal to drive significantly slower than surrounding traffic, effectively creating minimum speed limits). John Deere builds golf carts that aren't permitted on highways, and Scania's trucks too heavy for some bridges.

The better analogy here is that if a German band plays a concert in the UK, they still need to pay UK taxes on their ticket sales. Even if the band is incorporated in Germany, the portion of the tour that occurred in the UK is still subject to UK taxes.

Additionally, most European countries permit duty-free sales to foreign citizens in normal stores under the right conditions (often via requiring a passport to be shown at purchase, and via refunding the taxes at airport when leaving the country). This arrangement works because, it's generally required that travelers pay customs on arrival to their home countries on goods purchased abroad anyway. That being said, I've just learnt that the UK has killed their duty-free sales system as of 2021 [1], which is just stupid.

[1] https://www.executivetraveller.com/news/uk-to-axe-duty-free-...