6

That moment where you're scared for you job because one of your merges seemingly broke the builds for the 2nd time in a week, had HR reach out, a more senior developer take over the ticket after it gets sent back from testing twice ONLY TO FIND OUT LATER IT WAS ANOTHER PERSONS TICKET THAT WAS CAUSING THE ISSUE

Comments
  • 4
    Sounds like an unhealthy work environment.

    You should look for a place that won't fire you over stupid shit that is easily fixed.
  • 4
    What kind of fucked up place makes an employee feel like they going to be fired because of build issues? Reactionary idiot management much?
  • 5
    So...HR has to know about every bug you produce?
  • 5
    @TeachMeCode it was really weird to me too
  • 2
    @ihavePCSD Do you have a woke HR? If yes, tell them you have extreme emotional distress, and that you now identify as depression.
  • 3
    If you're not breaking builds, you're probably not doing your job.

    Previous admins had the same 'Thou shall not break the build' commandment mindset, and it was very hostile. Everyone was afraid to change anything in fear of possibly breaking a build, even if it was justified/easily fixable.

    Now, its OK (I'm now responsible for the builds). If the build breaks, its an opportunity to fix an oversight or make an improvement. Funny thing is we have far, far fewer broken builds than under the previous admin (at probably 10x+ the number). No drama, fix it and move on.

    For those curious, we had a master build of *everything* anytime anyone checked anything into the main branch. Even if you didn't change the code (and no linkage at all), checking in a WPF project would build, for example, our web site, and if certain variables were not in place, the master build would fail. Then came the angry emails and usually a closed-door 'meeting' with the dept. manager. It sucked.
  • 3
    @PaperTrail ... Wow. That's shit.

    The whole concept of an dev environment / dev branch / whatever you call it is is to spot stuff before it slips into production.

    I usually - e.g. for transitive dependencies - let builds for dev run daily...

    And feeling sad for people like the author of the ranf getting punished for making mistakes. You really don't learn anything from being yelled at or getting fired, you only get demotivated and frustrated.
  • 0
    @IntrusionCM > "The whole concept of an dev environment "

    That idea was lost on them. Our dev branches had GC builds too. What broke those the most was when adding something new (ex. a new library project) that wasn't mapped in the build. Easy to fix, but oh boy, the shit hit the fan.
Add Comment