I have a similar philosophy for the systems I manage. We have always been severely understaffed, so I treat any user support request that repeats twice as a bug.
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.
I'm doing this with the SaaS I'm building (outside of my day job). My URL endpoint functions were directly executing SQL on the database until I decided that I couldn't go on like this, and only then did I write some classes to represent the business logic objects. It sounds ridiculous, but it gave me the flexibility to experiment with what those objects should do before imposing a formalism on them, and I found that very valuable.
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.
imho TDD only works when you are augmenting an existing system. in the creative design phase, it's not as helpful. it can be no doubt, but it can also be a burden as you have pointed out. all things in moderation, as they say.
TDD is opposed to suffering orientated programming IMO.
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.
> until I decided that I couldn't go on like this, and only then did I write some classes to represent the business logic objects
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.
This is a very similar approach to the one espoused in Eat That Frog: do the hardest, scariest task first thing in the morning, and everything else will be easier.
I think Deadpool summed it up pretty well with "maximum effort". Though I think the whole path-of-most-resistance thing goes back to Marcus Aurelius at least.
Sounds like one of the tenets of Extreme Programming: Pay attention to pain. When something is hard to do, fix what makes it hard - your architecture, your class design, your build process, whatever. Don't keep suffering the pain. Fix it.
Yes, Rama emerged from following this approach exactly. The "make it possible" phase was grinding for years on innumerable backend infrastructure problems. These included problems I worked on directly at BackType and Twitter, and also the thousands of use cases I helped with through my open-source work (especially Storm).
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.
Thanks for explaining!
To me Rama looks so high level, that somebody feeling the pain of not having it should be launching new projects all the time, like a consultancy.
That's not the inverse. It's just a variant of TFA's
| 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.
No, those are very different. If the alternatives did not exist, or even if its as though they did not exist, then you are looking to produce something new for the sake or delivering any solution.
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.
Either way you're taking on a big task because of the pain you were suffering, and only when some pain threshold is exceeded. That's the core of TFA. It's the same.
I have a similar philosophy for the systems I manage. We have always been severely understaffed, so I treat any user support request that repeats twice as a bug.
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.
I'm doing this with the SaaS I'm building (outside of my day job). My URL endpoint functions were directly executing SQL on the database until I decided that I couldn't go on like this, and only then did I write some classes to represent the business logic objects. It sounds ridiculous, but it gave me the flexibility to experiment with what those objects should do before imposing a formalism on them, and I found that very valuable.
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.
imho TDD only works when you are augmenting an existing system. in the creative design phase, it's not as helpful. it can be no doubt, but it can also be a burden as you have pointed out. all things in moderation, as they say.
TDD is opposed to suffering orientated programming IMO.
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.
> 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.
How many tests do you write at your job (or are supposed to write) before you write the unit of code?
> until I decided that I couldn't go on like this, and only then did I write some classes to represent the business logic objects
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
I have a principle called "the principle of maximum inconvenience".
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.
That's a dangerous game to play if you consider dying to be a serious inconvenience.
People don't usually put this on their TODO list.
If you do, you will really need a really careful optimization algorithm.
This is a very similar approach to the one espoused in Eat That Frog: do the hardest, scariest task first thing in the morning, and everything else will be easier.
I think Deadpool summed it up pretty well with "maximum effort". Though I think the whole path-of-most-resistance thing goes back to Marcus Aurelius at least.
I like this
Sounds like one of the tenets of Extreme Programming: Pay attention to pain. When something is hard to do, fix what makes it hard - your architecture, your class design, your build process, whatever. Don't keep suffering the pain. Fix it.
Is the author still following this paradigm? I can't imagine a situation from which Rama would emerge like this.
Yes, Rama emerged from following this approach exactly. The "make it possible" phase was grinding for years on innumerable backend infrastructure problems. These included problems I worked on directly at BackType and Twitter, and also the thousands of use cases I helped with through my open-source work (especially Storm).
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.
Thanks for explaining! To me Rama looks so high level, that somebody feeling the pain of not having it should be launching new projects all the time, like a consultancy.
Thought it would be about vibe coding by the title alone :D
I read it as surfing-oriented programming at first and thought the same as well!
I call my personal methodology PDD, Pain Driven Development.
Fix the thing that is causing the most pain. Or is likely to cause pain in the near future.
I really like this but prefer to think of it in the inverse: Build new technology because you feel the pain of current alternatives.
That's not the inverse. It's just a variant of TFA's
| 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.
No, those are very different. If the alternatives did not exist, or even if its as though they did not exist, then you are looking to produce something new for the sake or delivering any solution.
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.
Either way you're taking on a big task because of the pain you were suffering, and only when some pain threshold is exceeded. That's the core of TFA. It's the same.