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 )!
I am a Software Dev girl who loves Uncle Bob, is drawn to the human side of software development and clean coded applications, and enjoys acting as a liaison between the business and tech.
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 :)
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.
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 :)