3 ms·
> when they fix other people's bugs, their commits are smaller and more tightly focused. While this may be true of junior engineers or people working on a pro
by DubiousPusher 5y ago
> when they fix other people's bugs, their commits are smaller and more tightly focused.
While this may be true of junior engineers or people working on a project that they don't actually put into production, I feel it can't be true of most people working a devops roll on a production system.
I only worked several years in devops on a small production system with a few hundred users but I learned very quickly to respect others' work and the thought they had put into their areas and to be very wary of "fixing" anything more than the described bug.
Honestly, not exaggerating, it makes my stomach churn a bit. Regressions are very real and if you don't have decent test coverage with actual integration or functional tests, you are writing regressions and you just don't know it.
- Jorengarenar 5y agoIn the first paragraph you say you disagree, but the second one just reconfirms the article?
- toxik 5y agoGP may be saying that senior devs tend to s---t all over people's code. I've certainly seen it happen. But I think that's more of a personality trait (well, lack of empathy) than anything else.
- drran 5y agoWhen I will see the problem, I will fix the problem. What the problem with that? Do I need to create a ticket and assign it to Junior with a book long description and proposed solution?
- cowsandmilk 5y agoDepends on priorities and how much you are working to help junior devs create better code in the future. Sometimes, teaching other developers why something is a bug is the best thing for your team long term.
- ratww 5y agoThe problem is that when one fixes a problem by "s---ting all over people's code" like GP said, chances are they're introducing more bugs or restoring old ones. That's why git-fu, comments and a collective memory is important. Not only we need to know what was done, but also why, when and in which conditions it was done.
- DubiousPusher 5y agoNo. It's not about satisfying bureaucracy. It's that at a certain point, any complex code system becomes a black box. You cannot fully reason about it. Your tests become your source of validating that box and any change you make is just as likely to break something as it is to fix something.
- DubiousPusher 5y agoYou're right! I misread this as meaning the opposite. Thanks.