I think that two criterias are important:

- don't block my productivity
- author should have his userbase in mind

1) Some simple anti examples:

- Windows popping up a big fat blue screen screaming for updates. Like... Go suck some donkey balls you stupid shit that's totally irritating you arsehole.
- Graphical tools having no UI concept. E.g. Adobes PDF reader - which was minimalized in it's UI and it became just unbearable pain. When the concept is to castrate the user in it's abilities and call the concept intuitive, it's not a concept it's shit. Other examples are e.g. GEdit - which was severely massacred in Gnome 3 if I remember correctly (never touched Gnome ever again. I was really put off because their concept just alienated me)
- Having an UI concept but no consistency. Eg. looking at a lot of large web apps, especially Atlassian software.
Too many times I had e.g. a simple HTML form. In menu 1 you could use enter. In menu 2 Enter does not work. in another menu Enter works, but it doesn't submit the form it instead submits the whole page... Which can end in clusterfuck.
Yaaayyyy.
- Keyboard usage not possible at all.
It becomes a sad majority.... Pressing tab, not switching between form fields. Looking for keyboard shortcuts, not finding any. Yes, it's a graphical interface. But the charm of 16 bit interfaces (YES. I'm praising DOS interfaces) was that once you memorized the necessary keyboard strokes... You were faster than lightning. Ever seen e.g. a good pharmacist, receptionist or warehouse clerk... most of the software is completely based on short keyboard strokes, eg. for a receptionist at a doctor for the ICD code / pharmaceutical search et cetera.
- don't poop rainbows. I mean it.
I love colors. When they make sense. but when I use some software, e.g. netdata, I think an epilepsy warning would be fair. Too. Many. Neon. Colors. -.-

2) It should be obvious... But it's become a burden.

E.g. when asked for a release as there were some fixes... Don't point to the install from master script. Maybe you like it rolling release style - but don't enforce it please. It's hard to use SHA256 hash as a version number and shortening the hash might be a bad idea.

Don't start experiments. If it works - don't throw everything over board without good reasons. E.g. my previous example of GEdit: Turning a valuable text editor into a minimalistic unusable piece of crap and calling it a genius idea for the sake of simplicity... Nope. You murdered a successful product.
Gnome 3 felt like a complete experiment and judging from the last years of changes in the news it was an rather unsuccessful one... As they gave up quite a few of their ideas.

When doing design stuff or other big changes make it a community event or at least put a poll up on the github page. Even If it's an small user base, listen to them instead of just randomly fucking them over.
--
One of my favorite projects is a texteditor called Kate from KDE.

It has a ton of features, could even be seen as a small IDE. The reason I love it because one of the original authors still cares for his creation and ... It never failed me. I use Kate since over 20 years now I think... Oo

Another example is the git cli. It's simple and yet powerful. git add -i is e.g. a thing I really really really love. (memorize the keyboard shortcuts and you'll chunk up large commits faster than flash.

Curl. Yes. The (http) download tool. It's author still cares. It's another tool I use since 20 years. And it has given me a deep insight of how HTTP worked, new protocols and again. It never failed me. It is such a fucking versatile thing. TLS debugging / performance measurements / what the frigging fuck is going on here. Take curl. Find it out.

My worst enemies....

Git based clients. I just hate them. Mostly because they fill the niche of explaining things (good) but completely nuke the learning of git (very bad). You can do any git action without understanding what you do and even worse... They encourage bad workflows.
I've seen great devs completely fucking up git and crying because they had really no fucking clue what git actually does. The UI lead them on the worst and darkest path imaginable. :(

Atlassian products. On the one hand... They're not total shit. But the mass of bugs and the complete lack of interest of Atlassian towards their customers and the cloud movement.... Ouch. Just ouch.

I had to deal with a lot of completely borked up instances and could trace it back to a bug tracking entry / atlassian, 2 - 3 years old with the comment: vote for this, we'll work on a Bugfix. Go fuck yourself you pisswads.

Microsoft Office / Windows. Oh boy.
I could fill entire days of monologues.
It's bad, hmkay?

XEN.
This is not bad.
This is more like kill it before it lays eggs.
The deeper I got into XEN, the more I wanted to lay in a bathtub full of acid to scrub of the feelings of shame... How could anyone call this good?!?????

I think the reason why git beginners have a hard time with it is because the api is a bit untuitive.

For example: if you want to "unstage" staged changes, you run git reset, and if you want to "delete" those changes from your working copy, you git checkout those files.

But then, you find out that you can do all of that if you git add . and git reset --hard.
So you're like "huh..."

And then you discover that if you end the resethard with a branch name/commit id then you also make current branch point to the commit or that branch/commit (respectively).
So you're like "huh..."

And also if you add a commit id or branch name to git checkout, you change the current branch to specified/enter detached state with HEAD pointing to that commit (respectively).

Oh and you don't use git branch to create branches, you use git checkout -b because it's a lot shorter.

So here's a rundown: git reset mutates things related to files, but also mutates things related to branches.
git checkout also mutates things related to files and mutates things related to branches too (in a diff way). Also, creates new branches.

I don't think this is intuitive. We users use the same commands for different purposes with just a different flag.
Commands shouldn't mutate different types of things. But don't composite commands (as in, "smart" commands that mutate different things) shoudln't be a flag in an existing command, it should be a single new command of its own.

Maybe if I reread the internals of git now, I'll be able to disgest the dozens of technical terms they throw at you (they are many). And in my mind, the api will cognitively fit to the explanations.

Here's another one that feels weird too.
If you want to make your changes start on top of someone else's commit, you do git rebase.
But git rebase -i can be used for that, and also to delete, modify changes or message of, reorder or combine previous commits of the current branch.

Maybe the reason why several things we do overlap with the same commands is because they internally do similar things, and while not separating those commands might make it less intuitive, it makes them more sensible? i dunno...

disclaimer: I'm not setting this opinion in stone though, and am aware that git was created by one of the most infuential programmers.

A bug is born
... and it's sneaky and slimy. Mr. Senior-been-doing-it-for-ears commits some half-assed shitty code, blames failed tests on availability of CI licenses. I decided to check what's causing this shit nevertheless, turns out he forgot to flag parts of the code consistently using his new compiler defines, and some parts would get compiled while others needed wouldn't .. Not a big deal, we all make mistakes, but he rushes to Teams chat directing a message to me (after some earlier non-sensible argument about merits of cherry picking vs re-base):
Now all tests pass, except ones that need CI license. The PR is done, you can use your preferred way to take my changes.

So after I spot those missing checks causing the tests to fail, as well as another bug in yet another test case, and yet another disastrous memory related bug, which weren't detected by the tests of course .. I ponder my options .. especially based on our history .. if I say anything he will get offended, or at best the PR will get delayed while he is in denial arguing back even longer and dependent tasks will get delayed and the rest of the team will be forced to watch this show in agony, he also just created a bottleneck putting so many things at stake in one PR ..

I am in a pickle here .. should I just put review comments and risk opening a can of worms, or should I just mention the very obvious bugs, or even should I do nothing .. I end up reaching for the PM and explained the situation. In complete denial, he still believes it's a license problem and goes on ranting about how another project suffering the same fate .. bla bla bla chipset ... bla bla bla project .. bla bla bla back in whatever team .. then only when I started telling him:
These issues are even spotted by "Bob" earlier, since for some reason you just dismissed whatever I just said ..
("Bob" is another more sane senior developer in the team, and speaks the same language as the PM)
Only now I get his attention! He then starts going through the issues with me (for some reason he thinks he is technical enough to get them) .. He now to some extent believes the first few obvious bugs .. now the more disastrous bug he is having really hard time wrapping his head around it .. Then the desperate I became, I suggest let's just get this PR merged for the sake of the other tasks after may be fixing the obvious issues and meanwhile we create another task to fix the bug later .. here he chips in:
You know what, that memory bug seems like a corner case, if it won't cause issues down the road after merging let's see if we need even to open an internal fix or defect for it later. Only customers can report bugs.

I am in awe how low the bar can get, I try again and suggest let's at least leave a comment for the next poor soul running into that bug so they won't be banging their heads in the wall 2hrs straight trying to figure out why store X isn't there unless you call something last or never call it or shit like that (the sneaky slimy nature of that memory bug) .. He even dismissed that and rather went on saying (almost literally again): It is just that Mr. Senior had to rush things and communication can be problematic sometimes .. (bla bla bla) back in "Sunken Ship Co." days, we had a team from open source community .. then he makes a very weird statement:
Stuff like what Richard Stallman writes in Linux kernel code reviews can offend people ..

Feeling too grossed and having weird taste in my mouth I only get in a bad hangover day, all sorts of swear words and profanity running in my head like a wild hungry squirrel on hot asphalt chasing a leaky chestnut transport ... I tell him whatever floats your boat but I just feel really sorry for whoever might have to deal with this bug in the future ..

I just witnessed the team giving birth to a sneaky slimy bug .. heard it screaming and saw it kicking .. and I might live enough to see it a grown up having a feast with other bug buddies in this stinky swamp of Uruk-hai piss and Orcs feces.

Today our Jenkins admin told me that I broke the build by merging a branch with too many commits.

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

When you type 'git facebook' in your browser and need a couple of seconds to figure out what's wrong with it, it might be a sign to take a break and go on a holiday far from any computers. Good thing I have next week off...

Ok finally, I can tell now.

There's a college project I'm in with 2 more people that uses Python and AnyLogic (separately).
We also need to write some LaTeX, so as I was already using PyCharm for the Pyshit, I used it for the LaTeX and for Git.
I used it for Git too because I didn't know how it used Git and was worried that if I used the console it didn't recognize something or glitched out or something. And what the hell, it's a mature IDE, what could be so hard or possibly go wrong?

I had to re download the repo a couple of times because between pushes, pulls, merges and commits something happened and the repo ended in a weird state.
These are all the things I do:
Add, commit, create branches, merge, push, pull and delete branches.

So, I hadn't opened in some time. The last time I tried to bring something from another branch, and stayed up late to finish something. I was waiting for my classmates to join the call when I thought something like "Hey, I should commit what I did until now, it worked great.". When I examined the IDE I found out I was in the middle of a rebase or something. I start clicking buttons to at least try to commit. I press "Skip Commit". I lose everything.

What the fuck‽ As you can see in the comprehensive list above, I never do something similar to a rebase. Apparently when I tried to merge a couple of branches, the stupid IDE thought I tried to do a rebase and never asked me to finish it. Why do something I have never asked? Plus, why haven't you prompted me to finish the operation? That's so stupid. I'm never trusting IDEs again.
I was so lit for losing so many hours of work I did a couple of weeks before, I would have to think it and do it all over again because of something I never asked.

We spent an hour looking for a way to recover the lost code.
Why an hour, you ask, if you can use the Local History for that in PyCharm?
Because none of us had used it before and the articles we found said that you had to open it from the toolbar. From the toolbar it was greyed out.
Then I found the option in the contextual menu of the files. Recovered the LaTeX files but on the AnyLogic files, it was greyed out.
I had to open the Local History of the folder containing the AnyLogic file.
And that was that.

I almost faint.
Fuck Python, fuck PyCharm.

Making a dev enemy? Quite simple. Asked too many questions for the dev. I wanted to learn and understand his reasons, he thought I was undermining his position. Other time, I forced him to make the source code be consistent with the structure of applications existing code. Dude came, made some commits adding features in places suitable for him, despite the code having clean layer separation, which took me long time to achieve.

Right now, everything. I started at a Consulting firm because I expected many new problems to tackle, solutions to develop and generally to always have a fire burning underneath my ass but instead I always develop the same standard bullshit.

I miss the days in my old job when there was just a problem and the task to solve it. When I stared down giant amounts of data, just KNOWING that somewhere in that mess is some structure I could exploit and that short moment of inspiration when I finally pinpointed it. The rush of endorphins when the solution became clear and everything fell into place to form a beautiful pattern amidst the chaos test data, git commits and numpy arrays.

Now its just "Yeah, would you just write another selenium testsuite that throws out fail or pass and wastes all the information because the only reason I'm a testmanager is because I'm too incompetent to do anything else and not my passion for the field".

The constant, mind numbing repetition of always the same patterns where the occasional dynamic element that becomes stale is the highlight of my work week... I would have never thought that making good money with easy work would ever get me as close to depression as it did.