Posted On: 2016-11-06
I've started up another game prototype as a little something to develop on the side, and I recently had my editor crash and lost a bit of work. It's probably less than an hour of rework to get it back, but it completely pulled me out my flow and made me want to drop the project entirely. Instead, I am taking a break to write up today's post, which will go through some things I do (or want to do) that help me maintain flow when I am working on any project.
When developing, I try to make sure I build the project every time I make a change (usually several times a minute). This allows me to address compiler errors immediately (if it's a compiled language), and my IDE of choice (Visual Studio) will automatically save all files and project settings on build, which limits the work I could potentially lose. When working on non-coding projects (such as writing documentation), I try to remember to save often, but I am sometimes forgetful, which leads to things like what happened today. It is also worth mentioning that working on larger code bases or having automated behavior on build can lead to compounding stress and productivity losses, as I expect my code to complete building in under a minute (otherwise I become distracted by not being able to go back to working on it).
Much like building, I aim to run my code any time I think it will be stable. When developing whole new code, this can be less often (for example, while building architecture I can go for hours without running it, since it often has so many missing dependencies.) When debugging or otherwise working on focused tasks, I will often run each individual change immediately after making it (usually every couple of minutes or so). Since running the code normally requires building it (any IDE that does not track changes and lets you run without building tends to cause me a lot of stress and confusion) this very nicely complements building often. To facilitate quickly testing the change, it can be helpful to use a backdoor of some kind to get to the page/app state that you need to (I have not yet found a good pattern for this in game development - the closest I have is that I temporarily move whatever I am developing to the entry point of the app, so I can see my changes immediately).
The metadata that describes how to load the code or load the project should be human-readable. This makes running a diff simple, and allows you to change something directly if any automated changes are incorrect (or if it is overly difficult to trigger them). Unfortunately, this is largely controlled by the tools you are using. Visual Studio is generally good about this (the various project and solution files are just XML), but when integrating with other tools (such as Unity) this can fall apart. This is one of the biggest reasons that I generally prefer to use plain text editors for (non-code) writing, as opposed to rich text editors (many of the leading products include compressed metadata - for example, MS Word stores information about document styling). One more thing worth mentioning: when I said that you can diff the files, that means you can use a tool to compare any changes side-by-side. If you are not familiar with the process, I highly recommend that you look into it. While I tend to use the diff tools built into the tools I use (Visual Studio significantly improved it back in 2013), there are lots of excellent free standalone tools available too (I have heard Beyond Compare is exquisite, but have not tried it myself.)
No matter what issue I'm addressing or where I am in the process, I always make sure the code runs before I stop working on it for the day. As mentioned in the opening, it's often tempting to abandon something when it's not working, but that will introduce additional work when you try to pick it up again: before you can start providing value, you'll first have to clean up the mess you left it in. At a minimum, this wastes time and focus, but if you're working on a personal project it can be disastrous as it increases the motivational barrier to picking the project up again. On a team, it can be equally disastrous if you check the code into your source control (everyone who tries to do work will have to fix your mistake first - often times duplicating each others' efforts). Source control can be very helpful when trying to do this: if I can't figure out why it won't run, I can back up my broken work and then roll back to the version in source control (which should always run).
This seems like a good place to stop this post (I still have a broken project to fix before I can stop for the day). Hopefully these things I've learned to do are interesting or helpful for you.