I finished onboarding on the last day of my second week. I wrote about the onboarding process in my previous post so I won’t dwell on it here, but I do want to add how great it felt to be done. It wasn’t an arduous or painful process, but finishing it meant that I could finally start doing something.
It’s Hard
On the first day of my third week, my scrum master asked if he could throw me into the deep end. I said I didn’t mind the deep end as long as I could ask questions. It turned out that I couldn’t always ask questions.
My objective, on the surface, was simple. There were two components to the system that my team is working on, and I had to get one to talk to the other. How hard could it be? As it turned out, incredibly hard.
Before I continue on this thread, I want to pause for a moment and just meditate on how mind-bogglingly complicated this stuff is. Up until now, the largest code base I’d ever worked with was an open source project with about a hundred files of source code. Given an afternoon of uninterrupted study, I could get a pretty good sense for what all the pieces were and how they fit together. But that will never be the case for me at Insitu. There’s simply not enough time to read through it all, let alone understand it. Instead, I have to be content with understanding tiny snippets and hoping that’s enough to make a contribution.
Back to getting my components talking to one another. This project meant that I got to spend a lot of time in the HiL lab, where we test our code to make sure it performs properly on the aircraft. At first I found it exciting, but by the end of a ten hour day in a room with no windows, listening to the loud hum of the cooling fans and the endless stream of beeps and boops from the hardware itself, I was happy to walk out.
Getting unstuck is a skill that I’ve spent a long time developing. In fact, that’s what most of math, computer science, and writing boil down to.
With this project, though, getting unstuck was really, really hard. There’s no Stack Overflow for the product I’m working on, no YouTube tutorials, no books. All I have are my own problem solving skills and if I’m lucky, those of the other people on my team. But there’s not always someone else there to help. People are in meetings or are out sick, or sometimes they’re simply working on something more important. At one point, one of the senior developers on my project said, “Sorry, no more questions today.”
I’ve spent a good chunk the past couple weeks on my own just trying to reason through the code in front of me. And frankly, it’s a skill I need to develop. When I first started programming I would look up a Project Euler problem and then spend hours or days turning it over in my head until I was confident that I’d arrived at a solution. I forbid myself to look up hints or ask for help. It was just me and the problem.
I need to get back to that mindset. Figure out the pieces and how they fit together. Someone may be able to tell you the answer in a fraction of the time, but that’s not learning. Learning is the messy part, the frustrating part.
There’s a dumb little saying that I repeat to myself a lot: “The hard stuff is hard.”
Like I said, it’s dumb. But it’s also one of the truest things I know.
Go Easy
The hard stuff may be hard, but another lesson I find myself learning over and over is that sometimes I need to go easy on myself.
On several occasions I’ve spent hours banging my head against a problem that I was convinced that I was simply not smart enough to solve. I imagined that as soon as I got one of the senior developers to sit down with me and step through the code, they’d immediately have it all figured out. But it wasn’t so. They may have had a better handle on the code than me, but unless they’d recently written it themselves, they had to step through it one line at a time, just like me. And sometimes they didn’t have time to, and so it was back on me to figure out.
Instead of being frustrated to still be trying to figure out, I find these moments encouraging. They show that there’s no magic, no omniscience. Sometimes you just have to work through the problem.