4 ms·

Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".

by raldi 10y ago

switchbak 10y ago
Having read that article, I do agree - but the requested change, while being "one line", could have unforeseen consequences that could also have a very negative effect on the business. I'm thinking that the CEO wouldn't take the blame for that though. But if people's jobs were truly on the line, I'm inclined to agree with the "screw it, push it through" approach.
didibus 10y ago
I wholeheartedly disagree. In fact, I believe that's the difference between an engineer and a programmer. If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." You don't just change a 3 to a 4 because the CEO wants you to. You have to make sure the change doesn't come with unforseen impact that would put the company at risk, and you have to make the change in a similar way. That's what the CEO expects also. If you did the change, and it had caused impact to the business, that you had not pointed out, and for which the business believe is more harmful then having waited a few more days, you and only you are to blame, and you will be. You can't say, but CEO told me, you're the engineer, you're the person they hired to know this stuff and prevent these issues from happening, not the CEO.
- raldi 10y ago
  I'm not sure we're actually in disagreement. If Captain Kirk tells Scotty, "We need warp 9 in five minutes or we lose the ship" and Scotty cuts corners that cause a decompression explosion that kills twenty redshirts, then yes, that would probably be an example of bad engineering management. But if Scotty delivers on time at the cost of overloading an expensive piece of equipment that, after the battle is won, requires a week in drydock to replace, that's probably a successful execution of exactly the kind of call a senior engineering manager is expected to make.
  - mjevans 10y ago
    It always amazed me how little Star Trek used robots, even just remote arms, to do things. (Yeah, it's a side-effect of it being made for TV)
    - Natsu 10y ago
      Trek wasn't made for logical consistency. They could duplicate Riker with a transporter accident, but they couldn't make another Data that way, they had an entire episode about deconstructing him, then another about him constructing a 'child' robot.
  - didibus 10y ago
    Could be we don't, most disagreement is miscommunication. In your example, Scotty knew what he was doing though. He didn't say, wow, what Kirk wants me to do could kill twenty redshirts in the process, I'll just take the gamble since he seems to want me to. He knew exactly the impact, and made it knowing he would easily be able to contain it. Which is often not the case in Software and in practice. You have to do something to know the impact, because most problem we solve is always new. Its not something we did many times before. If that variable was often changed, then it would be completely different, because he'd known, just like Scotty, that its something they can do. In that case you can make the choice to say, lets change it, and later handle the tech dept of the less maintainable code. Also, in software, its almost never the case that people can't wait a few more days.
  - mcv 10y ago
    If Scotty didn't confirm that it's important enough to risk serious damage, he didn't do his job. His job is not to blindly trust the captains omniscience, his job is to inform the captain of the technical consequences. If warp 9 in 15 minutes is preferable to taking damage, than that's the better option. In the example with the line of code that took 6 days, there was no dramatic emergency in production that required cutting corners. If it had been an emergency, of course the code refactoring demanded in code review should have been postponed; those changes increased the impact of the change, and therefore the resting requirements. And if it really is an emergence that requires people to drop what they're doing, then someone with sufficient authority should be directly involved in order to override all the usual procedures. But you don't just drop all procedures just because somebody claims somebody said something. That would be dangerously irresponsible.
- nostrademons 10y ago
  The point is that decisions should be made by the people who have the proper information to make them. If the CEO lacks the understanding of the technical consequences of a change that may blow up the company, the engineer should make the decision. If the engineer lacks understanding of the business consequences of not making the change - like losing an important client, or suffering a wave of negative PR, or facing a lawsuit - then the CEO should make it. Ideally, both sides should be communicating these consequences so that both of them have all the relevant information and would ideally make the same decision. Then the decisions can get made at the lowest level that has all this information, and the CEO doesn't have to get involved. In practice, there are many cases where the CEO can't communicate all of the relevant business realities, eg. if you're facing a lawsuit if you don't make a change, it's often better not to worry the rest of the staff or make them subject to depositions, and simply to ensure that the change gets made. That's why the CEO is the decider by default in organizations, and also why it's usually expected that employees will obey a direct order from the CEO or be fired.
- rplst8 10y ago
  > If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." This is a distinction that is a very thin line and most people with "engineer" in their title would not sign up for.
  - Nomentatus 10y ago
    True, most engineers, and others, will commit crimes including criminal negligence, when asked firmly enough by a powerful corporation that can fire them. See Flint, Michigan, the great robbery of 2008 etc, etc. But the idea of a profession is that you don't, that you have professional ethics.
    - rplst8 10y ago
      Yeah the term engineer is thrown around pretty casually in the software world. You can apprentice and take the PE (Professional Engineer) test, but it's often hard to find software engineers with their PE certificate. It's much more common in other fields like Mechanical, Electrical, and primarily Civil. It all my years (15) of professional experience, I've only worked under one PE, an Electrical Engineer. In some states you literally can not have "engineer" in your job title unless you have a PE certificate/accreditation/whatever.
- somecallitblues 10y ago
  This seperation of programmers to mindless programmers and somehow superior engineers is bullshit. You have to follow the best practices in whatever you do.
  - mlashcorp 10y ago
    Some people know how to program. Other people dedicated years to the study of computer architectures, first order logic, distributed systems, fault tolerant systems, etc ... In my opinion, computer science and engineering is not about just making the code you're told, it's about questioning whether that code needs to be done in the first place, and if so, how.
    - tracker1 10y ago
      Most software development is not done, or meant to be done as an engineering discipline. It is far more often a craft. That said, it depends on the project, environment, company and legal requirements.
      - mlashcorp 10y ago
        For that, hire a programmer. Need a dependable architecture for mission critical software? You get the point ...
        tracker1 10y ago
        Define mission critical? Can be down for a 15 minute update once a week? Most have transparent updates? Should be up most of the time? Must be up durring East coast business hours? It still depends.
- taneq 10y ago
  Exactly. As an engineer, no matter what your boss says, you are responsible for the consequences of your actions. If the CEO tells you to do something which you know is unsafe, you must decline (and explain why, preferably).
user5994461 10y ago
Sorry, the CEO's job is not to talk about nitpicky technical details. He's got no voice in what a code or a test should be.
bluesign 10y ago
Ok this is the problem with story telling tbh: David: It's for Philip. It we don't do this right away, we'll have to have a layoff. and Judy: OK, then I'll fill out that section myself and put this on the fast track. ----- 2 days later. ----- David: What's the status of 129281? "It we don't do this right away, we'll have to have a layoff" and "2 days later", making an impression of this is an "a day or two" task, not a "fire/emergency" I don't think if this change finished in 2 days anyone will be unhappy. But if you took this to production, and somehow failed, everyone would blame QA/testing

Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".

by raldi 10y ago

Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".

switchbak 10y ago

Having read that article, I do agree - but the requested change, while being "one line", could have unforeseen consequences that could also have a very negative effect on the business. I'm thinking that the CEO wouldn't take the blame for that though. But if people's jobs were truly on the line, I'm inclined to agree with the "screw it, push it through" approach.

didibus 10y ago

I wholeheartedly disagree. In fact, I believe that's the difference between an engineer and a programmer. If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." You don't just change a 3 to a 4 because the CEO wants you to. You have to make sure the change doesn't come with unforseen impact that would put the company at risk, and you have to make the change in a similar way. That's what the CEO expects also. If you did the change, and it had caused impact to the business, that you had not pointed out, and for which the business believe is more harmful then having waited a few more days, you and only you are to blame, and you will be. You can't say, but CEO told me, you're the engineer, you're the person they hired to know this stuff and prevent these issues from happening, not the CEO.

raldi 10y ago
I'm not sure we're actually in disagreement. If Captain Kirk tells Scotty, "We need warp 9 in five minutes or we lose the ship" and Scotty cuts corners that cause a decompression explosion that kills twenty redshirts, then yes, that would probably be an example of bad engineering management. But if Scotty delivers on time at the cost of overloading an expensive piece of equipment that, after the battle is won, requires a week in drydock to replace, that's probably a successful execution of exactly the kind of call a senior engineering manager is expected to make.
- mjevans 10y ago
  It always amazed me how little Star Trek used robots, even just remote arms, to do things. (Yeah, it's a side-effect of it being made for TV)
  - Natsu 10y ago
    Trek wasn't made for logical consistency. They could duplicate Riker with a transporter accident, but they couldn't make another Data that way, they had an entire episode about deconstructing him, then another about him constructing a 'child' robot.
- didibus 10y ago
  Could be we don't, most disagreement is miscommunication. In your example, Scotty knew what he was doing though. He didn't say, wow, what Kirk wants me to do could kill twenty redshirts in the process, I'll just take the gamble since he seems to want me to. He knew exactly the impact, and made it knowing he would easily be able to contain it. Which is often not the case in Software and in practice. You have to do something to know the impact, because most problem we solve is always new. Its not something we did many times before. If that variable was often changed, then it would be completely different, because he'd known, just like Scotty, that its something they can do. In that case you can make the choice to say, lets change it, and later handle the tech dept of the less maintainable code. Also, in software, its almost never the case that people can't wait a few more days.
- mcv 10y ago
  If Scotty didn't confirm that it's important enough to risk serious damage, he didn't do his job. His job is not to blindly trust the captains omniscience, his job is to inform the captain of the technical consequences. If warp 9 in 15 minutes is preferable to taking damage, than that's the better option. In the example with the line of code that took 6 days, there was no dramatic emergency in production that required cutting corners. If it had been an emergency, of course the code refactoring demanded in code review should have been postponed; those changes increased the impact of the change, and therefore the resting requirements. And if it really is an emergence that requires people to drop what they're doing, then someone with sufficient authority should be directly involved in order to override all the usual procedures. But you don't just drop all procedures just because somebody claims somebody said something. That would be dangerously irresponsible.
nostrademons 10y ago
The point is that decisions should be made by the people who have the proper information to make them. If the CEO lacks the understanding of the technical consequences of a change that may blow up the company, the engineer should make the decision. If the engineer lacks understanding of the business consequences of not making the change - like losing an important client, or suffering a wave of negative PR, or facing a lawsuit - then the CEO should make it. Ideally, both sides should be communicating these consequences so that both of them have all the relevant information and would ideally make the same decision. Then the decisions can get made at the lowest level that has all this information, and the CEO doesn't have to get involved. In practice, there are many cases where the CEO can't communicate all of the relevant business realities, eg. if you're facing a lawsuit if you don't make a change, it's often better not to worry the rest of the staff or make them subject to depositions, and simply to ensure that the change gets made. That's why the CEO is the decider by default in organizations, and also why it's usually expected that employees will obey a direct order from the CEO or be fired.
rplst8 10y ago
> If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." This is a distinction that is a very thin line and most people with "engineer" in their title would not sign up for.
- Nomentatus 10y ago
  True, most engineers, and others, will commit crimes including criminal negligence, when asked firmly enough by a powerful corporation that can fire them. See Flint, Michigan, the great robbery of 2008 etc, etc. But the idea of a profession is that you don't, that you have professional ethics.
  - rplst8 10y ago
    Yeah the term engineer is thrown around pretty casually in the software world. You can apprentice and take the PE (Professional Engineer) test, but it's often hard to find software engineers with their PE certificate. It's much more common in other fields like Mechanical, Electrical, and primarily Civil. It all my years (15) of professional experience, I've only worked under one PE, an Electrical Engineer. In some states you literally can not have "engineer" in your job title unless you have a PE certificate/accreditation/whatever.
somecallitblues 10y ago
This seperation of programmers to mindless programmers and somehow superior engineers is bullshit. You have to follow the best practices in whatever you do.
- mlashcorp 10y ago
  Some people know how to program. Other people dedicated years to the study of computer architectures, first order logic, distributed systems, fault tolerant systems, etc ... In my opinion, computer science and engineering is not about just making the code you're told, it's about questioning whether that code needs to be done in the first place, and if so, how.
  - tracker1 10y ago
    Most software development is not done, or meant to be done as an engineering discipline. It is far more often a craft. That said, it depends on the project, environment, company and legal requirements.
    - mlashcorp 10y ago
      For that, hire a programmer. Need a dependable architecture for mission critical software? You get the point ...
      - tracker1 10y ago
        Define mission critical? Can be down for a 15 minute update once a week? Most have transparent updates? Should be up most of the time? Must be up durring East coast business hours? It still depends.
taneq 10y ago
Exactly. As an engineer, no matter what your boss says, you are responsible for the consequences of your actions. If the CEO tells you to do something which you know is unsafe, you must decline (and explain why, preferably).

user5994461 10y ago

Sorry, the CEO's job is not to talk about nitpicky technical details. He's got no voice in what a code or a test should be.

bluesign 10y ago

Ok this is the problem with story telling tbh: David: It's for Philip. It we don't do this right away, we'll have to have a layoff. and Judy: OK, then I'll fill out that section myself and put this on the fast track. ----- 2 days later. ----- David: What's the status of 129281? "It we don't do this right away, we'll have to have a layoff" and "2 days later", making an impression of this is an "a day or two" task, not a "fire/emergency" I don't think if this change finished in 2 days anyone will be unhappy. But if you took this to production, and somehow failed, everyone would blame QA/testing