3 ms·

> Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Maybe. But... > Your job is to create

by pdonis 2y ago

> Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Maybe. But... > Your job is to create great software. No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. Some of those problems or services do indeed require great software. But many do not; mediocre software will do the job just fine. And if that's the case, and you insist on creating great software anyway, you are spending time and effort that is not adding anything to the company's bottom line. And while you personally might not care about that, the company does, and they're paying you. > What's great software? The kind you'd be willing to put on your resume without feeling bad. You used the term "software engineer". A software engineer's job is not to always write great software. It's to write the optimal amount and quality of software for meeting the particular requirement it's supposed to meet. More generally, an engineer's job is to produce optimal solutions to problems. That does not always mean building the highest quality product possible. Sometimes it means doing just enough to get the job done, even if it's not very pretty, and stopping there because doing more would add no business value. And you should not at all feel bad about putting that on your resume. Refusing the temptation to gold plate everything when it's not necessary is a good thing for an engineer.

aprilthird2021 2y ago
> No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible. If I am just a yes man, the company isn't getting what they paid for. If I honestly assess and say what is being sacrificed re: security, scalability, future flexibility, etc. in the software, then the company is getting what they paid for, and they can choose how far they want to go in the quality / time spectrum. And if they pick somewhere my expertise says is too far on one or the other side, it's my job to say so. No?
- pdonis 2y ago
  > The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible. Yes, but that does not always mean writing great software. Sometimes it means writing mediocre software because that's all that's needed. Sometimes it might mean writing no software at all because software isn't the best way to solve a particular problem. You recognize this because you say there is a quality/time spectrum, and the company wants you to use your expertise to help find the optimal point on that spectrum for a particular need. But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case.
  - aprilthird2021 2y ago
    > But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case. Yes I guess I just read the parent comment more charitably. Like always push for maximizing the quality as that's your job and your expertise. And sometimes when quality really matters you have to stick your neck out and push back aggressively, even if it will cost the company more than expected. That's what we learn in engineering ethics courses in school after all.
    - pdonis 2y ago
      > sometimes when quality really matters you have to stick your neck out and push back aggressively Yes, that's certainly true. But not all cases are cases where "quality really matters". In many cases you reach a point where adding more quality has rapidly diminishing returns in terms of business value--often because it takes time and effort away from other projects where quality matters a lot more. Ultimately that's the company's decision to make. And as I pointed out in another response upthread, if you genuinely believe the company is dysfunctional in this regard (and many companies are), your only real choices at that point are to try to become a manager so you can fix the company's culture, or change employers.
- willvarfar 2y ago
protocolture 2y ago
>No. Your job is to do what the company pays you for. Yes and no. Ultimately, your solution will live on after you. Even if theres no way for it to backfire publicly, your coworkers and future employees have to deal with it. It can absolutely ruin your reputation and cost you future employment. Admittedly its much easier for a contractor to draw a red line, but I had done this as far back as my first full time IT job, setting boundaries with the owner of that business as to what is and is not practical and achievable.
- pdonis 2y ago
  > It can absolutely ruin your reputation and cost you future employment. If your solution does not meet the company's needs, yes, this is certainly true. But I never said you should do something that does not meet the company's needs. I just pointed out that meeting the company's needs, even if you add the qualifier that you are going to do that in a way that is professional and does not create unnecessary burdens for others, still does not always mean "write great software". It means finding the optimal solution for the particular problem. > setting boundaries with the owner of that business as to what is and is not practical and achievable. And in cases where "write great software" is not practical and achievable (and yes, there will be plenty of such cases), that would mean telling the owner that it is not practical and achievable to write great software to meet this particular requirement, and recommending a different solution. Which is what I said.
  - protocolture 2y ago
    > Hey I wrote that software, you know, from last years massive security breach. Like company policies can be wrong. They are often wrong. It wont matter to your reputation that some CEO accepted the risk and asked you to ship before code review.
- pertymcpert 2y ago
  Sort of missed the point. It’s about writing the optimal amount and standard of software.
WgaqPdNr7PGLGVW 2y ago
> Your job is to do what the company pays you for. The problem with this mindset is the most companies are short-sighted and when the problems inevitably start coming in it is the developers who are placed under pressure. It is the developer being paged at 2am on a Sunday. It is the developer working overtime to get the feature out because the codebase is a giant mess. Etc. Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything.
- pdonis 2y ago
  > most companies are short-sighted The best course if you find yourself employed by such a company is to change employers. A company that is genuinely short-sighted is dysfunctional and no amount of professionalism on your part as an individual contributor is going to fix that. Now if you could get yourself promoted to management, then maybe you could have an impact--but then you wouldn't be doing actual software engineering any more, you'd be doing corporate management fixing, which is a different job. > and when the problems inevitably start coming in it is the developers who are placed under pressure. Yes, this is true. And as above, if it's genuinely dysfunctional, your best course, unless you are willing and able to become a manager yourself, is to change employers. > Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything. That's not what "write great software" means to me. "Great" is not the same as "minimum quality bar".

by pdonis 2y ago

aprilthird2021 2y ago

> No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible. If I am just a yes man, the company isn't getting what they paid for. If I honestly assess and say what is being sacrificed re: security, scalability, future flexibility, etc. in the software, then the company is getting what they paid for, and they can choose how far they want to go in the quality / time spectrum. And if they pick somewhere my expertise says is too far on one or the other side, it's my job to say so. No?

pdonis 2y ago
> The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible. Yes, but that does not always mean writing great software. Sometimes it means writing mediocre software because that's all that's needed. Sometimes it might mean writing no software at all because software isn't the best way to solve a particular problem. You recognize this because you say there is a quality/time spectrum, and the company wants you to use your expertise to help find the optimal point on that spectrum for a particular need. But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case.
- aprilthird2021 2y ago
  > But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case. Yes I guess I just read the parent comment more charitably. Like always push for maximizing the quality as that's your job and your expertise. And sometimes when quality really matters you have to stick your neck out and push back aggressively, even if it will cost the company more than expected. That's what we learn in engineering ethics courses in school after all.
  - pdonis 2y ago
    > sometimes when quality really matters you have to stick your neck out and push back aggressively Yes, that's certainly true. But not all cases are cases where "quality really matters". In many cases you reach a point where adding more quality has rapidly diminishing returns in terms of business value--often because it takes time and effort away from other projects where quality matters a lot more. Ultimately that's the company's decision to make. And as I pointed out in another response upthread, if you genuinely believe the company is dysfunctional in this regard (and many companies are), your only real choices at that point are to try to become a manager so you can fix the company's culture, or change employers.
willvarfar 2y ago

protocolture 2y ago

>No. Your job is to do what the company pays you for. Yes and no. Ultimately, your solution will live on after you. Even if theres no way for it to backfire publicly, your coworkers and future employees have to deal with it. It can absolutely ruin your reputation and cost you future employment. Admittedly its much easier for a contractor to draw a red line, but I had done this as far back as my first full time IT job, setting boundaries with the owner of that business as to what is and is not practical and achievable.

pdonis 2y ago
> It can absolutely ruin your reputation and cost you future employment. If your solution does not meet the company's needs, yes, this is certainly true. But I never said you should do something that does not meet the company's needs. I just pointed out that meeting the company's needs, even if you add the qualifier that you are going to do that in a way that is professional and does not create unnecessary burdens for others, still does not always mean "write great software". It means finding the optimal solution for the particular problem. > setting boundaries with the owner of that business as to what is and is not practical and achievable. And in cases where "write great software" is not practical and achievable (and yes, there will be plenty of such cases), that would mean telling the owner that it is not practical and achievable to write great software to meet this particular requirement, and recommending a different solution. Which is what I said.
- protocolture 2y ago
  > Hey I wrote that software, you know, from last years massive security breach. Like company policies can be wrong. They are often wrong. It wont matter to your reputation that some CEO accepted the risk and asked you to ship before code review.
pertymcpert 2y ago
Sort of missed the point. It’s about writing the optimal amount and standard of software.

WgaqPdNr7PGLGVW 2y ago

> Your job is to do what the company pays you for. The problem with this mindset is the most companies are short-sighted and when the problems inevitably start coming in it is the developers who are placed under pressure. It is the developer being paged at 2am on a Sunday. It is the developer working overtime to get the feature out because the codebase is a giant mess. Etc. Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything.

pdonis 2y ago
> most companies are short-sighted The best course if you find yourself employed by such a company is to change employers. A company that is genuinely short-sighted is dysfunctional and no amount of professionalism on your part as an individual contributor is going to fix that. Now if you could get yourself promoted to management, then maybe you could have an impact--but then you wouldn't be doing actual software engineering any more, you'd be doing corporate management fixing, which is a different job. > and when the problems inevitably start coming in it is the developers who are placed under pressure. Yes, this is true. And as above, if it's genuinely dysfunctional, your best course, unless you are willing and able to become a manager yourself, is to change employers. > Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything. That's not what "write great software" means to me. "Great" is not the same as "minimum quality bar".