Other people's code is why I love software. The division of labor is amazing. Even if it's terrible I can fix it faster than I can write it myself, then I can make a PR and the state of tech moves forward just a tiny bit.

I hate everything to do with devops and sysadmin work though. It superficially looks like programming work but it totally different, and often involves manually doing things that feel like they should be automated but can't quite be, or working on live systems making changes directly rather than writing code that only touches anything real after review and test.

I hate how often things get obsolete, but sometimes the constant march is wonderful. It's always great to rip out half you in-house code when your new framework does it all for you.

You can write large applications while only having to maintain your core functionality and some wrappers for external stuff.

Ahahha, fun to read this comment. I enjoy that you enjoy the exact opposite aspects of programming to me. I'm definitely in gp's camp. Always as little abstraction as I can stomach, never use a library if I only need a single function. Ruthlessly throwing out other people's code so that I don't have to try to understand boxes of spaghetti that go wrong in weird and quirky ways. I love me a good datasheet and a night spent flipping bits in registers.

I actually got my start flipping bits on the PIC, partly because I heard so much about lightweight software I just assumed it must be absolutely and objectively better in every way to get so much hype.

When IoT stuff started getting big and SSDs became affordable my attitude started slowly changing as I actually experienced more software complexity and how it could just work, and save so much time for users and devs.

The tradeoff is it only saves time if you do exactly what the library dev wants you to do, and don't look into the internals too much.

I still enjoy digital electronics design, but I don't do much outside of work because the finished product is often a bit disappointing compared to commercial stuff that usually has an app ecosystem, a warranty, an injection molded case, etc.

I've been on somewhat of a decluttering binge both physically and digitally, so I've currently got almost no DIY stuff in use at home.

Yep. It's hard to be romantic when you're trying to get a fix out for customers that really need it, but the fix has to paper over years of ahem diverse approaches to data modeling, the tests you write to help you uncover unknown abominations in your own codebase[0], every fix cascades to new fixes, it's late, dark outside, you're already thinking about how to apologize for the size of your PR tomorrow morning, and then when you finally push your branch to Github to watch the automated tests pass, it notifies you that there are merge conflicts with develop. Complicated merge conflicts.

[0] How's this for an abomination: due to an error using SQLAlchemy, one of our types was being constructed in one way in our code and being constructed in a different way by SQLAlchemy. When we instantiated it directly, you got its properties using methods: organization_id(), last_updated_at(), etc. When we loaded it from the database using SQLAlchemy, organization_id, last_updated_at, etc. were fields, not methods. Somehow people managed to call foo.organization_id(), foo.last_updated_at(), etc. in all the code paths where we handled instances we instantiated directly, and access foo.organization_id, foo.last_updated_at, etc. in all the code paths where we dealt with instances fetched from the database.

That actually could be fun. That's the pressure coming from whomever manages the project that turns it into a nightmare. Allow me however long I need to refactor someone else's mess and I'm having a field day.

I think what makes it not fun for me is seeing users screwed by things that shouldn't happen. Things we should have done right the first time. Things that can only happen because of bad technology choices. Things that take hours to fix for no good reason, things where the only reason a fix takes ten hours instead of two hours is that we're paying for bad decisions.

What you just described is what I consider the fun part

Agreed, up until the point when the deadline is last week and you only started working on it.

Transforming an old, rusty black box into a documented, smoothly-running clockwork can be a lot of fun. Truth be told, those kinds of jobs were the most rewarding I've had so far.

There's a sense of mystery when diving into an abandoned code base and deciphering the ancient scripts found there. There's the accomplishment when puzzle pieces start fitting together and the original programmer's intent reveals itself in the debris of half-decayed architecture. And then you chisel away at that, extract the beautiful core, and relearn the ancient knowledge. Sometimes there's a strange sort of historical connection formed with immaterial, long-gone programmers. There's always something to learn from those bygone workarounds and edge case traps.

Maybe I'm weird, but I love this stuff.

Much better than dealing with the hurt feelings and entrenched biases of live developers.

I really like the way you wrote about that kind of code archaeology. There's that mystery, and also almost a sense of loss when you see the ambitious hopes that fell by the wayside.

Once in that kind of codebase, I found a snippet of code that gave me a tiny glimpse of the long tuning, bugfixing, and hacking had happened on it. In a constant propagation pass inside a compiler/jit system, deep inside for a single kind of propagation, was the line:

  if (strcmp(symbol_name, "ip") != 0) {

Gack!! The instruction pointer, special-cased.

> Because you gotta work with other people's code at some point or another. And much of it is unreliable, buggy and/or badly documented.

Blaming others is fine but really sometimes that "other people" is yourself and often you barely remember that you wrote it.

> often you barely remember that you wrote it

Yes, exactly. My memory is extraordinarily crappy, another reason for me to invest time into writing documentation.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” - John Woods

I have a terrible memory. Sometimes I'll look at code I wrote ages ago and think "Wow! I really did a good job here.". Other times I'll think "Wow! What the hell was I thinking?" lol

Some people can maintain the complex code they write but might be viewed as spaghetti to someone else. You can't trust always trust someone's call when they say code is unmaintainable.

Yes, it's always other peoples code that's the problem.

When I'm writing new code, yes. Absolutely, yes.

It's when that code is written that it becomes a problem too.