• 0 Posts
  • 85 Comments
Joined 2 years ago
cake
Cake day: June 22nd, 2024

help-circle
  • proton offers functions to windows programs that those programms expect to be there, however those functions might differ from what the program expect, because they might not implemnted be fully or they don’t cause something to happen that would happen with the windows implementation.

    different proton versions might contain fixes for certain games that break other games or simply do things different enough that game x can habdle that but game y not.


  • yep, a team with “enough” workers when everybody is there and not sick is understaffed, working in those teams can become a nightmare the whole year round.

    and for questions the colleague does not know the answere to? we are atleast two people with a functioning brain, we can figure stuff out. Most of the time if a new dev asks me something and i have time, i’ll comb through docs with them or we debug something together even if i am pretty sure what’s to do, because i don’t want to become a search engine for my colleagues, i want colleagues who can figure stuff out, so i’ll show them how I figure stuff out, and I learn stuff along the way pretty often doing that.

    if I don’t have time I probably have some links that should lead to answeres and often enough a time window later in the day where we can talk, just because its christmas time and most of my meetings are cancelled :D


  • but christmas shift is imho pretty great for new team members (unless it collides with vacation plans, because the job switch was rather sudden and no one else is there), atleast here it tends to slow going, not many meetings and we get to do stuff that accumulated over the year that we wanted to do, but couldn’t for various reasons, so there are enough tasks for which you’ll see a lot of the code base and colleagues actually have time for pair programming and such.

    and christmas itself is 2 and a half holidays in germany, so that helps too.


  • Inability to settle on the right words: I’ll write something and think that what I wrote could be written better or differently and then I keep on writing and deleting and rephrasing with different words. Thus making very slow progress.

    editing is not writing, don’t edit before you are done writing the first version of your story, and editing gets easier after the first enarmourment for a story has worn off anyway. sounds easier than it is, but the voice in your head telling you that you are writting badly is not your friend and not helping, even if it might be right sometimes.

    Problems with continuity: I might think up a somewhat long plot line. But I have to write the whole thing in one go because if I don’t then my brain will splinter the story into multiple possible story branches when I stop and I am unable to choose the path to follow.

    have a look at the “snowflake method” and learn about various story structures to help plan the beats of your story. if planning far ahead is not your jam jot down some notes for what happens next, or if you can’t decide turn the possibilities into yes/no-questions flip a coin and run with whatever fate decided. in general take notes, can’t trust that brain to produce the same output twice.

    Lose interest in continuing if I take a break: If I stop writing mid way and take a break from writing for an extended period of time, I am unable to find the motivation to resume. Mostly because trying to catchup with the story up to that point feels hard. I have this same tendency with video games as well where I don’t feel like picking up a game after an extended period of absence.

    thats normal, if a story can’t reignite the spark that lead to starting it in the first place, that story won’t be finished. keep it somewhere you see it from time to time, it might call you someday and if it does not that’s fine, most stories are never finished. if you want to finish something badly try to set a deadline you cant easily ignore, i turned short stories into gifts (a long with a ‘real’ gift) sometimes just to have a reason why it must be done on day x. the story was not necessarily for the person i gifted it to, but i needed the pressure.




  • which is why many (oop)-patterns exist, what i described is a prime candidate for the strategy pattern, which basically means to turn different algorithms for a task into extra classes with the same interface that can be given to the transaction depending on it’s kind or something else in the context. the question is allways: does the pattern improve my code now or will it improve my code soon, because i know i have to implement 3 more of “almost the same”

    blindly applying a pattern or a guideline like “DRY” has allways the chance to turn into messy ball of code.


  • stuff like this tends to happen, if people look only at the operations the code does, but not what it’s doing it with, those abstractions are often not clean because we lost the sight on what things represent.

    e.g. calculating prices for selling stuff to a business might have enough differences to calculating prices for selling stuff to a private person, that having two different mehtods for that is easier to understand than having a single one with a genreous amount of ifelse thrown in there for cases that only matter for one type of transaction.







  • I’ve heard about people being encouraged to use AI-Tools and monitoring how they are used is good to identify if people are actually more productive with it, but forcing people to use it seems like forcing a gardener to use an excavator where a shovel would have been a sensible option.

    and atleast so far the experience at work is, that stuff that the AI can handle somewhat reliable, we have determinstic tools for. guess working a boring java job has its perks :D




  • knowing where something happens is not knowing what happens and especially not knowing why it happens.

    A big import of data caused a specific datapoint to be inserted twice into the database, but that only happened in our shared testing environment not in our development environment, logs made it clear that we tried to insert something twice into a join table but not why.

    the fix was easy, we can remove the duplicated datapoint from our data before writing it to the database, and we found an edgecase we can handle further upstream so we don’t end up duplicating it in the first place, but why didn’t we run into this issue in dev?

    the data is consumed from a kafka topic with a single partition and read order is allways the same as write order, so our service behaves the same way if the same data is written to the topic everytime, but it turns out the producer does not necessarily write in the same order to the topic given the same input and gaining that understanding was a goose chase with debuggers, logs and combing through code of multiple services written by multiple devs working at multiple companies and thats the true horror of enterprise development jobs, teying to get someone from a different team or even company on the phone who can actually explain something to you with whom you can analyse a bigger part of a system.