Comment by Schiendelman

5 hours ago

As a technical product manager, this 1000%. It's just irrelevant how bad code is unless it impacts the business.

7 comments

Schiendelman

> As a technical product manager, this 1000%. It's just irrelevant how bad code is unless it impacts the business.

If you are, in fact, "a technical product manager", I would hope you understand that "bad code" is identified as such specifically because it "impacts the business."

Schiendelman 4 hours ago
That is not how most engineers define bad code.
- AdieuToLogic 4 hours ago
  
  > That is not how most engineers define bad code.
  The engineers I have worked with most definitely define "bad code" as having intrinsic limitations and/or latent defects which impact successful system functionality/operation. Indicators provided to stakeholders such as yourself which support this assessment are, but not limited to:
  - the system doesn't work that way - the system lacks test coverage, so changes take longer - adding feature "X" is not feasible - there is no repeatable way to onboard team members - the backlog grows exponentially - that "one point task" is going to take a couple weeks
  All of the above impacts a business.
  It is up to you, the "technical product manager", to understand what your team is trying to tell you.
  
  3 replies →

nomel 4 hours ago

This is something I wish I understood sooner. There is strong merit to "good enough".

Of all the "concise" and "beautiful" code I worked hard to produce, I was the only one to ever lay eyes on it. It didn't actually matter, and nobody cared but me. The people in charge of my raises could never perceive quality of code, because it wasn't their area of expertise. They only cared (rightly so) that it did what it was supposed to, and all the elegant abstractions didn't practically help that purpose. It was, literally, wasted life that I should have spent just getting off work early, like most of my colleagues.