4 ms·

The WTF moments come when you don’t yet have credibility. Would you want to hear a stranger with an empty commit history use the wrong keywords to tell you how

The WTF moments come when you don’t yet have credibility. Would you want to hear a stranger with an empty commit history use the wrong keywords to tell you how to do your job? Start your campaign to change a place after demonstrating ability to work within it.

deleted 7y ago
[deleted]
capableweb 7y ago
That's better than nothing! They might not have any previous history and might get a term or two wrong, but their perspective can be useful anyway. You should not dismiss ideas based on what that person has previously said (or if they haven't said anything before) but rather the content of the message itself. This of course becomes hard to scale once you have a large team trying to collaborate, and the feeling of juniors wasting people's time with their easy questions comes up. Another thing is that when someone does not have a history with a particular subject, they enter it with a fresh mind, something you cannot have if you've worked on something for a long time. In case it's also useful to take what they say in consideration, as they can see stuff you cannot. Vice-versa is also true.
- closeparen 7y ago
  We dismiss the ideas because they contradict our priors. Knowing that someone else holds them adds no new information. Strong objective evidence is rarely available. But seeing that an opinion is correlated with superior skill will tend to make people take it seriously. (Sometimes too seriously! Why does everybody cargo cult Google?) For example, several Amazonians have joined my team and been horrified at the lack of central tracking and control over sprint tasks and productivity KPIs. I like my autonomy. I like not taking orders from JIRA. There is a reason I don’t work at Amazon. My team already ships, and well. So I am not excited about their campaigns. I am not a fan of test coverage as a KPI. I’ve seen lots of high-coverage but meaningless and brittle test suites, full of copy-paste and implementation-coupled mock expectations, do more harm than good. At the same time, I find that covering increasingly obscure “if err != nil { return nil, err }” blocks is a waste of time, so my stats aren’t always high. But I have seen SREs I deeply respect, people who have stopped major train wrecks and held insightful technical conversations, decide to use it in their recommendations. Because of that, I’m grudgingly coming around. That’s so much more convincing than the Sr. Staff and above saying “let’s set a minimum coverage threshold for the org [because KPIs and standards are inherently good].” That just reads as careerist sucking up to management. It's people who haven't touched code in 10 years and don't even know the language we use, claiming their judgement is so good that they don't even need to look at a situation to decide how it should be handled. They are the wrong messengers, even for a right idea.

deleted 7y ago

[deleted]

capableweb 7y ago

That's better than nothing! They might not have any previous history and might get a term or two wrong, but their perspective can be useful anyway. You should not dismiss ideas based on what that person has previously said (or if they haven't said anything before) but rather the content of the message itself. This of course becomes hard to scale once you have a large team trying to collaborate, and the feeling of juniors wasting people's time with their easy questions comes up. Another thing is that when someone does not have a history with a particular subject, they enter it with a fresh mind, something you cannot have if you've worked on something for a long time. In case it's also useful to take what they say in consideration, as they can see stuff you cannot. Vice-versa is also true.

closeparen 7y ago
We dismiss the ideas because they contradict our priors. Knowing that someone else holds them adds no new information. Strong objective evidence is rarely available. But seeing that an opinion is correlated with superior skill will tend to make people take it seriously. (Sometimes too seriously! Why does everybody cargo cult Google?) For example, several Amazonians have joined my team and been horrified at the lack of central tracking and control over sprint tasks and productivity KPIs. I like my autonomy. I like not taking orders from JIRA. There is a reason I don’t work at Amazon. My team already ships, and well. So I am not excited about their campaigns. I am not a fan of test coverage as a KPI. I’ve seen lots of high-coverage but meaningless and brittle test suites, full of copy-paste and implementation-coupled mock expectations, do more harm than good. At the same time, I find that covering increasingly obscure “if err != nil { return nil, err }” blocks is a waste of time, so my stats aren’t always high. But I have seen SREs I deeply respect, people who have stopped major train wrecks and held insightful technical conversations, decide to use it in their recommendations. Because of that, I’m grudgingly coming around. That’s so much more convincing than the Sr. Staff and above saying “let’s set a minimum coverage threshold for the org [because KPIs and standards are inherently good].” That just reads as careerist sucking up to management. It's people who haven't touched code in 10 years and don't even know the language we use, claiming their judgement is so good that they don't even need to look at a situation to decide how it should be handled. They are the wrong messengers, even for a right idea.