Causal Loop
Causal Loop
The interesting paradox that experience creates
Imagine you get the chance to coach yourself back in time. What would you tell yourself? Would you give yourself all the answers, or would you teach yourself the value in learning the lessons?
We are all different in our abilities to learn. For some of us, it takes just a reference and we can pick up concepts, whereas for others, it might require hours of reading. And for many of us, we are impatient and want to be given the easy button. And it’s that easy-button type of learning that often causes problems. Imagine if you could coach the younger version of yourself. Would you tell yourself which technology to use or maybe suggest a particular language or framework? Or would you teach yourself the values of languages, tools, and practices?
An example of a causal loop is this: Imagine you’re twenty years into your career as a developer and you’ve learned a lot. Thinking back on your past, you recognize a time in which you could have used some coaching. If you were to travel back in time and give yourself that coaching, it’s possible that would change your trajectory and in the future you might not have learned the right lesson (easy button). Your future self may have breezed through the problem, removing the need to go back in time to coach anything. It begs the question: What is more important, learning the lessons, or being given the answers?
When I asked Brian if he could make a phone call to anyone back in time, who would it be? He had a personal answer. He said, “I’d call myself”.
Okay, well if we're gonna engage in a theoretical paradox, then I would call myself. And I would tell them literally everything. And I do not know how bad that would fuck up the multiverse or whatever. It's probably impossible this could happen, anyway. And I would definitely give myself a heads up about the time I broke my leg. That sucked.
We both chuckled, and I realized we shared the same humor. If given the chance to go back in time and help himself, Brian definitely wanted to warn himself about the time he broke his leg! Not lottery numbers or any grand invention to make millions. Just don’t break your leg!
Everyone thinks immediately like the lottery, you know, sports team betting, something like that. I would probably do that too, but the first thing I would tell myself is “Gonna break your leg. It's gonna suck.”
This idea struck me, and it showed Brian’s thinking for coaching. The sentiment I took was that the important part of coaching is to make things easier to navigate, and not make things perfect or even helpful. And especially don’t give advice with the soup du jour answers, because things change. He repeated this idea frequently, and he usually juxtaposes the idea against technology trends and how most times, we should solve fresh problems with old ideas. It was the framing that I enjoyed. He quips again about breaking his leg,
This was avoidable. You did not need to learn this lesson. It was obvious. Just a reckless kid!
You can follow Brian’s twitter account and find this idea playing out in very many of his tweets. If you didn’t know him, you could mistake his position as contrarian or in the worst light — a bit of a nostalgic thinker, and maybe anti-progressive. You would be wrong, however, and it’s because of this causal loop we have with our experience of building software, fighting fresh problems with new solutions, instead of building on the foundations that already exist and have been proven.
Living in a lucky time
We discussed coaching in the software development industry and Brian pointed out that learning in our industry has advanced so much in the last twenty years that it’s often forgotten how easy it is to pick up coding. But also, conversely, there is such a gap left for teaching valuable ideas like emotional intelligence, ethics, and general social principles in software development that you might believe these are unimportant.
We are in a really lucky time. We were born at that perfect time, when the Internet took off and our craft came up as a real recognized job, instead of an academic pursuit. I don't know what the real numbers are; I don't work for Adobe anymore, so I can't get access to that kind of research, but when I did, it was 20 million software developers, and that was in 2012. And if GitHub is to be believed, there's now over 80 million professionally identified software developers.
Not everybody can do software development, you know, it's gonna sound cruel, it's not, it's just sort of observation. There are a lot of new people, very enthusiastic to get to that next level in their career. Many people take advantage of online courses, and building software following some Twitch and YouTube and other video streaming places because that's kind of where the next generation consumes content. And it's sort of predictably a terrible place for advice. Another interesting aspect to this is, values do not motivate a lot, so much as “I want to get paid”. And I think that's good. Everyone should get paid. Everyone should get paid a lot. We're in total agreement on that part, but I think when your only goal is to get paid, you could lose track of how to really advance your career, and really have a special career, one that you're super proud of, and one that can make an impact positively.
Then there are leaders, coaches, and people with experience, who are unfortunately taking advantage of that too. You know, like “10 steps to become a backend developer” and in a weekend, kind of stuff. I see people saying: “you can learn on the weekend.” This isn’t healthy because people are going to compare themselves. There is an enormous gap here and I think there's a genuine need for different levels of coaching. Many people think about this as an executive level step or something. It’s hugely important that our systems and tools meet people where they are. And where they are is a brand new platform.
Do we have a pen?
Brian asked his wife once, when he needed to fill out a government form, if they even had pens. He smiled as he told me, “we tore the house apart looking for pens”. Brian said he hardly has pens and most of his pencils are for woodworking. He added, “I like to iterate” after saying he probably would choose pencil. He also shared with me that recently he’s gotten into gardening.
He described his favorite place on earth as “Lord of the Ring style, mountain streams, shimmery and green pools.” Backwoods of British Columbia is Brian’s favorite place and he says, “it's my hobby to go back country.”
Brian said he likes to have a balance back to nature:
It’s nice to have outdoor space and have separation from the present moment’s problem from the tech world, where we get trapped in our heads.
Timelessness is better than freshness
Brian and I wove into the latest technologies, because we asked: What do people get wrong about the trend of “top 10 things to become a developer” lists? He laid out an explanation that was pretty simple and emphasized the need for deeper coaching than just the contemporary tools and frameworks. He starts by describing the conflict:
It's difficult to know. I mean, I think the outcome they're looking for is a new title and more money in the bank, and I think that's right. Okay, but the path there is contextual in a shifting scene. Ten years ago, backend development was completely different. Today it’s mostly in the cloud. However, some stuff is timeless. If I had said we'd be writing backend JavaScript for 50 years, everybody would laugh!
All these different new worker environments that are coming out like Bun and Deno, give us this awesome diversity of things, but you'll see these checklists, know they'll be naming technologies, but the technologies are meaningless compared to the practices and the values that guide those practices. And the values all sound kind of boring, you know? One of my values is that I want deterministic builds. There's no way to dress that up. The farther you get along in your career, the education is less about the latest runtime; the education is really about values and values to guide the practice.
Brian is one of my favorite people online for this type of thinking. He believes the real learning comes from the values and the practices — not from the latest tech. Those change, but the values stay the same.
Well, that's the other neat thing at the beginning, it really feels like there's a lot going on, like new libraries, frameworks, tools and stuff every day. But then the patterns emerge and then you realize maybe that whether it's Python didn't really matter all that much. What mattered was how do we realize business values? Maybe not necessarily business value, but maybe an outcome we want is to stabilize a part of the stack or remove a problem. Over time, I've grown more and more disinterested in, say, the new database of the week, and far more interested in the theory about what I can get out of it.
Pockets of goodness
I asked Brian where there are good examples of coaching or mentorship in our industry.
We've got an embarrassment of riches now for media and formats, and the ways to get it. You know, pretty much any platform you choose, you're going to find your flavor there. And this has also become a massive challenge. Now, there are probably developer tools, that rise above other's noise and make a meaningful impact without creating too much more noise, like introducing new acronyms or add into the existing chaos, but I'd say overall we're pretty lucky, and there are larger organizations sharing their knowledge to, and that's also kind of amazing.
A very under-appreciated resource is the Amazon Builders Library. It’s a series of papers. It's academic, but it's all the learning of building the data centers and services and the scale.
On the social media side, you've got the YouTube crowd and this fairly recent trend of live streaming coding. That's also its own fascinating kind of group learning and they're really cool. I went to one and I don't know how they do it. I could only last an hour and I'm kind of down on video and they do four, five hours of streams and tons of people in the chat and everyone mob programming together. It's a ton of fun, it's incredibly awesome, but for me I don't learn that way. And this is another challenge, you know. Everybody's got their preferred learning contexts and your environment will change how you learn. If you are a person who needs focus and quiet, it’s likely you will not love the Twitch stream style stuff that's going on. It's not gonna be for you.
It was unsurprising that we find this confused landscape regarding good coaching tools for developers online. There is definitely a wealth of information out there, and in all kinds of formats, but there isn’t a helpful guide for each of us as individuals. It can be daunting, and easy to find what we believe we need. But as Brian said in passing: “only after the fullness of time” will we really understand whether we are learning valuable and useful things, or if we just got the easy button and lost the underlying value?
Is it therapy?
As we progressed into the area of the good things in software coaching, we were talking about the literal and maybe physical parts of software development. Brian had used the phrase “sometimes it’s therapy” while describing good coaching. It intrigued me because as I am building this coaching service, the thought crosses my mind all the time: Should I become a licensed therapist for software developers?
It's a therapy where we have to, you know, play things back and take a breath and also acknowledge feelings. Feelings are good, okay? I've made calls and regretted them in the fullness of time and it's like “I got burned by that” and then you see things come back around again.
I think one of the more important books for me and being a leader was Nonviolent Communication by Marshall B. Rosenberg, PhD and I think it draws a lot on this type of thinking about creating space. So this is another thing that I did poorly, early as a leader, where I'd look for problems and then I would criticize, as though that was a solution. That's not a good way to help people. Figure out the context of where a person is. Sometimes people aren't even open to feedback, and that's a problem that needs addressing before you can give them the feedback to improve, and sometimes they're looking for the feedback, and sometimes there's people out there that are their own worst enemies. I had this terrible manager, who would use this shit sandwich technique, on every interaction.
So they would say, “you look great today Brian, on that one email thread, I would appreciate it if you attached things as PDFs instead of text files. Good job with the team today!” And after he did it for a couple of weeks, I realized this fucking guy was just giving me a shit sandwich every time I talk to him! No credibility. And so I wasn't in a place to receive anything because it was bad feedback usually, and that's tricky. So if you want to build a rapport, have trust, they have to know they're coming to a safe place to get that feedback and maybe for quite a long time, there's no criticism. Maybe for most interactions there's not much value in trying to find things that are broken and fix them, instead really leaning into a person's strength and helping them realize how great they are, so that they end up in a place where they can do it for themselves. This is touchy feely stuff.
So as a group, we like to use those words like “engineering.” But engineering would be, for example, if I was selecting a dependency, I would probably do something like a bake-off if I had four or five comparable dependencies. I looked at them: How long to build? How much latency did they introduce? How much code is there? What is the license? But a lot of time people just say: “is it popular?” If it has a lot of stars is instructive but that is not engineering: that is social proof. And that's okay, that can be a good shortcut. It would be nice if we did a little more of the soft stuff, and the soft stuff that we did was more about the people and a little less of the actual artifacts and code. I think we'd be a lot happier as an industry if we did that.
Leaving the empirical, data-driven methodologies to the software artifacts, and putting the soft skills on the people's problems sounds really straightforward to me. And yet, our industry doesn’t make that delineation very clear. It’s interesting how often we measure ourselves by code quality metrics instead of by human qualities. It’s clear to me we can’t coach with just one or the other, and instead we need to join them.
More dichotomy
I shared with Brian that one of my early concerns for my coaching service was that I would fall into a practice of just giving people false boosts of confidence and that the real critical feedback would be lost. I asked him how we connect these seemingly opposite outcomes. How do we inspire and provide confidence while also supporting the person through difficult critiques?
So, you know, it's easier in a game like sports or something. There is a score, and there is a winner and a loser. But this is real life and you know, we could say that the score is going to be a business outcome, but it might not be what's motivating. Are you going to put on your tombstone: increased efficiency by 10%? Everyone has their own drivers. And I think that's very important to make sure that they have the psychological safety to feel like that need is being met.
At the beginning of the pandemic, I spoke to all of our investors and a lot of other founders and the consensus was pretty clear. This was going to be a really hard time and we should cut costs immediately, which probably meant reducing headcount. And it made me think, people work with you and for you, they're giving you their time and you know, when shit goes wrong, you're holding them accountable to come fix it. And when the macro goes wrong, they're looking to their leadership to be there for them. So I put a bullet at the top of our strategy planning, where I said the first most important person is you and your family. The second most important person is your teammate. And then the third most important person is our customer. It's just a reversal of the thinking but we had no churn and no one has left and there was, you know, mostly a positive response to this and of course the pandemic wasn't the end of tech, it was positive for tech, so a lot of those fears were unfounded. That's why I’m always very optimistic and bullish about tech. So, I think to get the best out of people; they have to know that they're in a place that they can grow in and they'll still impress you. You could be surprised how they'll go to places that you couldn't have dreamed of.
It’s hard to know up front how best to help people. There are certainly methodologies that can provide a structure for finding out. But we are all so different that sometimes, applying the same method to everyone can be harmful. The software industry can be a causal loop sometimes, and create a difficult experience for all of us. If we could go back in time to help ourselves, would we just fix the problem? Would we go back in time to give ourselves the latest “top 10 things” article? Or would we teach ourselves the underlying values and let ourselves figure it out from there on our own?
Coaching for software developers is a unique and interesting place. There’s room for rigid empirical structure, data-driven solutions, but because software is a human endeavor, it also requires room for soft skills like being a wonderful human. And there is a very wide horizon there. Would you go back in time and give yourself the answers and maybe change the causal loop? Or would you help yourself by making the future trip through learning easier?
I had a great time talking to Brian and really enjoyed the direction this profile took. Thanks Brian!
This is the fifth in a series of profiles in software. If you enjoyed this subscribe to continue getting the series. I’ll be writing profiles of industry leaders and interesting people from all areas of tech every month.