2 ms·

I sympathize as well, but I also know many many developers are extremely poor at judging what/how the code affects a given Firm's KPI's. I've been in literally

I sympathize as well, but I also know many many developers are extremely poor at judging what/how the code affects a given Firm's KPI's. I've been in literally hundreds of conversations with engineers who want to refactor a given technical system and don't realize the code debt is really due to the fact human businesses run on endless edge cases and weird exceptions. They only account for the majority use cases, but the problem is the firm would get sued without complete coverage. So when they deal with the edge cases, the code looks like shit again, and then what was the point of the company spending money on the refactor ? Application/Code Architecture in real world businesses is extremely tough given moving requirements, endless legal/financial edge cases, and subtly different but similar concepts across different business domains. It's gets even tougher when you have to make difficult decisions about cost centers and profit centers. My firm has a super specialty team (extremely well paid) that goes in and refactors/clean's up codebase's that are identified as becoming less efficient. However even the average senior engineer lacks the experience and understanding to clean up code debt in most business codebases.

evntdrvn 4y ago
I’m really curious where you work, the team you mention in your last paragraph sounds like my dream job :D
- stuckinhell 4y ago
  Sorry can't say, but I doubt it's your dream job. That team is expected to work any amount of hours, sleep in the office, and do whatever it takes to get the job done.
CuriouslyC 4y ago
I work at such a firm with constantly changing legislative and organizational requirements, and while there is definitely a lot of moving target syndrome around business processing logic that this applies to, there are other things like a byzantine service architecture leading to people having to make web service calls rather than join across tables, a house of cards docker/kong setup that people are afraid to update because it's so difficult to debug, unit tests that take 10 minutes to run even in limited cases because of the poorly written migrations and other unrelated bad architecture/engineering choices. Those things could all be fixed with a very reasonable amount of effort for the productivity boost they'd give, but the technical leadership in the teams that owns those things is not super competent, so they're afraid to make any significant changes because they're not confident in their ability to solve problems that might arise as a result.

evntdrvn 4y ago

I’m really curious where you work, the team you mention in your last paragraph sounds like my dream job :D

stuckinhell 4y ago
Sorry can't say, but I doubt it's your dream job. That team is expected to work any amount of hours, sleep in the office, and do whatever it takes to get the job done.

CuriouslyC 4y ago

I work at such a firm with constantly changing legislative and organizational requirements, and while there is definitely a lot of moving target syndrome around business processing logic that this applies to, there are other things like a byzantine service architecture leading to people having to make web service calls rather than join across tables, a house of cards docker/kong setup that people are afraid to update because it's so difficult to debug, unit tests that take 10 minutes to run even in limited cases because of the poorly written migrations and other unrelated bad architecture/engineering choices. Those things could all be fixed with a very reasonable amount of effort for the productivity boost they'd give, but the technical leadership in the teams that owns those things is not super competent, so they're afraid to make any significant changes because they're not confident in their ability to solve problems that might arise as a result.