What the heck are you talking about Eck?
Earlier this week I built a standing desk using an extra desktop I had laying around. I was doing some related searches online and this video came up about the importance of "Squaring up" your carpentry.
https://www.youtube.com/watch?v=WhdcyMxwTBM&t=83s
The linked chapter is only about a minute long, but I'll summarize it for you here. When you build complex objects, it gets done in a compounding sequence. A flaw introduced early in the process gets amplified throughout your project. If you start out with a simple box, you might be able to sand down the edges to make it look mostly square. But as you sit it next to other boxes or stack them on top of each other, the tiny flaws become major eye-sores.
The same thing can be said about software. If you have a system that's mostly working, or only a little bit hacky - that might be completely tolerable in the early days of development. You'll cruise along and deal with the small amount of pain to stay productive. But as the project grows in scale and complexity, more of those small hacks start interacting with each other - magnifying the pain points to unbearable levels. Delivering new features or even fixing the existing ones becomes a herculean task.
How to avoid this?
When I'm working on some new feature, the first thing I do is sketch my ideas out on paper or a whiteboard. After I've thought about it for a bit, I might bring in another developer to bounce ideas off of. Then I'll start coding up a solution. As I'm working in the code, I discover more bits about the problem I had no idea about. Once the code is working, you might be tempted to move on to the next feature. DON'T!
Now that you have a more complete understanding of the problem, go back to the drawing board. Look at your original design and fix the parts that are wrong. In general, go back to the fundamentals: complexity is the enemy, don't repeat yourself, give things a single-responsibility, use design patterns, etc. Write some comments or external documentation about the trickier parts of the design. Then code the thing properly.
Build some time in the schedule to revisit and refactor your code. Pay off some of that technical debt or it'll weigh you down like a boat anchor. "But Eck... There's just not enough time!" you tell me. To that, I say there almost always is. I mean... if you have to get this thing shipped by Friday or the whole company shuts down... sure. But if that's true, why are you here reading my dev journal? Get back to work! :)
For long-term projects, this time you spend is an investment that will pay will pay for itself in no time. So take some time and Square up your Software.
Save Game Update
I've been having a lot of fun coding on my Save Game system this week. I got the basics working in unit tests, and started getting it wired up properly into a game scene. I can now serialize/deserialize regular data and Unity GameObjects, but there's more complex things I'll need to support: Message Subscriptions, State Machines, Callbacks, Prefab Instantiation, etc. I'll write up a post dedicated to the Save Game system once I get the code to a decent spot. Expect one in a week or two.
Tips from your Uncle Eck
- Think about it. Make it work. Make it right. Make it fast. - My general process.
- Make sure your system is easy to debug. - You spend more time debugging problems than writing code, so this should be your top priority.
I started streaming my programming efforts here: https://www.twitch.tv/eck314 If you're interested in what I'm working on, have questions, or just want to talk about programming, I encourage you to join the stream. Right now I'm shooting for weekdays 10am-2pm Eastern.
