JoshParnell wrote:With the most practical option shot down, I switched attack vectors and tried what seemed to me the next most practical: splitting the C++ into smaller bits to make it more manageable. I split up what was a 'monolithic' engine, compiled all into one library, into component pieces compiled into different libraries (libltcore, libltrender, libltui, libltai, etc.); this was an attempt to increase both runtime efficiency and my ability to keep all code in RAM. This attempt, luckily, only cost me a few months, as I quickly learned that code is code, and the programmer RAM limit applies no matter how you divvy up the lines. Another solution shot down, another lesson learned.
Sad to see that you have abandoned the likely correct approach. I, too, am a software engineer / project manager, and deal with (very) large codebases, so I know what it's like. But what you need to do, is instead of developing each of those in parallel, develop and
complete each one
separately, so you focus solely on them and they are 100% built before moving onto the next
separate module. Document your code and structures well (each and every bit of logic, each and every function, each and every class, each and every source and header file, each and every module) and keep the same formatting standards, so when you come back (which you inevitably will, to make
little tweaks) it is easier to pick up (and it is
your code, you
know your code better than anyone else). At this point, you should
never need to go back and rewrite substantial amounts of code, as you are well versed in what you need to achieve and how to achieve it - nothing should be foreign or require much thought from you any longer. When a module is completed, you can now swap the contents of that memory, and mark that memory area as "available to allocate more memory to", as you will no longer need to remember the entire structure of that module, rather just a high level "table of contents", if you will, so you can easily jump to and track down the relevant and necessary section / information from your documentation that you made. You shouldn't ever need to retain the complete contents of more than one module at a time in your mind as, as you have experienced, quickly suffer burnout. Also, take the week
end off. Don't post status updates on Sundays, do it at the end of the week on Fridays.
If for whatever reason that fails, you should seriously consider hiring a second person to help you complete it - have a team of two, and increase your LOC count / available memory from 100K LOC to 200K LOC. Or go back to university and learn how to properly manage a project.
And with regards to the communications front, just post bi-weekly, or whatever is a comfortable
routine for you, even if the posts are simply just, "I have made no progress". No need to sport fancy screenshots, only few in the community want that. More just want status updates.
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill