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

11–20 of 64 posts

Re: Suffering-oriented programming

#11

Post by rgoddard »

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 see this as more then just an extension. The basic premise is that you cannot build an elegant solution to a problem that you do not have a deep understanding off. When working in a domain that you do not know, create an inelegant solution which works. In this process gain a better understanding of the problem, and use this knowledge in a later stage to build a better solution.

Re: Suffering-oriented programming

#13

Post by revorad »

bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

I'd love to hear some examples where you got it fast, beautiful and possible the first time.

Re: Suffering-oriented programming

#14

Post by jon6 »

bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

"In theory, there is no difference between theory and practice. But, in practice, there is."

IMO its best to think about a problem for a little while until you come up with some reasonable solution, then hack it up, then revisit your original decisions and see if you can do it better.

Re: Suffering-oriented programming

#15

Post by gurraman »

bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

The key here is "an unfamiliar domain". The "make it possible"-part is empirical research. So, you could make it beautiful and fast the first time around, but some would argue that it'd be better to first make it beautiful and then optimize where necessary.

Re: Suffering-oriented programming

#16

Post by [deleted] »

bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

[deleted]

Re: Suffering-oriented programming

#17

Post by tim_h »

bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

In software engineering the "thinking beforehand" approach is probably riskier than the "think as you go" approach. For example, often the requirements aren't well-defined when the project starts.

Contrast this with physical-stuff engineering (which I think is what you're referring to by saying "engineering background"), where the requirements tend to be better-defined and the cost of experimentation/refactoring is a lot higher.

Re: Suffering-oriented programming

#18

Post by fatalerrorx3 »

Awesome. I have this exact same methodology...Now can you write an article about how to explain how this works to Business people/non-tech people, who have no experience in "iterative program development" or why the programming process MUST be iterative?

Everytime I mention code refactoring to a non-tech person the response is similar to "Why would you program the same thing again?" And your article is the exact reason why. You can't know everything you need to know in the beginning of developing some brand new technology. If that was the case, then every startup would be successful.

Re: Suffering-oriented programming

#19

Post by aaronyo »

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…

"Flaw" seems strong. If you have a small enough and strong enough team, the approach makes a lot of sense to me. I wonder how big the original Storm team was.

Re: Suffering-oriented programming

#20

Post by BadassFractal »

Great read, I have a question:

I would very much love to find out what kind of techniques you folks used to ensure some degree of quality (or sanity) in the "make it possible" phase.

I'm basically wondering if you used anything like CI / TDD / Code coverage or any other quality ensuring techniques at such an early stage. One might argue that it's counter-productive, since you're going to likely rip-out most of that code anyway during the "make it pretty" phase. Others will state that keeping high code quality throughout even prototyping will make you waste a lot less time on debugging and therefore make you overall on the long run.

To me it feels like it'd have to be a very delicate balancing act.

Post reply on HN