I don't think this is actually created by the company that owns the brand, Zwilling J.A. Henckels. I think someone managed to get this domain and generated this page (rather quickly, it looks like) to try and make money via Amazon affiliate links. Interesting new strategy.
A mod might remove it if enough people flag it. I think it's still interesting as an example of a new type of fraud, though. The site's been up since January of this year and Amazon and the actual owner of this brand don't seem to care. It's also the third result on Google for me for "Staub Cookware".
I’ve worked on code bases like this. It is a parody, but it’s not too far from reality.
Reading my original post i probably shouldn’t have said it’s how you should do it. I mean that lots of engineers created loads of pointless complexity with OOP
That's Bonappetit for you. All of their videos of this nature have wildly unqualified folks. One of them featured Alex Delaney who I think was the editor in chief's assistant before he became drinks editor. I'm sure the guy cooks, but they lost my respect when they put him in a video about "Pro chefs". (I didn't watch this one, sorry, but I hope he's not in it)
No no no no, it is absolutely necessary to salt the different components that go into a dish. Many things will absorb salt during the cooking process. Salt can also draw water out of an item which will change the way it cooks as well, for example with eggplant. You need to be constantly checking the salt level while cooking to ensure your final product is not just salty enough but salted throughout the dish and not just on the outer layer. This is especially true with proteins, all of which need to be salted in advance in order to get proper penetration.
Re your comment about olive oil, an extra virgin olive oil has flavor and it would be pointless to roast with it, but you absolutely need oil while cooking food as it's a thermal interface between your pan or your oven air and your food. Of course there are finishing oils that tend to be something with a lot of flavor like EVOO, sesame oil, or an e.g. rosemary infused olive oil, but most oil needs to be added during cooking.
I just wish I could cook two dishes, one with salt during cooking, and one with salt after, and do some blind tests. I bet most people would have no idea which is which.
The same thing happened with expensive coke and cheaper coke, or coke and pepsi, or branded yogurt vs cheap yogurt, or very expensive wines and OK wines. And blind tests tend to show that most people can't tell the difference. Yet everybody is convinced that they can :)
No, they are completely different things. Real time chat doesn't make people feel like they understand the overall goals of an organization. If someone says in Slack "we really need to get x done because the customers want it" and other people decide to talk about StackOverflow's hilarious April fools day joke for 5 minutes, some are going to miss that "we really need to get x done".
Your OKRs put that sort of thing in one place. The process to determine what the OKRs are ensure that everyone's on the same page about the objectives. People in an organization want to feel like they know what they're working towards. When they don't they get stressed out and unproductive.
I don't fully agree on this notion. Because implicitly doing this is also surfacing the gaps in achieving those targets.
Most okr are dependent on someone else - the Android app guy will not achieve their okr if the API guy is off doing something else. In that way, the whole aspect of goal setting and achieving that is probably more inefficient using an okr structure than thrashing it out on slack (and most likely in a dedicated channel called "planning")
If you only have six people, maybe :] But we're commenting on a post that's talking about the best time to introduce an OKR process. At my company we don't have an "API guy" and an "Android app guy", we have 30 or so different teams that my team interfaces with in a company with thousands of engineers. We can't just "thrash it out" on Slack at a company of this size.
You need to try and think about what things look like when the company is much, much larger.
OKRs aren’t supposed to directly depend on anyone outside the team or organization. I, personally, can’t fix my contracting office so I can’t set an OKR to improve production rates of our (few) physical products when contracting is always the bottleneck (supplier agreements for materials we need). If we used OKRs, with respect to that element we could only set OKRs that they could achieve on their own (quality, design updates, production rates when they do have material). A couple levels above me are the people who can directly impact the contracting people and set about improving their performance, though.
If you’re setting them and always missing them because of entities with other objectives, then your organization is obviously misaligned and needs to evaluate its goals.
OKRs can help solve this problem, if they're done well. Your OKR that depends on the API guy should derive from some common OKR that's owned by a guy up both your reporting chains. You can point at that to help make sure you get unblocked.
We use OKRs on a team level with the teams of 6-8 people being cross-functional. So the Android and the API persons would have the same OKRs working towards to.
