5 ms·

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

by chaps 4y ago

PaulHoule 4y ago
It's not (1) "reacting to the reaction" which is the endpoint but (2) not having that reaction. If (1) is important it as because that is the path to (2). I'd say a company that has accomplished (2) has cut the workload in hiring employees by 30-50% in the sense that every employee who has reaction (1) either internally or externally is at risk for being disengaged or leaving soon. Not only that but you are probably wasting your dev's time and could get dramatically more productivity out of them if you aren't WTFing them to death.
giobox 4y ago
There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and actually spending some time at the company to learn the historical context of why the thing you think is insane/shit is insane/shit before telling everyone who built it how insane/shit it is. People generally don't wake up in the morning and go into work motivated to make insane/shit things - context, tech debt and business realities all mount up and even the best of us can end up making choices that in isolation look crazy. There are of course companies who are really bad and you may well be right, but so many times I have seen in my career a young new hire storm in and think everything is shit without paying heed to the context and historical pressures. The best thing you can do in many cases is spend the first ~six months at a new tech company trying to understand that context, and indeed I think more mature engineers generally do.
- chaps 4y ago
  You (in fashion of the article) missed the point I made: I was explicitly asked to speak up as the new employee and when I did I was told to stop speaking up. When I brought it up in the meeting I gave my two week notice, he admitted to saying that and apologized.
  - dec0dedab0de 4y ago
    That's some bullshit. you did the right thing. When a new employee joins and notices that something sucks the answer should be something like these: We know, but haven't had time to fix it, maybe we'll assign that to you when you're caught up. We didn't think of it that way, good catch, lets go into detail later. Yeah, but doing it this way makes this other thing easier, we'll show you that when you're ready. or even: I don't know, my brain is fried with this project, can you ask again in a few months?
- a4isms 4y ago
  "Making good decisions, therefore, requires understanding past decisions. Without knowing how things came to be, it’s easy to make things worse." —https://thoughtbot.com/blog/chestertons-fence https://thoughtbot.com/blog/chestertons-fence
  - chaps 4y ago
    I was once told this after raising the issue that "hey maybe an API that responds with root ssh passwords is a bad idea, and our clients are going to be pissed once they find out." And.. I was right. So often, citing Chesterton's fence is significantly more naive than what it attempts to criticize.
    - justin_oaks 4y ago
      I agree. Chesterton's fence doesn't mean that if you don't know why the fence is there, don't ever move it, under any conditions. It means try to find out why it's there before moving it. In many cases in my career, I've seen code that doesn't make sense or seems like a bad idea. The person who could explain why it's there has long left the company. Am I afraid and leave the screwy stuff there, while citing Chesteron's fence? Hell no. I'll change it to do the right thing. This results in either exposing the reason why it's there, or showing that it really was unnecessary/bad. If something breaks from the change then it's good that I can finally document what wasn't documented before. So either way it's a win.
      - a4isms 4y ago
        I readily accept that this strategy has worked for you. In my particular case, I work with customers and software where making a change, pushing it to production, and finding out that I missed a key requirement when it breaks is sometimes unacceptably consequential. But that may not be true for everyone. If making changes and seeing what does or doesn't break is a successful strategy for you, go for it.
    - a4isms 4y ago
      How is being right about wanting to make a change a refutation of the idea that knowing why people made a decision in the past is an excellent idea? Nothing about Chesterton's Fence asserts that people in the past always made good decisions, nor does it assert that perhaps what was a good decision then is a bad decision today. It simply asserts that understanding why a thing is the way it is is valuable when making a decision to change it. That understanding could be as simple as--to take a real world example that most readers here will remember--"They chose to install a hidden web server on the user's system, because they felt it was the best way to deliver user convenience given the resources and time the team had available." We can still say it was a bone-headed choice to do that because it opened a massive back door to every user's system. And? What is the problem with looking into why they made that choice before arguing that the choice should be reversed with maximum prejudice? Chesterton's Fence isn't a suggestion that no changes should be proposed, or that if you look into the original motivations you will change your proposal. Think of it as insurance against the possibility that every once in a while, you will discover a requirement that needs to be addressed with your suggested change. I don't see where you're coming from that quoting Chesterton's Fence is even "criticism." It's a suggestion to take out a little insurance by doing a little homework.
- Buttons840 4y ago
  > There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and waiting 6 months to understand the context. I know this is reasonable advice, but it makes me deeply cynical. After 6 months I will have learned to live in the shit (to use your term), and so it still seems like I have nothing to gain by speaking up or trying to fix things. A culture that accepts shitty code probably isn't supper demanding for an experienced developer who is accustom to the mess, so I'll just coast through my time and hop jobs after a few years. If nobody wants to respectfully talk about my criticisms on day one, then they wont really want to at 6 months either. In the end I'm lead to believe I should have zero concern for code quality and only worry about my personal reputation.
  - AA-BA-94-2A-56 4y ago
    This is exactly where I am at right now. I have a million dollar mortgage and interest rates are going up. I'm keeping my head down and perpetuating technical debt until I can hop jobs for a higher salary. Criticising the status quo is not a winning move for me, especially when it's lead to the company's engineering team tripling in size. If I'm asked, I'll pick some low hanging fruit– remove reliance on legacy/redundant JavaScript libraries such as jQuery, and spent time writing better unit tests. But so far I haven't been asked.
- whats_a_quasar 4y ago
  I get what you're saying, but this is exactly how deviances are normalized. When you've been with the company for a long time and are familiar with the history, it's easy to rationalize why things are the way they are and that they can't be improved. You can explain something that's crazy with context and historical pressure. Dan's point is that sometimes the new person's judgement is correct, and there actually is a real problem that's invisible to people who have been with the project a long time. But the new person's judgment is basically always ignored, and that's a mistake - it ought to be weighted heavily because they legitimately have a perspective that insiders no longer have. If instead you spend six months trying to understand the context: "new person joins new person: WTF WTF WTF WTF WTF old hands: yeah we know we're concerned about it new person: WTF WTF wTF wtf wtf w... new person gets used to it new person #2 joins new person #2: WTF WTF WTF WTF new person: yeah we know. we're concerned about it." I'm sympathetic because my first company was a mid-stage startup with huge structural problems in the engineering org structure and processes. When I joined I had frequent "WTF" moments and had a similar experience where experienced people would explain to me why things are the way they are. So I trusted them, and put my head down, but eventually got frustrated and left. A few months later the company went bankrupt because they couldn't build product fast enough, investors lost patience, and they couldn't raise another round.
  - Buttons840 4y ago
    > the new person's judgment is basically always ignored, and that's a mistake Remember, the new person has something that nobody else on the team can ever learn, no matter how much they study or how long they work. The new person has a fresh perspective.
AnIdiotOnTheNet 4y ago
To be fair, you really shouldn't. You know nothing of the constraints that people are operating under, or the political or cultural landscape you're dealing with, so you just come off like a preachy academic.
- chaps 4y ago
  See the other comment I made: I was explicitly asked to speak up.
  - AnIdiotOnTheNet 4y ago
    If that's the case, then yeah fair enough. If someone doesn't want your opinion they shouldn't ask for it.

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

by chaps 4y ago

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

It's not (1) "reacting to the reaction" which is the endpoint but (2) not having that reaction. If (1) is important it as because that is the path to (2). I'd say a company that has accomplished (2) has cut the workload in hiring employees by 30-50% in the sense that every employee who has reaction (1) either internally or externally is at risk for being disengaged or leaving soon. Not only that but you are probably wasting your dev's time and could get dramatically more productivity out of them if you aren't WTFing them to death.

giobox 4y ago

There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and actually spending some time at the company to learn the historical context of why the thing you think is insane/shit is insane/shit before telling everyone who built it how insane/shit it is. People generally don't wake up in the morning and go into work motivated to make insane/shit things - context, tech debt and business realities all mount up and even the best of us can end up making choices that in isolation look crazy. There are of course companies who are really bad and you may well be right, but so many times I have seen in my career a young new hire storm in and think everything is shit without paying heed to the context and historical pressures. The best thing you can do in many cases is spend the first ~six months at a new tech company trying to understand that context, and indeed I think more mature engineers generally do.

chaps 4y ago
You (in fashion of the article) missed the point I made: I was explicitly asked to speak up as the new employee and when I did I was told to stop speaking up. When I brought it up in the meeting I gave my two week notice, he admitted to saying that and apologized.
- dec0dedab0de 4y ago
  That's some bullshit. you did the right thing. When a new employee joins and notices that something sucks the answer should be something like these: We know, but haven't had time to fix it, maybe we'll assign that to you when you're caught up. We didn't think of it that way, good catch, lets go into detail later. Yeah, but doing it this way makes this other thing easier, we'll show you that when you're ready. or even: I don't know, my brain is fried with this project, can you ask again in a few months?
a4isms 4y ago
"Making good decisions, therefore, requires understanding past decisions. Without knowing how things came to be, it’s easy to make things worse." —https://thoughtbot.com/blog/chestertons-fence https://thoughtbot.com/blog/chestertons-fence
- chaps 4y ago
  I was once told this after raising the issue that "hey maybe an API that responds with root ssh passwords is a bad idea, and our clients are going to be pissed once they find out." And.. I was right. So often, citing Chesterton's fence is significantly more naive than what it attempts to criticize.
  - justin_oaks 4y ago
    I agree. Chesterton's fence doesn't mean that if you don't know why the fence is there, don't ever move it, under any conditions. It means try to find out why it's there before moving it. In many cases in my career, I've seen code that doesn't make sense or seems like a bad idea. The person who could explain why it's there has long left the company. Am I afraid and leave the screwy stuff there, while citing Chesteron's fence? Hell no. I'll change it to do the right thing. This results in either exposing the reason why it's there, or showing that it really was unnecessary/bad. If something breaks from the change then it's good that I can finally document what wasn't documented before. So either way it's a win.
    - a4isms 4y ago
      I readily accept that this strategy has worked for you. In my particular case, I work with customers and software where making a change, pushing it to production, and finding out that I missed a key requirement when it breaks is sometimes unacceptably consequential. But that may not be true for everyone. If making changes and seeing what does or doesn't break is a successful strategy for you, go for it.
  - a4isms 4y ago
    How is being right about wanting to make a change a refutation of the idea that knowing why people made a decision in the past is an excellent idea? Nothing about Chesterton's Fence asserts that people in the past always made good decisions, nor does it assert that perhaps what was a good decision then is a bad decision today. It simply asserts that understanding why a thing is the way it is is valuable when making a decision to change it. That understanding could be as simple as--to take a real world example that most readers here will remember--"They chose to install a hidden web server on the user's system, because they felt it was the best way to deliver user convenience given the resources and time the team had available." We can still say it was a bone-headed choice to do that because it opened a massive back door to every user's system. And? What is the problem with looking into why they made that choice before arguing that the choice should be reversed with maximum prejudice? Chesterton's Fence isn't a suggestion that no changes should be proposed, or that if you look into the original motivations you will change your proposal. Think of it as insurance against the possibility that every once in a while, you will discover a requirement that needs to be addressed with your suggested change. I don't see where you're coming from that quoting Chesterton's Fence is even "criticism." It's a suggestion to take out a little insurance by doing a little homework.
Buttons840 4y ago
> There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and waiting 6 months to understand the context. I know this is reasonable advice, but it makes me deeply cynical. After 6 months I will have learned to live in the shit (to use your term), and so it still seems like I have nothing to gain by speaking up or trying to fix things. A culture that accepts shitty code probably isn't supper demanding for an experienced developer who is accustom to the mess, so I'll just coast through my time and hop jobs after a few years. If nobody wants to respectfully talk about my criticisms on day one, then they wont really want to at 6 months either. In the end I'm lead to believe I should have zero concern for code quality and only worry about my personal reputation.
- AA-BA-94-2A-56 4y ago
  This is exactly where I am at right now. I have a million dollar mortgage and interest rates are going up. I'm keeping my head down and perpetuating technical debt until I can hop jobs for a higher salary. Criticising the status quo is not a winning move for me, especially when it's lead to the company's engineering team tripling in size. If I'm asked, I'll pick some low hanging fruit– remove reliance on legacy/redundant JavaScript libraries such as jQuery, and spent time writing better unit tests. But so far I haven't been asked.
whats_a_quasar 4y ago
I get what you're saying, but this is exactly how deviances are normalized. When you've been with the company for a long time and are familiar with the history, it's easy to rationalize why things are the way they are and that they can't be improved. You can explain something that's crazy with context and historical pressure. Dan's point is that sometimes the new person's judgement is correct, and there actually is a real problem that's invisible to people who have been with the project a long time. But the new person's judgment is basically always ignored, and that's a mistake - it ought to be weighted heavily because they legitimately have a perspective that insiders no longer have. If instead you spend six months trying to understand the context: "new person joins new person: WTF WTF WTF WTF WTF old hands: yeah we know we're concerned about it new person: WTF WTF wTF wtf wtf w... new person gets used to it new person #2 joins new person #2: WTF WTF WTF WTF new person: yeah we know. we're concerned about it." I'm sympathetic because my first company was a mid-stage startup with huge structural problems in the engineering org structure and processes. When I joined I had frequent "WTF" moments and had a similar experience where experienced people would explain to me why things are the way they are. So I trusted them, and put my head down, but eventually got frustrated and left. A few months later the company went bankrupt because they couldn't build product fast enough, investors lost patience, and they couldn't raise another round.
- Buttons840 4y ago
  > the new person's judgment is basically always ignored, and that's a mistake Remember, the new person has something that nobody else on the team can ever learn, no matter how much they study or how long they work. The new person has a fresh perspective.

AnIdiotOnTheNet 4y ago

To be fair, you really shouldn't. You know nothing of the constraints that people are operating under, or the political or cultural landscape you're dealing with, so you just come off like a preachy academic.

chaps 4y ago
See the other comment I made: I was explicitly asked to speak up.
- AnIdiotOnTheNet 4y ago
  If that's the case, then yeah fair enough. If someone doesn't want your opinion they shouldn't ask for it.