Transcript from the "Culture of Learning" Lesson
>> Kyle Simpson: Now the argument I always get back from people, and some of you may be thinking this at this moment is, yeah, but even if I sat through your workshop and I learned all these nuances and I read the spec, what about all the junior devs on my code base?
[00:00:13] They would never understand this stuff. This I actually, in theory, hits me almost more than any question I ever get. This mindset that says, well I'm smart enough but those junior devs they're too dumb to understand this stuff. That is complete and total nonsense. I don't know what your backgrounds are, but everyone of you is excellent at what you do.
[00:00:56] You should be as obvious about how you're using the tools as possible. And when somebody is on the code base who doesn't understand, use it as an opportunity for them to learn. Use code reviews, use a culture of peer-to-peer learning, of pairing together. All of those things to help everybody learn how the tool works better.
[00:01:17] When you receive a code review and some junior developer did something dumb, like they didn't do a coercion correct and maybe there's some corner case they didn't know about, you don't reject the code review and say, you're dumb. You say, hey, come sit with me for a minute, let me just talk to you about this corner case that you weren't aware of, and if you did this thing instead we'd avoid that corner case entirely.
[00:01:40] Now you learned better and they learned better. This is a complete bunk argument, it's a lazy excuse for not wanting to actually do what we ought to do on our developer teams, which is promote that everybody should be learning, everybody should be headed upward. I don't care where you are, I care what your direction is, are you headed upward?
[00:01:56] Are you learning more about your tool? This is not an excuse for not using the tools well. It is also not an excuse for being clever, right. Some people say, well the slippery slope argument here. I can do all this clever bit-wise math, right. I'm using the tool and I'm being clever, and I'm doing all of my programming on one line of code, the way we used to do in Perl.
[00:02:20] That's not what I'm saying, either. What I'm actually saying is that your code is a form of communication, and there is an effective way to communicate that understands and uses the tool well. If you ask the reader of a code to understand something about the tool so that they can understand that line of code, that is an investment on their part.
[00:02:42] Make sure that that investment pays off beyond that line of code. Make sure that when they learn how that worked, they're gonna see more of that. Rather than, they learn how you did something weird, esoteric bitwise trick, and then they never get to use that ever again. That's a waste of their time.
[00:03:23] Yeah, the junior devs gonna need to learn some stuff, but that's what happens in every job and in every industry, you have to learn some stuff. You don't see an architect saying, well we're not gonna design that building well cuz we've got an intern on the job. You teach the intern how to build the building well.