4 ms·

> "The next guy to join the company will clean up your shit" Is that acting in the best interest of your employer? or ripping your employer off? I think more l

> "The next guy to join the company will clean up your shit" Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter. Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately. The world of difference between balancing trade-offs in technical debt, tradeoffs in long-term/short-term goals, and deliberatively sabotaging the company by leaving technical debt for other people to clean. You are a liability to the company and its culture. And you want people like you and your language to be taken seriously? that's why nobody wants to work with people like you.

apathy 10y ago
other professions do behave like this. Look at the CEO of Wells Fargo or Valeant. "Fuck you, I got mine!"
BoorishBears 10y ago
I was unaware finance people didn't operate like this.
- throwaway729 10y ago
  Finance has a bad rep, but there are actually lots of rules and regs surrounding ethics in finance and a practitioner can easily end up with massive fines or in jail for failing to follow those rules. Even if his boss told him to do it. Those rules may not be the right ones and they may not be enforced well enough, but there's at least some nominal level of assumed professional responsibility.
throwaway729 10y ago
> But suddenly because you are an "engineer" this is acceptable? No, it's acceptable precisely because you aren't an engineer. We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices. So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.
- partycoder 10y ago
  No. And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted. You don't, because you have you keep this to yourself because you know it is wrong and not in the best interest of your employer... Who is wrong now?
  - throwaway729 10y ago
    > Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT: > because you know it is wrong and not in the best interest of your employer Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employer. There is no prior obligation (aside from not literally breaking the law). And within the structure of the company, the engineer has no legal or professional obligation prior to manangement. So, if parent's boss tells him "get this shit out the door ASAP maintainability and quality be damned", and then parent does exactly that, I think he'd probably be OK from an employment perspective. In fact, insisting on some modicum of security or readability might even get him in trouble! Contrast that with the situation of a PE, who would be much more likely to answer "no" on the basis of professional ethical obligations which are prior to his obligations to his employer/immediate manager. And, when answering no, would be much more likely to have the leverage and respect necessary to survive an encounter with middle management.
    - partycoder 10y ago
      Do your job in the interest of your employer, to the best of your ability, without ripping off your customer. That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything. What if everyone ripped off everyone all the time? It would be a world of shit. Ripping off the customer is not in the best interest of the employer, and is being hostile towards society. Think about contributing to society not taking what you can. Adding customer value is different to adding apparent value with no real substance.
swalsh 10y ago
The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is. There are 3 phases: Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it. Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it. Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.
- partycoder 10y ago
  That's what I said: there's a difference between calculated trade-offs between short term and long term and "I got no time for that, let the next guy clean it up, haha!!". If you are rational you will understand that technical debt is a cost, and unless you are sabotaging the project you won't add cost without a good reason. Prototyping and iteration is fine. Throwing away prototypes might be fine. But selling a functional prototype as a finished product IS NOT FINE. It's morally wrong. And unless you want to be lynched like the Theranos people you better not get caught doing this.

apathy 10y ago

other professions do behave like this. Look at the CEO of Wells Fargo or Valeant. "Fuck you, I got mine!"

BoorishBears 10y ago

I was unaware finance people didn't operate like this.

throwaway729 10y ago
Finance has a bad rep, but there are actually lots of rules and regs surrounding ethics in finance and a practitioner can easily end up with massive fines or in jail for failing to follow those rules. Even if his boss told him to do it. Those rules may not be the right ones and they may not be enforced well enough, but there's at least some nominal level of assumed professional responsibility.

throwaway729 10y ago

> But suddenly because you are an "engineer" this is acceptable? No, it's acceptable precisely because you aren't an engineer. We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices. So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.

partycoder 10y ago
No. And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted. You don't, because you have you keep this to yourself because you know it is wrong and not in the best interest of your employer... Who is wrong now?
- throwaway729 10y ago
  > Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT: > because you know it is wrong and not in the best interest of your employer Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employer. There is no prior obligation (aside from not literally breaking the law). And within the structure of the company, the engineer has no legal or professional obligation prior to manangement. So, if parent's boss tells him "get this shit out the door ASAP maintainability and quality be damned", and then parent does exactly that, I think he'd probably be OK from an employment perspective. In fact, insisting on some modicum of security or readability might even get him in trouble! Contrast that with the situation of a PE, who would be much more likely to answer "no" on the basis of professional ethical obligations which are prior to his obligations to his employer/immediate manager. And, when answering no, would be much more likely to have the leverage and respect necessary to survive an encounter with middle management.
  - partycoder 10y ago
    Do your job in the interest of your employer, to the best of your ability, without ripping off your customer. That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything. What if everyone ripped off everyone all the time? It would be a world of shit. Ripping off the customer is not in the best interest of the employer, and is being hostile towards society. Think about contributing to society not taking what you can. Adding customer value is different to adding apparent value with no real substance.

swalsh 10y ago

The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is. There are 3 phases: Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it. Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it. Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.

partycoder 10y ago
That's what I said: there's a difference between calculated trade-offs between short term and long term and "I got no time for that, let the next guy clean it up, haha!!". If you are rational you will understand that technical debt is a cost, and unless you are sabotaging the project you won't add cost without a good reason. Prototyping and iteration is fine. Throwing away prototypes might be fine. But selling a functional prototype as a finished product IS NOT FINE. It's morally wrong. And unless you want to be lynched like the Theranos people you better not get caught doing this.