(Intro music: Electroswing)

So, welcome to BookBytes, episode who knows? I think it’s episode 2… 3?

I’m 3.

Is that right?

Yes, I think so.

So, today we’re talking about Apprenticeship Patterns and we’re going over chapters 5, 6 and 7. I’m Adam Garrett-Harris.

I’m Jen Luker.

I’m Safia.

I’m Jason Staten.

So, last time we all picked… Well, last time Jen was out, she was sick, but we all picked one action item that we wanted to do, and so I just wanted to follow up and see how that went. Jason? What’d you do?

So, my action item was under the “Find Mentors” patterns and specifically the thing that I was going to do is reach out to somebody who is more knowledgeable than me, and just find out what I could learn from them, maybe just talk to them for a little bit. And so, I actually reached out to Dave Smith. He has previously been on the JavaScript Jabber podcast and now does Soft Skills Engineering, and I really enjoy the show, and given he has far more podcasting experience than me, I said, “Hey Dave, what should I do, and what should I not do when I’m getting into this?” And he had some excellent advice for me on just little things to keep track of. So, it was really nice to be able to just get his perspective on the show and on things that I should watch out for. So, I’m glad that I wasn’t rejected immediately upon sending him an email and one success story so far with that.

Nice. That actually was not what I picked, but I did a similar thing where I mentioned something about TypeScript on Twitter and a guy said, “Oh, you’re really gonna want to learn some other cool languages.” And so I said, “Hey, yeah! You live in the same city as me so let’s meet up for coffee and you can show me some cool language that I’ve never learned before.” And so we met up and he taught me a little bit about Reason. What about you Safia?

So, my action item from last time was a little bit vague and it was just to be more introspective about the different processes or things that were going on in my life, and I actually realized that as I was starting to do a little bit more of the introspection it related to one of the topics that we’re gonna be covering in today’s episode which is “Creating Feedback Loops.” So, I’ve kind of coupled being introspective about my own shortcomings and paired that with measuring what they are and how I’m improving them. This was specifically with a respect to how effectively I can solve certain programming challenges.

You’re measuring something more, now?

Yeah, so I’ve started to be a little bit more diligent about measuring how much time it takes me to complete certain programming tasks whether it’s an open source pull request that I’m working on, whether it’s a project for a class, whether it’s something that I’m doing for my part-time job, and just trying to think more critically about what types of programming problems or challenges take me awhile to do, and which ones I’m good at, and setting up ways to reduce the amount of time it takes me to solve certain kinds of bugs or add certain kinds of features.

Cool, so how are you tracking it?

So I… It’s completely time-based, and for me, I used I tool called Toggl, which is T-O-G-G-L, and it’s kind of aimed more at consultants or people who work by the hour, but what it allows me to do is to set up certain tags for things. So, I can set up a tag that’s like “front-end task.” I can set up another task that’s like, “database queries” or something like that, and I can just like start a timer when I start working on something and then stop it, and it gives me the ability to look at visualizations of how long it’s taking me to spend, or to do, certain things, how much time I’m spending working on programming related stuff per week. So, just gathering more data about how I’m working.

Awesome. Jason?

I was going to say, I look forward to the blog post about you optimizing your developing times.

Yeah, that’s going to be super fun to read.

Yeah.

So, Jen, I know you weren’t here last time, but you said you’ve got something as well?

I do. So, I went with “Rubbing Elbows.” I ended up working with a couple of friends on a few open source projects. They were new to open source and had never actually gotten involved, so I pair programmed and we went through the steps of setting up their codebase to better work as an open source GitHub repo. So, setting up the origin and the remote branches, and then also the process of setting up that pull request. The specifics that the different repos required. Then I worked with them to get those pull requests actually submitted and merged in. So, it was really fun to introduce someone else to open source and to see their excitement and then to hear the stories afterwards about the different repos that they started getting involved in because of that.

I like that, lighting a little spark for them and kind of showing them some of the entry way on that because sometimes open source can seem like some big intimidating thing, and assisting somebody in to getting into it is a big thing. Just, small motivations make big changes.

It’s like, there’s a lot of people that want to get into open source, but everyone seems afraid of breaking something or not really understanding the codebase enough to be able to do it. So, it can really help to have that hand holding the first time to just kind of walk you through it a little bit, and give you a little bit more perspective. Someone did it for me when I first started, and so paying it forward was really exciting. I didn’t quite appreciate how much I would enjoy it.

Yeah, that’s way cool. When I first started contributing, I kinda had to work through my first pull request alone, and it was a pretty grueling process. So I’ve been pretty intentional about making sure that I support individuals who are interested in getting started in open source and making that a priority for the open source projects I’ve been involved in.

So, my action that I chose was from the “Draw Your Own Map” pattern, and the action is think of your current title and then think of three possible jobs you could do from here and then underneath each one of those, what are three jobs you could do from those, and then under those there are three more. So, it ends up being 39 jobs, and I … I’m not gonna lie. I couldn’t even come up with 39. After like, the third layer of jobs, I was having a hard time coming up with like, any job titles that I knew of. So, I came up with everything from front-end to full stack, to UX designer, to mobile developer and, I don’t know, QA tester, product manager, project manager, CTO. Yeah, it’s just a huge list and I wasn’t even considering being a UX designer, but now it sounds really cool.

With some of those things did you think about what would be your pathway to it? Or like, what steps you would have to take towards getting to it?

Yeah, that was kind of the difficult part. If I was serious about becoming one of these things I would have to think a lot harder about the path, you know? I feel like there is no one real path to any of these things. It could be completely different for different people, depending on what company you’re at. But I feel like my current position right now, where I’m jumping around from company to company every six months, kinda lends me to be able to do a lot of things, because I’m going to be getting a lot of different experience. So, I feel like my next job could be a big change if I wanted it to be.

So, Chapter Five is “Perpetual Learning.” So, what’d you think?

I felt like Chapter Five really started off well for me thinking about these things where I feel like I’m doing some of these patterns well, but then as I progressed, later, onto it and also onward into Chapter Six, I felt more like I was getting called out and needed to step up my game a little bit more. Chapter Five specifically touches on not getting stagnant, and always growing your knowledge base and finding where to grow it from, and staying active in just your ability to code by building small things or sometimes slightly larger things. Also, reflecting on those things and sharing your learnings with others. So, I thought it was a great chapter, for sure.

I felt the same way. It was really cool to be able to go through those and go, “Yeah, yeah. I do that, I do that, and I do that.” And then it’s like “Oh, well that’s a good idea” and “that’s a pretty decent idea” and then “Oh, well… Oops. Ha! Maybe I should do that one.” And then “Aw dang it. I knew I was going to get called out eventually on that one.” So, I get it. It was really cool though. I did appreciate the push to continue growing. I oftentimes hear, from the development community, that they want to be able to reach a point and then they’ve made it. I really want to just, hold these people by the shoulders and say, “No! You always are learning.” You know, whether you want to be a speaker or you want to be an architect or you want to be a director. Any of these things, it still means that you have to learn, you have to keep learning, because everything that you know is going to eventually become obsolete, and if you’re not continuing to learn, then you’re no longer going to be able to fulfill the roles in which you’ve been hired, essentially. So, I mean, even at that point if the purpose is to continue up the upper management scale you still have to keep learning those skills as well. So, it’s just even when you reach master, the learning doesn’t stop. At that point you’re learning from the Journeymen that are traveling from job to job, bringing you new skills and new ideas from different places.

Yeah, I like the part at the beginning intro section that says that an apprentice must learn how to learn, and just because you become journeyman doesn’t mean you need to stop learning.

And I think also reflecting as you go, how you learn most effectively can change over time, too. While you may start your journey needing a lot of immediate direction or you learn best say, with screencast, but then maybe later on your learning improves by some other approach of going through a white paper and tackling it that way. So, recognizing that you and your approach to learning change as well.

Yeah, so I like the very first pattern, “Expand Your Bandwidth” which, to me, seems like one that’s really good for early on in your career. Like, there’s certain times in your career where you really need to, like it says, drink from the firehose. I almost want to just call this pattern “Drink From The Firehose” because it reminds me… Has anyone seen UHF? With Weird Al?

(laughs)

Mm-hmm (Affirmative)

You have?

Mm-hmm (Affirmative)

I have not.

Spatula City!

So, Jason, you’ve seen it, too?

Yeah, I said Spatula City.

Nice!

(laughs)

Well, yeah, one of my favorite parts in that show is when he has this kids’ show and one of the kids like wins a prize and he’s like, “You get to drink from the firehose!”

Yeah. (laughs) Oh, god.

He puts him up on that little plastic horse and turns on the firehose and just like-

Blasts!

Blasts the kid off the horse. Also one of my favorite gifs. But yeah, I mean, it can be overwhelming. So, you don’t want to drink from the firehose all the time, you need to turn it back down sometimes, but at some points in your career it’s really useful to have that kind of information bandwidth coming in.

That’s actually something I did this year, or this last year. I kinda felt like I was starting to get behind, and we all have those times when we’re like, “Gosh, you know? It’s all changing so fast.” But I really started being concerned about the fact that I wasn’t quite keeping up as much as I wanted to. So, I got onto Twitter and started following all the people and all of those people started following all… You know, led me to even more people, which led me to books and conferences and all of these possibilities, and it basically meant that it was the super ultra fast speedway of learn everything possible, right now. It was really great, but it can be really exhausting, and yeah. You definitely can’t to it 100% of the time, but it was really cool to spend some time in that mode, and then to see that reflected in the book. It was like, “Yeah, yeah yeah. I just did that!.” I felt like it made me a better developer in the end.

Yeah, I was in a completely opposite situation. I definitely feel like over the past couple of years I’ve been very sharply focused on like, the world of front-end JavaScript, and as I was reading the chapter and especially some of the specific tips that they mentioned on how to expand your bandwidth, which for those who don’t have the book handy, just involves doing things like aggregating blogs from a ton of different software developers, or following folks on Twitter, or a really good point was reaching out to the authors of books you read and starting a conversation with them. So as I was reading that I was like, “Oh gosh, I don’t do any of those things and have been totally passive and unengaged with my learning and exploration process.

So, that was one of the early wake-up moments for me.

I didn’t necessarily contact the people that wrote books that I was reading, but I contacted the creators of libraries that I was learning and had them kinda talk me through some of the parts that I was having difficulties grasping, and it really allowed that open dialogue to, not only really allow me to understand things much deeper than I think I would have otherwise, but it also inspired a few pull requests from them that improved their products, too. So, sometimes it helps to have those fresh eyes looking at it from that different perspective to help inspire you to make things better or different. And, you also learn that the heroes in the community are just people, too. Sometimes really cool people. Usually really cool people, but just people.

So any other practices or patterns in this book you want to point out? We don’t have to go through them in order or anything but-

I actually wanted to ask Safia on one particular one, and that is “Use The Source” or “Digging In Source Code” because I know you have been digging into the node internals, or is it node or V8 internals and I wanted to know how that’s going.

I’ve been… Yeah, so over the past couple of weeks I’ve been reading the node [node.js] codebase. For those who are unfamiliar, node is a server side programming language, and it’s open source, and it’s available on GitHub so I’ve been looking through that. Ooh, it’s been an interesting process and what I’ve basically been doing is sort of asking myself a question about the way that I use node since I use it pretty frequently in my day-to-day work, and just trying to go into the source code and answer that question. So one of the big questions that I asked myself is how does the node programming language handle the built-in libraries that it uses? And how are they built and exposed to the end user? It’s been a cool process and I definitely related to some of the points that they mentioned in the “Use The Source” solution section. One of the ones that I’ve been trying to get better at is trying to refactor codebases in order to better understand how they work. I don’t know if anyone follows Julia Evans on Twitter, or reads content on her blog, but that was one of the pieces of advice that she gave me when I kind of talked to her about my software reading journey, was just starting to, once you understand something, being comfortable with breaking it in order to learn more about it.

What is your process when you’re refactoring? Are you trying to fix something? Are you trying to see if tests break or pass?

Yeah, so I should caveat that by saying that this is something I have been bad at doing, but reading the book and advice from other people has pushed me to try and attempt it more. So, as of yet, I’ve never actually refactored the node codebase to do anything differently. I’ve contributed to it, but I haven’t looked at a piece of code that I thought was maybe too complicated and then changed it to simplify it. And there’s definitely been some situations where I saw something in the node codebase and I was like, “You know, that’s kind of weird. Or that seems like some Legacy cruft that’s hanging around and I could probably submit a pull request to fix that.” But, I haven’t followed through on that, so, perhaps I might make it one of my actions for this week is to just go through some of the weird things I’ve found in the node codebase and see if I can submit pull requests to address them.

Sounds like a great idea. It does remind me of the “Breakable Toys” portion, as well. I really enjoy “Breakable Toys”, it’s a fantastic way of learning new technologies or trying to play with an idea. Does anyone else just like pick a particular project to build it over and over? Like, we as devs tend to do the To-Do app. Have you chosen anything besides the To-Do app to use as your breakable toys?

Yeah. I always like to build a Twitter clone, just because I think it covers a lot of the good basics. Like, how you make a feed, user authentication, efficiently reading from a database and rendering stuff, and then just like thinking about the UI as well. So, I tend to use the Twitter clone a lot.

What about you, Jason?

As for things that I’ve built several times over, I guess Game of LIfe is kind of a staple of that. Recently it’s not something I’ve built multiple times, but I was tinkering with Rust, and I was like, well I’m using a low-level language, I might as well build something low-level, and so I wrote an interpreter for the BF language, and I’ve never done that before, and that was kind of cool because it gave me a chance to fight with Rust-type system and do something also like, a little bit unfamiliar to me, but still small scale that I could get done in a shorter period of time.

That’s really cool.

Yeah, I don’t build the same thing over and over again. I’ve made some games. I’ve made 2048 and some other games. Jen, do you make the same thing over and over?

Uh, I’ve made a few things over and over. I tend to rewrite my website over and over again.

(laughs) Yeah, I do that.

So, I mean it’s… I have a few different websites. So, I have JenLuker which is my standard website, but I also have KnittingCodeMonkey, which always looks like just an absolute disaster and it’s because I’ve probably combined three different random conglomerate things together, and I’ve been trying to figure out how they work together and how they don’t work together, and what the limitations are on all three of these things that I don't actually know how they work. So, it looks like a horrible disaster and it never functions, but the point is that that’s where I house my collection of breakable stuff for the most part. I recently built a nested list that depended on the parents for various parameters, and that was really fun to build. It was kind of complicated and I think that might end up becoming my new breakable toy.

Well, if you have a repo for it, I would be interested to see it, and tinker with it myself. See my approach on it or something.

I must say, Jen, I just navigated over to your website and it’s quite gorgeous. So everyone listening should go check out JenLuker.com for a really cool website.

Thank you. That was actually another breakable toy. I realized that we had radial gradients and we have linear gradients, and we also have transitions, and you can transition linear gradients all day long, but we don't have the ability to create transitional radial gradients. So, I went forth and attempted to solve that problem, and it was more JavaScript than I want to talk about.

(laughing)

But I did it, and it was fun, and I learned a lot about SVGs in the process.

I like that they distinguished the difference between practicing and breakable toys as well. I guess the pattern being called “Practice! Practice! Practice!” and for me, my interpretation was that practice is a really small exercise that maybe you can do in a 5-10 minute sitting, and a breakable toy being something that you can go and try random stuff out with instead, and potentially break. More like a website, or they mention a Wiki in it, as well. I, myself, am a fan of… it’s codewars.com for a bunch of little exercises and then being able to see other people’s implementations, and I was curious on what are the places or things that you use for practice versus a breakable toy?

I can talk a little bit about that, because it actually relates to something that I started on my blog recently. So the backstory, when I was in high school I had a tech blog, which I will never share the URL of.

(laughing)

But on that tech blog I would go through some of the programming challenges on a website called projecteuler.net and what it is, it’s a bit more math oriented, but they basically give you algorithmic challenges and you have to design time efficient solutions to them. So when I was in high school I was working through those problems and blogging about it, and I kinda stopped after like, 2 years of that. I actually decided to throw back and continue doing that in my current blog now. So, I’ve been working through the problems and doing kind of live code storytelling just sharing my process, or how I came to certain solutions. I find that I quite like more algorithmic focused problems just because it really makes me sit and think, and it’s way out of my comfort zone, and that’s something I’d recommend if you’re a similar kind of person.

I’ve done some of them and I do like what you’re saying, Safia, with being algorithmic. One nice perk about it is because you can sometimes attempt the brute force way, and sometimes it will actually finish, but then you can also go and optimize it to make it actually fast. So, there is an objective measure, too, of “Have I improved this thing?” versus some other thing that it may just be code formatting.

Yeah, for sure. That’s another thing I’ve been tackling, too. Just learning to optimize things and recently I was solving one of the problems and I posted at the end of my blog post, if anybody had a more efficient solution, let me know, and somebody sent me something that 17 milliseconds faster than what I had implemented and as I usually do now, I went and read the source code to figure out why and ended up learning some super interesting things about how Python handles numerating over iterators. So, it’s also been fun not to just leave it as a self contained problem but to extend it and see ways that I can engage the community with it, and learn a little bit more about the tools I’m using and why certain things are faster and why other things are slower.

Yeah, at work every week we’ve been doing lunch on Thursdays, going over one of these katas from exercism.io using Elixir, which is a language I’ve never used. So, it’s been kind of fun to watch and help out and actually get involved in the conversation even though I don’t understand Elixir. I’ve noticed the more I get involved in trying to figure it out and talking, the more I’ve actually learned about Elixir. I did think it was funny, under “Breakable Toys” it said Linux started out as a breakable toy.

Mm-hmm (affirmative).

I saw that, as well. And I think there’s probably lots of modern examples of things that started off as breakable toys. I think I know… Maybe calling it a breakable toy in hindsight is demoting it’s value, but there are definitely things that started off as experiments and grew into more popular and stable tools.

Yeah, for sure. Yeah, the other one in this chapter is “Reflect As You Work”, and this is one that I thought was super hard.

I kind of... When I’m working with either the breakable toys, or some idea that I want to throw around, I tend to look at the areas that I feel like I spent a lot of time on. You know the hour killers that just kick you in the end. So, the parts that I really get frustrated over, spend a lot of time searching Google or Stack Overflow, those end up being portions that I start studying more, because I clearly have a mental block or limitation on that particular set of knowledge. So, you know, for one of them, recursion was something that I focused really heavily on, with one of my breakable toys, and I spent a lot of time trying to make sure that the recursion worked for every little aspect of it, and it wasn’t until I really stepped away and stepped back and started doing more research on recursion that I realized that part of it was a mental block, part of it is I was just really stuck on looping through things, but the other was that if I had structured things just a little bit differently that it would have been a lot easier to get through in the first place. So, I think that that’s a little bit more where I have that self introspection, is just going back and looking at what I really got stuck on and doing some research on those things.

Yeah, that’s like the “Confront Your Ignorance” pattern, you keep a list of things you know you don’t know, and then you can go and research those more.

Yeah, I’ve found this pattern in the book pretty interesting, just because I think I’m a pretty mentally introspective person. I do think a lot about how I work and what I'm doing, but I keep it all in my head. So, I thought their mention of the personal practices map was super interesting, which for those who are just listening, is basically writing down all of the things you do and trying to find the connections between them and how they relate, and I really like the fact that that’s kind of forcing you to get out of introspecting in your head and lay it out on paper and visualize it that way.

I definitely like that action and it was one thing that stood out to me as something that I haven’t taken the time to do, and I probably should, in terms of writing it down. I have done some reflecting and I have found a way to make things maybe easier to reflect on, is sometimes taking concepts a little bit to the extreme. For example, if you were to go and do test driven development 100% of the time, or maybe the ping-pong style of testing and development where you’re actually with somebody else and you write a test, pairing partner writes a snippet of code to make that pass and then back and forth. I’ve done that to the extreme before and been in a place where I’ve done that, and also been in places where that was never an option, or like, I didn’t consider it. Having experience in both of those extremes makes me understand where the value in it can come, for me. Have any of you taken some concept to the extreme before, just to see how far it would go before it stopped working?

I think I did that with recursion. Everything, everything in that thing was recursion.

No, I don’t think i have.

I haven’t done it myself, it’s been forced upon me. It kind of relates to the topic of agile development. I was taking a course at University and it was a software engineering course so it was a little bit about how you manage software projects and how you interact with a team and ship stuff, and things like that. And it was all around agile, but it took things to such an extreme. Like, there was a lot of velocity charts and measuring things and all of that stuff, and seeing agile applied so… I can’t think of a good word for this, so diligently and minutely? It made me realize that agile is definitely one of those things that you need to take the best parts of and incorporate it into your team based on your own team dynamics instead of following all of the different techniques and methods to a T. So, yeah that gave me lots of perspectives on agile by seeing it implemented to the extreme.

Yeah, it’s a good point. I’ve read a book in agile and under each practice it has a section called “Contraindications”, which is “This pattern or practice may not work for you if this happens” or “In a certain type of team you may want to tweak this, or not do it.” So, I’ve actually been marking this book up as well, because a lot of these patterns it will say, “Be careful if you take this to the extreme” and so I mark that off as a contraindication. So anything else in Chapter Five?

Well, there is the section on “Create Feedback Loops” that I mentioned earlier. The section touched on techniques like test driven development or using type check languages as feedback loops in your development lifecycle. I was thinking about the portions that related to things like taking in annual reviews or just, basically aggregating objective external data, is the word they used in the book. That kind of relates to the point I was making earlier about how I’ve started to use Toggl to time track how much time I spend on different tasks in an attempt to collect objective external data about how I work and how I do certain things. I’m curious to know for the three of you who are employed in positions where you get some sort of reviews, what’s your process like for incorporating the feedback you get from your annual, or quarterly, or however frequently reviews into your career?

For my current company we have quarterly reviews with goals, it’s not like we have quarterly goals and then we have annual reviews; however, we also have a bi-weekly meeting with a one-on-one. So, in each of those one-on-one’s we kind of go over what those goals were and what we’ve done to help or what we can still do in order to work on those goals. There’s a lot more mentorship, I feel like, that happens in those than just the one gear annual review, “Here’s your feedback and you should be done.” So, it becomes a much more ongoing feedback loop than just that once a year check-in, and I feel like that allows you, in more of the agile fashion, to kind of adapt as you learn, because some goals take all year, some goals take many years, some only take a few weeks. So, it allows you to work on the things that you need work on to improve or to grow, and then shift to something that fits you better without having that one annual review to report back on at the end of the year. When we do those, I normally don’t remember what my goals were for the year anyway. So, I like the quarterly and then checking in every other week.

I’m right there with you, Jen. I’m a bigger fan of doing the one-on-one over the annual review. I find myself, in annual reviews, often having to fill out a form on a website that I have to justify why I am still valuable to the company and should continue there, whereas like one-on-ones have way more context between those of us discussing it, me and my manager, because it’s about things that just happened or are happening. I think, for me, what’s nice in the one-on-one is being able to find out both the way that I’m perceived by other team members as well as from the manager’s perspective, to see if perhaps there is a behaviour that I have that can get adjusted. LIke, if I’m, I don’t know, coming off too arrogant or demanding or something like that, so I know that I can tone that sort of thing down as well as finding out ways that I really can improve the team as a whole, and adjusting the morale. So, that’s kind of the key thing for me, is definitely the regular one-on-ones and then the annual, because of formality.

In my experience, it’s really hard to get feedback. I don’t think most people are looking for feedback. As long as you’re not hearing anything bad, that’s fine, I guess. So, I think it’s really hard for people to give you feedback, because if you’re doing great then, hey they don’t really think about, you’re doing great. If you’re not doing so great then it’s kind of awkward for them to try to tell you. So, I think you really have to go and ask for it, and I like the way this book puts it with the reinforcing feedback, means do more of these of these things, and balancing feedback means do less of these things. That doesn’t sound so negative so I really like that.

It’s something that my boss started doing over the last year or two and I’ve picked up with my team as well is just at the end, “Is there anything I can do for you? Is there anything… Do you have any feedback for me? Is there anything you’d like to see me keep doing? Is there anything that I’m not doing for you that you need?” Just a few small questions but I’ve really started some really great conversations that way, too.

So, it seems like the big commonality is that a lot of these feedback loops are social and involve either getting support or guidance from other people as you’re tweaking it.

For the most part. We get so stuck in our own heads and our own lives and our own perspective that it can be really difficult to see our shortcomings and our strengths from our perspective, and I think that it goes back to the other pattern of writing down our issues and kind of looking through them over time, that it gives us a little bit more of that objective perspective when we’re not in the midst of feelings. Having the ability to ask both my boss and my employees for that feedback gives me those different perspectives and gives me a little bit more of that outside view that I just don’t see because I’m the one in my own head. The same thing goes for me code. Sometimes it’s nice... I love to have code reviews because I not only get to see how my codebases are changing, but often times I learn something new from seeing my coworkers’ codebases, seeing how they code things. And the same goes for them. Based on the feedback that I provide or based on the feedback they provide to me on my code, you know, i can learn something new that way, too.

Yeah, I didn’t really think of code reviews but that’s really one of the best ways to get feedback.

So, Chapter Six is “Construct Your Curriculum”.

I must say that I felt personally attacked by the “Study the Classics” pattern.

(laughing)

We were mentioning earlier being called out by certain chapters. When the book highlighted the problem, which is experienced people that you collaborate with are often referencing these concepts and rules and assume that you know them, this is something I struggle with so much as someone who’s been partly educated in a traditional 4-year computer science curriculum and partly independently taught, there’s still stuff I feel like I’m missing especially when I’m interacting with older developers. They’ll mention things and I’ll just sit clueless in the room and try and pretend I know what I’m doing. So, that chapter, or that pattern, really spoke to me about trying to figure out just what are the fundamentals that you need to understand, and going back to some of the classic texts and software engineering literature and reading those.

I’m almost completely self taught and I’ve been doing this for a long time, but I still feel like there’s a very deep language barrier between the people that have the traditional computer science education and me, who basically said, “You know what? I’m tired of rewriting this exact same header every time at the top of an HTML page, but if I change it to a PHP file, I can just include it.” You know? And that’s how I learned to program. So, I both felt attacked and enlightened by this based on the fact that it gave me a list of books to read. I’m like, “Yes! Now I can go find this information!”

Yeah, it’s so interesting that despite you and I having completely different trajectories, like you being completely self taught and me having formal CS education we still have that experience of feeling like we didn’t know the jargon from different points of view.

That is really interesting.

Yeah, and I have a computer science degree but I didn't’ read any classics in school, I just read textbooks, which is completely different, but I’m curious, one of the actions here is, “What is the oldest book in your pile? Read that first.” And as far as pile goes, I’m thinking just your list of books that you want to read, what’s the oldest one?

I can tell you that the very first time I ever bought a book i was 7 years old and we went to a library that was selling all of their books because they were closing down a high school and I bought this really ancient looking calculus book, and I would like, flip through it and I thought it was just he most magical thing in the world. But I bought it, not because I understood it at 7 years old, but because I knew that someday this was going to be amazing and important to me. So, the very first book I bought was a calculus textbook.

(laughing)

I still have it, and it still is better than the textbook that I had in high school, and again in college. It’s just interesting where sometimes that knowledge comes from and sometimes it is the oldest knowledge that really teaches it to you because they haven’t quite gotten to the point where it’s standard school of thought, it’s not quite to the point where everybody just knows the jargon, or they assume they do, it’s all very much new, so it speaks a little bit more in english, or whatever language it originated in. It speaks a little bit more layman, and just makes the concepts much clearer.

My oldest book that I have is the K&R C book, and I started it at one point but never finished it and as this states I should probably go through that, because it’s not too thick of a book and even though it’s not necessarily the best way of writing C, I’ve heard or read lots of criticism of it because you should write C like this other way, is what I’ve read online. I think the fact that it was there early can give a lot of insight into the way that things are right now. One of the things that was linked to within this chapter was… So, it’s from “Knowledge Hydrant”, it’s written by Joshua Kerievsky, and if you look in the footnotes it’s down in there, and he talks about how older books can sometimes get passed up, even though they may contain that exact piece of knowledge that we’re looking for, and he states that it’s an issue with humans that as great literature ages people don’t believe that it’ll contain the modern knowledge that they need, and that is not necessarily true. So, I really, really liked that little bit of a read of how to set up a study group and-

What did you say the name of the book was? K&R C?

Yeah, K&R C.

Is that the author’s initials?

Yeah, I mean, if you google K&R C… I guess it’s called the The C Programming Language, but…

Okay.

K&R is the shorthand and there’s a big K&R on it.

So, the oldest book in my pile that I want to read is from 1975 and it’s called, The Mythical Man-Month.

I’ve heard of that.

Yeah. It’s one of those that people have heard of, but not necessarily read, and I don’t think it’s that big, it’s just a collection of essays and it’s called The Mythical Man-Month because the first essay is called The Mythical Man-Month, and it’s where the idea of if one woman can have a baby in 9 months, then how many months does it take 9 women? So, basically adding more software engineers to a late project just makes it later, not on time.

So, I might be straying way off the beaten path here, but the oldest text that I’ve started to read and I need to finish is not a technical text at all. It’s René Descartes’ Discourse on [the] Method, which is published I think in mid-1600’s maybe? So way back when. But, it’s just kind of a philosopher discussing some of the techniques that he’s developed for reasoning about things, and just talking about his own intellectual growth and development. So, I started reading it just because I was kind of… I knew it was sort of an important text and philosophy, and I have a side interest in the topic and I’ve gotten through a couple of pages, but I need to finish it. So… That’s the oldest book on my list that is not technical at all; although, a little bit, because it involves some critical thinking and introspection about how best to learn.

Can I ask how you were pointed in that direction?

I’m a weirdo with an eclectic set of interests.

(laughing)

No, in reality there’s a list online of kind of like the 100 books that everybody should read and the majority of them are mostly public domain books and they’re things that were published usually more than 50 years ago, and I was just like, you know, I’m just going to go through and read like the classic canon of all of humanity, although that sounds a little bit grandiose, and René Descartes’ text was on the list. And there’s a couple of like old Greek stories and some 19th century American novels and things like that.

No, that sounds awesome. I used to have a book like that when I was a kid that was the 100 or 1,000 books everyone should read, I don’t remember how many, but I’ve kind of gotten away from that but I really wanted to, at one point, read all those great works of humankind. I think it would be fun to read something like that on here, even if it’s not programming related. We’re all programmers so I think it’ll be interesting and useful to branch out a little bit.

Yeah, I agree.

You know, if we’re going for really, really old texts that completely not applicable, since yours actually is applicable, I’ll go for one. I’ve read Beowulf.

Oh!

So, the oldest epic that we know of, in existence, is Beowulf. So that’s… And there’s even a Star Trek episode.

(laughs)

Nice.

(laughs) It’s quite awesome.

It’s truly transcended time.

It really has. It is. When it becomes a Star Trek episode, you know.

Yep.

So, it was really interesting to see the original text and then the translation of the original text and to see how it was kind of brought up to a little bit closer to modern english as well, and reading that text and seeing maybe what may have fit or may not have fit. But the story is still really relatable in a lot of different connotations. Not knowing what that monster is that comes in the night, and it feeds into the ingrained and natural fear that we have of the dark.

At the same time though, it can also be that it’s the ingrained darkness within each of us, you know? And it’s the fear of how being mad, or angry, or sad, or any of the more negative emotions can… By suppressing them, we end up fueling them. So, it can be interesting following that path too, and to take that and to apply it more closely to on-topic items, by shoving down those feelings of inadequacy or frustration or exhaustion, or just incomprehension, what we’re actually feeding is our imposter syndrome. So, by facing them head on and approaching them and talking to people, and finding out and asking questions even… Especially if you’re the only one in the room that doesn’t know. We’re actually not just allowing those feelings out, but we are also counteracting them by educating ourselves. So, it’s impossible for everyone to know everything, that’s the first thing you need to know, but he other thing is that by suppressing the negative emotions, that we’re actually fueling the things the make us feel like we’re bad people, or bad at our jobs.

I think that relates to something that I noticed in the list of texts of things that were provided as things you must read. In the bibliography of this book is that a lot of them address fundamental, almost universal technical problems and having to appeal to the, like common denominator that we all have to struggle with as engineers is a consistent part of each piece of literature that was mentioned, whether that be how do you manage a team, how do you refactor a codebase, how do you ship a product? Like, those big picture questions that are super difficult to answer concretely.

Yeah, and I like the pattern about reading lists. So, we’ve talked about looking in the bibliographies to construct a list or just looking up a list that someone else has made, and you can ask your mentor what kind of list to make, but in this pattern is says, “Hey, this is your list. So, you don’t have to do it in any certain order. There may be some books that seem interesting at one point but no longer do, so they might fall off your list, and so you can reorder your list any time and try to read the right book at the right time, depending on what interests you.

As a super relevant tad side-bit. I thought it was quite comedic that the link to the bookshelf.org website that is referenced in the reading list chapter is to a compromised wordpress blog, or what is presently a compromised wordpress blog.

(laughing)

Wow.

Yeah, I found a lot of broken links.

Which goes to show, always update your wordpress instance.

With a lot of these things though I’ve noticed I can usually Google the author and the name of the article and find it somewhere online.

Yeah

Speaking of broken links, actually the online version of this book was taken down over the past week as well, so thank goodness for archive.org.

Yeah. I’m surprised because this book has been available as long as I’ve known… At least 4 years.

I don’t know what the choice was for that.

Maybe they knew we were making this podcast.

I know.

(laughing)

Let’s take off the tin foil hats.

So, diving into the “Read Constantly” pattern, I thought one interesting thing I saw that may seem obvious afterwards is that it says emphasize books over blogs, and this is something that I can find myself guilty of where I will be on, say Hacker news and cruising through all of these articles and feeling like, “Yeah, I am just soaking it up and doing the firehose thing.” And in fact, though, I can go and do that and then turn around an hour later and look back and say, “Actually, I don’t really remember much of anything in that. I was just kinda cruising through some of those things.” I think, for me, one of the benefits of doing a book is that it keeps me in that same context for a longer period of time than a blog post can often do. I mean, there are exceptions, there are exceptional blog posts, but books, I definitely feel like help me lock in the knowledge a bit more.

Yeah. I agree, and I think one of the big distinctions between books and blogs is that books go through numerous editors before they’re published so you get text that’s less opinionated and more nuanced and objective than you would in a blog that somebody might have written and had a couple of friends review and posted out there. Which is not to say that there’s anything wrong with blogs, obviously I think they’re wonderful, but I think books can definitely be a little bit more objective and useful because there’s been that rigor in the editing and production process.

You don’t see too many books that are named, like, “Is React dying?”

(laughing)

I like the part here that says keep a slim book with you at all times, because that’s what I’ve been doing as I’ve been reading this book.

It’s always nice when the patterns reinforce your habits.

Yeah.

It says that we should also have our next book queued up and purchased, and I guess for this club we’re on top of it.

I just-

Yeah.

Actually I was a little bit reflective on this. It’s like, “Great! We are doing some of the things that recommended to us by this book, simply by having this book club.” Actually, a lot of these patterns relate back to being in a book discussion group, simply because we’re giving ourselves feedback loops on things and taking questions that we have about something and putting them up to each other to see, “Did I understand this in the same way that you did?” So, good on us for doing BookBytes.

(laughs)

Yeah. So, under “Digging Deeper” that’s where it talks about when you read a book, look at the bibliography and over time you’ll start to see the same books over and over, and I like the idea of tracing the lineage, and that’s kind of like what we’re going back to earlier with the classics, that you want to keep going backwards, trace the lineage to the original source. Like you were saying Jason, see if there’s some nugget of wisdom back there in the past that we’ve overlooked.

I feel like that ties into the 7th Chapter. I love the story at the beginning of the 7th Chapter about Stradivari violins and how he… You know, the reason why the shop died is because he basically didn’t pass on the tiny bits of information, the nuances that were “common knowledge.” He failed to pass that on, he thought that those were so assumed that they didn’t make it to his sons or to their apprentices, either. They were still excellent but they weren’t ingenius because they were missing those steps, and to this day we’re still missing those steps.

So, for tracing that lineage, looking at those bibliographies, finding those very original old texts, it allows us to potentially go back and find those bits of information that may have been lost over the years based on the fact that we just assumed that they’re common knowledge now, and eventually they just fall out of knowledge.

Yeah, that reminds me a lot of when I was talking about “Rubbing Elbows”, or “Pair Programming”, you pass on a lot of knowledge that’s so minor you would never think of actually teaching it.

I think with that I have a quote from the “Digging Deeper” where it mentions that when we are digging into things to have a, I guess, understand it in depth. Depth meaning to understand the forces that led to the design rather than the details of the design, and whether that be doing things like reading prior works or reading specifications, it made me think about, for example, Julia Evans, where she’s been digging at the Linux kernel and I think she’d found, or OS10 kernel and found a bug there, and that was because she was diving deep to get an understanding through debugging and specifications, and so I think she is an excellent example of that.

Yeah, the last chapter also talks about trying to get an accurate self assessment of whether or not you’re a master or whether not someone else is a master and how incredibly difficult that is. Unless you’re already a master, you can’t really tell if they’re a master. What experience have you all had with that and trying to assess someone better than you or yourself?

I think it’s way easier to determine who’s behind you on the path than ahead of you, and it can be really hard to figure out where you are on the path because you don’t know how far you still have to go, you only know how far you’ve come. So, it’s like hindsight is 20/20 but the future is fully veiled. I think this falls back on other patterns of “Finding Mentors” and “Working With Other People” and kind of learning where your strengths are and where your weaknesses are. And part of me thinks that it doesn’t really matter. The purpose is to keep growing one way or another, whether you’re a master, or an apprentice or a journeyman in between. It’s like, does it entirely matter where you are?

Yeah, I think the important thing for me is mastery is not a complete attribute. You can be a master in some things, but i think not all things, because that’s almost like attaining some sort of perfection. See, I think it helps to kind of define what mastery is. I think it’s easy to say, “I want to find somebody who is a master in this specific framework or has mastery in this specific library within this ecosystem.” But I think general mastery or mastery based on your own experiences is harder to discover.

Yeah, and at the end of the chapter here it says there are no masters, really, and it’s not even a problem. For one thing, it was saying that creating software is a new craft. It’s only been going on for about 70 years or so, so it’s super interesting to think of it as, “Hey this is a new thing. We haven’t quite figured this out, yet.”

On the topic of the book kind of saying, you know, masters… Like, how do we know that true masters can exist and that discussion on it? I did appreciate that they put in the quote, “The authors of this book are not masters.” It was kind of meta but I appreciated the fact that they were willing to step back and be honest about the reality of the fact that even though they wrote this entire text about apprenticeship and tips for achieving mastery, they did not consider themselves masters.

Yeah, I love the part that says, “We would probably rate ourselves a 9/10.”

(laughs) Yeah.

“... and then sometimes we meet people where we’re like ‘Oh wait, the scale actually goes to 100.’ ”

Yeah

(laughing)

Yeah, they did mention a portion where they said that even if you have several really good software engineers sitting at a table, as soon as Bill Gates sits at the table you gotta remember that a majority in that specific community are subpar, just based on the fact that the bell curve is skewed based on the community in which you’re in. So, it’s like, you can be the master in your college class, but then you take the next college class and you’re starting all over at the bottom again, you know? Going from elementary to junior high, junior high to high school, high school to college, you know, from junior dev at this job, to senior dev at that job, and as soon as you go into any sort of management it’s like a whole other career and you’re starting at the very bottom again. You’re the junior boss and you have to learn all over again. A new library or a new framework comes out and you’re starting at the beginning. I do have a problem with the “junior dev for life” thing though, just because I feel that the difference between the junior dev and the not junior dev is the “Learn How To Learn” portion. I feel like that’s where you learn exactly how to learn, and after that it’s about continuing that learning.

One of the patterns in, back to “Finding Mentors” actually, mentions that when you are being mentored by somebody that you need to recognize that they’re probably not going to be a master and that they are still fallible and that they may not have all of the answers for you. I think one of the things that we can gain across our journey is that we can recognize people who we can learn something from, and gain skill from, and at the same time we can look in the opposite direction and see people that we can help with our own skillset.

Yeah, I think it talked about becoming more teachable because as soon as you do that it opens up the doors to a lot more people that are available to teach you. Cool. How about we pick an action that we wants to work on this time. So, how about Jen? You go first.

I want to dig deeper. I do not read a lot of the source code unless I have to, and I think that I really want to start diving into a couple of technologies that I’ve been helping with and researching. So, I think that I’m gonna start trying some of Safia’s techniques.

Jason?

I am going to not do soft skills this time, but I’m actually going to go with making myself a breakable toy, because I just feel like coding up something. This reading this really gave me the itch to go and do it, and so that is what I’m going to do, is build something and toss it on GitHub. The recommendation is making a Wiki, so maybe I’ll go down that front because it’s been a long time since I’ve built that. So, maybe using tool sets that I’m aware of I can go and build something along that line.

Can you make a spoiler-free wiki for TV shows?

(laughs)

I will see what I can do. I guess if I create it, and you’re the only other person that knows about it, then I mean there’s not a lot of room for there to be spoilers on it.

(laughing)

So, I want to continue doing something else that I just started. So, inspired by Safia, I started reading the source code for Redux. Just barely-

Oh, cool.

And I wrote one blog post about it, and so I want to do that more, because I just barely dug into and read another blog post about it.

Mine also relates to the “Use the Source” pattern. I mentioned earlier that I wanted to go through some of the things that I learned from reading the node.js base and actually use what I’ve noticed to create a pull request or modify the code in some way. So, that’s going to be my to-do action for next time.

Okay, cool.

Thank you so much for listening. We’ll be talking with author Dave Hoover next time. There’s still a chance to win one of the 5 signed copies of the book. You can head over to orbit.fm/bookbytes/giveaway and the instructions there will ask you to leave a review on iTunes.

I just wanted to leave one of the reviews we got real quick. We got a review from user name Sudbla. S-U-D-B-L-A

“Great concept. Very timely. I was looking for a good developer podcast. This seems like a good team of 4 podcast presenters and also good book club to join. It’s always easier to keep momentum when you’re reading along with others.”

Thanks for that review. Yeah, I definitely agree. I’m glad that you can read along and keep momentum.

You can follow this show on Twitter @bookbytesfm and you can find the show notes and transcript for this episode at orbit.fm/bookbytes/4.

See you next time.

(Exit Music: Electroswing)