3 ms·

i'm a pretty mild mannered personality, very reluctant to get angry with other people. i try to be diplomatic with people, at least, in person. one of my worst

i'm a pretty mild mannered personality, very reluctant to get angry with other people. i try to be diplomatic with people, at least, in person. one of my worst experiences working on a dev team was checking in code that broke the build. the alpha came into my office and got quite angry with me. it left new emotional wounds and reopened old wounds. it didn't help me become a better programmer, just more fearful and stressed. i've reflected many times on how that message could have been conveyed better. multiple years later, a manager i was working for decided he needed to start writing code and he checked in something that broke the build i was working on. of course, now that the shoe was on the other foot, what do you think i did? i reacted angrily! (lucky for me, he's a good guy with a lot of class and didn't just fire me on the spot. he didn't even react in a negative way.) the lesson i learned is that i need to become classier. still working on that ...

Aeolun 9y ago
As far as comments on a checkin go. The main thing I find is that the way to phrase things is very important. Whatever you do, write any of your thoughts as suggestions instead of tasks to be completed. If you have a decent coworker, they'll know when something is really a problem, and when something is actually up for discussion.
mv4 9y ago
Hey, what happened to "move fast and break things?". Put that poster on your wall, it will work wonders. In all seriousness though, writing code (and especially production deployments) can sometimes be stressful. Smart people do stupid things sometimes, or some random event occurs, and makes them look that way... after a while, you learn to separate your persona from your work product. One other thing you start to value after a while, is directness. While sugarcoating things sometimes makes people feel better, most effective teams are good at delivering facts, or if it's an opinion - making a logical case to support it.
gknoy 9y ago
I hope this doesn't come off as snarky, but you and your team may find many benefits from making infrastructure changes that prevent anyone from breaking the build. One way we do this is to have CI run for all pull requests, and prevent merges if there are any test failures, and the other is that we have a staging site where we run even more tests to ensure mistakes don't go to production (very often). The interesting thing is that we programmers still make just as many mistakes -- but there are no angry feelings or animosity when they do because it doesn't hurt anyone else. If I make a pull request that fails linting, or breaks a bunch of tests that I forgot about, it won't affect my teammates, won't get to production, et cetera. It transitions the interaction from "You broke my stuff!" (which causes hurt feelings) to a robot (callously? uncaringly?) informing me that I have more work to do before my stuff is of a caliber that merits merging with the rest of the codebase. Somehow, that doesn't hurt feelings nearly as much. This also requires the codebase to have extensive enough test coverage that you can trust the tests to catch any breakage -- which requires code review to notice if one forgets to add a test for functionality. The upside is, having that kind of coverage means that you can refactor fearlessly, and can really trust an automated deployment workflow.

Aeolun 9y ago

As far as comments on a checkin go. The main thing I find is that the way to phrase things is very important. Whatever you do, write any of your thoughts as suggestions instead of tasks to be completed. If you have a decent coworker, they'll know when something is really a problem, and when something is actually up for discussion.

mv4 9y ago

Hey, what happened to "move fast and break things?". Put that poster on your wall, it will work wonders. In all seriousness though, writing code (and especially production deployments) can sometimes be stressful. Smart people do stupid things sometimes, or some random event occurs, and makes them look that way... after a while, you learn to separate your persona from your work product. One other thing you start to value after a while, is directness. While sugarcoating things sometimes makes people feel better, most effective teams are good at delivering facts, or if it's an opinion - making a logical case to support it.

gknoy 9y ago

I hope this doesn't come off as snarky, but you and your team may find many benefits from making infrastructure changes that prevent anyone from breaking the build. One way we do this is to have CI run for all pull requests, and prevent merges if there are any test failures, and the other is that we have a staging site where we run even more tests to ensure mistakes don't go to production (very often). The interesting thing is that we programmers still make just as many mistakes -- but there are no angry feelings or animosity when they do because it doesn't hurt anyone else. If I make a pull request that fails linting, or breaks a bunch of tests that I forgot about, it won't affect my teammates, won't get to production, et cetera. It transitions the interaction from "You broke my stuff!" (which causes hurt feelings) to a robot (callously? uncaringly?) informing me that I have more work to do before my stuff is of a caliber that merits merging with the rest of the codebase. Somehow, that doesn't hurt feelings nearly as much. This also requires the codebase to have extensive enough test coverage that you can trust the tests to catch any breakage -- which requires code review to notice if one forgets to add a test for functionality. The upside is, having that kind of coverage means that you can refactor fearlessly, and can really trust an automated deployment workflow.