maybe I should compose an official list: Foone's Symptoms of A Programming Environment That Hates You

1. Factors completely outside your control break the code periodically. This is anything that's an add-on, usually. The browsers changed something, the sites changed something, the game changed something... It's a project that can never be finished, can never be put away. It will just break on some random day because some people in a different organization with different goals changed it

3. Environments where you can't do it "the simple way". This is usually a security thing, but it can be other problems (licensing, approved software lists, etc).

Basically any scenario where there's a simple and easy way to solve your problem, but that can't be done, and a much more complicated solution must be done.

so you set up a simple local webserver (python has a oneliner from the command line for it! python -m http.server, or python -m SimpleHTTPServer if you're on 2.x), but then it turns out you can't use some specific feature because chrome decided to arbitrarily limit it to HTTPS to help push the web towards encrypted pages, and canvas fingerprinting means you can't download a PNG off the page...

and now you need a more "real" local server, with valid TLS certificates...

and the thing about that friction is that you remember it? you internalize how annoying it is to do development on this thing.

so the next time you might have some motivation to work on it, that gets lessened by the reminder that you gotta make sure your node-based HTTP mini-server is correctly installed (you updated Node for another project, maybe that broke it?) or if the certs expired or your new browser didn't accept them

a big part of what helps keep projects going after a long time is minimal friction to getting back into them, you can just pick them up and start coding.

The more that feels like a slog, the less likely you are to keep up working on it

We all have limited time, limited energy, limited focus, limited patience.

and the more of those limited resources are spent on other things, like upgrading/repairing the environment before you can get to coding on the feature, the less you have to spend on the feature itself

the only other way I can think of to quickly burn out a programmer on a "fun" project:

4. Your changes don't seem to matter.

either you're fixing something and the bug remains, with no evidence you're affecting it, or your new feature can't be tested for whatever reason.

lack of feedback in general

this can both be immensely frustrating (I've rewrote all five modules that integrate with the TextBox module, and the Spellchecker bug STILL HAPPENS INT HE SAME WAY! AHHHHH COMPUTER GOES IN LAKE NOW!)

or just demotivational, because you're not getting the whole "yay, I did a thing!" dopamine hit

but even if you've not got my particular broken brain...

if every time you work on something, there's no reward for that work, you're not going to want to do it. Your brain recognizes this is not a reliable path to reward, so why bother?

a tip for this that'll help, if you're doing something that's not going to result in an obvious change?

make it change something.

set up performance metrics, unit tests, integration tests, whatever.

Now the reward is "I got formatText() down to 7ms on The Bee Movie Script!" or "I finally fixed that bug where octupley-nested brackets would segfault the parser"

which can feel exactly like friction before you can code.

but if you can get that set up so you have a visible goal, it can really help

like if you've got a lot of manual steps you have to do as part of the build/test process, see if you can find time/energy/motivation to spend some time just streamlining that.

Even if it doesn't give you a new feature or bugfix now, it'll help with future ones

and doing it in a separate session from feature/bugfix work means it doesn't feel like friction.

this is basically a "clean up your room, put away all your tools" kind of maintenance. It doesn't advance your project itself, but it lessens the friction for your next development session

so yeah. quick summary on the common features of Development Environments That Hate You:

1. Third parties break your code (regularly)
2. You can't deploy it without third party approval that could take days
3. You can't do anything "the easy way", even as a test
4. Your code changes don't seem to matter