15 ms·

Just saying "no" isn't helpful for anyone. Much better is variations of "We could do that, but it would take X weeks and/or cost this much in expenses/performa

Just saying "no" isn't helpful for anyone. Much better is variations of "We could do that, but it would take X weeks and/or cost this much in expenses/performance. This leads to a conversation that enlightens both parties. It may even result in you understanding why and how the request is good after all.

setr 1y ago
Seconding this. With infinite time and money, I can do whatever you want — excepting squaring the circle. Onus is yours to explain the difficulty and ideally the other party decides their own request is unreasonable, once you’ve provided an unreasonable timeline to match. Actually straight-up saying no is always more difficult because if you’re not actually a decision-maker then what you’re doing is probably nonsense. You’re either going to have to explain yourself anyways (and it’s best explained with an unreasonable timeline), or be removed from the process. It’s also often the case that the requestor has tried to imagine himself in your shoes in an attempt to better explain his goals, and comes up with some overly complex solution — and describes that solution instead of the original goal. Your goal with absurd requests is to pierce that veil and reach the original problem, and then work back to construct a reasonable solution to it
brandall10 1y ago
Some years back I took on a embattled project, a dispenser/retriever for scrubs in a hospital environment that had a major revision stuck in dev hell for over 2 years. After auditing the state of the work I decided to discard everything. After that, we started with a clean slate of over 200 bugs w/ 45 features to be developed. Product wanted it done in 6 months, to which I countered that the timeframe was highly unlikely no matter how many devs could be onboarded. We then proceeded to do weekly scope reduction meetings. After a month we got to a place where we comfortably felt a team of 5 could knock it out... ended up cutting the number of bugs down only marginally as stability was a core need, but the features were reduced to only 5. Never once did I push back and say something wasn't a good idea, much of what happened was giving high level estimates, and if something was considered important enough, spending a few hours to a few days doing preliminary design work for a feature to better hone in on the effort. It was all details regarding difficultly/scope/risk to engender trust that the estimates were correct, and to let product pick and choose what were the most important things to address.
whstl 1y ago
I don’t think you’re grasping where I’m getting at. It’s not just about time or budget, at all. Some things are downright impossible without the appropriate data. I mention this above but: I was recently in a situation where a PM wanted two calls to a pure mathematical function to have the same result even though the inputs were different. I can patiently explain this multiple times and provide alternatives and try to explore the actual problem space, but it comes a point that the PM saying “maybe I should ask another engineer” becomes grating enough to make you want to quit. Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry.
- BurningFrog 1y ago
  I would tell the PM that "sure, let's go talk to him together". Most likely the other engineer will agree. Or maybe he can see something I don't. Either way we're making progress. > Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry. In parts of it, sure. But there really are places with higher quality of people. You will have to prove yourself a bit more to get hired there, of course.
  - whstl 1y ago
    > You will have to prove yourself a bit more to get hired there, of course. What you're implying here is extremely disrespectful and uncalled for. This phrase alone says much more about you than it does about me. The point of my story is that taking cheap shots at your interlocutor isn't the way to build software, or win discussions. Let's at least aim to be a bit more respectful towards each other here.
    - BurningFrog 1y ago
      This is a misunderstanding. I meant "you" as the "generic you" (any job seeker), not the "specific you" (you). I hope the fact that you need good skills to get good jobs is not controversial. I meant this as a message of hope: There really are good jobs out there, so don't give up on the industry!

setr 1y ago

Seconding this. With infinite time and money, I can do whatever you want — excepting squaring the circle. Onus is yours to explain the difficulty and ideally the other party decides their own request is unreasonable, once you’ve provided an unreasonable timeline to match. Actually straight-up saying no is always more difficult because if you’re not actually a decision-maker then what you’re doing is probably nonsense. You’re either going to have to explain yourself anyways (and it’s best explained with an unreasonable timeline), or be removed from the process. It’s also often the case that the requestor has tried to imagine himself in your shoes in an attempt to better explain his goals, and comes up with some overly complex solution — and describes that solution instead of the original goal. Your goal with absurd requests is to pierce that veil and reach the original problem, and then work back to construct a reasonable solution to it

brandall10 1y ago

Some years back I took on a embattled project, a dispenser/retriever for scrubs in a hospital environment that had a major revision stuck in dev hell for over 2 years. After auditing the state of the work I decided to discard everything. After that, we started with a clean slate of over 200 bugs w/ 45 features to be developed. Product wanted it done in 6 months, to which I countered that the timeframe was highly unlikely no matter how many devs could be onboarded. We then proceeded to do weekly scope reduction meetings. After a month we got to a place where we comfortably felt a team of 5 could knock it out... ended up cutting the number of bugs down only marginally as stability was a core need, but the features were reduced to only 5. Never once did I push back and say something wasn't a good idea, much of what happened was giving high level estimates, and if something was considered important enough, spending a few hours to a few days doing preliminary design work for a feature to better hone in on the effort. It was all details regarding difficultly/scope/risk to engender trust that the estimates were correct, and to let product pick and choose what were the most important things to address.

whstl 1y ago

I don’t think you’re grasping where I’m getting at. It’s not just about time or budget, at all. Some things are downright impossible without the appropriate data. I mention this above but: I was recently in a situation where a PM wanted two calls to a pure mathematical function to have the same result even though the inputs were different. I can patiently explain this multiple times and provide alternatives and try to explore the actual problem space, but it comes a point that the PM saying “maybe I should ask another engineer” becomes grating enough to make you want to quit. Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry.

BurningFrog 1y ago
I would tell the PM that "sure, let's go talk to him together". Most likely the other engineer will agree. Or maybe he can see something I don't. Either way we're making progress. > Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry. In parts of it, sure. But there really are places with higher quality of people. You will have to prove yourself a bit more to get hired there, of course.
- whstl 1y ago
  > You will have to prove yourself a bit more to get hired there, of course. What you're implying here is extremely disrespectful and uncalled for. This phrase alone says much more about you than it does about me. The point of my story is that taking cheap shots at your interlocutor isn't the way to build software, or win discussions. Let's at least aim to be a bit more respectful towards each other here.
  - BurningFrog 1y ago
    This is a misunderstanding. I meant "you" as the "generic you" (any job seeker), not the "specific you" (you). I hope the fact that you need good skills to get good jobs is not controversial. I meant this as a message of hope: There really are good jobs out there, so don't give up on the industry!