I write bugs and sometimes features! I’m also @CoderKat@kbin.social.

  • 0 Posts
  • 61 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2023

help-circle





  • 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.


  • CoderKat@lemm.eetoProgrammer Humor@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    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.


  • I love such formatters and wish they were even more widespread. In many cases, I really want consistency above all and it’s so dang hard to achieve that without an opinionated formatter. If the formatters isn’t opinionated enough, it just leads to countless human enforced rules that waste time (and lead to an understandable chorus of “why can’t the formatter just do that for meeeee”).



  • Ugh, there’s some parts of YAML I love, but ultimately it’s a terrible format. It’s just too easy to confuse people. At least it has comments though. It’s so dumb that JSON doesn’t officially have comments. I’ve often parsed “JSON” as YAML entirely for comments, without using a single other YAML feature.

    YAML also supports not quoting your strings. Seems great at first, but it gets weird of you want a string that looks like a different type. IIRC, there’s even a major version difference in the handling of this case! I can’t remember the details, but I once had a bug happen because of this.

    Performance wise, both YAML and JSON suck. They’re fine for a config file that you just read on startup, but if you’re doing a ton of processing, it will quickly show the performance hit. Binary formats work far better (for a generic one, protobuffers has good tooling and library support while being blazing fast).



  • Also, if OP is new, they may not yet be aware of aliases and functions. Generally you’d out those in a ~/.bashrc file that gets automatically executed when a terminal starts. They’ll allow you to save a more complex command as a really simple one. And particularly can be useful when things you want to run are in unusual directories. Eg, maybe you have a git repo somewhere that contains some project you spend most of your time on, so you could have an alias that just cd’s you to it’s directory. Git also has its own way of doing aliases and that’s really nifty for the more complicated git commands (or the more commonly used, like st for status).



  • CoderKat@lemm.eetoProgrammer Humor@lemmy.mlLaughs in Jira
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 year ago

    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”.


  • Your union sucks then. Unions have done all sorts of things besides get more pay. They fight for benefits like vacation and sick time, make sure you can’t be fired without cause, ensure good work/life balance, make your job physically safe, and help bad management be held accountable.

    Striking isn’t the only tool in a union’s répertoire. They’ll also do things like help pay for lawyers to fund legal action (hard to do as an individual) and negotiate on your behalf. Most people don’t want to be negotiators (especially the most vulnerable) The union does that undesirable work for you and can often hire experts to do it.

    Work to rule is an alternative to striking that is similar but keeps you working. That’s doing exactly what your contract says and nothing more (eg, bus drivers have done it by not collecting fares, but still driving their routes; teachers have done it by only teachong their classes without doing any extra coaching or supervision on the side). And since your comment suggests that people won’t strike because they can’t go without pay, they can also pay you for the duration of a strike.