The First Days
The first commute, yesterday, went less than smooth, though I only really have myself to blame. Californian public transport, though surprisingly ubiquitous, is very confusing! Unlike the UK where even if we do have many private companies running the rail, we still essentially have one rail system. In Cali there are multiple fairly disjoint train networks, each with their own nuances and designs. The CalTrain’s nuance is that every train stops at seemingly random stations, and has its own unique number. And to avoid dragging on, that your honour, is why I got off an hours walk from work instead of 10 minutes, and my boss had to come collect me in his Tesla Model S (every cloud has its silver lining!)
There’s an amusing condition sometimes encountered by visitors to Paris, who on arrival are overwhelmed by the disparity between the popular image of the place, and the reality, appropriately named Paris syndrome. Last night while reviewing my first day, I feared I might be suffering from a similar condition, one you might name “Valley syndrome”, but I’m relieved to report a day later that my fears were unjustified. Today, though bumpy, ended well, and is a story worth telling so here it is…
This morning I set about my first true task, my first opportunity to add value to Caring. This was the moment I’d been waiting for for months. The only problem? I couldn’t do it. I must have spent the best part of 5 hours studying the problem, switching between files and editors, and I just didn’t know where to begin! And worse, once in that negative state of mind, you quickly lose all sense of perspective. Logic says you should be going “it’s one feature, one thing you aren’t getting, it’s really not a problem” but instead just blows things out of proportion. By lunchtime I found myself rolling preposterous thoughts around in my mind to the tune of “am I going to get fired for being incompetent?!”.
The Turnaround
Over lunch I made my lack of progress evident to another member of the engineering team, and that’s when the situation started to improve.
In software engineering we have a thing called pair programming, pair programming for the uninitiated, is simply the act of two people working on the same bit of code together, generally with only one at the keyboard at a time, and the other observing. The result is not only better code, but also an opportunity for each of the pair to assimilate the others knowledge and techniques, while remaining productive.
So hearing my plight, said co-worker suggested we head to a conference remove and pair for a bit, at least until the problem looked less insurmountable to me. It wasn’t long at all before, bit by bit (if you’ll excuse the pun), an opaque system became a lot more transparent, and I could continue my day alone.
Pairing is a valuable technique in many situations and certainly saved my ass today, but what I find most interesting about it is that I can’t think of an equivalent in another field. Let me be clear, pairing is not tutoring, while my pairing session today was undoubtedly one sided, we both learned something, I hope. In other trades you have ‘shadowing’, but that’s a decidedly one way affair. There’s regular team work, but pairing is more intimate than that, not quite Ghost intimate but not far off! You’re learning from one another, not just how to operate well as a unit, but to take away that knowledge gained and better yourself as an individual with it.