Joel: Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.
Aaron: And this is Aaron. So, I have a lot of personal pride. I like to look at myself and be like, "I'm doing a great job at my job, I'm smart, I'm driven."
I reasonably feel good about myself in a lot of these areas. But one thing that I've been struggling with lately is what do I do when I'm wrong? And actually, if I look at it more or often, the more I get to be a senior developer, the more times I feel like I'm wrong more often.
And then I start questioning, "Am I even a senior developer?" Do you even know what I'm talking about, Joel?
Joel: I think so, I think I'm following you. My first thought was like, "Just don't be wrong." But well, that's not an option, so that's not helpful. I think maybe this is an aspect to it, it's not even that you are wrong with higher frequency, but is it possible when you're wrong, it's more visible?
Because if you're a senior, you're on a team, and other people are maybe looking to you for guidance. It's like, is that part of it too? Is being more visibly wrong, whereas because of your position on the team or in the company or something like that?
Aaron: Well, that could be. That's something I didn't even think about. I would say it's more frequency than size.
And I'm starting to come to a sort of a pattern, I'm going to explain why that's happening, but I'm just not sure. That's why I want to talk it out with you.
Joel: Yeah, I'm up for it.
Aaron: So what I'm noticing is, as you become senior developer and as you kind of learn more about your craft, you get to these plateaus of knowledge and understanding where you suddenly know a lot.
And then you can either stay there or you can stay there for a while and push yourself to the next level. So, I found that throughout the many years of my programming career, I think I've mentioned that in other podcasts, like within the first five years, I thought I knew everything.
I was lucky enough to go to a ZEN.COM when that was a thing, and totally got my plateau set at the proper level and realized, "Oh, this is just the first step, I don't know anything."
Joel: Is that a euphemism for knowing, getting set straight? Like, "Oh, I got my plateau reset to a new level."
Aaron: Nice. I think as I kind of build out and spend more time in this, I'm not sure if I'm hitting more plateaus or if I'm becoming more fluid with like, if the plateaus are actually less.
Because I'll say, every time that you hit that plateau and then you learn a new things, you realize all the things that you did know but all the things that you were wrong about too. And I know wrong is kind of a strong word but that wasn't right, it could have been better.
You didn't architect that right, you've learned a new technology or know new architectural process. And boy, the way you were doing it before now is just silly.
Joel: Yeah, and there is like an interdependency of some of these decisions or opinions too. And the more foundational the dependency or the opinion that you're like rethinking, the more impact it has too.
I'm sure that's like the blast radius of changing my mind on this is a lot bigger, as you're a senior dev and you're driving these bigger decisions and more architectural type things. But, yeah, I can relate. I mean, you could chalk it up to like self-awareness and wisdom.
Like, maybe the more you know the more aware you are of what you don't know. So it's kind of like the little journey you traced us through. Like, the first five years you thought you knew everything.
Well, of course, you're not going to think you're wrong because it's not being challenged. I mean, I think there's a positive side to this rethinking certain things, Aaron.
Aaron: Well, thank you. You actually kind of led that in the right direction. I didn't prepare Joel, but that was kind of where I was going. It was like, well, there's two different ways to look at this.
Either I'm wrong more often or I'm building up a larger collection of knowledge as I intend to move forward in my career. And I'm able to more fluidly assess each set of decisions. And maybe I am just creating a better and better mental model in a way of how all my things work.
So it's not necessarily wrong, it's that I'm getting more and more information, I'm getting more and more experience, and therefore I can go and adjust these things that were "right at the time". But now that I have more experience and more different things they become a little bit more nuanced.
Joel: I think nuance is a great word. Because like right/wrong is just... it sounds so black and white but it isn't that simple in most cases, right? Like, you could probably make an argument to even defend your previous position and it could be like mostly valid.
But the nuances where these additional thoughts come in and it just opens up the door to rethinking it, which again, I think is healthy.
Aaron: So, it's interesting is that as you kind of go throughout your career, the places where you get told you're wrong sort of change whether by the exterior or the interior.
We do code reviews, for example, and when I was a more of a junior programmer, I would get a lot more feedback on my code reviews. I had done a lot of things incorrectly, or not to the highest level of quality, or things like that, I had much to learn.
As I grow my career, I'm finding my corrections are more at the architectural level and even the mechanical level of how I use my tool set to my languages. So you're kind of right, there's a nuance and there's also a targeted layer.
But one of the things that I've been kind of struggling with... I mean, struggling is almost too strong of a word though, is when you're a junior, unless you have crazy cocky pride, it's easy to be told you're wrong because you know nothing.
Joel: Okay.
Aaron: But as you get to senior level, how do... I find myself sometimes pushing back against another senior developer like Joel. And like, "Are you sure? Because what I know that isn't right," you know, if I'm maybe cranky or something like that.
But the other thing is, when I'm meeting someone of my equivalent experience, like Joel for example, I might get nervous when I start to realize that something I've been sort of proposing or supporting I've now changed my mind on.
And is Joel or my other programmers going to not trust my opinion moving forward? Are they going to see this as personal growth or are they going to see this as a large mistake because it's an architectural thing?
Joel: Yeah, or hold it for ammunition the next time you share one of your opinions and tell them to do something different and they're going to be like, "Well, you'll just change your mind on this." So, I appreciate that you're sharing this with us.
Do you think there's maybe a deeper lesson both for senior devs and junior devs? Like, to kind of take away from this? Isn't just an Aaron session, you know, just-
Aaron: Yeah, I think there is something. I think, like you said, there's a nuance to things. So first of all, besides saying something's right or wrong we can kind of say that, right?
I mean, we talk a lot about unit tests and stuff like that, or even very opinionated tools like code standards, tools and stuff. Those are situations where things are either right or wrong, but right or wrong compared to the expectation or the criteria.
It doesn't mean it's right or wrong for the business, it means that we've set up criteria and we know they're right or wrong. Beyond that, when it comes to things of choices of how would I do this? Architectural things, artistic things, stuff like that, maybe the conversation I need to have in my head, as well as others, is at one level I'm dealing with binary yes and no?
The next level let's actually deal with it as a ratio or slider, almost like you would art. I mean, you can look at art and say, "That is a really great piece," or, "That's a decent piece," or, "I don't like that piece."
And depending on the quality of art, it's whether it's at the dollar store, whether it's something you buy for a couple hundred dollars and put in your house, or if it's something in the museum, and are any of those wrong art?
They're made for different reasons and different quality, different things? And are any of those artists really bad, bad people? Are they just destroying things?
No, they're just different, it's just a different nuance. So the takeaway for me is, and it wasn't even before we talked this out, was that there's right and wrong at a certain level, and then everything beyond that it becomes a ratio that is nuanced.
And it's okay to change that as you get more information, that's what makes us most flexible. Is as we add more information, being able to adjust those levers of what we think the right answer is created from.
Joel: And just to put another positive spin on this. Maybe think about the fact like that if you are never changing your mind, maybe you're just stuck in a rut too, right? Like, there's almost a lack of growth implied from not at least reconsidering your opinions.
So, just that's something I'm taking away with this too. Also, the fact that I want my code in a museum. Aaron, other people don't have the privilege of watching us record this, but we see each other as we're recording.
And I just wanted to tell you, I have not been winking at you throughout this entire episode.
Aaron: Okay, I was wondering about that. Like, every time I would say something, there was a little bit of a, you know, cheeky look.
Joel: It was cheeky, I like that. Shortly before we recorded, I ate a piece of pizza and a little crumb popped off and went straight into my eye.
So from now on, first of all, I will be wearing safety goggles when I eat pizza. But second of all, that is why I was kind of twitchy in the eyes today.
Aaron: Okay. I'm not the only senior developer that's kind of ran through this process and had code that they thought could be better or could be updated, right?
Joel: I know for a fact that you're not. In fact, we have helped other senior developers review their code and review some of their architectural decisions. If you'd like us to help on your project, head over to masteringlaravel.io/codereview.