40
Root
66d

"Mature codebase"
"Our entire team are senior devs"
"Almost everyone that worked on the project is still here and available, so nothing's lost! We can ask whatever we need to."

You would think this would mean the code was clean and easy to read, and you could ask the person who wrote it for help. But. no. It's kinda the opposite.

Here's an example:
I'm trying to write a mailer, and I have no freaking clue how to get it working. I talked with two of the more senior devs, and both assured me it was very straightforward, and then walked me through the quite complicated mailer structure and got lost. The first pretended not to, but glazed over a few holes in his tour, and said I could figure the rest out. The second one ended up admitting that he's totally unfamiliar with it -- his last commit on a mailer was from about 8 years ago -- and doesn't know how to get it working anymore.

So, I'm on my own.

I wrote a super basic mailer for debugging (no idea if/how it actually sends a mail, but I think I can construct one?). But whenever I call the mailer, it gets run twice? Somehow? Apparently I need to start a bunch of daemons to get that part of the system to work. Which is cool because they don't work fresh out of the repo. Got some further help, and now my ostensibly working code throws errors for an undefined var that i'm not even using, and to make it easier: without a backtrace. joy! There's so much inheritence and extending and including going on that it's going to take me hours to track this down. ugh.

I'm keeping my paystub in front of me for some desparately needed motivation.

Comments
  • 8
    Also, thanks to some preloading shenanigans, I often need to kill my server and console instances, and run `killall ruby` and/or wait about 15 seconds before I can see any code changes. After restarting one of the daemons, ofc, which takes another 30 seconds or so. I still haven't managed to get the other daemons to work, and I'll probably need to contend with that later. All for what amounts to a simple email form. Ugh.

    This job is a dream, let me tell you.
  • 4
    Unless you wrote the code as a green field project and it's less than a month old, that code base sounds.... normal.
  • 6
    @monkeyboy Not for my code.
    Not for code written by any of my devs, either.

    This code is a disgrace.
  • 2
    Long-lived + no major eng changes => yeah, tbh I'd kinda expect it to be wonky. There hasn't been any need to improve it, everyone already knows what they need to know.

    Some small turnover is healthy, it keeps stuff like this from getting truly absurd.
  • 2
    Write from scratch, and just push the mail out?
  • 0
    This is some quality rant material right here.
    Have you tried a bigger hammer?
  • 0
    @Root I'm a little less sanguine about my body of work.
  • 2
    Been there too. One would assume that code base maintained by the same set of people would be somewhat consistent but... no.
  • 1
    On my team, it's usually me vs everyone else... How I want/do things vs how they do things...

    I just had another I told you so but ¯\_(ツ)_/¯ on Friday...
  • 3
    "everyone is still here so nothing is lost"
    That sounds like there is a lack of documentation!
  • 2
    @saucyatom but brain cells are lost and therefore so is memory unless everyone had photographic ones....

    Oh wait I believe they do... Somewhat... It's called writing it down.... In an understandable and sharable way...

    Hmmm... If only everyone else on my team realized it's not a waste of time.

    Or perhaps they avoid doing so they don't need to come to terms with how shitty their code is... (So bad they can't even explain it or why they write it the way they did)
  • 0
    @saucyatom You're right. There is no documentation.
  • 3
    Gotta love ghost bugs producing double
    /multiple of something in those big legacy codebases.

    Have had a ghost bug (unreproduceable) emitting multiple user notifications in prod, plaguing the team for at least a year.

    "Mature" and "rancid" can be interchangeable from a certain angle.
  • 1
    Mature code base. Immature devs
  • 2
    „Our entire team are senior devs”
    That’s an orange flag to me.

    Without a healthy fraction of juniors, your codebase becomes gradually convoluted. They whine and complain and at least indicate possible overengineering problems. Best code review from a junior, I received, was „I don’t understand this”.

    The seniors adapt too easily to their own BS.
Add Comment