| Suffering-oriented programming can be summarized like so: don't build technology unless you feel the pain of not having it.
If the current alternatives are so bad that it's as if they didn't exist, then you are already at the point of wanting to build the thing you are missing.
If the alternatives just suck and you realize you can do so much better then your goal is wildly different. Its not about any solution because you already know what the baseline and acceptance criteria are. Its only about not feeling the pain that other solutions provide. You are otherwise providing the same solution and just doing it in a way that's like chocolate and caviar.
This principle tells you that whatever you should be doing right now, is the most inconvenient possible path at this time.
It serves as a guide to help orient me in life especially when I'm at a crossroads.
If you do, you will really need a really careful optimization algorithm.
At my day job, I'm expected to use TDD, and I don't like it. It's not that I don't like tests - I don't like writing them, but I like it when they're there, so I write them while feeling a bit grumpy. My problem with TDD is that I'm a big picture thinker, and I start from the inputs and work incrementally towards the outputs, without having a good outline of how I'm going to get there, so I can't write unit tests before writing any actual code, because I don't know what the units are going to be yet.
I also find my colleagues' code to be factored in a slightly unnatural way, because it reads like they've structured the code to match the tests, rather than written tests to test aspects of the code.
Maybe I should just be a hermit-programmer.
this is just another form of TDD in my opinion. it's a bummer if your work literally makes you write tests first just to satisfy some theoretical checkmark.
> Maybe I should just be a hermit-programmer.
<3
How many tests do you write at your job (or are supposed to write) before you write the unit of code?
What pain does writing the tests first resolve? Tests should only be added when you are scared of making changes or want to support assumptions about how things work.
If the decision to push a button is yours, I'll give you the button. If you need some data more than once, you get a button too. My ideal user never needs to know who manages the system or how to contact us.
This has even got me a "why do you guys have almost no tickets? You aren't doing anything!" talk a couple times. Music for my ears.
Fix the thing that is causing the most pain. Or is likely to cause pain in the near future.
sesm•10mo ago
nathanmarz•10mo ago
The "make it beautiful" part involved unifying all these use cases into a single set of abstractions that could express them all concisely, with high performance, and without needing any other infrastructure. Since I was building such a general platform, I was also able to consider use cases I hadn't directly worked on – basically just looking at popular web applications and their features.
Leaving Twitter in 2013 was the start of the "make it beautiful" phase. By that point I had already figured out the broad outlines of what such a next generation platform would look like (event sourcing + materialized views, indexing with data structures instead of data models). It was a long road from there to figure out the details and turn it into a production platform.
sesm•10mo ago