You will not always go faster by writing clean code. Quality clean code takes time (especially if you have a large code-base). Often there is an inverse relationship between code quality and development speed. So to meet a rushed deadline you either have to sacrifice quality or features.
You should strive to maintain a consistent level of quality by reducing the feature set to meet a deadline. This requires early and constant communication (with manager / product owner, client, etc).
Caveat: you should be willing to sacrifice quality temporarily if it's an emergency. E.g. You will go out of business if you don't meet the deadline. This is reserved for emergencies, because it is unsustainable, but it would be stupid to lose your job/company over code quality.
I hear you, but there is a point that I fear readers might miss.
In the short term, depending on your system, doing something the "right"/high-quality way can take far longer than a quick fix or hack. This is very important in the context of a deadline. It means you may meet your deadline to deliver a feature that would be impossible to deliver in the same time with quality clean code. However, you run the risk of crippling long term maintenance.
Anyway, time is relative. For most a "deadline" is short-term. Clean code is about the long-term, and while sometimes it's really just a mind trick that you think it will be longer, but in practice you run into the situations I described as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You will not always go faster by writing clean code. Quality clean code takes time (especially if you have a large code-base). Often there is an inverse relationship between code quality and development speed. So to meet a rushed deadline you either have to sacrifice quality or features.
You should strive to maintain a consistent level of quality by reducing the feature set to meet a deadline. This requires early and constant communication (with manager / product owner, client, etc).
Caveat: you should be willing to sacrifice quality temporarily if it's an emergency. E.g. You will go out of business if you don't meet the deadline. This is reserved for emergencies, because it is unsustainable, but it would be stupid to lose your job/company over code quality.
Quality code appears to be taking time. In fact, it is saving you from spending more time during maintenance and feature addition.
I hear you, but there is a point that I fear readers might miss.
In the short term, depending on your system, doing something the "right"/high-quality way can take far longer than a quick fix or hack. This is very important in the context of a deadline. It means you may meet your deadline to deliver a feature that would be impossible to deliver in the same time with quality clean code. However, you run the risk of crippling long term maintenance.
Anyway, time is relative. For most a "deadline" is short-term. Clean code is about the long-term, and while sometimes it's really just a mind trick that you think it will be longer, but in practice you run into the situations I described as well.