[HN Gopher] Suffering-Oriented Programming (2012)
___________________________________________________________________
Suffering-Oriented Programming (2012)
Author : whalesalad
Score : 40 points
Date : 2025-04-10 18:11 UTC (4 hours ago)
(HTM) web link (nathanmarz.com)
(TXT) w3m dump (nathanmarz.com)
| sesm wrote:
| Is the author still following this paradigm? I can't imagine a
| situation from which Rama would emerge like this.
| nathanmarz wrote:
| 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.
| austin-cheney wrote:
| I really like this but prefer to think of it in the inverse:
| Build new technology because you feel the pain of current
| alternatives.
| supportengineer wrote:
| 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.
| butlike wrote:
| I like this
| speed_spread wrote:
| That's a dangerous game to play if you consider dying to be a
| serious inconvenience.
| AnimalMuppet wrote:
| 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.
| cjs_ac wrote:
| 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.
| whalesalad wrote:
| 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.
| timcobb wrote:
| > 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
| BoiledCabbage wrote:
| > 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?
| tomxor wrote:
| > "First make it possible. Then make it beautiful. Then make it
| fast."
|
| A clear distinction between an "exploration" phase and a
| "implementation" phase has emerged for me over time. It
| definitely helps to be conscious about which mode you are in.
|
| "make it beautiful" by finding abstractions that simplify
| implementation while checking the most number of boxes is the
| real game we play, and ideally should be discovered in a more
| disposable exploratory phase ("make it possible"), while being
| validated under the same demands of the intended use case. This
| is the path to something powerful and reliable that is also a
| pleasure to work with under the hood. Writing a clean
| implementation after figuring this out makes for a really nice
| codebase.
|
| It's also not usually possible to check all boxes without
| undermining the chosen set of abstractions, and so there is a
| balance to be struck, and it really helps to have your stake
| holders understand this balance so they don't cripple the
| software long term - I believe endless bug churn is one of the
| side effects of either not understanding or not respecting this.
| Blackarea wrote:
| Thought it would be about vibe coding by the title alone :D
| fcatalan wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-10 23:00 UTC)