The coding hole

Help, I’ve fallen into a coding hole and I can’t get out! Okay, to be fair I actually DID get out, but at the time it felt like there was no hope and I would be trapped banging my head against a wall trying to figure out what I was doing. Today I figure we can discuss how I code and what my idea of a coding hole is, it will be a fun break for me.

Every code you write will have a different purpose. No matter what language you use or what that purpose is, you still end up with the same basic structure, at least in the engineering sense. Sure you can write a GUI (graphical user interface) or you can do what I’ve been doing which is write code to process data in particular ways. At the end of the day if coding was literal language, you would just be doing what I’m doing now, writing words in a way that makes sense!

Let’s talk about my specific case first, then I’ll define my coding hole term. I’m writing code that takes a “raw” dataset, data that I haven’t done anything with. The code processes that data in a particular way then arranges the outputs in a way that makes sense for the next step. In my case, the next step is plotting so I need to have things arranged in a very particular way for the function that makes plots to work without throwing a fit. The process of writing the code is a lot like making a map. There are an infinite number of ways to go from start to finish, some are easier, quicker, or less convoluted than others, but sometimes you can’t always see the shortest or best path so you find one that makes sense for you.

That’s how I like to code. Before I write a single line, I plan my steps. Lately my code has followed this type of flow: import the data I need (because I start in the folder I have the data in), first I check to make sure I can actually find the data, if not I change folders and back up 1 folder (a common mistake I make because I’ll save data to a new folder and sometimes forget I’m working in that folder and not the one before it) so something like \data\savefolder so the code will look and if I am in the save folder instead of the data folder it will back up and look in \data. Next I make sure I have the save folder, if not the code will generate it for me and set that as the save path. Then I import my data and I’m ready to do the rest.

That’s right, I have done nothing and I’ve already got a lot of code just to make sure I’ve got the prep work done prior to the actual code running. This is important because I can batch generate plots, but if I put them in the wrong folder, it can make a mess for my organization, so I take steps to make sure that doesn’t happen.

Next I write the bit that does the thing I want. This is the tricky part because sometimes arranging things into different formats can be non-intuitive. For example, my current code has 8 trials each made up of a 3-dimensional matrix. I needed to average all those trials, so I create a dummy variable in the command line to test how to do this before I cement it in my code. Most of the time my dummy variables will be called tst. It’s quick to type and I can number them tst1, tst2, …, tstN. The solution I came up with was to take all 8 trials, make a 4-dimensional matrix and average across the fourth dimension. Then I write it into my code.

Unfortunately solutions aren’t always straightforward. That’s when I fall into a coding hole. To go from one step to the next I might need to average, reshape the matrix, perform some sort of operation on the matrix, reshape it again, then get an output for the next step. When I have a million tiny steps like this, it’s hard to keep track of it all and I fall into a coding hole. Basically I’ve come up with a solution, but there’s so many intermediate steps to get to the end product there seems to be no way out.

Thankfully I took a moment and took a step back to make a list of the steps I needed, tested those steps, and then got myself out of that coding hole. The tricky part is that coding holes are sneaky, you don’t realize you’re in one until you can’t get out. I’ve written a lot of code for this project and I mean A LOT! As in > 10,000 lines of code over a handful of scripts so that I can go from Raw EEG data to something that I can plot and looks good. This last script I’m writing is going to be LONG, it’s already at ~1000 lines and I’ve only written a tiny fraction of what it needs to do. It may be the longest piece of code I’ve written when it’s done and I’ve written some long code.

There’s been a lot of work put into this project and I will still have a lot left to do after the presentations (due tomorrow and friday!), namely publish the findings, but I’ll be thankful when the next few days are over and I don’t have to focus on this project so exclusively.

Speaking of which, I still have the rest of that code to write… back to work I go!