3 ms·

This reflects more poorly on your engineering leadership than your coworker imo. Where are the guardrails? Why aren't his migrations going through a pull reques

by mjr00 4y ago

This reflects more poorly on your engineering leadership than your coworker imo. Where are the guardrails? Why aren't his migrations going through a pull request where you can review and say "this should be a batch insert?" If PRs are in place but nobody speaks up, why is the culture afraid of pointing these things out?

CuriouslyC 4y ago
Oh, I totally agree, had I been the technical lead for that team I would have flagged a lot of that stuff. As it stands the lead for that team is also on the nice but incompetent spectrum to some degree, and since the code base they're working on is an inherited dumpster fire I get the sense people on that team have mostly given up on code quality.
morelisp 4y ago
I can’t speak for the GP but I am currently in a position where we have the PR, we make the comments, the fix happens (kind of), but then it all repeats the next time. It’s tiring for the (technical) PO and the senior dev doing most of the reviews (me). It does not seem tiring for the employee. He seems like he could enjoy doing this forever, often commenting about how much he’s learning.
srcreigh 4y ago
Yeah this kind of stuff is always best solved with general eng guidelines. I’ve been that guy many times. Having to do my PR 3 separate times over the course of a week because of feedback. IMO each solution worked fine, and the feedback was also fine. The trouble with explicit guidelines is it’ll make clear that your high-clout engineers are always breaking them. The reality is some peoples time matters more. And ideas aren’t always better, it’s about reducing the mental workload of one person at the expense of another person. There was a comment on previous thread about how they beautifully offered the autistic guy his own somewhat independent projects and he excelled. This is unthinkable in many places. It’s common to have the one high clout senior guy who wants to maintain clout but doesn’t have the mental resources to offer autonomy of the underlings. One can dream, though.

by mjr00 4y ago

CuriouslyC 4y ago

Oh, I totally agree, had I been the technical lead for that team I would have flagged a lot of that stuff. As it stands the lead for that team is also on the nice but incompetent spectrum to some degree, and since the code base they're working on is an inherited dumpster fire I get the sense people on that team have mostly given up on code quality.

morelisp 4y ago

I can’t speak for the GP but I am currently in a position where we have the PR, we make the comments, the fix happens (kind of), but then it all repeats the next time. It’s tiring for the (technical) PO and the senior dev doing most of the reviews (me). It does not seem tiring for the employee. He seems like he could enjoy doing this forever, often commenting about how much he’s learning.

srcreigh 4y ago

Yeah this kind of stuff is always best solved with general eng guidelines. I’ve been that guy many times. Having to do my PR 3 separate times over the course of a week because of feedback. IMO each solution worked fine, and the feedback was also fine. The trouble with explicit guidelines is it’ll make clear that your high-clout engineers are always breaking them. The reality is some peoples time matters more. And ideas aren’t always better, it’s about reducing the mental workload of one person at the expense of another person. There was a comment on previous thread about how they beautifully offered the autistic guy his own somewhat independent projects and he excelled. This is unthinkable in many places. It’s common to have the one high clout senior guy who wants to maintain clout but doesn’t have the mental resources to offer autonomy of the underlings. One can dream, though.