155 karma · joined November 21, 2016
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.
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.
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.
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.
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.
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'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.
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.
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.
> 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.
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.
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.
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-...
Sony explicitly didn't allow for cross-play until 2 years ago [https://kotaku.com/sony-is-finally-allowing-cross-play-on-th...], even though it was technically possible before then [https://www.engadget.com/2017-06-24-rocket-league-cross-netw...]. In fact, the only reason Sony opened up to cross-play is due to pressure to stay competitive with rival platform Xbox. This was a take-it-or-leave it situation, but Sony was too big to leave. Nothing changed until Sony caved to social pressure.
If the argument is that Apple is a unique kind of device that Apple has a monopoly over, it would hard to argue that Sony and Microsoft don't enjoy the same monopoly powers. On the other hand, if argument is that it's easy enough to switch from Playstation to Xbox, then how is that different from buying a new phone?
In fact, I would bet that Epic sued Apple not because it's more monopolistic, but because they want to set a legal precedent that they can then apply to Playstation, Xbox and Switch, without threatening Epic's core business on consoles.
Carpentry, both the house-building and furniture making kinds, have adapted by emphasizing tricks to measure lumber without rulers. That means starting with more wood than needed, and cutting down to make pieces fit.
There are videos on YouTube of people using Xbox game streaming, but it requires setting up a VPN at home which presumably few people do.
Edit: with the Stadia launch, I'm currently working on setting up a Raspberry PI as a VPN server to try this myself.
[1] https://www.onmsft.com/news/you-can-grab-an-xbox-one-s-all-d...
As-is, Google just happens to be first-to-market in the current generation of on-demand game streaming options. But we've seen this technology before, and I could get the same results with a high quality VPN set-up to connect to a Xbox at home.
I think this comment comes off as misleading, so I'm going to fill in with knowledge gained from a past career. The regulatory environment didn't create this set-up, and it's not really institutional capture. We've gotten here through the market finding it's own Nash equilibrium.
For the most part, American drug coverage is driven by traditional American employer-based insurance or by insurers who make the majority of their money via employer-based insurance. Medicare provides general drug coverage via Medicare Part D, but Part D is optional for patients, and administered via traditional insurers. For some specialty drugs, Medicare provides drug coverage via medical coverage, but those prices are specifically set based on the average prices paid by commercial insurance. I can't recall how specifically Medicaid handles drug coverage, but it's not a large enough segment of the population to distort the market by itself. Therefore, consider the playbook for a drug manufacturer looking to maximize profits:
The playbook for a drug manufacturer looking to maximize profits in Europe looks like this: * In northern Europe, price your drug based on some value per QALYs as outlined in national regulations * Most of the rest of Europe, assemble a team analyze the bidding and tendering rules and devise a pricing structure around those rules
The relationship between different tendering systems might be complex, because some countries may require that they get the lowest price offered to any of their neighbors, while others are willing to grant complete exclusivity in a class in exchange for more favorable pricing (ie, beating out similar but different competitor drugs). You're going to need a team of specialists to navigate the terrain, but fundamentally the principles are simple.
By comparison, the playbook for a drug manufacturer in the US looks like this: * Raise list prices noticeably * Negotiate with insurers for formulary access in exchange for rebates * Offer co-pay assistance programs for patients * Next year, repeat
List prices are essentially just the starting positions in the US, and are essentially made-up. Insurers will negotiate for rebates, in exchange for not requiring prior authorizations or setting high co-pays or coinsurance. Prior authorizations are generally effective at dissuading doctors from prescribing a certain drug (because it's more paperwork), but the efficacy of prior authorizations goes down as competitor drugs also require prior authorizations (or if there are no competitor drugs). From the manufacturer side, the only way to circumvent prior authorizations would be have pharma reps help fill out that paperwork, but that's illegal for multiple reasons (as I understand it, this one of the crimes that brought down Insys Therapeutics).
Co-pays are generally less effective in dissuading prescribing by doctors. That's because co-pay assistance programs let drug manufacturers cover the patient copays, a) makes the drug manufacturer look good in front of the end consumer, and b) let's the drug manufacturer price discriminate based on patient income after-the-fact. An insurer could choose the nuclear option and ban any drug that has co-pay assistance, but that's a heavy-handed method not popular with patients or employers (especially if the manufacturer structures the co-pay assistance as a separate charity).
Insurers will respond by banding together behind PBMs. The PBM will get a cut of the rebates that they negotiate, so higher prices will make it easier to negotiate with them. Medicare drug coverage is split between being run by traditional health insurers via Medicare Part D (most conventional medications), or having prices set as fixed discount on average prices via Medicare Parts A, B and C (most specialty drugs). Medicaid will be the same way, with a steeper required discount. The drug manufacturer can think about Medicare and Medicaid after thoughts.
Additionally, the drug manufacturer knows that costs will ultimately be passed to employers. While insurers and PBMs need to negotiate for those rebates, they don't need to negotiate that hard since the cost will ultimately be passed onto insurers. As long as the PBMs are negotiating a better deal for insurers than what insurers would have gotten on their own, everyone in the negotiations will be happy with the rebates.
Fundamentally, rising prices are a result of the system being stuck in a Nash equilibrium that's extremely favorable to drug manufacturers that understand the game, which means raising prices.
As a side note, we're starting to get integrated health systems (where the insurer and hospital network are the same company) a side effect of hospital systems consolidating, that can buck this trend. In general, the average working American sticks with the same employer-provided insurance for less than 2 years, since they'll either switch jobs or their employer will shop around for cheaper insurance. Because they tend to dominate specific locales, the integrated health systems tend to stick with patients longer, and therefore have much stronger incentives to find cost effective care for their patients than traditional insurers.
My experience is that testing the interactions of historic versions of different components in a mono-repo against each other is difficult. With a multi-repo set-up, one can checkout to whatever historic version one needs to test. That makes it trivially easy to set-up testing that allows one to test historic versions of components against each.
I find this approach to versioning and bugs problematic, because public APIs are about the contract with the user. It's hard to work with contracts with undocumented portions. If my API says that the behavior is supposed to be one thing, and in certain cases its different, my obligation is to bring the behavior to be consistent with what my API documentation says it's supposed to do. I feel like any other position would be a slippery slope into arguing that any change in behavior needs to be considered a breaking change, and therefore there's no such thing as a patch version change.