Great post! I'd also definitely recommend a third (and often less controllable) option: cutting scope to keep to your code quality practices and team norms.
As a line developer this can be difficult, but by working together with management / product ownership to distill the feature you're working on down to the things it really needs (and not less valuable fluff) may provide some space in the other two areas of the classic project management triangle (time and quality).
Managing the scope creep is pretty reasonable. If you work on this with the business side you can deliver extra fluff in the next batch/release (if needed).
I don't recommend cutting corners and working too much overtime. I mean overtime once in a while is fine, but there are managers that think overtime is normal. "Developers don't have normal life after work after all"
Glad to have seen this discussion!
While I'm currently between positions, I've had more reading time, and have recently discovered the concept of Minimum Viable Product (MVP).
I've had recent experience with a team needing (under very tight time constraints) to get enough of a product (in this case a web application) built and rolled out quickly simplify to satisfy requirements for continuing the project. From a rather junior role, I learned a great deal walking through that process of distinguishing 'need from want'... and how critical it is to have foresight when pre-planning the timeline, setting up milestones, defining sprints, etc.
At the same time, I'm also reading about some of the common struggles that those of us new to the field face (learning curves, confidence, time/task management)... and seeing that it's very common for newer developers to try to get everything perfect before committing (which ultimately prohibits one from committing anything... and another lesson learned), when it's often more practical to just get it into the repo (or review, etc.) as a working version, and then fine-tune for style as a function of tech debt.
The two concepts (to me, anyway) seem to have a real parallel. MVP for quick out-the-door iteration, and not sitting on code that's functionally working.
I know for me that the whole balancing time/scope/quality, just within my own working context, has been challenging.
Thanks for a great thread (and yes, in fact that was the first instance of my using markdown in-line without a cheat sheet :P )!
There's a thin line with good work and actually overdoing things.
No code is perfect at first sitting. We have pair programming and code reviews to help :) But being too much of a perfectionist is no good too.
We have to help each other to keep the right balance here :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.