I was chatting with my good friend, Chris, recently. He had asked for my advice and help. He wanted to brush up on and add to his programming skills. I recommended a language to consider, a couple of books that have helped me gain a working fluency with it, and a newsletter on the same. We scheduled a time for a video chat where he had many excellent questions from his reading so far. Our chat brought up some unexpected memories that yielded a fresh insight and reminded me of an old one. There are things about being a manager I hadn't realized I missed. Helping my friend approach a professional transition reminded me of some helpful thoughts from my last move from management back to contributor.
We were winding up our chat when he described his goal this way: to become the developer he always wanted to be. I loved that way of putting it--I got it, instantly, deep in my gut. I have experienced that feeling frequently, especially with my most recent return to a contributor role.
His sentiment reminded me of how I try to start a new coaching relationship. One of the first things I tell someone I have agreed to coach or mentor is that I see my job as, "helping you become the you-est you that you can be." I know it sounds corny but I feel that I am allowed as a parent with adult children. I have been validated more than once to hear one of my long time mentees adopt this very same sentiment once they in turn start to coach or mentor. Corniness aside, I think it captures something positive and helpful about the tension developers often feel between where their skills and experiences are now and where they feel they could be.
His words landed viscerally with me because I am still a developer despite taking a few turns over the years as a manager. I recently returned to a contributor role and immediately started feeling this tension again, like so many times before. There are many topics and skills I have always wanted to be better at. As often as not I chose not to do anything about them. Even the skills I do use regularly require active maintenance. Good practices evolve based on what we learn through building, launching, and maintaining projects. Changes in practices place new strain on what once were good tools. Stress fractures lead to rapid evolution and re-invention, hiking the learning curve up even higher. Life as a developer is knowing there are always more reasons not to stop and skill up despite knowing a career in the profession of software development requires it.
Even with the reminder of one of the greater challenges of job, at the end of the conversation I felt energized and content. I had spent three-quarters of an hour actively listening and sharing my thoughts and experiences in a way that I haven't in a while. Up until a couple of years ago, I used to mentor or coach more than the two I do n ow, on average around seven or eight. Part of me welcomed the decrease when I moved from a large organization to early stage start up. Helping my friend, I realized I missed something about helping so many people every week. My own reading and learning was at a much higher volume and pace back then. I used to read and think about a wider variety of technical and professional topics. Most of my help is in the form of technical mentorship these days. I enjoy that but hadn't realized how much I missed talking about the rest, the social and collaborative aspects of how we built software as people and teams.
I am still thinking about what I will do with that realization. I will continue to help my friend, of course, in any way he would like and finds useful. I am exploring facilitating a book club with collaborative coding exercises. I have enjoyed the format, as a participant and a leader, several times in recent years. The most recent time I led one, I really enjoyed how teaching challenged my own understanding of the subject. Coming up with weekly exercises connected to our daily work was regularly a challenge but very rewarding.
Chris's career has followed a similar general arc over the years, moving back and forth between manager and individual contributor. I had the benefit of about a year and a half of experience from making my most recent switch back to full time developer. I felt a lot of empathy for my friend. The change back to contributor can be daunting but also an opportunity. Thinking about the opportunity helped me with my own recent move back, more so than any previous time. I hoped sharing my insight could translate into some enthusiasm he could borrow. He did seem to be warming up to it, especially when I shared some code examples. We explored the connection between some new concepts he'd encountered in the books I recommended and what they looked like in practice.
There is an added tension when skilling up, wanting to be able to do something useful as soon as possible. Giving into that tension risks missing an opportunity that is easy to overlook. I call this frustration-driven programming. How many times will you manually enter that command, risking getting it wrong, or scroll back through your command history endlessly to use the version you know works before you consider doing something about it like writing a command alias or even a script? Last year, I decided to examine how I have resolved this tension in the past. Mostly, I was unsatisfied with my past choices. I wanted to be a better developer, and these had all been chances for that.
I started considering automation every third time I had to repeat an error-prone task, instead of endlessly putting it off. I undertook overdue upgrades and worked on forming a weekly habit of keeping my systems more up to date. Not only that, but I found and learned replacements for tools and plugins that were no longer maintained or actively deprecated. I was lucky enough to cement a few early wins that encouraged me to keep going. I figured out each improvement as I went, I did not have or create a big plan up front. When working on a project or task, I chose to take additional team as needed.
That decision, that moment of calculating whether an annoyance was worth addressing or living with, is what shifted for me. I felt less complacent, more empowered, simply by choosing to at least acknowledge a frustration. More often than not, I chose to act, encouraged by each improvement to my work on my computers, both personal and professional. I also felt like I was learning more, not only about the immediate problem I was trying to solve. By investing more time, more regularly, I was finally understanding concepts that had been nagging me as gaps in my knowledge for years.
Choosing to act on a frustration generalizes to another concept I often use in mentoring. I eventually tell each of my mentees about the mirror polisher. I no longer remember where I picked up this metaphor but the idea is that in order to produce a mirror from bronze, you have to polish the surface. A lot. There are no shortcuts, the finish is only achieved through all of the accumulated work. Like becoming the developer we want to be is the accumulation of each choice we make, no matter how small. Do we channel frustration into a solution? Pursue a head scratching bug further into a better understanding of a tool, technique or concept?
I find this view helps overcome the inertia and anxiety that can arise when thinking about a large or vague goal. Like the ones we often think about when considering a career path. Journey of a thousand steps beginning with the first one and all that. Except for me I try to recognize each step and invest intention a little bit at a time. The bigger picture view is still necessary and somehow more approachable with a stream a incremental accomplishments in hand. We spend so much more time with every step along the way, there is a certain symmetry to investing more there and hence needing a bit less when stepping back.
I learned another lesson polishing the mirror teaches recently, one that relates to Chris's and my career arcs bending between contributor and manager. The feeling of regularly needing to learn and re-learn is also like a mirror. You cannot clean a mirror so well that it never needs cleaning again. Even if Chris or I were to stay with coding, we'd never be done learning. I've gotten frustrated with that in the past but now have inverted my perspective. Rather than being a tireless effort required to stay in my career, I have an open ended opportunity to embrace the fun I have learning. Rather than dwelling on the effort, I try to find ways to lean into the joy where I can.