> Code quality doesn’t matter that much. No one else is going to see it.

This is just false for anyone who has worked in the industry for any meaningful amount of time. Do you seriously never encountered a situation where a change was supposedly easy on the surface, but some stupid SoB before you wrote it so bad that you want to pull your hair out from trying to make it work without rewriting this crap codebase from scratch?

▲

simianwords 6 hours ago | parent [-]

at least where i have worked, you need to identify the context. certain projects require good readable code and certain projects require you to iterate fast and explore.

in my experience very few projects were serious enough that required such scrutiny in code.

▲

FuckButtons 6 hours ago | parent [-]

Sounds like you’ve never had a prototype become foundational infrastructure before, or dealt with someone else’s.

▲

edgyquant 3 hours ago | parent | next [-]

I have many times and if you spend too long over architecting a prototype you start to get annoyed looks and tons of questions from PMs who just want something that looks right today (we can fix it/optimize it later)

▲

simianwords 4 hours ago | parent | prev [-]

you can always change it later. this is exactly the dogmatism i'm speaking about - you need to prioritise pushing things. the clean up can come later.

ironically it is your camp that advices to not use microservices but start with monolith. that's what i'm suggesting here.

▲

discreteevent 3 hours ago | parent | next [-]

> You can always change it later.

People seem to think that technical debt doesn't need to be paid back for ages. In my experience bad code starts to cost more than it saved after about three months. So if you have to get a demo ready right now that will save the company then hack it in. But that's not the case for most technical debt. In most cases the management just want the perception of speed so they pile debt upon debt. Then they can't figure out why delivery gets slower and slower.

> ironically it is your camp that advices to not use microservices but start with monolith. that's what i'm suggesting here.

I agree with this. But there's a difference between over-engineering and hacking in bad quality code. So to be clear, I am talking about the latter.

▲

skydhash 3 hours ago | parent | prev [-]

> you can always change it later. this is exactly the dogmatism i'm speaking about - you need to prioritise pushing things. the clean up can come later.

Everyone that says this has not been the one that had to fix the code later. They have already moved to the next jobs (or have been fired). Engineers do know the tradeoff between quality and speed, and can do hack if that’s what needed to get the project to the finish line. But good ones will note down the hack and resolve it later. Bad ones will pat themselves in the back and add more hacks on top of that.

	▲	2 hours ago \| parent [-]
		[deleted]