71–80 of 105 posts
There is the risk of conflating two separate types of problem. There are problems that arise from the complexity of the code, and problems that arise from particular people. If a programmer has a habit of sloppy code, or violates the team's standards in some ways, then a good leader will keep track of the fact that one person is responsible for a recurring pattern of mistakes. I absolutely agree with Rachel By The Ba…
I do a lot of open source work and unfortunately a very common posion is focusing on “who broke it,” which is especially disparaging when done in public. A particularly nasty habit is when outsider Alice opens an GitHub issue saying “xxxx is broken” and developer Bob replies with “yup, @Charlie’s commit fubar’d everything.” Unfortunately both very demoralizing and very common.
I just don’t really get it. Even when I was a junior, if I overheard “this thing is broken,” I was the first to pop up and say “oh, I bet that was me, let me have a look.”
I do a lot of open source work and unfortunately a very common posion is focusing on “who broke it,” which is especially disparaging when done in public. A particularly nasty habit is when outsider Alice opens an GitHub issue saying “xxxx is broken” and developer Bob replies with “yup, @Charlie’s commit fubar’d everything.” Unfortunately both very demoralizing and very common.
Demoralizing - why? That seems like an attitude problem on the part of “Charlie”, not “Bob”. If “Charlie” is going to slink off with his tail between his legs every time he makes a mistake, he’ll have a tough time of it - it’s not like everyone can’t SEE that he broke it through version control anyway! I just don’t really get it. Even when I was a junior, if I overheard “this thing is broken,” I was the first to pop…
First, it's generally best to praise publicly, and criticize in private.
Second, saying "@Users's commit screwed-the-pooch" blames but, frankly, may not be the whole picture. It's entirely possible that the commit caused the issue, but everything was done by the book in which case it's really an organizational failure.
Personally, I sympathize with your argument. I have no personal problem with Torvald-style correction. I used to work under an asshole who would threaten to have me fired routinely. Personally, I prefer the blowhards because you can always tell where you stand. Still, not everyone is wired this way and part of leadership is recognizing that and playing to various folks strengths and weaknesses.
I used to think this way until I started working with someone who was nearly always the one who broke it. At some point we just had to face the fact that his work was unreliable even after significant mentoring. If the tasks were difficult that would be one thing, but I'm talking about stuff like committing code to prod that was clearly never even executed once.
Sounds like you have a code review and automated testing problem and not a bad coworker problem.
I do a lot of open source work and unfortunately a very common posion is focusing on “who broke it,” which is especially disparaging when done in public. A particularly nasty habit is when outsider Alice opens an GitHub issue saying “xxxx is broken” and developer Bob replies with “yup, @Charlie’s commit fubar’d everything.” Unfortunately both very demoralizing and very common.
Demoralizing - why? That seems like an attitude problem on the part of “Charlie”, not “Bob”. If “Charlie” is going to slink off with his tail between his legs every time he makes a mistake, he’ll have a tough time of it - it’s not like everyone can’t SEE that he broke it through version control anyway! I just don’t really get it. Even when I was a junior, if I overheard “this thing is broken,” I was the first to pop…
Imagine if Apple came out and said “yeah, that blank root password bug, it was all because of John Smith and his crap patch that caused this.”
Outsiders don’t have the same perspective as insiders. If Charlie’s commit message read “implementing the really difficult thing we talked about,” the team might be aware of mitigating factors that Alice won’t. But even without those mitigating factors, all you’ve done is badmouth your own devs to the public. Additionally, you are not considering whether Charlie is an otherwise stellar developer that has never had a bad patch before. Alice may incorrectly presume that the only reason he’s being called out is because this is a habit of his, perhaps.
It's not about whats broken, its about what you DO when it is broken. This my favorite interview question to ask candidates: "What is your all time biggest screw up, and how did you come back from it" - I then tell them the story of me loosing several hundred thousand dollars and the funny things that happened around it to set the tone. If you have been in tech for any length of time you have one of these stories (if…
On the other hand, I have had to clean up some major screw-ups that I inherited from other, less careful developers. I have saved at least one company millions of dollars in annual cost that were being wasted (still waiting for ANY recognition for that one).
One place I worked was being charged for blank pages scanned and all my team and I did was come up with a way to avoid scanning those blank pages by not needing to use them as a physical delimiter. That process change saved $100K a year in cost. Some asswipe of a developer that came before me caused that and both didn't care and didn't even know what they did wrong, probably.
I took down an assembly plant by clicking on a Network status icon from a particular hardware supplier. Over the weekend, firmware patches were applied, and the server rebooted. After reboot, everything worked fine, so the tech marked the change successful and went home. Well, apparently the NICs would work just fine, but not all settings were applied until you opened the UI provided by the vendor. When you opened th…
> [...] not all settings were applied until you opened the UI provided by the vendor. [...] the NICs would reboot, just long enough to kill TCP connections. The UI part suggests that it was Windows, and if it was, it's not quite the case that "just long enough" to kill TCP connections, as you need quite a lot of downtime to terminate a typical TCP session. In Windows, if a NIC goes down, all the TCP connections that…
It is not about some small and well defined set of "idiots", it is essentially industry-wide design mistake.
Earlier quoted context omitted.
Im going to say this - When it is all said and done, if you fucked up, you should get some shit for it. However this should be good natured, YOU should be laughing at it and everyone else laughing WITH you.
No one has right to demand what I laugh about or not. There is enough shit I have to take regularly to have zero desire to have to pretend laugh to it. The discussions about everybody mistakes should be open, with emphasis on everybody, but leave mockery out of it. Inform everyone when they make mistakes without mocking them or attacking their egos and keep it factual. Don't assume everyone is friend with everybody n…
I work in the nuclear industry, where most places are pretty good about maintaining a "blame-free" culture. You focus on what processes and procedures failed, what controls were missing, etc., that allowed somebody to make a mistake. As this attitude was adopted, things shifted too far (at least in the opinion of industry groups, and my observation) to the point where people underperforming to the point of negligence…
Well, that's just it, the fact that underperformers aren't recognized is also a symptom of the process, and the fix is fixing the process, not throwing away the process. Every problem is organizational, even those caused by individuals, because it's the organization's job to recognize and remove those individuals where appropriate.
I enjoy organizations where individual's expectations are clearly defined, and I prefer if there are consequences for missing those expectations because I feel like it increases the reliability of the team.