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









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





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