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.
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.
Before you do anything, write down a game plan
You may think to yourself that you know exactly how to do something, but just, “can’t put it into words.” You expect to open your editor, start coding, and have the perfect solution flow out of you like some beautiful piece of music. This lovely idea is a lie. Your brain is lying to you. And listening to it will bite you in the ass nine times out of ten.
Write it down. No matter how simple the feature seems. What is your approach? What components do you need? How are you going to organize your code? What is the flow of data going to look like? What are some of the main edge cases, and how are you going to make sure they are covered?
Share your game plan with your team
I don’t think it matters how senior of a developer you are, this is always a good idea. I work with some VERY smart people, much smarter than me, and yet they still share with the team how they plan to approach a problem, and open up the floor for comments and critique.
Your game plan might be solid, but having a few more eyes to comb over the fine print, to ask you questions, forcing you to explain why you decided what you did, gives you a much greater understanding of the problem at hand. And often, someone will notice something you forgot, or have a small suggestion that is an improvement on your original plan.
I’ve seen great results come out of team discussions, and I’ve found we do our best work when we collaborate and discuss how we want to solve a problem as a team.
Opening it up to the team gives you a chance to round out your approach before you even write a single line of code. It’s like preemptive code review. And if everyone knows how you plan to solve a problem, there are way fewer surprises down the line, when you’ve already done all the heavy lifting.
Don’t try to do it all at once
When I work on a feature, as a Front End Developer, I usually have to worry about two things: How it looks, and how it behaves. I never want to have to think too hard about the “how it looks” side of things until after I’ve perfected the “how it behaves” side.
I have had the best success when I have absolutely nailed the behaviour first, and held off on addressing the appearance/styling until after everything is moving like a well-oiled machine. Then, the appearance part is usually a piece of cake, and it feels good to leave the easy part for last and see your beautiful creation come to life design-wise.
Always be testin’
There is no such thing as having too many tests. I can’t tell you the number of times a well placed test has saved my butt. And I also can’t tell you the number of times we’ve been MISSING a test we should have had, and dealt with bugs that we really could have avoided if we’d only had a test in the first place. (bonus hint: When this happens, don’t just fix the bug and move on. Write the test that was missing so it never happens again.)
I had a Java teacher in school who was a big proponent of the, “write tests first, write actual functionality second,” practice. I think this is cool. I’m going to admit that I have never done this since graduating from his class. But maybe I should. At any rate, write some freaking tests, either before or after, because they will save your life one day.
Don’t be afraid to ask for help at any point in the process
You don’t want to lean on someone else to solve your problems for you, but there’s also no point in messing something up just because you didn’t want to burden someone else with your troubles. As long as you’ve given something some serious thought, it’s OK to ask for help. We all do it :)
Enjoy yourself!
The struggle is part of what makes development fun! Don’t get down on yourself when things don’t go how you want, but embrace it as a learning experience and promise yourself to do better next time. And maybe next time will also put you through the wringer and you’ll curse the day you decided to become a programmer. Chin up, keep trying. You’ll get there!
And here’s a secret: Everybody makes mistakes, even the best in the business. You get better, but you’ll never be perfect. And that’s OK. If you had no more room to grow, things would get pretty boring.
Most developers, at some point, make the mistake of thinking about their work as a black art, where some magical combination of natural aptitude and hard work are all that’s required. I really don’t believe that’s the case. We do our best work when we plan things carefully as a team, mapping out behaviour and requirements well ahead of touching even a single line of code. Nothing is private, and nothing is spontaneous. Once you have a solid plan, writing the code for it is easy.
