Personally, I enjoy the problem solving. Debugging is fun once you’re good at it (and when there isn’t major time pressures).

Professional software dev is also waaaaay more than just coding, too. And the more you do it, the less coding you’ll do. A junior dev might spend most of their time coding, but senior devs are spending a lot of time doing high level design, helping the juniors, and reviewing various kinds of things.

Bash is so bad. I literally use it every day and have written many Bash scripts, yet I’m constantly having to search for how to do things in it because syntax is so bizarre and difficult to remember. Need to do a for loop over lines in a file? You can bet I’m googling the syntax for it. I have a general idea for what it looks like and know what to search for, but no way in hell can I write it correctly in the first few tries.

String manipulation is the absolute worst. Have fun getting to learn the unreadable syntax of most sed and awk programs (the only thing most people have memorized is find and replace). Stuff like “split a string of comma separated ints and add them up” are way harder in Bash than in Python, despite the fact I often need to do stuff like that in Bash. Well, in the terminal anyway. Sometimes I’ll just use Python, but Python’s weakness is executing programs and getting their output, which is nowhere near as convenient as it is in Bash.

Side note, isn’t it weird that for a language where flags like --foo bar are so commonly used, there’s no built in or standard tools for accessing flags?

The most recent C++ thing I worked on (not that recent, like 5 years or so ago) was a fairly new project and the people working on it were really passionate about C++. But it was C++ code that ran as a Python library and was using the official Python C bindings. Not sure why we didn’t use one of the unofficial C++ libraries, but the usage of that C library (and such a fundamental one) held things back. We wrote was was modern C++ (at the time), but big chunks would be a completely different style.

I hate writing code in either language. But at least what C has going for it is that it’s waaaay simpler than C++. Simple can be a really good thing. Sure, all those cool features can save you time, but they can also be gotchas that will cause bugs.

Though it is a balancing act. Too simple and you’ll make mistakes due to how much you have to repeat yourself or using unsafe equivalents (like using preprocessor directives to mimic features that C++ natively supports).

I remember wondering this when I was first trying to self learn. It’s because I needed a map (or list + struct or something) and was such a noob I didn’t know what maps were. Whatever material I was learning from wasn’t good enough, especially for winging things. Plus I was trying to learn C++ and maps aren’t quite so built into the language as they are with a better first language like Python.

Totally depends on what the use case is. The biggest problem is that you basically always have to compress and uncompress the file when transferring it. It makes for a good storage format, but a bad format for passing around in ways that need to be constantly read and written.

Plus often we’re talking plain text files being zipped and those plain text formats need to be parsed as well. I’ve written code for systems where we had to do annoying migrations because the serialized format is just so inefficient that it adds up eventually.

But why? Part of why reddit became so useful was its ability to use it for searching. Even though I no longer visit reddit regularly anymore, I still use site:reddit.com on many of my google searches because it gets better results for opinion or explanation based topics. Similarly, I found tons of useful local info from my local city’s subreddit. I can’t say the same about the Lemmy community, which I only see if I explicitly remember to go to it because the sorting doesn’t show small instances.

I have two levels of backlog. The first level is my curated list of tickets that are highly worth doing in the near future and is limited in size. It’s currently larger than I’d like at 30-something (for a team of a little under 10), but I’m trying to get the team to focus on it more after historically neglecting it.

The second level is literally just everything else. Hundreds upon hundreds of tickets, ranging from restructuring unit tests (which will frankly never happen unless the structure of the tests somehow became a major barrier) to cool features that just aren’t important enough yet (or would take too long). Plus all the super low risk bugs, often in edge cases that nobody really cares about yet or aren’t worth the time to fix yet. And then there’s all the automation style tickets about improving the handling of something (commonly edge cases of things already automated for the happy path), but often that something just isn’t common enough to be worth it.

Tickets in the second level sometimes do get done. Usually because some issue becomes more common, enough people ask for it, or we simply finally have time for a new feature (can only do so many of those at a time). A common theme I have is I’ll encounter a problem, file a ticket, then eventually encounter the problem enough times that I go, “fuck it, I’ll do it myself”.

Light mode is the best and I think a significant number of people who oppose it are students or hobbyists who only program outside of typical work hours. During work hours, I want bright light to keep me alert. And I work in a well lit office and home mostly during the time of day when there’s lots of sunlight. Dark mode just doesn’t make sense for professionals.

Plus, if even a single documentation site or Google search uses a light theme (and many do, especially by default), you risk blinding yourself with the sudden flash to light. By comparison, if I’m using light mode and something else is in dark mode, it doesn’t hurt me at all.

Yeah, I’m constantly recommending junior devs to use TDD specifically for this. I don’t recommend it for anything else. If they don’t write the test first, it’s possible that the test will end up testing the wrong thing and thus they can’t be sure they really did fix the bug.

Sometimes it’s hard to tell where to write the test ahead of time, so sometimes a slight variation I do is to write the test after (usually because it was such a struggle to figure out where the bug is), but when I’m testing it, I’ll comment out the fix or whatever and make sure the test fails.

Reported here: https://github.com/LemmyNet/lemmy-ui/issues/1968

Yeah, and they don’t just lie. They lie extremely convincingly. They’re very confident. If you ask them to write code, they can make up non existent libraries.

In theory, it may even be possible to use this as an attack vector. You could ask an AI repeatedly to generate code and whenever it hallucinates, claim that package for yourself with a malicious package. Then you just wait for some future victim to do the same.

The reason for the approximately 50 character limit is because there’s many tools that display a single line and will truncate it if it’s more than about that length (though really the point of truncation can vary wildly – plenty of tools will let you go twice that before they cut you off). So if your one line summary is too long, it’ll be cut off and harder to understand your commit at a glance.

You always can elaborate in a second paragraph, at any rate.

Just a heads up, I think the word you’re looking for is empathize.

Well, that’s what happens when you’re not careful enough. You can’t just go yanking cables! They need to be finessed. To be bought dinner, first.