I have found that structuring your code is far more important than structuring your time.
Don't get caught up with "getting it working". It is better to have something you cannot see happening working properly, than to see something moving around on-screen, but know deep down that it's a hack.
And if you end up rushed, you will end up taking short-cuts which may cost you dearly in the future.
In coding, the structure is everything - structure for efficiency, structure for usability, and above all, structure for structure.
If you get through only one object in a week, but it is properly planned, you can come back to it later, and immediately know exactly what it does by its name and scope. It should be studied, refined, and ingrained before you go anywhere near a keyboard.
Once you have achieved this "harmony" with your program's structure, you can return to it any time, and become re-acquainted in a matter of moments.
You can always leave yourself comments where you know code needs to go, so that you know what has been done, and what needs work when you come back.
-- apply force dampening here
-- refine method to include dynamic file loading
-- needs a more elegant solution!!!
etc
Then document some more.
And don't leave ambiguities.
w.o[t].v.x might seem tidy, but is likely to give you a headache at some point, while you will leave yourself with no doubt using world.objects[target].velocity.x (you shouldn't have to do that, but if you do, you know you can)
Following love convention is a good idea.
As an example, all of my game objects have object.load(this) object.update(this, dt) and object.draw(this)
When the game loads up, it calls state:load() which iterates over this.states, and calls state:load()
Now all my states are loaded and ready for action.
state[state.current]:update(dt) calls the current state's update function, which in turn calls this.gui:update(dt), and in the case of the world state, also calls world:update(dt), which iterates over this:objects and calls object:update(dt).
One call to rule them all, and best of all, I don't need to have any of this in my head, so if I suddenly get called away to the moon for a month, no problems - all my objects are little mini-MCVs inside a structure which I know works.
You will thank yourself for taking these kinds of pains in the future, and it should give you great satisfaction to know that your code is well-formed, and very likely, re-usable for your next project. You will also have more invested in the project, so it will keep your attention better.
Many and wordy are the volumes which have been written about coding practice - in fact, you can glean a lot of good advice right here on the forums, but always take the time to fully assimilate, and consider usage cases.
I'll stop now, before I end up needing a publisher of my own, but in essence : think it through. Writing a small game is, generally speaking, a leisure activity, and you can afford to take your time and produce something which will give you lasting satisfaction. And if it's a business, you can even less afford to make costly mistakes.
Well, I know that's not exhaustive, but I hope I managed to impart something useful.
Many happy structure to you, and I hope this helps you get more
satisfaction from your projects