Drowning in Code

How teamwork and proper planning can save you from making terrible decisions

There is a nasty trap I see inexperienced developers fall into, and it’s something I recognize immediately because I’ve been through it myself.

It goes something like this:

You are assigned to write some code for a new a feature. Or, if your boss is a good boss and organizes feature development into small independent chunks, you’re assigned a piece of a feature.

You strike out on your coding adventure with great intentions, and you’re excited that it’ll be your finest work yet. Fingers fly across the keyboard, and in the beginning, things are feeling great.

The chaos starts off innocuously enough, so subtle you may not even recognize it for the monster it will soon become. You might notice one tiny little bug that can’t be solved in any elegant way, so you squash it with a piece of hacky code (“It’s not a big deal to quickly monkey-patch this ONE thing,” you tell yourself, trying to smother a faint sense of unease). Your confidence begins to flag even more as you realize that you also need to do it somewhere else (“shit”).

…But the real sign that things have gone south is when there’s this requirement that REALLY doesn’t fit in very well with the architecture of how you’ve set things up, but you’ll be damned if you’re redoing all your hard work, so you try to bolt the functionality on.

Before you know it, things are snowballing out of control and you’re adding little hack-y fixes for all these pieces here and there and everywhere and your masterpiece is ruined and you have no idea how to fix it or where you went wrong. You do your best to clean it up, but ultimately you feel a nagging sensation that this could have been so much simpler; that you overcomplicated it somehow.

Usually, at PR review time you’re swamped with comments and spend a week doing revisions that you know you could have avoided.

Good ‘ole xkcd has a comic for every occasion: https://xkcd.com/1513/

I have been there. A lot. More than I’d like to admit. As I’ve grown as a developer, these horror stories have faded away (mostly!), but every time I start a new project, I’m always painfully aware of the potential for something to go sideways. And when I see it happen to someone else, a pool of anxiety fills my stomach as if it were happening to me all over again.

Part of this is caused by a bad management decision. Not your fault. Your team lead should give you work that you can handle, and provide you with the right amount of guidance to make sure you don’t mess up too badly, but also enough leeway that you are able to think for yourself and learn and grow. They should be breaking larger projects up into logical chunks to be shared amongst the team to help avoid any mammoth undertakings.

BUT! Sometimes a team lead doesn’t quite get it right. These things happen. Or maybe you’re an independent contractor and you don’t have someone looking out for you.

So how to avoid these death spirals? If there’s a magical perfect solution, I’d love to know about it. But I do have a few tips that I’ve found to be helpful for my own workflow.

If you did any post secondary education in a computer science-y field, I’m betting you have have heard some of this advice before. Or maybe you’ve read it in other articles. But if you’re anything like me, you probably need to hear it again. So hold on to your butts. I am going to bestow such wisdom upon you.