Honestly, the things you describe are not that bad. If they are writing code that passes the test cases, move on and be happy. If you'd described things like

Honestly, the things you describe are not that bad. If they are writing code that passes the test cases, move on and be happy. If you'd described things like circular dependencies and passing brittle "magic strings" through multiple layers -- things that will GENUINELY cause maintainability issues I'd sympathize more. I doubt anyone named it the "...last6hours" but then parameterized the number of hours -- so you're changing that code anyway if the number of hours changes. If you have a requirement to parameterize that, do so, otherwise YAGNI, move on. Hardcoded strings is another one. Frankly, unless you are using the string in more than two places or it's part of a "set" of values, where referencing the full set is useful, you may just be making more work to do it 'correctly'. You reference timeline pressure. "Good, Fast, Cheap, pick two". If you don't have enough programmers for the timeline alotted, the powers-that-be have already selected Cheap and Fast. Deliver a product that does the job asked, a few maintenance iterations (if the product is one of the 30% that make it that far) will teach you want areas of code are touched a lot and need to be "made maintainable"