Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I once inherited a very thorny performance problem with a service. Thorny as in, the previous engineer was ordered to give up and move on because our boss was worried it was adversely affecting their mental health and their performance on other tasks.

I quickly learned that every person who found out I was working on this problem was eager to share the same three or four ideas on how to fix it. All of these ideas were early on the list of ideas that the previous engineer had ruled out multiple times in multiple ways. For the sake of thoroughness, I also tried them and ruled them out. But of course each person who wanted to share ideas didn't know they were saying the same thing I had heard a hundred times before, so the suggestions kept repeating.

Over time, dealing with the same suggestions over and over again, I learned an important lesson: when someone suggested an idea, it didn't do any good to explain that multiple people had tried it and ruled it out in multiple ways. That made people perceive me as close-minded, stupid, and inflexible. Instead I just nodded and said, interesting, that's worth checking out, thanks, or, hmm, I wonder how I could measure that.

At first I was afraid that if I acted intrigued about a very basic obvious idea, people would think we were idiots for not trying it long ago, but that turned out not to be the dominant dynamic at work. The dominant dynamic was that people think you're smart if you are receptive to your advice, and and they think you are stupid if you are not receptive to their advice. This only stops being true when you work with someone closely or consistently over time.



It seems like you found a good strategy.

I might have tried earnest curiosity. "And what results would you expect from that?" or "Let's say we do this, and get such-and-such result?" or "What kind of result would diminish your confidence in this approach?"

Or, better yet, invite them to pair on the implementation! (Organizational agility permitting.)

I wonder, also, why were none of these "dead ends" accessibly documented? If so many people can offer suggestions, shouldn't they be able to see the results of prior experiments? Maybe in the form of closed tickets, at the very least.


And did you fix the performance problem?


No. My boss kept me busy with other things. After the work my colleague had done, he was convinced that we weren't going to solve it, and the idea that I was going to get to work on it turned out to be kind of a white lie so the original engineer could mentally let go and get his sanity back. I didn't have many fresh ideas anyway.

In retrospect, there's an obvious suspect. It was early AWS days, and our deployments were controlled by sysadmins, who refused to give us any access to the infrastructure on security grounds. Our dev boxes were in our datacenter. They promised us the infrastructure we were running on was 100% reliable and consistent, but it probably wasn't.


Wonderful insight!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: