Suffering-oriented programming
nathanmarz.com
Suffering-oriented programming
1–10 of 64 posts
Re: Suffering-oriented programming
#2The 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 development.
I didn't stop development because it got boring - I stopped development because I'd solved my own problem. Not beautifully (certainly not from a coding perspective), not efficiently, but the problem I had was solved.
The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building.
(oddly, my password for my old account no longer seems to work. I was hebejebelus)
Re: Suffering-oriented programming
#3This 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 start having the ability to help solve those pains until they're further along in their education, at which point the earlier pains don't necessarily apply as well. In a similar vein, learning to program is a problem that's been on the map for a long time, and, while the situation is constantly improving, we're dealing with the problem of, by the time we've got the skills to really help solve it, we've already learned to program, and have lost some amount of sight of how learning could be improved, because we're no longer in the proverbial trenches.
So while “scratch a personal itch” is awesome advice, and almost certainly helps in product development and framework development, sometimes it isn't enough. Sometimes just following your curiosity or intuition and exploring a space that doesn't produce regular hurt for you can lead to an equally good result. At that point, what you need to make sure you have is external feedback from the people whose itch you're trying to scratch. Maybe the chances of failure are greater in these cases, but the opportunities for success are also probably greater.
Re: Suffering-oriented programming
#4The 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…
"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.
Re: Suffering-oriented programming
#5The 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…
Nathan's talking about solving recurring problems (that belong to a single problem class).
Re: Suffering-oriented programming
#6This 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 approach - you have to be an expert in the code to produce such a set of abstractions, which is a potential bottleneck when your codebase is big enough to require multiple developers. Not everyone has the time/capability to be an expert.
Re: Suffering-oriented programming
#7"First make it possible. Then make it beautiful. Then make it fast."
Alas, the guy writing the checks all too often doesn't see past step 1.
Re: Suffering-oriented programming
#8"First make it possible. Then make it beautiful. Then make it fast." Alas, the guy writing the checks all too often doesn't see past step 1.
This. I've yet to see a client development project that made it past step 1 on anything other than the most trivial features. Sucks, but I got paid. What can you do?
Re: Suffering-oriented programming
#9The 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.
Re: Suffering-oriented programming
#10The 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…
"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.