Q:

How to keep your productivity level high when people keep changing requirements at the last minute?

I started working as a software engineer with a startup about one and a half year ago. Everyone here cares about this project and works hard. but I have been having an issue here for some time. 
People here have "lack of discipline" when it comes to development tasks. They ask for one functionality, I ask a thousand questions so that I am clear on the requirements of the functionality. As I don't ever like to miss a single scenario when collecting requirements. and I do my work with all my heart and brain in it. 
Later on the day of the demo, they would say: let's change this to that and that to this. 5 demos later, trying to fit in their changed requirements and flow, I end up with a mess of code that works the way they want. 
Now, because the flow is totally changed, it's not even the same function that I started with, there's delay in launch, there are bugs in production and  marketing people are screaming about it. I always end up in some mess. and I am tired of it.
I can't fix the issue with these people, I can only try to fix myself, I believe that issues come when they make me work on the same thing again and again and I get demotivated to work and I procrastinate. 
I like this project, I really want to stay here for a bit longer and I want to give my best even if I am working on something for the 5th time.
Any advice on keeping the productivity level high in these scenarios? How do I make sure that I don't miss anything while changing the functions? and what do I do when I feel stuck. 
p.s. ATM I am making changes in the flow of a user portal that I actually finished flawlessly last week. and now I am stuck, I don't feel like doing it. and I can't even think how to fix these issues. 

A:

The idea that requirements are fixed and that the code you are writing will not have to be changed is extremely problematic.  In reality, requirements are never fixed.  Whether you need to change it prior to the initial release or not, at some point in the future, your code is very likely going to need to change.  When that ceases to be true, it's because the code base is abandoned.
In your situation, you've identified that 1. your initial requirements are not what you will eventually deliver and 2. that you can't affect any change to that reality.
All of this points to one thing: you need to optimize your development strategy around the ability to change.  A lot of software practices you will read about here are either about the ability to understand code later, the ease of modification, or both.
The first thing I would suggest is that you stop attempting to build a fully complete polished system before showing it to your product owners.  Instead build functioning prototypes and get them in front of the decision makers early.  Take their feedback, implement them and make things a little more finished.  Show it to them again.  Rinse and repeat.  Eventually, you should get to a point where they start saying everything is OK except for the details.  That's when you start finishing things off.
The other thing that stands out is that when you are making these changes, you are hacking them in.  You should be following the same standards for your code whether it's a last minute change or if your code isn't due for 6 weeks.  Yes, it's inevitable that you might need to tweak something at the last minute and clean it up later every once in a while but doing this as part of your regular release is very damaging to the code base.  The more poorly written code you put in, the harder it will be to adapt to the stream of changes.  Getting it in front of people early will help with this since you will have more time to make the changes appropriately.
The last thing I will recommend is a couple of specific development practices that can be very help in this kind of situation: 

Modular code: If nothing else, make sure you are breaking code down into short readable methods with a single responsibility and meaningful name.
Unit tests: What's often misunderstood about unit tests is that they have relatively little value in determining whether your code meets requirements.  Where they shine is when you are modifying code.  They give an instant feedback when you have broken something.  Keep them up to date and modify the tests that you need to change first before implementing the change.

