8 ms·

Optimizing your talking points (2018)

195 points by compiler-guy 2y ago

rkachowski 2y ago
I agree this righteous "one" stuff is toxic. There is something very liberating and wholesome about a senior developer being able to discuss the mistakes and fuckups they've made. It's not just a learning opportunity, it also demonstrates a culture of openness and works against imposter syndrome. A perfectionist attitude stands in opposition to this - just try harder and stop making mistakes. There's nothing to learn, just more individual effort to apply.
- tetha 2y ago
  Most of us are hopefully also improving at what they do. Our config management has a bunch of stuff written by me that's perfectly functional and works overall. But after a year or two working with the tool, I would call it pretty bad quality for various reasons. But that's fine. If I have a reason to change it, I'll clean it up. Until then, it stays around as an example to show some bad practices and why other approaches are better.
- otherme123 2y ago
  I immediately recall at least two big fuckups that the "one" (two different persons) didn't acknowledge, even if that meant to lose a good client, and I would guess bad mouthing. Once I ate a small fuckup from one of my juniors (we put a wrong software version in a report), and instead of fixing it with the client by simply saying "we had a mistake, here is the fixed report", my superior only could think about "could we hide this, and keep the face that we are perfect?". Of course, this same person takes any mistake from other people as an opportunity to ask for discounts, compensations and freebies.
- evrydayhustling 2y ago
  If you can't find things to criticize about yourself, it means you aren't improving. Sharing these critiques helps others both learn from your mistakes, and that it's ok to learn from their own.
dclowd9901 2y ago
Why is this person feeding trolls? Don’t we all know people who think they’re infallible are full of shit anyway and just ignore them?
- bjackman 2y ago
  You can't just divide the world into people who believe fallacies and people who don't. They are rooted in fundamental cognitive biases, everyone falls for the "just try harder"/"just be better"/"just don't put any bugs in the code"/"just have excellent test coverage" thing sometimes. Certainly all the most experienced engineers I work with, who should definitely know better, still haven't fully internalised the fact that all code is broken.
  - 8n4vidtmkvmk 2y ago
    They really should. I've been programming over 20 years and don't think I've seen a program without at least a few defects. A couple have come close, those are impressive, but bugs always happen.
    - gravescale 2y ago
      Show me a program that has no bugs and I'll show you a program that does nothing at all! Even most Hello Worlds don't check the pipe was written to correctly. And now we get into "well actually that's technically not a bug because it is not in the spec" and if we're finding the need to split that hair, we can hardly be talking about some mythically perfect software.
      - richardw 2y ago
        You’re not wrong but Knuth’s programs have very few bugs and do a shitload. “The reward for coding errors found in Knuth's TeX and Metafont programs (as distinguished from errors in Knuth's books) followed an audacious scheme inspired by the wheat and chessboard problem,[10] starting at $2.56, and doubling every year until it reached $327.68.” https://en.m.wikipedia.org/wiki/Knuth_reward_check https://en.m.wikipedia.org/wiki/Knuth_reward_check
akoboldfrying 2y ago
>malloc("HTTP") I'm reminded of a Simpsons episode where Homer tries to assemble a barbecue by pressing a brick and a piece of pipe together.
- jrockway 2y ago
  "That's one fine looking barbeque pit."
- pavlov 2y ago
  Because I am the one, my custom malloc checks a given size against the list of known constant string pointers and if it matches, it calls strdup instead. So easy to program defensively in C.
  - lambdaxyzw 2y ago
    I guess you could check if the pointer points inside a data section of your program, and if yes, call strlen on it. It's all so easy!
philbo 2y ago
I've received a few nasty comments in response to blog posts, both here and on reddit. When it happens I update the post to link to the nasty comment, without judgement, just to shine a light on it. Usually nothing happens but sometimes it steers the discussion to a healthier place.
- rulalala 2y ago
  This is great. I wish all humans could think that way.
- ChrisMarshallNY 2y ago
  I've received quite a few. Some, probably deserved; most, likely not. In a few cases, it was -sort of- deserved, but not helpful, or directly harmful to the community. Saying the right thing, in the wrong way, is still saying the wrong thing. > When it happens I update the post to link to the nasty comment, without judgement, just to shine a light on it. Not a bad idea. Not always possible, if the comment gets dead'nd. In any case, I do not respond in kind. I'm quite capable of it (recovering troll), but I won't go there. It's not being a "snob." It's just that I've learned that gasoline is an ineffective fire suppressant. If I'm wrong, I've learned to promptly admit it; in the same venue as the mistake (a pet peeve is private apologies for public attacks). There is a line though. I feel that I do really good work. I've been doing this for a long time (like, 40 years), and have learned quite a bit, in that time. I've also worked some pretty tough rooms, and for folks that wouldn't accept crap, so I have learned to habitually do decent work. My general policy is to avoid casting judgment onto others in public. It doesn't help; even if I'm right (not always the case). But if we're working together, or I am using your stuff, then it might be a different story. I have had people savagely attack me, because I won’t accept garbage. Guilty as charged, but I don’t go Torvalds on them. I just tell them that their work is not acceptable to me, in a respectful manner, if possible. Nevertheless, I have found that I can always improve, and learn new stuff; sometimes, from the most unexpected places, and being open to these lessons is basic good policy. I become right, by being wrong, and learning otherwise. "Good judgment comes from experience. Experience comes from bad judgment."
  - 2y ago
BillFranklin 2y ago
I don't disagree that some engineers have bad attitudes! Everyone is capable of writing bad code, and there is something to be said for the argument that all code is bad and a liability. This article is an interesting companion to "No more pink mustache" [1] wherein Lyft is described as "broken at a scale that is hard to believe" - often the explanation for quality is the org, not the human in the chair :-) [1] https://rachelbythebay.com/w/2020/02/29/poof/ https://rachelbythebay.com/w/2020/02/29/poof/
surfingdino 2y ago
I could not disagree with the point made, but there is a flip side to this--being able to take feedback.
- jasonlotito 2y ago
  Most people can take feedback and apply it. I find some people just give feedback poorly and equate that to others not taking feedback. These people usually think there preferred feedback is the best way so therefore everyone should feel the same way and if they don’t the other person needs to change. They are of course wrong. But if you tell them this, they demonstrate why I use the word “most” in the opening sentence.
  - npsimons 2y ago
    > I find some people just give feedback poorly and equate that to others not taking feedback. Too true! I find it helps if I think of it as an engineering problem: "what can I say that will make these people not commit the same error again?" A bit dehumanizing and manipulative, but can be super effective at shifting away from blaming and belittling (almost never works), and towards mentoring.
red_admiral 2y ago
(2018), but still worth reading.
tanelpoder 2y ago
I can’t find the blog/article anymore, but its message was that “when you see something suboptimal in the code, do not assume incompetence”. As people who wrote the code may have had tight deadlines, different priorities set for them and other factors that may have prevented the developers from “doing the right thing” immediately…
- lambdaxyzw 2y ago
  There's also chesterton fence - maybe this dumb thing in code actually was important some time ago. Or, even worse, maybe it is still an important for a rare edge case and you just don't see how, yet.
  - brazzy 2y ago
    That as well is "not doing the right thing", namely adding a comment that explains the need for it.
  - kqr 2y ago
    The Chesterton fence in my book is only about something that is still meaningful only in non-obvious ways. In evolutionary theory I believe "used to have a sensible explanation but no longer does due to changing circumstances" is known as discordance.
    - MrJohz 2y ago
      The fence is about all things that you might want to change, whether or not they're still useful. Both of the characters in Chesterton's parable are reformers, and the assumption is still that the goal should be reform. The question is more about the motivation for reform. The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it. Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious. (That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)
auggierose 2y ago
And how can this be? Because he is the Kwisatz Haderach!
- cushychicken 2y ago
  The Mahdi is too humble to admit he is the Mahdi!
Sammi 2y ago
I regularly have codevs who say similar things to "why don't you just not make that mistake?" and "why not just do <insert crazy complex thing here> instead?". I've taken to responding with: "Because you probably have more IQ points than me. I have fewer IQ points than you, so therefore I must do dumber and simpler things than you." It's made some of their faces turn red in embarrassment, as they finally realized what unreflected belittling little dorks they were being.
- juliushuijnk 2y ago
  If it is said in ignorance, there is no need to view it as an attack that you need to make them pay for with embarrassment.
- dmichulke 2y ago
  An alternative is to plainly agree with them: "I know, that was dumb, wasn't it?" or "You're right, I probably shouldn't"or just "I'll think about it" This means they can't shame / guilt you for doing something suboptimal and I believe this is often their goal - establish superiority by inducing guilt or shame. It's like opting to not play the game with them. And usually, that's the winning move.
  - kortilla 2y ago
    This gives them what they are looking for though (public praise). It quickly ends the interaction but doesn’t prevent future ones.
  - npsimons 2y ago
    > "I'll think about it" Unless you're being totally earnest, this one reads like "I'll take it under advisement"[0] [0] - https://getyarn.io/yarn-clip/ed82da6b-db48-49aa-a105-f190e632e85b https://getyarn.io/yarn-clip/ed82da6b-db48-49aa-a105-f190e63...
- viraptor 2y ago
  Very nice application of grug brain https://grugbrain.dev/ https://grugbrain.dev/ > given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex
h2odragon 2y ago
When someone offers advice about "it might have done better"; it not always an assualt on you, an insult of your abilities, and so on. The person offering the advice may be an idjit, just at dealing with others or maybe even completely. It's OK if the some of rest of the world fails to agree with you. People voicing contrary opinions, failing to agree with you, etc; doesn't threaten you in any way.
philk10 2y ago
"You shouldn't hire bad programmers" - I did work at a company where the CEO did say that he wished they had programmers who didn't write bugs He did also not want me to do any testing as "the customers were better at finding bugs than we are"
- lelanthran 2y ago
  > He did also not want me to do any testing as "the customers were better at finding bugs than we are" He's not wrong about that quoted bit, though :-/ Paying customers are uncannily better at finding bugs than anyone! [Note: I am not advocating for removing testing from your process.]
avensec 2y ago
I read this in 2018 and I'm glad to see it posted again. It was one of those posts that made me ask myself a question. I can't remove the absolutism or extremes, so how can I create a filter for when I hear these conversations/people? I have my model, but... What strategies do people employ here?
- sdwr 2y ago
  These people are claiming emotional territory that doesn't belong to them. Usually, they have precalculated that they can "get away" with it, which means they see you as weak. Three options: - Give up, cede the ground, and move on with your life. The less sleep you lose over how unfair it is, the better. - Confront them head-on. They are ready for a fight, but their position is inherently unreasonable. The less you get dragged into their headspace, the more you "win". - Come down from above. Bring social proof that they are wrong into their space. In the OP, this would be programmers who mutually respect each other's work, and are productive without nitpicking.
  - avensec 2y ago
    Thank you for your response and perspective!
mgkimsal 2y ago
Couple of stories about 'bad code': I've often worked solo, but have been on teams where I've written code that was... not great. Worked, but... suboptimal. Various reasons, but it is what it is. To remedy that, I would try to refactor old stuff in conjunction with new work. That was often rejected. So... I'd take to documenting needed refactorings/fixes in tickets. Those would rarely ever get attention - generally deprioritized or ignored. This led to - for me - constant low-level frustration. When working solo, I can prioritize what I need to; in teams... you can't ever make a suboptimal decision because it will live forever. Or until a 'system is down' moment. Those would lead to "post mortems", in which I would point to tickets requesting to fix ticking time bombs months earlier, explain they were ignored by leadership, and... that came across as 'blaming' or 'antagonistic'. The 'fix' is to just never write suboptimal code, which leads to more frustration and anxiety when writing. Secondly, in 2017, I got a call to fix something I'd written in ... 2003/2004. That code was still in production (with minor patches by others along the way). It's quite humbling to have to review broken code and corners cut, and realize that you were the one responsible for it (and no one else). That (and a few other incidents) have given me a big change in perspective on writing maintainable code (and documentation, etc).
- thadt 2y ago
  You either die a hero or live long enough to see your name in the decade old git blame.
  - mgkimsal 2y ago
    2003... svn all the way :)
  - marcosdumay 2y ago
    Joke's on you, our repositories do not live for that long! But yeah, the experience of having somebody asking you "Hey, you know about X! Do you know anything about this system here? What am I doing wrong that my program always gets a different result?" when it's your code, it's because your code was always obviously wrong, it's the first you ever notice it, and that person's boss is complaining because their code is correct... It's not nice.
npsimons 2y ago
To play Devil's advocate, I'd like to point out that many of these egotistical assholes are "trying" to "help" - by "trying" I mean their communication skills are poor, and by "help" I mean they are trying to encourage people to improve. I know, I've been one of these assholes. What I've tried to do to be less of an asshole is leverage my empathy and hone my communication skills. But I also recognize the anger and frustration with things that seem like they should be no-brainers - and recognize that what we despise in ourselves is often what we attack others for. Nobody's perfect, but there are ways people can get better. Or just take advantage of tools that can help automatically catch these sorts of errors. This is precisely why people create regression tests and set them up to run in the CI/CD, to reject changes that break them. As for being less of an asshole, no shortcuts with that - just exercise your empathy, put yourself in their shoes, take a deep breath, then go to bed. Tomorrow morning, if you still feel the need to pen a blog post, maybe write out a technical solution without assigning blame.
OliverJones 2y ago
Dang, Rachel, you must have had a rough day at the orifice that day. Condolences.
isaacremuant 2y ago
Weird post. Sounds like a tweet. Says little and the title seems clickbait because it doesn't reflect what it says.

195 points by compiler-guy 2y ago

I agree this righteous "one" stuff is toxic. There is something very liberating and wholesome about a senior developer being able to discuss the mistakes and fuckups they've made. It's not just a learning opportunity, it also demonstrates a culture of openness and works against imposter syndrome. A perfectionist attitude stands in opposition to this - just try harder and stop making mistakes. There's nothing to learn, just more individual effort to apply.

tetha 2y ago
Most of us are hopefully also improving at what they do. Our config management has a bunch of stuff written by me that's perfectly functional and works overall. But after a year or two working with the tool, I would call it pretty bad quality for various reasons. But that's fine. If I have a reason to change it, I'll clean it up. Until then, it stays around as an example to show some bad practices and why other approaches are better.
otherme123 2y ago
I immediately recall at least two big fuckups that the "one" (two different persons) didn't acknowledge, even if that meant to lose a good client, and I would guess bad mouthing. Once I ate a small fuckup from one of my juniors (we put a wrong software version in a report), and instead of fixing it with the client by simply saying "we had a mistake, here is the fixed report", my superior only could think about "could we hide this, and keep the face that we are perfect?". Of course, this same person takes any mistake from other people as an opportunity to ask for discounts, compensations and freebies.
evrydayhustling 2y ago
If you can't find things to criticize about yourself, it means you aren't improving. Sharing these critiques helps others both learn from your mistakes, and that it's ok to learn from their own.

dclowd9901 2y ago

Why is this person feeding trolls? Don’t we all know people who think they’re infallible are full of shit anyway and just ignore them?

bjackman 2y ago
You can't just divide the world into people who believe fallacies and people who don't. They are rooted in fundamental cognitive biases, everyone falls for the "just try harder"/"just be better"/"just don't put any bugs in the code"/"just have excellent test coverage" thing sometimes. Certainly all the most experienced engineers I work with, who should definitely know better, still haven't fully internalised the fact that all code is broken.
- 8n4vidtmkvmk 2y ago
  They really should. I've been programming over 20 years and don't think I've seen a program without at least a few defects. A couple have come close, those are impressive, but bugs always happen.
  - gravescale 2y ago
    Show me a program that has no bugs and I'll show you a program that does nothing at all! Even most Hello Worlds don't check the pipe was written to correctly. And now we get into "well actually that's technically not a bug because it is not in the spec" and if we're finding the need to split that hair, we can hardly be talking about some mythically perfect software.
    - richardw 2y ago
      You’re not wrong but Knuth’s programs have very few bugs and do a shitload. “The reward for coding errors found in Knuth's TeX and Metafont programs (as distinguished from errors in Knuth's books) followed an audacious scheme inspired by the wheat and chessboard problem,[10] starting at $2.56, and doubling every year until it reached $327.68.” https://en.m.wikipedia.org/wiki/Knuth_reward_check https://en.m.wikipedia.org/wiki/Knuth_reward_check

akoboldfrying 2y ago

>malloc("HTTP") I'm reminded of a Simpsons episode where Homer tries to assemble a barbecue by pressing a brick and a piece of pipe together.

jrockway 2y ago
"That's one fine looking barbeque pit."
pavlov 2y ago
Because I am the one, my custom malloc checks a given size against the list of known constant string pointers and if it matches, it calls strdup instead. So easy to program defensively in C.
- lambdaxyzw 2y ago
  I guess you could check if the pointer points inside a data section of your program, and if yes, call strlen on it. It's all so easy!

philbo 2y ago

I've received a few nasty comments in response to blog posts, both here and on reddit. When it happens I update the post to link to the nasty comment, without judgement, just to shine a light on it. Usually nothing happens but sometimes it steers the discussion to a healthier place.

rulalala 2y ago
This is great. I wish all humans could think that way.
ChrisMarshallNY 2y ago
I've received quite a few. Some, probably deserved; most, likely not. In a few cases, it was -sort of- deserved, but not helpful, or directly harmful to the community. Saying the right thing, in the wrong way, is still saying the wrong thing. > When it happens I update the post to link to the nasty comment, without judgement, just to shine a light on it. Not a bad idea. Not always possible, if the comment gets dead'nd. In any case, I do not respond in kind. I'm quite capable of it (recovering troll), but I won't go there. It's not being a "snob." It's just that I've learned that gasoline is an ineffective fire suppressant. If I'm wrong, I've learned to promptly admit it; in the same venue as the mistake (a pet peeve is private apologies for public attacks). There is a line though. I feel that I do really good work. I've been doing this for a long time (like, 40 years), and have learned quite a bit, in that time. I've also worked some pretty tough rooms, and for folks that wouldn't accept crap, so I have learned to habitually do decent work. My general policy is to avoid casting judgment onto others in public. It doesn't help; even if I'm right (not always the case). But if we're working together, or I am using your stuff, then it might be a different story. I have had people savagely attack me, because I won’t accept garbage. Guilty as charged, but I don’t go Torvalds on them. I just tell them that their work is not acceptable to me, in a respectful manner, if possible. Nevertheless, I have found that I can always improve, and learn new stuff; sometimes, from the most unexpected places, and being open to these lessons is basic good policy. I become right, by being wrong, and learning otherwise. "Good judgment comes from experience. Experience comes from bad judgment."
- 2y ago

BillFranklin 2y ago

I don't disagree that some engineers have bad attitudes! Everyone is capable of writing bad code, and there is something to be said for the argument that all code is bad and a liability. This article is an interesting companion to "No more pink mustache" [1] wherein Lyft is described as "broken at a scale that is hard to believe" - often the explanation for quality is the org, not the human in the chair :-) [1] https://rachelbythebay.com/w/2020/02/29/poof/ https://rachelbythebay.com/w/2020/02/29/poof/

surfingdino 2y ago

I could not disagree with the point made, but there is a flip side to this--being able to take feedback.

jasonlotito 2y ago
Most people can take feedback and apply it. I find some people just give feedback poorly and equate that to others not taking feedback. These people usually think there preferred feedback is the best way so therefore everyone should feel the same way and if they don’t the other person needs to change. They are of course wrong. But if you tell them this, they demonstrate why I use the word “most” in the opening sentence.
- npsimons 2y ago
  > I find some people just give feedback poorly and equate that to others not taking feedback. Too true! I find it helps if I think of it as an engineering problem: "what can I say that will make these people not commit the same error again?" A bit dehumanizing and manipulative, but can be super effective at shifting away from blaming and belittling (almost never works), and towards mentoring.

red_admiral 2y ago

(2018), but still worth reading.

tanelpoder 2y ago

I can’t find the blog/article anymore, but its message was that “when you see something suboptimal in the code, do not assume incompetence”. As people who wrote the code may have had tight deadlines, different priorities set for them and other factors that may have prevented the developers from “doing the right thing” immediately…

lambdaxyzw 2y ago
There's also chesterton fence - maybe this dumb thing in code actually was important some time ago. Or, even worse, maybe it is still an important for a rare edge case and you just don't see how, yet.
- brazzy 2y ago
  That as well is "not doing the right thing", namely adding a comment that explains the need for it.
- kqr 2y ago
  The Chesterton fence in my book is only about something that is still meaningful only in non-obvious ways. In evolutionary theory I believe "used to have a sensible explanation but no longer does due to changing circumstances" is known as discordance.
  - MrJohz 2y ago
    The fence is about all things that you might want to change, whether or not they're still useful. Both of the characters in Chesterton's parable are reformers, and the assumption is still that the goal should be reform. The question is more about the motivation for reform. The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it. Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious. (That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)

auggierose 2y ago

And how can this be? Because he is the Kwisatz Haderach!

cushychicken 2y ago
The Mahdi is too humble to admit he is the Mahdi!

Sammi 2y ago

I regularly have codevs who say similar things to "why don't you just not make that mistake?" and "why not just do <insert crazy complex thing here> instead?". I've taken to responding with: "Because you probably have more IQ points than me. I have fewer IQ points than you, so therefore I must do dumber and simpler things than you." It's made some of their faces turn red in embarrassment, as they finally realized what unreflected belittling little dorks they were being.

juliushuijnk 2y ago
If it is said in ignorance, there is no need to view it as an attack that you need to make them pay for with embarrassment.
dmichulke 2y ago
An alternative is to plainly agree with them: "I know, that was dumb, wasn't it?" or "You're right, I probably shouldn't"or just "I'll think about it" This means they can't shame / guilt you for doing something suboptimal and I believe this is often their goal - establish superiority by inducing guilt or shame. It's like opting to not play the game with them. And usually, that's the winning move.
- kortilla 2y ago
  This gives them what they are looking for though (public praise). It quickly ends the interaction but doesn’t prevent future ones.
- npsimons 2y ago
  > "I'll think about it" Unless you're being totally earnest, this one reads like "I'll take it under advisement"[0] [0] - https://getyarn.io/yarn-clip/ed82da6b-db48-49aa-a105-f190e632e85b https://getyarn.io/yarn-clip/ed82da6b-db48-49aa-a105-f190e63...
viraptor 2y ago
Very nice application of grug brain https://grugbrain.dev/ https://grugbrain.dev/ > given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

h2odragon 2y ago

When someone offers advice about "it might have done better"; it not always an assualt on you, an insult of your abilities, and so on. The person offering the advice may be an idjit, just at dealing with others or maybe even completely. It's OK if the some of rest of the world fails to agree with you. People voicing contrary opinions, failing to agree with you, etc; doesn't threaten you in any way.

philk10 2y ago

"You shouldn't hire bad programmers" - I did work at a company where the CEO did say that he wished they had programmers who didn't write bugs He did also not want me to do any testing as "the customers were better at finding bugs than we are"

lelanthran 2y ago
> He did also not want me to do any testing as "the customers were better at finding bugs than we are" He's not wrong about that quoted bit, though :-/ Paying customers are uncannily better at finding bugs than anyone! [Note: I am not advocating for removing testing from your process.]

avensec 2y ago

I read this in 2018 and I'm glad to see it posted again. It was one of those posts that made me ask myself a question. I can't remove the absolutism or extremes, so how can I create a filter for when I hear these conversations/people? I have my model, but... What strategies do people employ here?

sdwr 2y ago
These people are claiming emotional territory that doesn't belong to them. Usually, they have precalculated that they can "get away" with it, which means they see you as weak. Three options: - Give up, cede the ground, and move on with your life. The less sleep you lose over how unfair it is, the better. - Confront them head-on. They are ready for a fight, but their position is inherently unreasonable. The less you get dragged into their headspace, the more you "win". - Come down from above. Bring social proof that they are wrong into their space. In the OP, this would be programmers who mutually respect each other's work, and are productive without nitpicking.
- avensec 2y ago
  Thank you for your response and perspective!

mgkimsal 2y ago

Couple of stories about 'bad code': I've often worked solo, but have been on teams where I've written code that was... not great. Worked, but... suboptimal. Various reasons, but it is what it is. To remedy that, I would try to refactor old stuff in conjunction with new work. That was often rejected. So... I'd take to documenting needed refactorings/fixes in tickets. Those would rarely ever get attention - generally deprioritized or ignored. This led to - for me - constant low-level frustration. When working solo, I can prioritize what I need to; in teams... you can't ever make a suboptimal decision because it will live forever. Or until a 'system is down' moment. Those would lead to "post mortems", in which I would point to tickets requesting to fix ticking time bombs months earlier, explain they were ignored by leadership, and... that came across as 'blaming' or 'antagonistic'. The 'fix' is to just never write suboptimal code, which leads to more frustration and anxiety when writing. Secondly, in 2017, I got a call to fix something I'd written in ... 2003/2004. That code was still in production (with minor patches by others along the way). It's quite humbling to have to review broken code and corners cut, and realize that you were the one responsible for it (and no one else). That (and a few other incidents) have given me a big change in perspective on writing maintainable code (and documentation, etc).

thadt 2y ago
You either die a hero or live long enough to see your name in the decade old git blame.
- mgkimsal 2y ago
  2003... svn all the way :)
- marcosdumay 2y ago
  Joke's on you, our repositories do not live for that long! But yeah, the experience of having somebody asking you "Hey, you know about X! Do you know anything about this system here? What am I doing wrong that my program always gets a different result?" when it's your code, it's because your code was always obviously wrong, it's the first you ever notice it, and that person's boss is complaining because their code is correct... It's not nice.

npsimons 2y ago

To play Devil's advocate, I'd like to point out that many of these egotistical assholes are "trying" to "help" - by "trying" I mean their communication skills are poor, and by "help" I mean they are trying to encourage people to improve. I know, I've been one of these assholes. What I've tried to do to be less of an asshole is leverage my empathy and hone my communication skills. But I also recognize the anger and frustration with things that seem like they should be no-brainers - and recognize that what we despise in ourselves is often what we attack others for. Nobody's perfect, but there are ways people can get better. Or just take advantage of tools that can help automatically catch these sorts of errors. This is precisely why people create regression tests and set them up to run in the CI/CD, to reject changes that break them. As for being less of an asshole, no shortcuts with that - just exercise your empathy, put yourself in their shoes, take a deep breath, then go to bed. Tomorrow morning, if you still feel the need to pen a blog post, maybe write out a technical solution without assigning blame.

OliverJones 2y ago

Dang, Rachel, you must have had a rough day at the orifice that day. Condolences.

isaacremuant 2y ago

Weird post. Sounds like a tweet. Says little and the title seems clickbait because it doesn't reflect what it says.