Moreover, legality doesn’t even necessarily imply reduced cost. I’ve heard anecdotally that in California illegally produced cannabis is cheaper: it’s not taxed and there’s no cost to meet regulatory compliance for the producers.
>Making a product legal increases its availability, affordability and reach. So, the number of people exposed.
Really, a prohibition argument made with a straight face?
North American governments famously failed to maintain a ban on alcohol. How well do you think they'd fare with trying to ban sales of caffeine, given it's reach is greater (and far more socially-accepted) than alcohol?
Much better, because alcohol can be made with any grocery store items (like fruits and bread for example) so nearly impossible to ban, whereas caffeine without coffee beans or tea leaves is going to be extremely challenging.
>Much better, because alcohol can be made with any grocery store items (like fruits and bread for example) so nearly impossible to ban, whereas caffeine without coffee beans or tea leaves is going to be extremely challenging.
Don't forget the vast selection of caffeinated pop/soda, energy drinks, etc. You're talking about a wide ban here, as this is one of the world's favourite drugs, covering a very popular array of beverages. If you're daft enough to propose it, I suspect you'd be laughed out of the halls of legislatures.
Regulation of caffeine levels in energy drinks and pop is probably an easier sell, and some jurisdictions already do this.
Oh yeah that’s a good one. Both Zeus and Jupiter are cognates of Dyus Pter (Sky Father) of old Indo European mythology. They just took different parts of that name.
This is a tangent but it reminded me of Christopher Hitchens when he used to claim that waterboarding is not torture. He then subjected himself to waterboarding to prove that it's not torture and changed his mind in 5 seconds.
Despite me not agreeing with a lot of what he said I really respected that he was willing to put his belief to the test and then actually changed his mind when he was proven wrong.
The conservative radio host "Mancow" did the same thing. I don't think I've ever heard a story of someone getting waterboarding and still maintaining that it's not torture.
Unfortunately, developers often write code in a framework they don't know well so they end up fighting the framework instead of using the niceties it provides. The end result being that the surface area of things that can go wrong actually increases.
True. But I also find that a lot of frameworks are narrowly optimized for solving specific problems, at the expense of generality, and those problems often aren’t the ones I have.
Supposedly declarative approaches especially are my pet peeve. “Tell it what you want done, not how you want it done” is nice sounding but generally disappointing when I soon need it to do something not envisioned by its creator yet solved in a line or two of general purpose/imperative code.
Most companies unfortunately don't let developers adequately explore solutions or problem spaces before committing to them either. The ones that dominate do, but that's also because they often have the resources to build it from the ground up anyway.
The average mid-sized business seems to have internalized that code is always a liability, but they respond by cutting short discovery and get their just deserts.
> Culture Amp was well on its way to doing this in 2018, when things started to get hard for the recently-formed Design System team.
This is the problem right there. Design system teams never work well. A design system that’s complicated enough to need a dedicated team always creates more friction than it’s worth. Turns out that it’s really hard to standardize UI components in a way that makes them flexible enough to be used across different teams.
The only design systems I’ve seen work well are the minimal ones that just define the color values of the visual theme and look of some basic components like buttons but leave the implementation up to the individual devs.
Just speaking it off my ass here, but it could be the scale of those companies that make those teams viable. Like let’s say you have some standardized systems that can cover the use cases of 20% of your teams. If you have 1000 teams vs 10 teams, covering 200 teams might make economic sense, but 2 teams wouldn’t
I work at Culture Amp and was once team lead of the Design System team.
Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive.
At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.
The problem, with something like a Design System and many other aspects of organizational management, is that efficiency measuring tends to ignore the overhead, the death by a 1000 papercuts, and only focuses on the sweet points.
There’s also the part where they just let teams get away without fulfilling their responsibility to update both versions of a component and just let their tech degrade.
I'm at the point now where I think a design system team is huge mistake unless you've got 25+ people to permanently staff it. At best the team will provide more consistent UI/UX. At worst they will slow all other teams to a halt with poor documentation, bugs, and broken libraries.
I've seen three different ~100 person companies throw decades of person years into building out design systems, each to eventually throw it all out. By which time many teams have been forced to adopt the half finished project, so now they've got to tear it all out.
We all know now not to build our own databases unless there is an extremely unusual need. In another decade or two we'll say the same thing about design systems.
There's nothing wrong with some CSS colors and basics. But you'll only invite ruin if you try to build out (or wrap) React or Angular libraries. I'd guess right now that a full design system library takes about 25 person years to complete and 10 person years per year to maintain. By which time the target language and libraries will have changed so much you'll have to start over at the beginning and start upgrading.
Every company I've seen try this staffed the team with about 5 people. So they've got about 5 years to get to 100%. What has changed in the front end in the last 5 years? I know one design system team that started 5 years ago on an Angular 1 design system. No they don't have Typescript, no it doesn't work in Angular 16. I know another design system team that started about 6 years ago in Angular 1, then restarted 4 years ago in Angular 2, leaving most of the company on the Angular 1 version which was about 40% complete. Then 3 years ago they decided to stop forward progress for a year to go back and add Typescript types to existing components. They still aren't 100% on the Angular 16 version.
(I think Typescript is great, but I'd guess it adds at least an extra 5 person years to the timeline, since you have to be pretty great with Typescript to accurately apply it to a design system.)
All this to say, building out wrapper libraries for a design system is _really hard_. Just the documentation is probably 5 person years of work. The whole thing is expensive, tricky, and error prone. Unless you can staff 5 teams of 5 permanently, the front end just changes too fast to keep up. The ecosystem will look so different in five years, you'll need a whole division working forever to keep up and move to new tech while simultaneously maintaining the old versions.
And heaven help you when your designers get tired of the look of it after a year and want to redesign it all again. Because they will. (Wasn't that the point of all this, easy changes to the UI?) Now you've gotta go back and update all the half finished Angular 1 code and release a new version, along with your half finished Angular 16 library.
The golden path here is to just provide some basic CSS for buttons, tables, uls, inputs, etc, along with documentation and a site that shows it all in use. Put it up on a CDN with a version in the name so teams can upgrade easily. This whole project could be done in under two person years, just a UI engineer, a designer, and maybe a QA person. It's quick, and after it's over, everyone can work on something else. There's no need to keep a big team staffed forever. There's no need to do a rewrite for React Hooks or whatever. The CSS will work forever. Next year when the designers want a new set of colors, spend a few months to have someone release a new version. Don't change any of the CSS selectors. DON'T CHANGE ANY OF THE CSS SELECTORS. Everyone bumps the version on their CSS src tag and it just works. Easy day.
I agree. I enjoyed WC4 even though it went a bit overboard with fmv but the story held up and both Mark Hamill and Malcolm McDowell were amazing. The senate scene at the end when Tolwyn breaks is just great.
Gameplay and story wise I really think WC2 is by far the best in the series. The camaraderie between characters is just beautifully portrayed, and so many moments of betrayal, death, and tragedy were very emotional.
