A Software Apprentice’s Retrospective on her Mentor

In April I began my apprenticeship with Def Method (formerly known as Cyrus Innovation) software consultancy. For the past four months, I’ve been working under the guidance of a senior developer, Mark, at one of Def Method’s clients, a major real estate firm in NYC. Mark had never had an apprentice before me, but you’d never have known it.

As I think back on both the overarching trajectory and the daily experiences of my apprenticeship, it feels as if it must have been carefully crafted and adjusted based on the outcomes and feedback of many apprentices before me. When, in actuality, I think my apprenticeship could probably be described as the result of a talented, passionate senior developer being informed one day — likely with little notice — that he’d be receiving an apprentice and having to figure out what to do with her. Luckily for me, Mark approaches every aspect of his work with reflectiveness and dedication, and, it turns out, is a natural teacher.

While I’m continuing on with our real estate firm client for a bit longer, Mark’s last day on the project is today; next week he moves on to another client that needs a strong senior developer. And so today seems like a good day to write a list of some of the things that Mark has done as a mentor for which I’m most grateful.

Maybe this post will be an interesting read for any mentors or mentors-to-be out there who’d like an apprentice’s take on how to structure a simultaneously rigorous and supportive apprenticeship experience. Or maybe it’ll give some apprentice hopefuls an idea of what a software apprenticeship — at its very best, in my opinion — might be like. Mostly, though, I envision this post as detailed retrospective feedback for my mentor. Mark, I hope that you have many more apprentices. And I hope that you continue to do these things with them, because they worked.

So here’s my list of top mentor techniques:

1.) At the beginning, pair program with them all of the time.

And I really mean all of the time. On my first day, Mark set up a chair and a key board and mouse for me at his desk. During my first four weeks of work, aside from a few hours of weekly consulting meetings that I wasn’t privy to, all of Mark’s development time was spent pairing with me. As overwhelming as it was to try to wrap my head around an enterprise software project for the first time, it was overwhelming in a measured, encouraging way. I quickly became immersed in one section of the code base that gradually opened doors to other pieces. I developed a careful routine of development and a thorough understanding of portions of the code and our general approach to them. These weeks spent solely pairing were indispensable for setting me up to be successful when working on my own and with other junior developers in later months.

2.) Ask them questions and give them tasks just outside of their knowledge base.

When you know that at any moment your mentor might ask for your opinion about how to write a piece of code or what to do next, you’re fully engaged and trying to figure out what’s coming next at every step, even if you’re not the one doing the typing. Mark had high expectations for me; he expected me to have opinions and to be actively working to understand the reasoning for the ways in which we wrote each line of code. But he didn’t expect me to always be right, and he never made me feel bad for being wrong. And because of this, I felt encouraged to constantly ask questions and contribute ideas, even if I wasn’t sure about them.

3.) Let them struggle, but not for too long.

After the first month or so of my apprenticeship, I began to work on small stories by myself or with other developers. Often I’d feel nervous when Mark would suggest that I take a card that I didn’t already know exactly how I would complete. However, he made sure that I always had enough information to get started, and the process of problem solving such cards taught me a lot about figuring out other people’s code and gave me an opportunity to apply what I’d learned in making decisions about the best way to implement something. And I never went more than half a day without Mark checking in to make sure I was on the right track.

4.) Let them watch you struggle.

(Okay, “struggle” is an overstatement here. But the literature major in me liked the symmetry with number 3. )

Sometimes Mark would apologize for “dragging me along”, or thank me for being a good sport while we experimented or researched challenges that came up with which he wasn’t immediately familiar. However, I learned a great deal from watching him problem solve by experimenting and looking things up — reading through documentation, wading through source code, and glancing through online discussion forums. It was encouraging to realize that even experts have to search for answers sometimes, and those moments were lessons in how to do it well. I also learned about the necessity of triaging time when determining how deeply to pursue the most ideal means of accomplishing something and getting the thing completed.

5.) Let them choose their tools, and make them learn those tools well.

Mark uses Emacs. Sometimes he says funny, sarcastic things about editors other than Emacs. But he never told me that I ought to use Emacs. What he did say (over and over again) was that I should learn my tools well. A few times he tasked me to learn how to do specific things (like lint Typescript files) in my editor. When I started learning Vim, he encouraged me and spent part of lunch one day giving me tips about Vim. Whatever codebase or project I work on next, one skill that will undoubtedly transfer over is my greater familiarity with my text editor.

6.) Review all of their code.

Mark has reviewed every single line of code I’ve written that’s gone into production. He’s watched me actually type the majority of them, and then watched me re-type them after we’ve discussed how they could be better. It seems unnecessary to explain the benefit of this to my learning. What is perhaps less obvious, though, is the impact that knowing Mark will review every line of code I write has had on the way I’m able to approach development work on my own or pairing with other junior engineers. For one, I/we have to write quality code because I know that Mark is going to see it. There’s no way he’ll let us/me get away with prompting the window to do a refresh in order to update the data in the UI, or with having three functions that are nearly identical. Secondly, knowing that Mark will review all of my code gives me confidence to try experimenting and tackling problems that I’m not quite sure about. I can try my best, make a list of questions and concerns, and then we figure out the best way to implement it together.

7.) Be on their side.

Yeah, yeah, I know this one sounds corny. But I really think it’s true. Throughout my apprenticeship, not only did I feel that Mark valued my development as a software engineer but also that we were working as a team and he felt responsible for the code that I produced too. If I made a mistake, he always pointed it out, but he never did this in a way that felt alienating or chastising, rather in a way that felt like we were working as a team to do the best possible work. Even the time when I broke the build because somehow I’d managed to merge code into master without seeing that my tests were failing (the new functionality was correct, but the tests still had assumptions based on the old code that caused them to fail), Mark apologized to the developer who noticed and patched the broken build, saying that he was sorry that we’d checked it in and hadn’t noticed. I felt keenly aware that it was me, not us, who’d made the mistake — despite careful training to always run the tests before merging and watch to see that the build passed — but Mark didn’t blame me, even when I deserved it. I learned from that mistake; I haven’t broken the build since. I also learned how it feels to be part of a team that doesn’t point fingers but takes collective responsibility for the code.

One of my college professors once told me, “you have a tendency toward wordiness.” Even now that I’m a software developer, striving for concise, clean code, that still seems to be true of my writing. There are certainly more things that I could say about my mentor and my apprenticeship. I’ve narrowed it down to the top seven. Thanks for these and all the others, Mark.