Suffering-oriented programming (2012) | Hacker News Reader

Suffering-oriented programming (2012)

nathanmarz.com

77 pointswhalesalad15 comments

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.

>Don't build stuff unless you are suffering

That strikes a good chord, thanks for the concise response to excessive abstraction evangelists.

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.

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."

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.

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.

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.

This is especially important at the seams of our profession. We've got a couple of guys doing the admin-type stuff for customers at work. They usually don't do any programming at all, and thus their focus while solving problems doesn't usually include any non-trivial automation.

From time to time I encounter a situation where one of them slugs through some hideously boring task by hand, wasting hours, for something I could wip out a shell script in a couple of minutes for. Usually, that's because they haven't been given any useful tooling, and more often than not, a programmer knew about that and didn't care. Turns out, some of us are really good at ignoring our colleagues' suffering for that matter.

Also, turns out people are generally really grateful if you can tell them 'just pull the data out into an Excel sheet' and give them the data they need after a couple of minutes of "wizardry".

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.

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.

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.

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.

Did those happen to be Go developers? Just curious.

Interesting language, but some peculiar fanboys.

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.

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.

Reply on news.ycombinator.com