Alice Averlong🏳️⚧️the button I want most in my Typing English career: a "yes that's misspelled, correct it to the first suggestion" button.
having to switch to a mouse to click on the spellchecking for every minor word is so tedious
maybe if you hit it again after it applies a correction, it goes to the 2nd most likely suggestion
I'd have to pair this with a spellchecker that understands my personal english dialect of Later IRC English, though. Standard spellcheckers don't understand how I capitalize and think I misspelled words all the time, just because I didn't capitalize them.
one thing I'd really love to have is a better way to do text input, like have a single program I type into that interfaces with everywhere I type English*.
right now it's a bunch of website textboxes, chat apps, text boxes... a unified customizable & hackable frontend for typing would be perfect.
* as opposed to programming/shell/commandline stuff, not other Human languages. The only other language I know enough to ever type in is Latin, and that's fairly limited. I'm sure I can figure out "cinaedus sum" myself
a few replies mentioned IMEs: maybe I could implement this as an IME, which'd let me tie it into my operating system's keyboard support in a nice way?
my other option is just having it be an always running textbox app, that appears when I hit a hotkey. But crucially when it appears, it queries the running program and figures out where the cursor is, so when I finish typing into the floating textbox, it can paste it back into there.
having it as as a browser extension would also get me 90% of the way there since that's my main place I type, but the remaining 10% would be a pain.
and browser extensions are a pain, too
I have been programming in a lot of environments for a long time and I have long since learned to identify when you're developing for an environment that hates you personally and is always going to be an uphill nightmare of security, updates breaking things, and 3rd parties you have to wait on to approve anything
and those environments are never fun to code in. you should be getting paid to code for them, or they will rapidly burn you out.
(if you're getting paid, they'll slowly burn you out)
this is why I don't usually do mobile or minecraft development.
I've done both before, but those environments hate you too much, so I'll stick to programming where it can be fun and enjoyable
I've done both before, but those environments hate you too much, so I'll stick to programming where it can be fun and enjoyable
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
this doesn't include the time my website broke because a subcontractor unexpected renamed columns in the database on a saturday. that's just a massive fuck-up
but any environment where shit changes periodically and have to change your code to fix it? easy burn out. you're not feeling like dealing with that app you wrote 3-20 years ago, but that doesn't matter, it suddenly needs attention or it will just stop working
2. third-party authorization before code can run.
The more steps there are between you writing code and that code actually running where it needs to be ran, the less enjoyable it can be for my specific style of fast-iteration-loop ADHD-fueled programming, sure, but the worst is delays where you need to wait on other people, people outside your organization.
The more steps there are between you writing code and that code actually running where it needs to be ran, the less enjoyable it can be for my specific style of fast-iteration-loop ADHD-fueled programming, sure, but the worst is delays where you need to wait on other people, people outside your organization.
nothing kills my motivation to fix problems and add features like knowing that even if I spend all day hacking on this, no one can see my changes until Wednesday (if I'm lucky. it might be Friday...)
this is why my personal projects are all on platforms like the web (where I run my own hosting, or use very simple free hosting) or scripts/binaries I can just throw up on github or my own site, and people can download and run them on their own machines.
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.
"security" itself isn't a bad thing, but sometimes the way it interacts with programming is terrible, and results in there being two ways to do something:
1. the obvious simple way
2. the much more complicated, but secure way
1. the obvious simple way
2. the much more complicated, but secure way
and some environments enforce you doing #2, even if this is only a test that you're doing on a local machine
this is especially bad when you're iterating: Maybe you just need to see if loading this file and then running it through the module will work, and then it turns out you gotta make three source files and set up a FileContentsProviderBean to just load the text file, and UGH this was just to test!
or when browsers decide you can load index.html off the localhost, but it's not allowed to do a JSON.get("file.json") because that's HTTPS only, and file:// doesn't count
and obviously this is important to help secure the browser against users getting tricked into downloading files and then the file JSON requests their bank account's router password and blah blah blah I know what I'm doing stop protecting me from my self
so now you can't just test your HTML+JSON website on your localhost without first spinning up a web server, which just adds another layer of friction to your development cycle
and provides you with absolutely nothing. Of course it'll be on an HTTPS site when it goes live! but right now, it's not, and apparently my browser can't tell the difference between "production" and "my own machine"
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 this is a whole fuck ton of extra friction that just isn't needed for development, but is being pushed on you to make a completely different environment (the open web) more secure.
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
I think maybe all three of these rules can be simplified down to "there's too much shit you gotta do before the thing you want to do"
like if I go "I should add feature X to my program, or fix bug Y", the best way to productively do that is if there's minimum friction between me deciding to do that, and actually getting to work on feature X/bug Y
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
maybe I just feel this so strongly because with my ADHD, all those are more limited than they might be for a nuerotypical programmer
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
(that second one is very much an ADHD thing: I don't really get the satisfaction at a job being completed, so I substitute it with feedback, from users, from other developers, etc)
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?
and this situation can easily happen accidentally. An environment with broken caching, with weird and complex rules for when code gets invoked, it's easy to accidentally end up with a coding project where the outcome doesn't seem to change as you make changes
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"
this isn't a "free" solution, and like all coping mechanisms it has a cost you're paying: you have to set up that framework
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
one strategy you can sometimes do that'll help with friction is to sometimes work on the project solely to make it easier to work on the next time
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
my advice is to avoid doing personal projects in these kinds of environments if you can avoid it, and to limit professional involvement as much as you can. Getting paid helps with getting burnt out on development, but that's all, it only helps. You will still burn out eventually.
and when you recognize you're in one of these environments, try to find ways to mitigate these problems.
for third parties breaking your code, you can set up tests on nightly versions of programs, you can monitor patch notes, you can try to anticipate these changes.
There's a lot you can't avoid in this area, but that doesn't mean the impact it can't be lessened.
There's a lot you can't avoid in this area, but that doesn't mean the impact it can't be lessened.
third party approval is hard to work around for obvious reasons.
sometimes it can be streamlined, or you can simplify how much new code needs to be verified
sometimes it can be streamlined, or you can simplify how much new code needs to be verified
not being able to do things "the easy way" can be worked around by building your own utility libraries for development. make a development-only function that takes a filename and gives you the file source, who cares if it leaks memory if you're only using it to develop, you can replace it with the real version once you've prototyped it
Vincent Sparks 🔜 Furlingame@foone I've heard chores like this referred to as "shaving one's yak", or "yak shaving", a term that broadly means something that does not obviously accomplish any goal but will make accomplishing other goals easier in the future.
It's a concept I'm excited about. I spent today building a Rust version of nvr (program that, when called with a file argument from a terminal emulator inside of Neovim, will open that file in the parent copy of Neovim), complete with the ability to stream from stdin to a new Neovim buffer and allow the user to begin to edit the file while the program generating it is still running, which I'm immensely proud of even though I didn't make any progress on my actual projects today. When I can convince myself to do it, it pays dividends.
I just really wish Nix didn't generate quite so many endless headaches, so I didn't keep putting off fixing my home-manager configuration for months at a time.
Wolf480pl@foone
not sure if that works for you, but for me there's a certain type of coding where I'm happy if it doesn't change anything: refacroring.
In fact, I'm only happy if I can convince myself that it didn't change how the program works, and surprisingly, the trick here is the same: have tests.
Brad Martin@foone political work feels that way to me. It seems easy to work one's whole lifetime for a cause, and only be able to say "well maybe things didn't get as bad as fast as they could have, maybe" at the end. If I don't see tangible results within a few weeks of effort on any project, my motivation goes to zero.
Marcus Helvig@foone I was reading this, and wondering the same thing. People don’t realise how much of a large obstacle any extra “small” step can be for those of us with ADHD.
mid-apocalyptic preclude@foone
Same as how one spends their Life. :)
Same as how one spends their Life. :)
😷orb delivery service@foone this is honestly why Blender nodes is where 99% of our coding happens nowadays