

Ask YC: Coping with frustration a la setup/dependency/documentation hell? - whacked_new

I have just finished spending a few hours tweaking a flash charting package which was quite insufferable to use. After a few hours (and more), I end up feeling my soul getting sucked out of my brain in every passing second and feel progressively destructive, but at the same time, I know I have to keep working on it, and want to see its completion more than ever -- and finally, when it's over, I feel so suffocated that there is no feeling of accomplishment. Sound familiar? Setup hell? Dependency hell?<p>I have always wondered about how others deal with this kind of frustration, from problems that challenge your patience more than your thinking. How patient is impatient? How do you cope? Or, if you don't encounter these problems, how do you do it?
======
nostrademons
Kinda confused...is the question about the specific problem of learning new
libraries, the general problem of setup/dependency/documentation hell, or the
even more general problem of dealing with frustration?

For libraries, I just accept that it'll take a long time to get familiar with
them, and dive in. That's what Hello World is for, anyway. If I've got them
setup and working and _still_ have a tough time mastering the library (bad
documentation, for example), I'll often just ditch the library.

For setup/dependency/documentation hell, depends on the language. I use
setuptools for all my Python-related code, and use it's dependency-management
functionality whenever libraries support it. Small 3rd-party libraries (no
more than a source file) get pulled directly into our source code repository,
larger ones are easy_installed, with a shell script to take care of everything
that isn't available via easy_install. HTML, CSS, and images get packaged
along with the web framework code they're associated with, and installed via
setuptools. I wrote a custom documentation/dependency analyzer for JavaScript,
and use that for all our JavaScript. It's wrapped in a setuptools package that
just consists of a library of build scripts, the JavaScript being pulled in
through pkg_resources.

As for frustration, I usually go do something else. Oftentimes, when I return
to the difficult part, I find it's become irrelevant.

~~~
whacked_new
Thanks for the reply, and sorry about the confusion. This is a question about
frustration in general; I thought the most salient example for fellow readers
would be the hair-pulling craziness from dependency hell and that sort.

Taking the mind off the problem is one way, but subconsciously you know the
problem is still there; so for example, if I decide to go treat myself a
snack, I wouldn't enjoy the taste as much because the stress is still there,
and the "time elapsed since you started" keeps increasing, which is annoying
to think about when you ask yourself "how much did I accomplish in the last X
hours".

Say you are 2 hours into the onset of some extreme frustration. In your
experience, do the benefits of leaving for 20 minutes and coming back usually
outweigh the costs of decreased efficiency from working in a bad mood?

~~~
nostrademons
I actually meant a longer timescale...like leaving the problem alone for a
week while I work on some other aspect of the product, and then coming back to
it. Like if I'm stuck on a UI library, I'll go work on backend stuff instead.
About half the time, the solution to my original problem is obvious when I
return to it, and another quarter of the time, the problem is irrelevant and I
need to rewrite it anyway.

If I'm stuck on everything, I'll work on a side project. That's how Scrutiny,
Bootstrapacitor, ArcLite, and Randomicity were done. (Most of the time, the
side project itself amounts to nothing, but it serves its purpose of getting
me unblocked.)

This is one reason why I find projects often accelerate as I get farther along
in them: they generate other productive tasks that I can do when I get stuck.
I'm less likely to work on something completely unrelated then, so overall
project velocity increases.

