Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Suffering-oriented programming

nathanmarz.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Suffering-oriented programming

#21

Post by leftnode »

tim_h wrote: post #6

This resonates: > The most important characteristic of a suffering-oriented programmer is a relentless focus on refactoring. This is critical to prevent accidental complexity from sabotaging the codebase. I can't tell you how many times I've seen accidental complexity creep in because someone adds a new feature without taking the time to refactor to the simplest set of abstractions. But - and here's the flaw in the a…

What's a good solution then? Have code reviews where the newer developers have to get their changes approved by older developers?

Re: Suffering-oriented programming

#22

Post by mekoka »

It's a mistake to try to anticipate use cases you don't actually have or else you'll end up overengineering your solution.

I wish more people would think like this before sabotaging their perfectly good APIs with noise. I'm a huge fan of the Pareto principle in that regard. First and foremost, expose the 20% that allows me to be 80% effective. The rest can be figured out as we go, but at least, what you'll teach me today, I'll learn fast and will know well.

Re: Suffering-oriented programming

#23

Post by alttag »

shadowfiend wrote: post #3

This is really an extension of the advice to make sure you build a product that scratches an itch you have. Extend it to developing frameworks, and you have “suffering-oriented programming”. Of course, the real problem is that there are certain spaces that wouldn't really be serviced if that's all we did. Education is an excellent example: the people who really feel the pains of education, students, won't really star…

I'm not sure I (fully) agree with your example of education.

In education the scratchable "itch" is felt by educators and parents in their offering of a service (education). The extent to which we as a society expend resources providing tools/resources for educators and allowing them to build/purchase solutions demonstrates the extent of (or lack of) our societal valuation of education. The itch in this is scratched by the service providers, not the consumers.

Re: Suffering-oriented programming

#24

Post by sbochins »

csl_ wrote: post #2

The biggest problem I have with this approach (and believe me, I love this approach), is that it makes it hard to finish things. For example, over Christmas, I built a small pretend-natural-language CLI controller for iTunes. I made a working version in something like four hours, spent a few days adding in crazy half-thought-out features like speech recognition and a web interface - and then I basically stopped devel…

I think in this case the approach worked fine for you. Most of the times a hacky solution will do. Not everything needs to be cleanly architected and bug free, especially a weekend project.

Re: Suffering-oriented programming

#25

Post by scott_s »

Deestan wrote: post #10
astine wrote: post #4

Earlier quoted context omitted.

"The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building." Then how is the project incomplete? If it's not a product that you're planning to sell, put your code on Github or the like and others will add any features that you're missing.

> put your code on Github or the like and others will add any features that you're missing. No they won't, because he hadn't even started on the "make it beautiful". When I want to solve a new-ish problem, I can't imagine grabbing some barely working cowdung from some guy's github repo. If he hasn't even tried to make it clean or readable, it'll take me more time to make sense of the mess than just rebuild it myself.

It depends on just how useful, and how ugly, it is. See: http://dreamsongs.com/WorseIsBetter.html

Re: Suffering-oriented programming

#26

Post by arctangent »

mekoka wrote: post #22

It's a mistake to try to anticipate use cases you don't actually have or else you'll end up overengineering your solution. I wish more people would think like this before sabotaging their perfectly good APIs with noise. I'm a huge fan of the Pareto principle in that regard. First and foremost, expose the 20% that allows me to be 80% effective. The rest can be figured out as we go, but at least, what you'll teach me t…

I agree with you 100%.

This is also known as the YAGNI principle: http://en.wikipedia.org/wiki/You_aint_gonna_need_it

Re: Suffering-oriented programming

#27

Post by sbochins »

mekoka wrote: post #22

It's a mistake to try to anticipate use cases you don't actually have or else you'll end up overengineering your solution. I wish more people would think like this before sabotaging their perfectly good APIs with noise. I'm a huge fan of the Pareto principle in that regard. First and foremost, expose the 20% that allows me to be 80% effective. The rest can be figured out as we go, but at least, what you'll teach me t…

Especially if you want people to adopt your API's. If I'm looking at using a service and I have to choose between a complicated or a simple API, its an easy choice. Starting off, you want to solve the most annoying problems first.

Re: Suffering-oriented programming

#28

Post by 3pt14159 »

"With Storm, I distilled the realtime computation problem domain into a small set of abstractions: streams, spouts, bolts, and topologies. I devised a new algorithm for guaranteeing data processing that eliminated the need for intermediate message brokers, the part of our system that caused the most complexity and suffering."

As someone who has gone through the storm source in very fine detail, let me tell you how he did this. He hashed each tuple that needed to be processed then XOR'd it into a variable that started at a value of zero.

When the piece that needed to be processed was complete it would get XOR'd back into the variable. Once the variable hit 0 he knew everything was done! Pretty neat if you ask me.

Re: Suffering-oriented programming

#30

Post by ced »

3pt14159 wrote: post #28

"With Storm, I distilled the realtime computation problem domain into a small set of abstractions: streams, spouts, bolts, and topologies. I devised a new algorithm for guaranteeing data processing that eliminated the need for intermediate message brokers, the part of our system that caused the most complexity and suffering." As someone who has gone through the storm source in very fine detail, let me tell you how he…

Isn't it problematic that 11, 01 and 10 XOR together to get 00? And why not use a simple counter?
Post reply on HN