For three years, I was one of the more junior developers in the Presence office. Whenever I had any questions, I had direct access to the minds of brilliant, more experienced teammates. But this past June, I was challenged with graduating from my role as a mentee to mentor CODE2040 Fellow Scott Paillant, a bright-eyed computer science student from Brooklyn, NY, who would be interning with Presence for the summer.

With this shift in roles, I felt a sudden weighty responsibility to represent the decisions a “good” software engineer should make. During my pairing sessions with Scott, I emphasized best practices I’d learned over the years, sent him countless articles and tutorials on popular frameworks, and helped him download our tools and navigate our JIRA board.

But as Scott’s time with Presence nears a bittersweet end, I realize most of what we taught Scott were things he could have gleaned just as easily from other disciplined development teams. As much as I believe that Presence engineers are uniquely driven and meticulous, that we are constantly striving to diversify our proverbial toolboxes and hold ourselves to the highest standard, I also know that much of what we practice and preach is widely documented. Thousands of books have been written on tech consulting, writing clean code, and architecting robust applications.

Scott, on the other hand, gave us a perspective we hadn’t been able to get from our research or even each other. While he came in with less technical experience, he had enough distance from the 9 to 5 of an engineering job to have that coveted beginner’s mind. He forced me to question what I had long accepted as standard, and to see my processes with fresh and critical eyes.

When exploring unfamiliar code, don’t miss the forest for the trees. When ramping up on a new project, I often find myself reading code line by line to get up to speed. I feel the most “productive” when I meticulously comb my way through a codebase in this fashion, understanding each file from top to bottom before moving on.

But the truth is, we do not always have the luxury to spend this much time ramping up on unfamiliar code. We all work with project managers and clients with shifting priorities, or tight deadlines, or more often both.

Scott’s tactic of approaching a new project worked especially well in Presence’s consulting environment. Whether out of personal preference or necessity, Scott avoided the upfront cognitive overload of looking up every bit of code that confused him. He made it his priority to first articulate on a conceptual level what the entire app was supposed to do. Only after he was able to do so did he dive into the app’s incrementally smaller parts — its directories, then subdirectories, then individual files — to map out the codebase’s moving parts and how they related to each other. By the time he finally dove into the code line by line, he’d had enough of a high-level understanding about the “forest” to figure out where exactly he should start rooting out bugs or adding his own “trees”.

Being comfortable with not knowing everything upfront, and striving for breadth of understanding before depth, helped Scott gain immediate insight into a new project’s inner workings. His bird’s-eye view of how the cogs of an app worked together not only gave him a good conceptual start, but it also later informed his technical decisions.

Articulate issues in a “human” way before finding a technical solution. Code isn’t so much about modules and callbacks as it is about roles and relationships. Often, when hacking through the weeds in hot pursuit of a bug, I would lose sight of what exactly I was trying to accomplish. My field of vision would often narrow down to a line-by-line level — “this function has to return an object, not a string”, or “this variable needs to get passed in here, not there”. Oftentimes, when Scott paired with me and forced me to articulate what exactly I was trying to do (“I’m trying to get this graph to display the same number of lines that the data says it should!”), I was able to step back and more clearly strategize my solution.

Scott made sure he understood the core of an issue before engaging in any sort of conversation to approach a technical solution. It was only after he fully grasped what was wrong, and what a feasible solution could look like, that he would engage in the semantics of the code needed to implement it.

Ask questions that take your unique experience and knowledge into account. Scott’s experience before joining us lay mostly with Java and PHP, while most of our work this summer has been in full-stack JavaScript (i.e. Angular, React, and Node). When confused about a certain concept, Scott worked his way up the learning curve by constantly drawing parallels between what we were working on and what he had done in the past. He compared, say, how Node fetches data to how Java also requests information from a database. He explained Jade to himself as another flavor of PHP templates.

Because his questions were always angled to best benefit his particular experiences, Scott was able to significantly accelerate his learning. Instead of learning everything from scratch, he leveraged his existing foundation of technical knowledge to quickly become a more well-rounded developer.

Consulting and programming are social arts. Although Scott came in knowing basic JavaScript, a huge part of his value to our team wasn’t just his coding skills. Because he would pair with multiple developers over the course of a day, he would often translate an issue that came up for one developer into more “human” terms for another developer. In this way, the two developers would be able to collaborate and find a solution together. Scott’s ability to translate technical conversations into conceptual ones and keep conversations as high-level as possible made him a great mediator among our teammates.

Scott is also almost inhumanly enthusiastic and optimistic. His ego is anything but fragile, so he jumps into pairing sessions with an open mind, thoughtful questions, and brave suggestions. If I even so much as make a casual comment about being frustrated by a bug, he rushes to my side, reassures me again and again that I am an ‘AMAZING developer’, and enthusiastically jumps in with me. Coding with Scott always feels more like play than work, and it makes a huge difference at the end of an 8-hour day.

Confidence in your abilities is a choice. Every day, I am amazed by how confident Scott is as a junior developer. Contrary to my and many of my engineer friends’ own experiences combatting imposter syndrome as junior developers, Scott simply does not seem to be afflicted at all by this disease that plagues so many people in our field.

In fact, I recently asked Scott if he simply was better at hiding his misgivings about his abilities. In true Scott fashion, he brightly said he didn’t feel at all insecure about or intimidated by what he did not know. He offered no further explanation, no ‘if’s or ‘but’s. Judging by his lack of hesitation, I believed him.

This is not to say that Scott knows everything, or even acts like he does. He is the first to admit that he has a great deal to learn. But for Scott, the gaps in his knowledge don’t feel so much like reasons for misgiving as opportunities for him to be an even better developer. He relishes the challenge of the unknown and jumps into unfamiliar territory with all the gusto that I exhibit when jumping into something I know like the back of my hand.

Scott reintroduced to me the fact that coding is the most effective when you spend more time articulating concepts rather than cranking out functions. He reminded me that coding is the most enjoyable when you approach it as a social art; it is the most gratifying when you forgive yourself for not knowing all the answers. His beginner’s mind showed me that as “advanced” as I’d become, there were quite a few “beginner” things that I needed to revisit to recapture what had made me want to become a developer in the first place.

Everyone here at Presence will miss Scott terribly. Aside from all that he taught me, I will miss his sunny “Good morning!”s and the feel-good Top 40 songs he added to our office playlist. We wish him all the luck in the world in his future endeavors, even though we know he won’t need it.