Code Detectives

You’re sitting at home and realize the worlds gone black and white.  Maybe there’s a cat prowling around the room, knocking over old case files, or a half empty bottle of cheap whiskey you didn’t finish from the night before. But they’re all distractions now. There’s a bug to be caught, or a branch of a project that needs refactored or hell, you just want to get your hand dirty. In any case, you’re about to start looking at someone else’s code.

But don’t worry, you’re a code detective and all the tools you need are at your fingertips.

Still, that knowledge didn’t feel particularly comforting when I started working with some slackers on our latest project: creating a new working path out of a pre-existing branch of a react-native-web project. So here’s a broad overview of what my approach to this project has been:

1. Ask Questions:
   1. What’s my goal?
   2. How does the current code reflect those goals? i.e. What do I need to change or keep?
   3. If it’s a large scale application, then which files are relevant? Which can I ignore?
2. Use Development Tools:
   1. The first thing I do with a web application I’m taking a stab at for the first time is watch the network calls while I go through the motions. Once I see the calls that are being made I can go back to the code and search for where the calls take place in the code and travel them like a tour map.
   2. But network activity typically isn’t enough. I console.log code to near obsession. It helps me understand the timeline of when things are happening in the code, and also gives me a more visual representation of the product.
3. Check for plugins that can help.
   1. I’m making a lot of use of the React Developer Tools plugin for this project. It feels a bit unwieldy at times, but it’s such a benefit to be able to see which parent to child relationship of components is, and what renders as a result of what. This has taken me far in tracking down the files I really need to edit and what information they are privy to.
4. Use your co-detectives!
   1. I’m so often working on my own I forget how important it is get feedback from other people. Just because you can normally solve a problem, doesn’t mean you’re going to solve it the best way possible, or in a timely manner. Open up and ask questions. If you don’t have a question about what you’re working on, ask your partner to explain their code to you. Who knows, maybe you’ll help them out and maybe you’ll find out something about your own code at the same time.

Those are the most important tools I find I have at my disposal, but this is by no means an exhaustive list. If you have your own means to deciphering someone else’s code, leave a comment below, I’m always looking for new ways to solve code!

A New Project

A fellow hacker on a slack group I’m a part of approached us with a mysterious mission on a Friday evening: Build a react-native-web application over the weekend and deliver to production by sometime early the next week. Luckily none of this went as planned because I didn’t see the message until the following Monday.

And honestly I wasn’t sure I wanted to be a part of it. I had a new routine in place that I wanted to adhere to, with my own work to do and studying. I didn’t think I had time for it. But then Nick linked to the website we’d be building on top of (https://liquid.vote/) and I found it genuinely intriguing. Our work was to replicate a San Francisco branch into a Berkeley (and transmuted later into New York City) branch. Pre-existing code, tweak a few things here and there. No problem. Nothing could be easier.

Well, humility was just the first of many lessons I was to learn starting on day one.

Day One

The first hurdle for me was information. I’m a details guy. I want to know what we’re doing and why and who wants it and who’s even going to see it, and it took a bit of vague answers for me to just take a breath and decide the work was more important than the why for now. So I focused on deciphering what the work was.

This was not easy because as soon as we started up with the project we found that there was an error communicating with the API responsible for our data. A quick aside: the crux of our project is a method of delivering the ability to vote on issues to consumers (in this particular case a board of supervisors or city council) in the easiest, most straight forward way possible. This mean accessing data like the dates of council meetings and the names of bills and their id’s. The API is integral for any of it to work. And it was down.

We spent a while trying to decipher it. We broached the dreaded topic of CORS and turned off the security in our browsers to allow ourselves access to the data. This worked until it didn’t. We started seeing responses in our network calls, but the data was coming back incorrectly.

I found myself frustrated. It was day one and already progress was stifled by an error that was out of our hands. I was so used to working on my own that I didn’t really know how to approach a next step. Thankfully, Nick is a good project manager and we found ourselves starting to dive into the code just to get our bearings straight even if we couldn’t do a lot of testing our ideas at the moment.

And then, by the end of the day, the API had been fixed, and day two promised the potential of a lot of work.