> Part of the reason it had taken so long is because I put a substantial amount of work into a part of the project that's no longer necessary due to changing requirements, which I don't think I could have forseen. One of the things that I've experienced with new grad junior devs is that there's an adjustment needed to change from academic working to business working. In academia, usually the professor gives an assign…
Thanks. I definitely will take that into consideration in the future. I'm not sure if it would have helped in this specific case but I can definitely think of other situations at work where taking your advice would have helped me.
There's also a an art to getting together a good MVP efficiently. You can treat lots of added requirements as shiny feature requests, and prioritize them below getting the MVP working. Having an MVP that people can try out and see it working at all goes a long way towards building belief in your work. At the same time, you want to build flexibly enough that the MVP can expand rationally to take on those added feature requests... without writing in SO MUCH generality that nothing ever gets done. Doing this well is a skill learned on the back of many failures and tedious refactors... But efficiently getting a demo+MVP is golden, even if you build up some tech debt to get it.