4 ms·

There's a lot to unpack here. "So, the engineer makes a wild guess and his boss responds with, "That's too long."" -> You have a dysfunctional relationship wit

There's a lot to unpack here. "So, the engineer makes a wild guess and his boss responds with, "That's too long."" -> You have a dysfunctional relationship with your boss. They don't trust your estimates - whether based on their hubris, or your past results, or something else. You need to either find a way to reset that trust or leave the company and start anew with a new manager. Otherwise you'd going to have this same problem forever and neither of you will be happy. "Very often, if he chooses to do a lousy job, everyone seems happy that something was produced, even though what was produced may have been total garbage that was good for absolutely nothing." Reading between the lines here, this sounds like an engineer who wants to satisfy requirements that the project doesn't actually have. In my experience, this often looks like an engineer who wants to add more adjectives (modifiability, robustness, scalability, etc) than is actually needed. If you delivered a result that the stakeholders are happy with, that's a good outcome as an engineer. If you want to overengineer something, consider either doing it on your own time or switching to a job where, for example, more scalability, is actually a requirement. "In other words, if a boss is not totally clueless (which some seem to be), he knows an engineer can't complete a job in three days that will take a month" -> the author clearly assumes their boss has a ton more insight into the engineering work than most do. Actual engineers working on a given project are usually pretty bad at estimating how long tasks will take - a manager (even a non-"clueless", technical one) generally has very little idea how long something will actually take. Assuming that their manager knows and is intentionally screwing you over is just another sign that the author has a completely broken relationship with their boss and is incredibly bitter about it. They would probably benefit from a reset (eg at a new job).

pdonis 6y ago
> Reading between the lines here, this sounds like an engineer who wants to satisfy requirements that the project doesn't actually have. In my experience, this is one of the least understood aspects of the engineer's job, often by engineers themselves. An engineer's job is not to create the absolute highest quality solution every time. The engineer's job is to match solutions with requirements. Often that means not implementing something that, from a purely technical perspective, would be an improvement, because it's not needed to meet the actual requirement, and would take time and effort from something that is needed.
- gnusty_gnurc 6y ago
  I get frustrated when it seems like no one is maintaining requirements (or aware of them) and I'm just expected to make something work, as though I can read minds about what's expected. I have no problem with developing solutions on my own with the right accommodations and compensation - but stop handing me sprints based on things where the greatest extent of planning is a single sentence fragment of a Jira issue title.
  - pdonis 6y ago
    > I get frustrated when it seems like no one is maintaining requirements (or aware of them) and I'm just expected to make something work, as though I can read minds about what's expected. Yes, another (often frustrating) part of the engineer's job is to try to get the client (or a manager or someone else who is supposed to be communicating the client's requirements to you) to understand what "requirements" actually means and what does and doesn't count as actually specifying a requirement so it can be met, or at least so that a reasonable estimate of the time and resources required can be given. As others in this thread have said, sometimes the only real cure for this problem is to find a new job where you have different, and more reasonable, clients and/or managers.
TeMPOraL 6y ago
> If you delivered a result that the stakeholders are happy with, that's a good outcome as an engineer. If you want to overengineer something, consider either doing it on your own time or switching to a job where, for example, more scalability, is actually a requirement. On the flip side, that sounds like a fast track to making shitty products that cause financial losses to the users (or, depending on industry, loss of life and limb). There are always implicit requirements to balance that stakeholders don't think of (or sometimes can't even conceptualize). Like, "satisfy the obvious safety constraints despite them not being mentioned in the spec", or "don't ship kludges that will slow everyone else down later on". Sometimes, part of being an engineer is saving stakeholders from themselves. Might depend on the company culture, but personally I do not want to work in the place where the engineering culture is "ours not to reason why, ours but to do and die".

pdonis 6y ago

> Reading between the lines here, this sounds like an engineer who wants to satisfy requirements that the project doesn't actually have. In my experience, this is one of the least understood aspects of the engineer's job, often by engineers themselves. An engineer's job is not to create the absolute highest quality solution every time. The engineer's job is to match solutions with requirements. Often that means not implementing something that, from a purely technical perspective, would be an improvement, because it's not needed to meet the actual requirement, and would take time and effort from something that is needed.

gnusty_gnurc 6y ago
I get frustrated when it seems like no one is maintaining requirements (or aware of them) and I'm just expected to make something work, as though I can read minds about what's expected. I have no problem with developing solutions on my own with the right accommodations and compensation - but stop handing me sprints based on things where the greatest extent of planning is a single sentence fragment of a Jira issue title.
- pdonis 6y ago
  > I get frustrated when it seems like no one is maintaining requirements (or aware of them) and I'm just expected to make something work, as though I can read minds about what's expected. Yes, another (often frustrating) part of the engineer's job is to try to get the client (or a manager or someone else who is supposed to be communicating the client's requirements to you) to understand what "requirements" actually means and what does and doesn't count as actually specifying a requirement so it can be met, or at least so that a reasonable estimate of the time and resources required can be given. As others in this thread have said, sometimes the only real cure for this problem is to find a new job where you have different, and more reasonable, clients and/or managers.

TeMPOraL 6y ago

> If you delivered a result that the stakeholders are happy with, that's a good outcome as an engineer. If you want to overengineer something, consider either doing it on your own time or switching to a job where, for example, more scalability, is actually a requirement. On the flip side, that sounds like a fast track to making shitty products that cause financial losses to the users (or, depending on industry, loss of life and limb). There are always implicit requirements to balance that stakeholders don't think of (or sometimes can't even conceptualize). Like, "satisfy the obvious safety constraints despite them not being mentioned in the spec", or "don't ship kludges that will slow everyone else down later on". Sometimes, part of being an engineer is saving stakeholders from themselves. Might depend on the company culture, but personally I do not want to work in the place where the engineering culture is "ours not to reason why, ours but to do and die".