
Suffering-oriented programming (2012) - whalesalad
http://nathanmarz.com/blog/suffering-oriented-programming.html
======
mikekchar
Possibly a way to say YAGNI which is easier to relate to. Don't build stuff
unless you are suffering, and hence understand the problem domain. Do the
"easiest thing that could possibly work" and then don't change it unless you
see a problem with it. Even if there are better ways to do it, if you aren't
experiencing a problem, then there is no point in changing it. Don't fix
problems you don't have :-)

On the other hand, this requires a considerable amount of discipline. It is
easy to procrastinate. You think, "Oh we are suffering here, but it's only one
small thing, so it's not too bad. Plus we're super busy adding these other 100
features". Then there are 2 small problems. Then there are 10. Then 100.
Pretty soon, the amount of time necessary to fix the problems you need fixed
exceeds the amount of time that you can spend without losing business. So you
prioritise the worst issues and work around the others... The workarounds
cause more issues and because it's a network effect, the software starts to
degrade in a non-linear way. After a while, you are spending entire days
reading code just to make sure that a few line change won't break something.

It's not a panacea. You still need a lot of experience... and for want of a
better term, good taste.

~~~
kradroy
The experience part is key. I have junior engineers who implement solutions
without understanding the whole they're adding to. They end up believing
they're peeling an onion and start crying. There is no onion. It's a potato;
peel it and throw it in the pot!

It's difficult to tell them that they're not suffering though. I've sat many
down to explain that we don't need containerized components and rearchitecting
into an SOA with a blue-green deploy model. They protest nonetheless. But what
do I know after 15 years of engineering? I surely know that our customers'
suffering caused by their relief of suffering will make us all suffer more.

------
aidenn0
Also, don't ignore suffering (humans adapt to suffering very quickly). I have
many times seen cases where years went by before someone asked "how much work
would it take to engineer a solution to pain point X" and the answer was "less
than a week."

~~~
andrewflnr
I've been bumping into this kind of thing a lot lately. Flipping embarrassing.
But it's hard to know which pieces of suffering you should think about when
there are so many little papercuts you've learned to not notice.

~~~
colechristensen
This is one reason why moving jobs somewhat frequently can be very beneficial.
You and your employer have different sets of papercut blindness and you can
both help each other.

~~~
natedire
I've often had this same thought about starting a new job. I'm going to have
to use "Papercut blindness", the mixed metaphor makes me smile.

------
hyperpallium
Abstractions make it easier to reason, but you need a lot of suffering-the-
detail to know what they should be (analogous to _do things that don 't
scale_).

If abstractions help you think, abstracting wrong makes you think wrong - and
harder to think right than without them.

So it's helpful to use abstractions others have already schlepped out e.g. in
mathematics... but there's no guarantee that it's the right one for your
particular situation.

~~~
colechristensen
I have experienced quite a lot of people pushing to over-abstract code
(abstractions that will are used only once with reuse being wishful thinking
for the far future) and very little pushback against as though reaching the
"perfection" of abstracted code has a moral high ground.

I would like to balance the difficulty of wading through abstractions with the
difficulty of repetitive code, not to act like one difficulty is superior to
the other.

~~~
watwut
After working with people who refuse any kind of tiny little abstraction
because "abstractions are complicated" and "even splitting it into named
functions is step toward being like java", it is no better.

It was high in repetition and whenever you changed something, you had to not
forget five places. It was also hard to get the big picture of what was
supposed to happen.

There is such a thing as too little abstraction as much as there is too much
abstraction.

~~~
rabidrat
Forth is great. It takes both DRY and JIT abstraction to the extreme.
Developing software is creating a DSL with a custom vocabulary for the problem
space being solved.

------
3chelon
Sounds a little bit like Paul Graham's argument for doing things that do not
scale. Until doing something manually, or the hard way, becomes a serious
blocker, don't try to fix it with technology because it's almost certainly not
worth it, esp. if you're not actually losing money from it.

I certainly stopped wasting a lot of time on pointless half-baked automated
tools after I read that.

------
SimplyUnknown
Funny, I have devised almost the same mantra:

\- Make it

\- Make it correct (i.e. test/prove it works always)

\- Make it fast

There is always some mixing going on but I think it is a nice way of building
software.

