Weirdly enough I’ve met a few other people who are weird enough to share their toothbrush with me

He wanted to prove he doesn’t care about money and is fully willing to throw away $44 billion dollars on a shitpost

Yes but the thread would not have made sense if I hadn’t added my follow up questions to your original question

My gf says this. But when I eat spicy food, it doesn’t interfere with the taste whatsoever. I also love the taste of really hot coffee when I’m eating something spicy. Something about the double burn really enhances the flavor.

After 2 years I couldn’t wait to get back in there each week. I felt great, looked healthy, my skin cleared up, I wasn’t depressed, was in the best shape of my life at the time. Playing video games (and later doing drugs) for 15 years didn’t exactly pay off in those areas.

I look at it like this: Am I going to be alive in 2 years? Ok, then taking on a 2 year project is worth it. Months fly by in the blink of an eye these days, 2 years will have gone by before you notice.

I don’t remember the presentation, but luckily I did remember the concept and here’s an article: https://netflixtechblog.com/reactive-programming-in-the-netflix-api-with-rxjava-7811c3a1496a

It’s called “reactive” programming and that article goes over some of the basic premises. The context of the presentation was in front-end (web) code where it’s a god awful mess if you try to handle it in an imperative programming style. React = reactive programming. If you’ve ever wondered why React took off like it did, it’s because these concepts transformed the hellish nightmare landscape of jquery and cobbled together websites into something resembling manageable complexity (I’m ignoring a lot of stuff in between, the best parts of Angular were reactive too).

Reactive programming is really a pipeline of your data. So the concepts are applicable to all sorts of development, from low level packet processing, to web application development on both the front and back end, to data processing, to anything else. You can use these patterns in any software, but unless your data is async it’s just “functional programming”.

Follow up questions: Were you saving up the shit for 3 days for the sex party? Or was it that you didn’t want to shit at a sex party? Was it a personal decision or a house rule? And was that 3 day shit afterwards more enjoyable than the sex party itself? Sounds amazing

There is definitely a huge difference after 6 months of focusing on one thing. I’ve done hot yoga off and on over about 12 years and I’d say it took 6 months of going consistently before I felt like my body adjusted and it was more enjoyable. After 2 years I didn’t feel like I was going to die and it actually became very enjoyable.

I’ve fallen off recently because it’s easier to sit around and initially it does suck because you need to readjust. But I when I had gone 2-3x in a week, man I felt like a god. I started going in my 20s, I was high af all the time and knew I needed some exercise or I was gonna die.

I think it takes a certain person to love lifting weights of all things. But luckily there are lots of things out there

I don’t think I truly understood why some people don’t like spicy food until reading your comment.

Yep, that’s how I write my code too. I took a class in college, comparative programming languages, that really changed how I thought about programming. The first section of the class was Ruby, and the code most of us wrote was pretty standard imperative style code. If statements, loops, etc. Then we spent a month or so in Haskell, basically rewriting parts of the standard library by only using more basic functions. I found it insanely difficult to wrap my head around but eventually did it.

Then we went back and wrote some more Ruby. A program that might have been 20-30 lines of imperative Ruby could often be expressed in 3 or 4 lines of functional style code. For me that was a huge eye opener and I’ve continued to apply functional style patterns regardless of the language I’m using (as long as it’s not out of style for the project, or makes anything less maintainable/reliable).

Then one day a coworker showed us a presentation from Netflix (presentation was done by Netflix software engineers, not related to the service) and how to think about event handlers differently. Instead of thinking of them as “events”, think about them as async streams of data - basically just a list you’re iterating over (except asynchronously). That blew my mind at the time, because it allows you to unify both synchronous and asynchronous programming paradigms and reuse the same primitives (map/filter/reduce) and patterns in both.

This is far beyond just eliminating if statements, but it turns out if you can reduce your code to a series of map/filter/reduce, you’re in an insanely good spot for any refactoring, reusing functionality, easily supporting new use cases, flexibility, etc. The downside would be more junior devs almost never think this way (so tough for them to work on), and it can get really messy and too abstract on large projects. You can’t take these things too far and need to stay practical, but those concepts really changed how I looked at programming in a major way.

It went from “a program is a step by step machine for performing many types of actions” to “a program is a pipeline for processing lists of data”. A step by step machine is complex and can easily break down, esp when you start changing things. Pipelines are simple + reliable, and as long as you connect them up properly the data will flow where it needs to flow. It’s easy to add new parts without impacting and existing code. And any data is a list, even if it’s a list of a single element.

Personally I try to keep my code as free of branches as possible for simplicity reasons. Branch-free code is often easier to understand and easier to predict for a human. If your program is a giant block of if statements it’s going to be harder to make changes easily and reliably. And you’re likely leaving useful reusable functionality gunked up and spread out throughout your application.

Every piece of software actually is a data processing pipeline. You take some input, do some processing of some sort, then output something, usually along with some side effects (network requests, writing files, etc). Thinking about your software in this way can help you design better software. I rarely write code that needs to process large amounts of data, but pretty much any code can benefit from intentional simplicity and design.