Thanks, that was interesting to learn, I’d never thought about how odd the phrase sounds as-is.
There’s a fascinating complexity to what constitutes constructive feedback, criticism, or dismissal. And to when it’s okay to provide one, the other, or none at all.
A new bug appears, it’s in an encryption layer. You solve this by deciding to disable the encryption layer because user experience is better without the errors. You write it up as a recruitment piece for your engineering team.
There may be some good answers and lessons, but they didn’t make it into the article. Saying it’s on a cloud provider’s private network so encryption between your nodes isn’t necessary is a bold choice. Also, what happened to the root cause? Why did it start failing a week ago? Was a downgrade of the offending code not possible?
Not all bug investigations are worth really digging into. Sometimes the right call is to find any fix and move on. But all the nuance, judgement, implications, and lessons learned failed to make it into this post. And they are what make reading incident reports interesting for most engineers.
As pointed out in the article, naproxen is an NSAID like Ibuprofen, though slightly more COX1 selective. It likely has a somewhat lower risk of serious renal and cardiovascular events, but higher risk of GI bleeds. There are some studies that show little to no increase cardiovascular risk, but most do show some or even comparable to ibuprofen.
Convenience vs ibuprofen is a thing given the longer half life, but it still generally comes with similar risks. If you are taking anything for more than just an occasional headache, definitely discuss with a doctor, COX2 selectives like celecoxib may be a better risk profile and even more convenient.
(COX1 and COX2 selectivity loosely separate which systems get the brunt of the side effects)
Neither WebRTC or WebGL are remotely ‘useless’. Very fair though to say that you would prefer to have them disabled and/or whitelisted for certain sites.
Calling the industry largely a scam is pretty strong. Of course for the small minority of technically competent people with interest and time it will always be cheaper to do something yourself rather than pay a business to accomplish the same thing. But most people cannot/do not want to do it themselves, and regulations are there at least partially to help protect them against the house-fire-waiting-to-happen untrained handyman.
Sure a bunch of businesses opportunistically up-charge, some I'm sure are predatory, and there are obviously efficiencies to improve, but overall scam it is not.
Not really. The majority of data center water withdrawal (total water input) is consumed ("lost" to evaporation etc...) with a minority of it discharged (returned in liquid form). I believe it's on the order of 3/4ths consumed, but that varies a lot by local climate and cooling technology.
There's lots of promising lower-consumption cooling options, but seems like we are not yet seeing that in a large fraction of data centers globally.
Best comment by far. The post suffers from making good points about the lack of rigor and narrative nature of the book, but then does exactly the same thing to claim the opposite conclusion the book makes.
Thanks, you have helped at least me think a bit differently about this. I still believe primary energy is a valid way to look at the problem, but see more clearly how easily it can lead an uninformed audience to a bad conclusion.
And on heat pumps - it’s sad to reflect that even if we replaced all heating, it’s still only a couple % of the total rejected heat. There are few easy wins in this game, just many different ways we need to chip away at it.
Ah, seems like I was missing some context where the fossil fuel and anti-renewable folks have been using the term in arguments against trying to change.
I’m not sure of Smil’s politics but to be fair, there’s nothing in that quote that is inherently misleading. I can see through how others could spin it, and I’ll be more careful knowing the term has some politics behind it now. To me his argument in the article is that it’s not practical to expect a transition in a 25-year timescale, not that it’s impossible or not worth working on.
Heat pumps are a good example where the practice has been a lot harder than we might hope. Sure COP > 4 for heating is great, but the units are very expensive today, and in most of the US and Europe with sub-zero winter temps operate with much worse efficiencies, making them significantly more expensive to operate. I’m sure with effort those issues will improve, and major policy shifts can help mitigate some of the costs. But especially without a strong will today those changes are practically too far off for the 2050 target.
Primary energy sources are what they are, both your comment and the linked article seem to imply discussing them should lead to a deserved punch in the face. Can you help me understand why?
As far as I can tell, your link argues that if we overcome all the practical challenges (politics, resources, financing, technical innovation) and go all-electric for global energy, we only need ~1/3 as much input energy potential as we use today for the same useful work. That’s useful, but the hard part lies in those practical challenges. And the primary sources of global human energy use are a long way away from that goal.
So should we strive to get there? Sure. Should we be tactical about how? Yes. And the link seems to argue that as well. But is it reasonable to hit our 2050 goals based on the current global fossil fuel usage? Not really. So I’m really missing how this refutes Smil’s article, and why “primary energy” is such a stupid thing.
So there’s another force at work here that to me answers the question in a different way. Agents also massively decrease the difficulty of coming into someone else’s messy code base and being productive.
Want to make a quick change or fix? The agent will likely figure out a way to do it in minutes rather the than hours it would take me to do so.
Want to get a good understanding of the architecture and code layout? Working with an agent for search and summary cuts my time down by an order of magnitude.
So while agree there’s a lot more “what the heck is this ugly pile of if else statements doing?” And “why are there three modules handling transforms?”, there is a corresponding drop in cost to adding features and paying down tech debt. Finding the right balance is a bit different in the agentic coding world, but it’s a different mindset and set of practices to develop.
What does Germany use to manage microorganism growth in it's water distribution system? As I understand cloramine/chlorine is used to keep the small amounts of microorganisms that will always be present in water and pipes from growing into a problem while it travels/sits in the distribution system.
As I imagine it, Einstein would no be happy with fixing a couple bugs and making a state machine. Einstein would add a new unit test framework and implement a linear optimizer written with only lambdas to solve the problem and recommend replacing the web server with it as well. This is tongue in cheek but gets the idea across.
So this is a really good example of small sample size intuition being a big challenge. Fatalities happen on the order of billion miles driven - obviously people don’t come to that. Take a few thousand miles of positive experience sets a statistical floor on accident rates, but that is orders of magnitude away from how safe (or unsafe, depending on how you look at it) human drivers are on average. FSD and other, less capable L2 systems are amazing at paying attention in situations where humans fail, but also tend to have major limitations in places humans will largely do great most of the time. Your experience, as positive as it has been, doesn’t support the assertion that fatalities would decrease.
There’s a fascinating complexity to what constitutes constructive feedback, criticism, or dismissal. And to when it’s okay to provide one, the other, or none at all.