3 ms·

> "Any chance I can get an ETA on having that fixed?” This is the most annoying question in the world. I usually want to respond "probably sometime before the

> "Any chance I can get an ETA on having that fixed?” This is the most annoying question in the world. I usually want to respond "probably sometime before the heat death of the Universe, but honestly that could slip". Until I write the fix I have no idea that the direction I'm taking will actually work. Very often I discover some $SADNESS while trying to actually do the fix. Some test may blow up in some way I never expected (often on some platform that I'm not actively testing until I run it through CI because I don't have an AIX virt on my laptop). That could derail me for a week or two. Then there's CI itself which breaks quite often due to how complicated it needs to be (we have to support AIX builds and things like that). I can't give you an estimate on that because I don't know how that is going to fail or how long it'll take to fix it, but if I tell you we can fix it next week that's exactly the time CI gets broken in some way that'll take 2 weeks (often for a different team that I don't have any control over) to sort out all the mess. The realistic estimate is often closer to 4 weeks for something that might seem like it'll only take a few days at the start. And it doesn't matter how vitally important it is to some customer. I'll try to get it out in a few days / next week, but it might slip for a month due to the unknown-unknowns and breakage outside of my direct control.

titzer 5y ago
> This is the most annoying question in the world. But this is exactly the information that other people need to plan around to get on with their own work. You need to see things from their perspective. The inner workings of your processes and the long-winded explanation, from their side, is "the most annoying" response in the world. It's a simple question. The ETA is the only information that is actionable for them. If the answer is "anywhere from a couple days to a month", then flat out say that. If you think that sounds wishy-washy and absurd and that it must then require a long-winded explanation to soften, chances are that it does sound absurd and the long-winded explanation will not soften it, but instead the person may start to think that you are unorganized and clueless. They might start to cringe at the thought of their next interaction with you. Just give them a straight answer. FWIW, I don't know anything about your system, but it sounds like you need to invest in making triage in your system more efficient.
- lamontcg 5y ago
  You can't triage the unknown
  - titzer 5y ago
    Triage involves getting insight into running systems, particularly how well they are performing, or not performing, at many levels of granularity. You can make the act of triaging more efficient by building tools that give you quick insight and help you narrow down what is and isn't working, and how it's failing. I spent years working on V8 and we consistently invested in tools, tests, processes, and best practices to help us fielding the thousands of production issues over the years. Again, I don't know anything about your system, but my advice would be to be more serious and diligent about the requests you field instead of treating them as annoyances. Take a look at your processes and dispassionately try to figure out why it takes you so long to know anything about anything.
    - lamontcg 5y ago
      > try to figure out why it takes you so long to know anything about anything. External dependencies changing without warning at the worst possible times. And many of them we can't arbitrarily prune because when you boil it down they ultimately support things which have a contract value associated with them. The system is large and complicated, mostly necessarily so, which makes it brittle. We spent time making it less brittle and attacking the complexity, but its still large and brittle. We don't get to go back to startup square 1 where we don't have those kinds of contracts and get to reconsider the business decisions that have been made over the past decade.

titzer 5y ago

> This is the most annoying question in the world. But this is exactly the information that other people need to plan around to get on with their own work. You need to see things from their perspective. The inner workings of your processes and the long-winded explanation, from their side, is "the most annoying" response in the world. It's a simple question. The ETA is the only information that is actionable for them. If the answer is "anywhere from a couple days to a month", then flat out say that. If you think that sounds wishy-washy and absurd and that it must then require a long-winded explanation to soften, chances are that it does sound absurd and the long-winded explanation will not soften it, but instead the person may start to think that you are unorganized and clueless. They might start to cringe at the thought of their next interaction with you. Just give them a straight answer. FWIW, I don't know anything about your system, but it sounds like you need to invest in making triage in your system more efficient.

lamontcg 5y ago
You can't triage the unknown
- titzer 5y ago
  Triage involves getting insight into running systems, particularly how well they are performing, or not performing, at many levels of granularity. You can make the act of triaging more efficient by building tools that give you quick insight and help you narrow down what is and isn't working, and how it's failing. I spent years working on V8 and we consistently invested in tools, tests, processes, and best practices to help us fielding the thousands of production issues over the years. Again, I don't know anything about your system, but my advice would be to be more serious and diligent about the requests you field instead of treating them as annoyances. Take a look at your processes and dispassionately try to figure out why it takes you so long to know anything about anything.
  - lamontcg 5y ago
    > try to figure out why it takes you so long to know anything about anything. External dependencies changing without warning at the worst possible times. And many of them we can't arbitrarily prune because when you boil it down they ultimately support things which have a contract value associated with them. The system is large and complicated, mostly necessarily so, which makes it brittle. We spent time making it less brittle and attacking the complexity, but its still large and brittle. We don't get to go back to startup square 1 where we don't have those kinds of contracts and get to reconsider the business decisions that have been made over the past decade.