Cold showers on overhyped topics (2017)
github.com
github.com
It's really hard (I would go so far as to say impossible) to set up useful metrics and it's really hard to create comparable scenarios. And even if you had those, very few things apply generally to all fields of software, let alone the different types of personalities that developers have, even if the stereotypes have a bit of truth to them.
Of course personal experience is very valuable, precisely because it's a (limited form of) research.
I had an incredible moment in a job interview: for context, I’ve been programming for about 30 years and 10 of those years have involved a lot of JavaScript. I was given a timed debugging problem to test my skills: “Here is some JS code with failing tests. Go fix the bugs.” Before I even ran the tests I scrolled through the code to get a sense of it. My instincts tweaked on one section. “This code smells. I don’t trust it.” I said. On second glance - “Oh yeah this is totally buggy”. Sure enough, I was right. The interviewer was blown away.
There’s no way I could do that consciously. Science is great for a lot of things, but when we don’t have science, we could do a lot worse than trusting our intuition.
you can attempt to dismiss that as being a small sample value, but that's the reality.
The reason people want to be so data driven is because it takes the decision making out of their hands, which takes the responsibility for poor decisions out of their hands.
But when it's all said and done, some people are better than others, not all "small sample values" are equal.
Better at what though? Success doesn’t tell you why someone was successful.
The point of looking at larger sets of data is to learn something tangible beyond anecdote.
it's another version of cargo cult programming. The data suggests if a plane is present, food will come. We want food to come, lets build a plane, with no real understanding of where the food actually comes from.
> Better at what though?
whatever the fuck it is you're trying to evaluate. Are you evaluating musical aptitude? then the answer to your question is that some people are better at music. are you evaluating the ability to tear down an engine? then the answer to your question is that some people are better at tearing down an engine.
Linus Torvalds opinion on kernel development is not equivalent to that 16 year old web developer. Dismissing opinions as "small sample value" _completely_ misses the forest for the trees.
Likewise anecdotal success of an individual is also just correlation but with only a single data point.
I’d also agree that expert opinions are great but they’re also not infallible or necessarily generalisable. Nor is it necessarily easy to tell who is an expert and who is a charlatan. Which is why we should use them as the basis for investigating the larger picture.
Similarly both expert opinion and singular anecdotes can lead to cargo culting.
hmmmmmmmmmmm.
> Likewise anecdotal success of an individual is also just correlation but with only a single data point.
oh yeah, someone should tell Linus Torvalds that his expertise is just correlation. Same with Elon Musk, Bill Gates, et al.
"oh but I think expert opinions are great!"
doesn't actually change that stance, whether you think they're great or not is irrelevant to the claim.
Your problem is putting everything into data terms.
stop doing that and suddenly your problems with my responses go away because I stop calling it out as ridiculous.
Data grants authority to a decision that gut feel driven one doesn't. It is hard to argue against evidence as it should be, but that assume a certain level of quality in the evidence.
Second, if practice doesn't match the expected outcome, the first thing you will look at is what the team is doing wrong, not review the decision as not working.
That said, parent is far from unique in his skepticism, so I think the problem is more often reversed in the industry. Having some data, even flawed can help your company decide to try something new.
What is "bad data", and how is it worse than no data?
Have a really dumb example:
All of the developers I work with are short, therefore all developers must be short, and we could save time by filtering job applicants by height.
(Note: I work with only one developer. He's great!)
The alternative is to rely on rich experience and good taste. If you want to make it a bit more rigorous, you can approach this in terms of qualitative research—which makes sense for academic research, but isn't necessarily the best way to learn for yourself or to design tools.
Expert experience is far more effective at capturing complex, multi-dimensional phenomena than anything we can reduce to a small number of easily-gathered quantitative metrics.
At what point, and how do you determine that?
>The alternative is to rely on rich experience and good taste.
Everyone thinks they have good taste.
That is not true
In a different domain I play music in bands
I have played in a band where the band leader was so so at playing their instrument, but had oodles of taste, so much more than me
Not all of us, not many of us, are arrogant pric,s who think we know better or are better than we are
By looking at the research? By understanding what kind of studies and experiments are actually viable? By evaluating what we can measure effectively, what we can't, and how good (or bad!) our proxy metrics can be?
As a field, we really need to understand the inherent limits of quantitative methods.
I'm constantly amazed at how people are willing to throw away data if it's not perfect. All you need is a bit of signal, and it's, literally, better than nothing.
Very few of these kinds of studies follow scientific method well enough to be vaguely useful let alone generally applicable. How many have you ever read of being successfully reproduced?
Everything that's written on the subject -- every bit of research, fad, and personal anecdote -- is just one more experiment flailing around in the darkness while we try to figure out what it means to "engineer" software.
I don't think that makes research about it valueless. Some is good, some is not, some will get revised over time because science and engineering gradually tack towards discovering natural laws. But also, yes, an enormous amount of human effort is wasted on following practices that are often not well-founded.
I think Ian Sommerville does a pretty good job in the book "Software Engineering" (I have the 10th edition), from the section 1.1.1:
> Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases:
> 1. Engineering discipline: Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work within organizational and financial constraints, and they must look for solutions within these constraints.
> 2. All aspects of software production: Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software development.
These quotes don't do it justice. I'd really recommend this book.
I will note though that "Changes from the 9th edition" on page 4 reads to me like it supports my point moreso than contradicts it. I'd also add my favorite quote about engineering, "any idiot can build a bridge that stands; it takes an engineer to build a bridge that barely stands". That's the engineering that is as yet unsettled in software. Any of us, given enough time and financial support, can eventually build some software that does something. Approximately none of us however can agree on the right way to build such a thing (where "right way" means something like "most efficient, cost-effective, and future-proof, according to the users' and owners' needs and specifications").
Hell, pick 10 people from HN and you'll get 12 different recommendations for which language to use.
Well, as this is also depends on parameters. What languages the team members know, what languages the problem domain maps to well, how much capital do we have, what's the schedule, what's the expected rate of modifications on the system, load, security and safety hardening requirements.
All bridges, tunnels, houses, roads, pipes, and dams are more similar than websites, Android, databases, videogames, and embedded software.
Mostly because the former had hundreds of years to settle down somewhat. (And of course there are huge advances due to materials science advances and because of better structural modeling, due to software advances.) And that settling down allows for time to develop models for the common scenarios. That's why there are engineering standards (building codes).
Are you sure about this? I feel like somewhere between "dirt driveway I dug out last weekend" and the Hoover Dam, they would've had to figure some hard shit out. I could probably dig a tunnel with a shovel, but it wouldn't survive the next rain, much less be able to go under the ocean or support a vacuum.
I mean, outsiders probably couldn't tell apart a WordPress template from whatever gee-whiz app. It's all just computer stuff. And as a web dev, I could probably figure out an Android app given a weekend or two, or learn a new SQL dialect in a few hours. I would have no idea how to, say, frame a window for a house or calculate the right materials and techniques to move water from here to there, even to Roman standards.
Sure, that tunnel might not survive, but the way to fix it is pretty clear. More structural support and then protecting the structures from the environment (corrosion, soil erosion from water and wind, underwater currents, etc), and then due to the inherent nature of brick and mortar stuff is they are hard to change after the fact (it's hard to change a skyscraper to have a stronger core to resist more wind loads for example) , so it basically forces the customer to commit to some requirements (eg. how many rooms do you need, how much traffic the bridge/tunnel has to carry, how big floods the dam has to be able to withstand) and this has downstream effects of drastically pruning the search space. And then cost estimation is usually again simpler, because we have measurements (this long, this amount of mass, we need this amount of stainless steel of this grade, this amount of concrete of this type, in this region by this availability, etc...)
> frame a window for a house
sure, but there are about ten options, and you can go through them pick the one you like and get a craftsmen/contractor
Most IT/software problems reduce to very straightforward ones once we have the same degree of constraintedness, but mostly we don't.
1. Derek Jones. (2021, January 17). Software effort estimation is mostly fake research. The Shape of Code. https://shape-of-code.com/2021/01/17/software-effort-estimat...
2. Andy Oram, Greg Wilson, & Andrew Oram (Eds.). (2011). Making software: what really works, and why we believe it (1st ed). O’Reilly.
3. Bossavit, L. (2015). The leprechauns of software engineering: how folklore turns into fact and what to do about it. Leanpub.
> Shower: Extensive literature review showing that formal methods are hard to learn, extremely expensive to apply, and often miss critical bugs.
Glad you had the caveat "Written in 2000". What was hard and perhaps not worthwhile in 2000 has changed. Computers are a bit faster and software is more pervasive.
A colleague of mine was involved in the formal verification of a really tricky cellular network bug. That was around year 2000. It was hard but was still necessary and successful.
GM has a buggy car. That wouldn't have been an issue in 2000. Now it's an issue that forced them to withdraw a car from the market after about two weeks. Not saying that formal methods could have for sure avoided that, but I suspect that it very well may have.
People unfamiliar with formal verification think it means "the code is provably correct", but that's not what it does. Formal verification can prove that your code correctly implements a specified standard. You still have to define and write that standard. And that's where the problems begin:
- Standards themselves can have bugs, or the standard you wrote is not what you actually wanted. Note that this is the same problem that often occurs in code itself! You've just pushed it up a level, and into an even more arcane and less-debuggable language to boot (formal standards are generally much, much harder to write, debug, and reason about than code)
- The standard is constantly changing as feature requests come in, or the world around you changes. Modern software engineering mostly consists of changing what you or somebody else already built to accommodate new features or a new state of the world. This plays very badly with formal verification.
Formal verification can work in areas where you have a long time to do development, or where your problem space is amenable to having a formal standard (like math problems). In most other cases it just runs completely opposite to the actual problems that software engineering is trying to solve.
It amounts to the same thing: it takes a long time to develop, the specification can get out of sync with the code, and once out of sync you now have no provable characteristics of the new system.
Though this does make me wonder: If there exist some formal methods that can prove that code implements a standard, and others that can prove that the standard is correct, it seems like there ought to be something in the middle that can prove both.
The big pay off in formal methods is learning to think abstractly (imho). Even if you don't make a full blown model, sketching out the problem in something like TLA+ can be extremely valuable just by forcing you to think about the modeling independently of code. Even in the world of general software engineering, being able to reframe requirements as temporal invariants has felt something like a super power.
Have you actually tried, or is this just the standard line?
I've heard this from people I've worked with, and when I followed up to ask what kinds of projects they've worked on with Agda, Idris, Coq, Lean, whatever, they had nothing.
I don't have anything either, other than that I've toyed around with some of these systems a little bit. But it seems to me like there's a lot of potential in dependently-typed programming, and we just don't have a lot of experience with it -- which is fine, but that's a very different situation than what seems to be the standard line, "all formal methods take a ton of time and are only viable in a few niche projects" (what are people imagining here? NASA space probes and stacks of binders? really it doesn't seem obvious to me, I'm not trolling).
Those problems have been with every EV it has put on the market since the Bolt (which was developed in South Korea, and largely not by GM.)
https://insideevs.com/news/702126/ultium-platform-owners-gm/
It's just sheer incompetence and mismanagement in one company.
https://news.ycombinator.com/item?id=31793030 (June 18, 2022 — 629 points, 355 comments)
https://news.ycombinator.com/item?id=23935943 (July 24, 2020 — 588 points, 241 comments)
Cold Showers - https://news.ycombinator.com/item?id=31793030 - June 2022 (355 comments)
Cold Showers: For when people get too hyped up about things - https://news.ycombinator.com/item?id=23935943 - July 2020 (241 comments)
Awesome Cold Showers: for when people get too hyped up about things - https://news.ycombinator.com/item?id=17604379 - July 2018 (3 comments)
Awesome Cold Showers - https://news.ycombinator.com/item?id=16019844 - Dec 2017 (1 comment)
Let's stick to bickering about Formal Verification and Static Typing and leave that cold shower stuff to the pros...
> Hof's first attempt the day before failed when he began his swim without goggles and his corneas froze solid and blinded him. A rescue diver pulled him to the surface after he passed out.
this probably has code analogies too...
I mean there's centenarians who didn't do any of these and still got old. Daily alcohol intake, no sports, that kinda thing.
Is this perhaps because frequent sauna access is correlated with higher socioeconomic status/less stress/more free time/etc. What kind of confounding factors did they include in that study?
This can't possibly be true. 65% of Americans are living paycheck to paycheck. They definitely aren't in a position to get a Sauna.
And besides, just because people can afford to do something, doesn't mean that less wealthy people do. Almost anybody could afford to golf, but that doesn't mean golf doesn't skew wealthy if you're looking at the people who actually play. If you looked at how long people who golf live vs people who don't, I'd be willing to bet that golfers live longer. I'm not about to suggest that golf is what is keeping them alive though.
Here at home I belong to a gym for $55/ month and sauna there almost daily, and in prior home in Green Bay, each YMCA had a sauna included with membership. Mostly northern cultures and many southern have had something similar for thousands of years. The Oneida tribe outside Green Bay has regular sweat lodge ceremonies, same basic thing. I won’t enumerate the benefits of a true deep heating sauna but it is deeply meditative for me. This is one of the healthy ways to relax that is often available if sought out. Even during a recent trip to Orlando, I was able to sauna at one of the Y’s. My dad (86 yo) saunas at his health club near his home in SC.
I have never heard saunas described as something outside normal economic lifestyles.
And if there isn't fuel, they can simply relax by the pool.
Let them eat cake.
While there, I became friends with an old Finnish couple about 10 miles east of town near the Lake Superior shores. They explained that until just a few years ago (at that time), people had outhouses, and a sauna for relaxing, bathing and socializing. They did not eat cake. (They ate pasties :-) )
The mechanism of action seems very plausible. Sauna's are moderate stress which spikes your heart rate temporarily (they say 100-150bpm in the study). So it's not surprising it could be protective for cardiovascular disease just like many other forms of moderate stress/exercise.
[1] https://jamanetwork.com/journals/jamainternalmedicine/fullar...
Emerging evidence suggests a plausible mechanism is the "heat-shock response", which upregulates a lot of crap related to cleaning up misfolded (= aggregatey) proteins, like protein degradation and chaperone protein expression. Where most of these neurodegenerative diseases AD, PD, some dementias, CTE, prion diesases etc. involve protein aggregation at some point whether necessary-and-sufficient or just along for the ride. Like at this point if some kind of degenerative disease isn't thought to relate to protein aggregation, it's more likely nobody's bothered to look for it
Anecdotally/personally, it seems like there's kind of a step response going from "not cooked" to "cooked", the good stuff doesn't happen until you get "cooked" (ideally remaining that way for a while), and this seems to happen around a body temperature of 38.5-39C.
I guess a "cold shower" is that it only checks the type. You could put 999 into a variable that's supposed to hold the outside temperature.
An interesting implementation of this idea is outlined here too: https://medium.com/iterators/to-tag-a-type-88dc344bb66c
A strictly newtype can be very powerful, but needing to "unwrap" your datatype to use it in normal operations of that datatype can be a little unwieldy so tagged types are a pretty interesting mechanism that provides type safety and convenience. I don't think it's strictly better though, it depends heavily on context.
A function that has a parameter of ints but will only yield numbers within a certain range? I guess I'm really confused by the Scala example you posted but really trying to understand.
[1] https://doc.rust-lang.org/std/convert/trait.TryFrom.html
I've never done this, but you could also define types for stuff like this. type: PositiveInteger, or type: BoundedTemperature that would only ever hold valid values.
Or one thing where it might come in handy would be when dealing with user/potentially malicious input - SanitizedString etc.
type OutsideTempC is digits 3 range -100.0 .. 70.0;
(Edit: others mentioned this)
``` type Temperature<min: number, max: number> = { x: number | x >= min && x <= max } ```
This is what gets me about “even modern relatively-low-boilerplate type systems just slow me down” folks. That means you’re skipping documentation you ought to be doing.
Hype: "Static Typing reduces bugs."
Shower: A review of all the available literature (up to 2014),
showing that the solid research is inconclusive, while the
conclusive research had methodological issues.
Not hype, but an obvious fact: "Static Typing reduces type related bugs."
Ruby apps are easy to build, but are difficult to maintain.
Rust apps take a bit more effort to build, but are easier to maintain.
There is so much variation confounding any study, in tasks, specifications, programmer inclination.
I use both staticly typed (rust) and dynamically typed (perl) a lot. I like rust for the big projects and perl to hold everything together-job control
That is my inclination, not a fact.
I have used many languages over the years. Static/dynamic typing is just one dimension, and not necessarily related to quality
Except for the documentation effect. For that there is apparently solid research.
What you’re proposing here sounds like somebody saying “How do we know Rust results in less bugs than C++ without an empirical study?”. Even though, we _know_ Rust eliminates an entire class of memory related bugs. I say this as a C++ advocate too. Anytime I run into a memory bug, that’s a bug that would not have happened in Rust. Likewise, any time you run into a runtime exception due to a type mismatch (for example: expected an int not an object), that is a bug that would not have happened with a type safe language.
Edit: I also want to add that the metric is important. Is it number of bugs per line of code? What does that even mean? Assembly programs consist of many more lines of code because it’s more terse, but the number of bugs in assembly will probably be greater than a higher level language. Even though the large number of lines of code would probably push the metric down and make it seem like assembly has a low number of bugs per line of code. Because of this, bugs per line of code isn’t a useful metric.
The only way I could think of measuring this would be to have two feature for feature equivalent projects in two different languages and compare the number of bugs in each. But even that probably has a bunch of flaws.
I don't understand your point about metrics and measurement. Are you saying the effect of static typing is so small that it is completely dominated by other confounding factors and thus cannot be measured?
Because of this, I feel like the only way to truly measure whether or not static typing has a significant effect would be to create two equivalent projects. Say you created stack overflow in Python and in C#. Then you could compare the quantity of bugs and see if it differs. But even this has problems because who knows how many bugs haven’t been caught? Is the code truly equivalent? Did the people who wrote the two codebases have slightly different experience resulting in differing number of bugs?
There’s too many variables in an experiment like this to conclusively determine whether or not static typing reduces the bugs. But, I don’t think that means that we can’t infer that eliminating a whole class of bugs is helpful.
Edit: the more I try to think about my reasoning the more I’m thinking it’s flawed. I think the answer to whether or not static typing reduces bugs is unknowable, but I strongly believe that it helps. Maybe we’ll get a study that isolates this metric one day :)
I've read some of the research on this! Yes, static typing improves documentation and helps you navigate code.
It also correlates with code quality and reduces smells. Inconclusive whether that's because of static typing or because more mature teams are likelier to choose static typing.
But all the research agrees: Static typing does not reduce logic bugs. You can build the wrong thing just as easily with dynamic and with static typing. The only type of bug that static typing reduces is the sort of bug you'll find by running the code.
In my experience, static typing is best thought of as a way to reduce the need for manually written unit tests. Instead of writing tests that break when a function signature changes, you write types that break when you call functions wrong.
You still need tests for logic. Static typing doesn't help there.
This seems like a strong statement to make based on the research. What I've seen falls into several camps:
- research that made some conclusion about logic bugs for complete beginners on small assignments, with languages that have bad type systems
- research that had significant limitations making it impossible to generalize
- research that failed to demonstrate that static typing reduced bugs—which is very different from demonstrating that it didn't!
I haven't done a super thorough review of the literature or anything, but I have looked through a decent number of software engineering papers on the subject. The only strong conclusion I got from the research is that we can't get strong conclusions on the subject through purely empirical means.
Hell, the whole question is meaningless. "Static typing" is not one thing—there's way more difference between Java and Haskell than between Java and Python, even though both Java and Haskell are statically typed and Python isn't. (This is even assuming you completely ignore Python's type annotations and gradual typing!)
This is a pretty solid argument in favor of static typing, then, unless you somehow have a test suite that exercises every possible code path and type variation in your codebase, and also keeps itself perfectly up to date. Because otherwise you're rarely running all of your code and verifying the result.
Are you calling compilers robots?
It's a machine that performs a task, just like a welding robot in a car factory or a Roomba.
But to the main point, I read "robots" as a metaphor. Metaphors can be situational, jut because I might call a compiler a "robot" in one context doesn't mean I have to call them that every time.
And it's not as if there isn't long-standing precedent for using "robot" to refer to a piece of software. Have you ever heard of a "robots.txt" file? People complaining about "bots" on various social media sites?
If someone came to me with some outlandish claim, "Studies show that singing in the shower lowers cancer risk," I honestly won't be surprised if they could produce 2-4 white papers published in modern journals in support of it. So much of modern science seems to be reading between the lines and meta-analyses of scientific studies.
Scott Alexander's review of Ivermectin[0] is a great example of this. Bold claim is made, everyone divides into two camps, and in fact both camps have multiple peer reviewed studies backing their side, and to arrive at some semblance of understanding of the topic you need to spend hours diving into the studies and checking off boxes: were they peer reviewed, were there confounders, do the authors have a history of fraud, and on and on and on.
[0] https://www.astralcodexten.com/p/ivermectin-much-more-than-y...
When it comes to ivermectin though, I'm not convinced that was for profit per se, I think that was a crowd looking for a cure or something to latch onto because ????.
*-scientifically proven.
American healthcare is such that this would never be tested for until it becomes a problem, when your immune system is strained by other things the worms become a burden to your body. COVID is that other thing. So taking Ivermectin kills the worms as it was designed to do and this results in the body being able to focus just on fighting COVID. Given the "improved outcomes" being such low percentages to begin with, that fits pretty well to the distribution of the population that maybe have worms. So they say, "aha ivermectin did it, big pharma doesn't want you to know!" despite ivermectin being big pharma and just not being in on the conspiracy club
so then the other camp tries to do a controlled study of just covid patients and finds no link. their headline says "no link found, not recommended" of course, because they're John Hopkins instead of their next door neighbor, this is just a symptom of the conspiracy theory and leftist institutions.
but beyond that, it is a symptom of Republicans feeling accurately underserved by those institutions. There is an obsession with pointing out how dumb someone is, instead of empathizing and doing the additional study. "ah I see how you reached that conclusion, a bunch of people have been in a symbiotic relationship with parasites the whole time!"
If it turned out that ivermectin was effective at treating covid, the emergency authorization would no longer hold, and it would have ended the extremely lucrative business of covid vaccines. There was incentive to design studies that, on purpose, applied ivermectin incorrectly (not the right time, not the right dosage).
In the media, ivermectin was described as horse dewormer, a fake story about hospitals being overwhelmed by people overdosing ivermectin was repeated for weeks in mainstream media, even though before covid, it was considered a low risk medication, and was described as a wonder drug.
I'm not implying ivermectin successfully treated covid, mind you. I'm just saying that it's hard to trust the people that were saying it doesn't and, going further, they said it was a silly dangerous idea to even try using it for treating covid under medical supervision.
With that in mind, I can see how some people could come to the conclusion that, if big pharma and its lackeys in media and government want to discredit it so hard, it might even work.
At the end of the day, if X really cured Y, I don’t see why big pharma wouldn’t be all over it as well. There are plenty of countries that didn’t have American resources to buy expensive vaccines, why wouldn’t they use something cheap like ivermectin? In India they were manufacturing ivermectin and shipping it out to rich countries like the US while they were burning bodies in the streets because they couldn’t afford treatments. If ivermectin really worked, they would’ve used it.
https://theintercept.com/2021/10/13/intercepted-podcast-covi...
* let's not forget https://en.wikipedia.org/wiki/Klára_Dán_von_Neumann !
> Up to a point it is better to let the snags [bugs] be there than to spend such time in design that there are none (how many decades would this course take?). — A. M. Turing, Proposals for ACE (1945)
I had no idea. What a sad story.
Saying static typing is "hype" is like saying "adding a handle to a coffee mug makes it easier to hold" is hype.
My guess would be this depends on what problems is the majority of developers trying to solve.
But of course this summary is just a huge simplification of evolution of languages.
Hyperbole
Horses for courses
If I am batch processing text streams by applying regular expressions I really have no need for static typing, it just gets in my way
If I am processing MIDI note and control signals in real-time, and quickly, then I do.
I think so too, but that doesn't mean it's not controversial.
There are plenty of commenters who will happily say that it takes too long to put a handle onto a coffee mug. Handle-less mugs will get to market first! Besides, you spend too long fighting the handle.
Most systems don't need infinite scale. A big machine (not your laptop) can handle 95% of data analysis tasks. By big, I mean 1-4TB of main memory.
Spot prices for a 1TB instance are 2-2.5$/hr.
I found myself wanting to argue with the typing one as soon as I saw it went up to 2014 and so would have nothing on more modern Typescript and gradual typing and then I realized what I was doing.
[0]: Sort By Controversial https://slatestarcodex.com/2018/10/30/sort-by-controversial/
EDIT: The original title was simply "Awesome Cold Showers"
Only downside is I live in a desert so the water from the tap is warm when it's summertime.
I think a cold shower in the morning, when I do make it happen, gives me a can-do and energetic emotional state for the rest of the day. Force your body to start moving, and the mind follows.
This is a plot, a trick, a ploy. You're all some sort of environmental mega zealots, trying to trick me into cold showers to save hot water power costs. I won't have it, I won't.
</You're all monsters!>
Many of the most enjoyed moments in my life -- moments when I really was living the moment, and appreciating and enjoying every element -- were often after "bad" moments. Not bad like war or trauma or anything, but like my best camping moment ever was when it had been raining for days, we were cold and miserable, but then the sun rose and it was a warm day and that day, with everything drying, warmth, and comfort, suddenly everything was brighter and better than it had ever been. The meal we made over the fire was next level. My best moment skiing was having a long, tiring and intensely cold day and then going into the blazing hot cabin to sit by a fire and have hot chocolate.
I make a french press pot of freshly brewed coffee and honestly the experience quickly becomes....meh. It's just coffee. But then I go on a business trip for a week, where I can only source mediocre coffee, and suddenly come home and my home coffee is just revelatory. It is just something I can sink into and sit in awe of.
So cold showers for me are like that. It is intense discomfort to reset the baseline, and suddenly warmth feels exhilerating and wonderful.