(Intro music: Electro Swing)

Hello and welcome to BookBytes. This show is a book club for developers where the four of us come together and talk about a book we've all been reading and discuss it with one another. This week, actually, it's only three of us because Jen is too sick to knit. This week we're discussing chapters 3 and 4 of Apprenticeship Patterns by Dave Hoover and Ade Oshineye. And we're also giving away 5 signed copies of that book. So head over to orbit.fm/bookbytes/giveaway to enter to win that. I'm Adam Garrett Harris.

I am Safia.

I'm Jason Staten.

So, this week, we're going over chapters 3 and 4 of Apprenticeship Patterns, but first I want to see if you have anything from last time where we went over chapters 1 and 2 that you wanted to talk about.

I did have something. It was actually a bit of an introspective moment for me and it kind of related to something that was said in the text as well. I think last time we were talking about some of the lessons that were outlined in a particular chapter and I said something to the effect, "Oh. I thought most of these were really obvious." And I was going back and thinking about the conversation we had and all of the different ideas that were flowing and one of the lessons that was highlighted in Chapter 2 was "emptying the cup" and I realized that that comment was kind of indicative of some of the behavior that was highlighted in that chapter, which is coming into a situation with a lot of preconceived ideas and assumptions. And then I stepped back and I was like, "Oh, wow I should have definitely tried emptying my cup a little bit more before I read that chapter, and maybe been more open to some of the ideas that were in it." So that's just a realization I had where realized that I hadn't completely internalized one of the lessons that was in the chapter.

Oh cool. Yeah that's kind of meta to empty your cup before you read the chapter about emptying your cup.

Yeah.

I think that's one of the reasons why early in this book it talks about being able to have just the patterns because they apply again in different situations. And so the first situation, you reading it fresh was probably you reflecting back on previous experiences, but then you going and reading it again was reflecting back on your experience after reading the chapter. That itself is the practical purpose of re-reading these patterns and seeing how they apply.

Yeah that's a great a great point, Jason.

For me one of the things that I thought about and actually put into action, or at least got rolling, at at work is ... My team that I work with, I am the technical lead over them and one of the things that I wanted to do was start a bi-weekly technical discussion, and part of that was putting out a survey to say, "Hey, what are the things that we don't know about at the company or what are black boxes to us?"

That was one of the ways I actually went and said I'm going to expose my ignorance as well as confront it, to say, "I don't know these things about my job and I will find out what those things are. As well as if somebody else on the team doesn't know what that is, I will attempt to do some of the digging to find out what that thing means because there are plenty of things that are unknowns to me."

Nice, yeah "expose your ignorance" is one of my favorite patterns in that chapter.

I hope that it will work out over time and it and I'm sure I'll come out at least having interacted with more people within the company, or more developers that work on things that are unknown to me. To go along with some of the things that we've covered in these upcoming chapters we're going to talk about, maybe I'll find some mentors or kindred spirits along the way.

Yeah, so one of the things from last time that I did is the "retreat into competence" pattern. So I've been building the website for this podcast and some of it's new technology, but I just realized as I was making it, how much faster and better I am at it than the last time I made a website. It's been a while since I made a simple website and it's just very refreshing to see how much more easily it comes and how much better I am.

There's definitely value in doing that. I know that sometimes recreating a blog or a website can just be churning, but also at the same time there is that satisfaction. I've definitely seen you cranking away at stuff in the GitHub. I commend you for that for that effort, Adam.

Thanks.

Okay, so what about chapter 3?

One of the things that struck out to me was about the first section of this chapter, which is titled "The Long Road" and it's just about envisioning your career on a long-term basis. And the comment that stuck out to me about it actually appeared a little bit later in the chapter, just a couple of pages after and it's this quote that I pulled out. It's on page 46 for anybody following, and it goes something like this: "The people who walk the long road are not the heroes who sprint for a few years and burnout. They're the people moving at a sustainable pace for decades."

And that quote really struck with me just because I feel like, oftentimes, I am the person who sprints for a few years and burns out, or I have a personality that makes me susceptible to that particular characteristic. So, when I read that quote, it just really hit me. I was like "Whoa, I can see myself in this quote." And I can understand the value it's presenting in choosing a sustainable pace for decades versus just working really fast and really hard for a few years and then totally fizzling out at the end.

I think that it's really key that you mentioned that you recognize that about yourself, Safia. That you know that you can get yourself into a position of potentially burning out. Noticing that about yourself before it actually happens is definitely a good way to prevent long-term detriment.

Yeah.

Yeah so one of the things this chapter talks about is making a plan to be a software craftsman for your entire life rather than moving into management or some other role where you're doing less coding. What did you think about that? Because a lot of people see that as the goal to become a manager or CTO.

Yeah, that was a really interesting section to read for me. At the moment, I'm actually interviewing for my first post-college career. So, I've been talking to a ton of different companies and usually one of the first things they ask me is, "What is your long-term career goal?" And my answer is generally, "I want to be in management and leadership. That's where I feel most comfortable, just based on some of the experiences I had with leading things in open-source and in other places."

So when I read that particular section, "The long road" that said to plan to be a software craftsman or craftswoman on a long-term basis, I thought that this doesn't really align with the career trajectory that I've chosen for myself. I sat and thought about it for a little bit and I thought, to be a software craftsperson, does it have to be your career? Can you be somebody who is in management as your day-to-day job, but the craft of software development is something you do on your off time with open source work or side projects or things like that. And I just kind of started to think about how flexible the definition of a craftsperson is in this case. Does it have to be your job? Does it have to be something you commit x number of hours a week? Who is this label open to? Did that make any sense?

Yeah! And there's also the patterns in here of "Draw your own map" or "A different road", which "Draw your own map" means not everyone's path looks the same and "A different road" means not everyone has to be a programmer for life. And that's totally okay. And you can define it for yourself like you were saying

It does mention that that is the focus of this book. So it's not necessarily even in the form of, it's the one way, like you said, drawing your own map and finding the way that you progress in your craft. And I would say that, having had a touch in management (only because it was a small startup company), it is nice to get the exposure in the context there, but even though you may be filling that role, that doesn't necessarily mean that you're out of the craft or that you're not able to grow your skills there. But actually, I think having that context can sometimes just be you in a leader role for a period of time as well.

Yeah.

So, for me, that section talking about trying to be a programmer for as long as you can rather than taking a management role just because it's a promotion and more money was actually really comforting to me, because that's what I want to do and I felt like I was supposed to eventually move into management. And the fear was that if I'm an old programmer, no one's going to want to hire me because they think I'm old and my skills are out of date.

I think it does continue to go on to talk about ways that you can help with that. There's the pattern of "retaining concrete skills" that can help you with remaining relevant. I think where you can really get caught up in the old programmer ageism issues is when you just get yourself stuck on a single tech or something and don't want to change from there because you think you know enough from where you're at.

Yeah I think earlier in the book it talks about being a craftsman versus being an expert. An expert is just good at only one thing and that's the only thing they know how to do and if that thing becomes out of date then they're kind of irrelevant. So yeah, I like how this book constantly pushes you to... "Hey you think you're a journeyman. Well, have you done this on multiple platforms? How about learning a new language?"

It says if you're still going to be working in 20 years time then you can do anything. Even people that we look up to like Donald Knuth and Linus Torvalds. Their set of skills are attainable by us in 20 years time. Because that is a ton of time, but also keeping in mind that they are continuing to to go forward too.

Yeah.

So I'm curious to know, as both of you have been in the industry for a little while, when you started off your software engineering career with your first job, did you have a chance to sit and create a long-term road map for where you wanted to be? Or what was the experience like for figuring out what your experience in tech was going to look like?

Hmmm. I didn't really map it out. And I felt really inadequate for a long time. I didn't have a mentor. I kind of stumbled into being a front end developer because I started off as full stack. And then my second job I was hired as a PHP developer and ended up not writing a single line of PHP at that job. I did all JavaScript. And then that led me to a really good job at Domo as a front end developer, where I felt like I really could hone my craft and rub elbows with a lot of really great developers.

Now I feel like I'm at a point where I can, and should, map out at least some ideas. This book doesn't say you make concrete plans. One of the exercises is that you write down several possible job roles and then on each of those, other ones that you could go to from there, and then it keeps branching out to all these different possibilities. I'm starting to do that. I'm starting to think I should pick up some more languages, some back end stuff. I want to be more diversified now.

What was the experience like for you, Jason?

I could agree that I wasn't a long-term planner through sorting out my career. I guess I interviewed and acceptable a job offer on a Friday and then started work the following Monday. So, I just got dropped into it, and actually went into a company where, when I started, the people around me were really brilliant. And we're going to jump into it more in the following chapter where it talks about being the weakest person on the team, and I certainly felt like that coming in, questioning, "Why am I getting paid this much? I don't even know why I'm here."

Because I was put on a on a team that had two people in particular that but I felt were kind of mentors for me, it really pushed me to level up. I was able to out feeling like I did know what I was doing a bit more. When I left that company I actually switched to go to a small startup where there was 1 other developer and 5 people total in the company at the time, and the other developer eventually left, and so I lead up development there on my own and helped build the company and roll it along.

So, I got the flip exposure of not having an internal company mentor, but I did get the exposure of having a big title of Chief Architect and got to do everything from systems management all the way up to designing on the front end. And I know that the only reason that I was successful there was because of my prior mentorship. Even though it wasn't necessarily formalized, it was rubbing elbows with those people in particular that pushed me through that, and then the pendulum swung back.

I'm at Domo at the moment and am now with a much larger company and I'm trying to progress myself as a multiplier for developers that are there. So, instead of only being focused on producing features, which is a typical day-to-day goal for helping the company succeed, I also aim to be personally satisfied by helping other people in the company improve. And so, I guess it hasn't really been charted out super well and this book has made me reflect on that. I think I need to get a little bit more concrete on some of that just to to make sure that I am following a trajectory where I will wind up in a place that I really do want to be. But so far, That's been my path.

It seems from hearing both of your stories that it's kind of striking the balance early on with going with the flow and then trying to channel that flow into some sort of loose road map.

Yeah, I mean at some point I realized I really loved JavaScript, so that's what I wanted to go for. What about you?

Me?

Yeah.

It's so interesting for me because... Well I asked for your experiences because I don't technically consider myself... this might be a terrible thing to say, but a real software engineer. Since I haven't officially worked full-time in the industry at a 9 to 5 as a software engineer. I've done a lot of work in open source. I've worked at a ton of internships. I freelanced a ton. But I've never actually filed a W-2 as a software engineer. Which just might be an irrelevant distinction, but I haven't really had the opportunity to stay at an organization for a really long time and develop the kinds of mentorship that are useful.

I think the tough thing with being an apprentice in the literal sense, like some companies will have apprenticeships or internships, or just short-term employment opportunities, is you don't really get to lay down your roots anywhere. And although I've had a couple of people at the different organizations that I've worked for that I've connected with, that still mentor me, not so much in the technical sense, but general life and career mentorship, I feel like I haven't really had the chance to join a team, work on a product for a really long time, and get the hand-on-hand mentorship that you might get in a corporate environment. I think the closest I've gotten to it is in open-source where I've known people for 3 years at a time and have had the chance to get mentorship from them and have them kind of guide the road that I travel on with my career.

So yeah, I guess I have had experiences where I've had situations where I didn't really know where I wanted to go with my career, but I've had people help me, especially in open source. I think that's my version of a full-time job throughout my career as a college student, is I've done a lot of open source and that's where a lot of my experiences and insights come from. And they're a little different, I'm sure from what you've experienced in a full-time jobs, but I think a lot of the stuff intersects. The lessons learned and the concepts. I don't know if that answers your question. I'm still trying to figure out my path looks like so I don't have a completely solid answer.

Yeah

I would say firstly a paycheck does not determine if you're a developer or not, Safia. You're definitely a developer. I mean, being an open source contributor and being as active as as you are in the community, I think you are definitely a developer. And so, do not sell yourself short.

That's true.

I am impressed with your path.

Yeah, and it reminds me of a quote from the book that says, it's under the "Use your title" section, it says, "Do not allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness." And if you're in an organization then you can use that to gauge your organization rather than yourself. So Jason, you were mentioning, you're a chief architect, but that's a way to gauge your organization more than yourself. And so, Safia, I don't know what you'd consider your title; student, open source contributor, whatever.

Yeah, that's been a great source of confusion for me over the past couple years, just because when you introduce yourself everybody wants ... "What's your role? What company are you at?" I'm just like, "I'm not sure, I'm just here chilling." So ...

Yeah, and I think that's kind of a distraction, because like Jason said, you are a developer.

Yeah. So I have a question regarding the title thing for you folks.

Yeah

Did you get the sense that at the particular organizations that you've worked at throughout your career that titles did kind of have an outsized role in the way that people worked and interacted with each other? Was there kind of the senior folks, and the junior folks, and distinctions in rank and management? Or do you feel like titles are not actually a big thing at the places that you've worked and the experiences that you've had?

I don't think they're usually that big of a deal what your official title is. There's generally more of a sense of a cultural title for people. A sense of cultural respect. Jason, when I was a Domo, you weren't a senior engineer, but I felt like you totally were. You could just tell in the organization who's more junior even if they have a normal title, or who's more senior even if they have a normal title. Then sometimes people more from normal to senior and you don't even know, but you still ... It's still someone that people look up to.

I think I go along with that same vibe of it doesn't particularly matter. I don't know what most titles of developers are that I work with, but I kind of know that they are in a position of responsibility, maybe over a specific domain. I do know that externally, at least in LinkedIn sometimes, titles matter a little bit, even if in the wrong way.

For an example, previously when I was a chief architect, I once actually had a recruiter contact me about an actual architecture job, of like building a building, and I told them that they had definitely picked the wrong person, because using Agile for constructing bridges may be harmful.

So... There is a little bit of outward perspective, but definitely don't get too caught up on it. Like the book says, it kind of describes how you may be perceived in the organization, not necessarily by your peers, but by ... Whether it be accounting, or high up execs, if they don't have an individual relationship with you at the time.

I think one thing that stood out to me, or one pattern I liked, it was the mentioning of "craft over art" and saying that while we can produce really impressive things, it's important to have the things that we make be useful. It's not that we can't make things that are not useful, we can certainly make codepens that create amazing things only CSS, but we should also have a focus of creating things for our customers, being potentially as the companies we work for, or who we're producing things for, and making that fine, but always keeping the focus on having a use in what we ultimately create.

Yeah, I love this Richard Stallman quote at the beginning of the "craft over art" pattern, and he said "Craft means making useful objects with perhaps decorative touches. [And] fine art means making things purely for their beauty." That's kind of cool to me too because my wife, in the last couple years, she's moved from a fine art background to a UX background, where she went from making things just for beauty's sake to actually making things that are useful for people.

I quite liked the point made in this chapter with respect that you sometimes have to produce satisfactory work, or things that make your customers happy, even if you don't feel like it, or of it doesn't rise to your standard. I've definitely been experiencing that a lot with one of my side projects of just having to sit down and ship things to customers even if it doesn't look perfect or as good as I would like it, to me.

And I personally think this might be one of my strongest patterns, or the pattern which I uphold the best. It's just kind of valuing making people happy with the code that I build versus satisfying my own engineer who needs things to look right, or be efficient, or be perfect. I think that, in large part, stems from the fact that when I entered the field, and I think a lot of people who enter the field, come in wanting to solve problems for people, or to build apps to fix things or address issues. I think that kind of using software to serve people, makes it much easier to view it as a craft, than art.

Yeah, this section reminds me of an article I was reading this week on CSS-Tricks by Sarah Drasner, and it's called "The Art of Comments" and it's defending the use of comments, because there's a lot of stuff out there saying your code should be so beautiful and elegant that you don't need to write any comments, and one of the reasons why she says you might want to write a comment is if you're in such a hurry, you have a lot of pressure to get something out there, so you just get something that works. You might want to write a comment that says something like, "This isn't my best work, but we had to get it in by the deadline."

So, that's cool to see that that's totally fine sometimes. There's value in just getting it done for the customer.

Mm-hmm (Affirmative)

I think there's the flip side of that, too. Of also being a responsible craftsman as well. Of only hacking things together to get them out as quickly as possible. So, if you find yourself writing lots of those comments, or if you find yourself seeing them as you are working on code, going back and taking the time to clean up some of that mess you may have made in order to ensure that your customer really stays happy because you can continue to produce things quickly, and you haven't coded yourself into a corner.

Yeah, totally. I think that's one of the reasons why you would write the comment, as a note to yourself that this is okay to refactor, and should be refactored.

Okay, so chapter 4 is called "Accurate Self Assessment" and actually, I don't have a good way of explaining how these chapters fit together.

It definitely leads off with the mentioning of potentially becoming a big fish in a small pond, or outgrowing the current situation you're in, and not allowing yourself to be comfortable with your skillset, or your ability, and instead saying, "Yes, I've improved" but also seeing, "I can go further, and in order to do that I need to take steps rather than just idling by in the current state I'm in."

Yeah, so the first pattern is "be the worst", which you mentioned earlier, Jason. I actually read this book right before leaving a really, really small company where I was one of two developers, so I was a big fish in a small pond, and going to Domo, and that was one of the big reasons why I wanted to go to Domo, because I knew that at a larger company I would be surrounded by lots of talented developers and I definitely felt like I was the worst there, for quite a while, which was great. I got to learn a lot, and grow a lot.

It's interesting that you mention that, Adam, because I actually brought this pattern up, in a way, during one of the job interviews that I had recently. They were kind of asking me, "What do you want out of a career?" So on and so forth, and I was like, "Oh, I want to be somewhere where I can be the worst." I probably should have cited the book, but I just explained to them a lot of what book highlighted, and it kind of helped me see this by highlighting it, that my learning has stagnated at a certain point, just with the kind of open source work I've been doing lately, and some of the work I've been doing from an academic sense, and some of the personal side projects that I'm pursuing.

And I was like "I want a challenge to invigorate my learning and a place where I can be the least competent person and have to catch up with everybody." So, yeah. I'm also using this pattern as I transition into a career.

One of the things I love about this pattern is, just because you're the worst, doesn't mean it makes you feel worse. It actually makes you feel better, because everyone else is bringing you up.

Yeah, that's a great way to flip the perspective and look at it.

I think too, your last line that you mentioned, Safia, about making sure that you want to be the worst, but you want to catch up. That is the key part of this. Something that's mentioned in it is when teams bring on somebody who is going to be the worst, is that they are inherently taking on a risk.

The book actually makes a reference to Jamie Zawinski's resignation from Netscape, or the Mozilla project, at the time. It's a pretty blunt paper. I actually enjoyed getting side tracked and reading that, because it's called "Nomo Zilla." But he specifically says there is a factor ... He talks about how Netscape was really innovative at the start of its time, and said that during the first few years they revolutionized the world, they made a face to the internet. Then from '96 to '99, it was more of a coasting type situation of the company, it wasn't continually improving. They said that one of the factors involved is that you can divide our industry into two kinds of people; those who want to go work for company to make it successful, and those who want to work for a successful company.

It was claiming that the latter was becoming more common at Netscape at the time, and essentially not bringing on people that are going to push themselves to keep up with the really strong developers there, and instead just saying, "Yeah, I'm here. I'm at Netscape and I've made it." Instead of having the perspective of, "All right, I'm here. This company has done a lot of awesome stuff, but I want to push myself and this company further."

Yeah and I think that's definitely one of the reasons that I've focused a lot of my career search on small to midsize companies, just because I feel like they are in a better position to employ or attract the kind of people who want to make a company successful and have that drive and innovative nature. I would say it's really hard to find that magic that Jamie talks about that was at Netscape when he was there, and that he felt was lost, is really hard to find in a company. I think that's what keeps you, as somebody's who's hired as the worst, or somebody who's maybe less skilled than the other engineers, keeps you from staying in that position, is having some magic to invigorate you and inspire you. So, that was a pretty cool read.

I think one other quote from that paper, along with the line of working for a small or a midsize company, is kind of a bold statement, but it says, "... big companies just aren’t creative. There exist counterexamples to this, but in general great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is.

Like I said, it's pretty blunt, but I could see the effect of that when you have a massive group of people all surrounding to come up with one interface for a modal or something like that. I've heard of developers who have been in that situation, and they are just ... They can't handle it, because they're just stuck. They're not moving forward, or feeling like they're making any real impact, and so they're not motivated."

Yeah, and I think that that kind of connects with the "kindred spirits" pattern that was discussed in the book, which is essentially that you might find yourself in a position where you're stranded in an organization and you don't have any mentors, and I think despite the fact that large companies have more people so there's a bigger chance you might interact with somebody who might end up being a mentor, I don't think there's as much of an ability there, for it to emerge. The organic friendly mentorships that you might find at smaller organizations, that I think are much more fulfilling than some of the structured mentorship strategies they set up in larger companies and things like that.

I do, definitely, think it's important to get in contact with those outside, even for the influences that they can expose to you outside of your company's culture or its current tech stack. I had a personal experience with going to a Ruby group that was in Salt Lake, and one particular meeting that I was kind of blown away with, is a guy came there and presented on Clojure, and he had this whole room full of Ruby-ists who were ranting and raving about how they didn't like parenthesis, and he held his own against the entire room about how he thought it was a beautiful language and he was so productive in it because of reasons X,Y & Z. That was enough to draw my interest, even in the language, to even look at it, and so by going and stretching myself outside of just the walls of the company, I was able to go and get a little bit of insight on that front. And while I don't necessarily write Clojure now, I did go and explore it and get the influence of it in my craft.

So I'm curious if y'all have had experience with the "find mentors" pattern, because it's saying here that its exceptionally rare and it can be difficult to tell who's a master craftsman and sometimes you have to scratch and claw your way into the lives of master craftsman.

Yeah, my approach has always been - and maybe I need to rethink this - but my approach has always been that most people in a senior position, or with more experience than me have perspective to offer, and valuable mentorship. So, I think I don't necessarily go out seeking master craftsmen to engage with in a mentorship relationship, I'll just hear anybody out and pick and choose different ideas from different people.

Yeah, I don't know how I feel about the scratch and claw your way into the lives of master craftsmen.

Yeah and then it says you should be grateful for whatever you get.

Yeah ... It feels a little, I don't know, I feel like it's promoting that elitist heroism that kind of exists in tech.

Yeah, I see a lot of people complain on Twitter that people will ask to meet up with them and not explain why. I think that's the biggest complaint. I think a lot of people are open to meeting with people, and open to mentoring, but you need to be more specific about what you're looking for.

Yeah.

Stephanie Hurlburt on Twitter, posted something pretty recently about reaching out to people in networking way, and she actually posted some really nice examples. I'll pass the link over to you, Adam, but it gave examples of ways to email or tweet at somebody to say, "Hey, I want to meet up, here's why I want to meet up, and are you available at this time?" And most people, if you keep it short and to the point, they might read it, and as the book says, the risk of being flat-out rejected and saying, "No, I don't want to help you at all." Is pretty low, and even if it does happen, the payoff from it can be huge, even if you can get a short moment of somebody's time. Not even necessarily being a master, but rather anybody that you want to learn from, or gain perspective from, reaching out to them can ... You either get the value in it, or you're in the same place that you're at.

I'm curious to know, have you ever been in situations where you have had to reach out to somebody who you considered a master craftsman, for advice or mentorship, and how did that experience go for you? How did you reach out to them? Did they respond? Did the relationship end up positive? I can share one if you want to take some time to think about it.

Okay.

Please.

Go ahead.

So this happened the summer after my freshman year of college. I was interning in San Francisco and I had gone to Dropbox for some hackathon they were doing, just for the interns in town, and my team ended up winning 2nd or 3rd place at the hackathon, and I decided to use that win as an entry point to get a meeting with Guido van Rossum, who's the creator of the Python programming language.

Wow.

Yeah, and that was so nerve wracking for me. It was one of the first times in my life that'd ever emailed a "big deal" person for something, so I just sent him an email and said, "Hey, I was at Dropbox's offices a couple of weeks ago for an event. You weren't there, I was wondering if you wanted to grab lunch. I'd love to know your experiences building the Python programming language, because I'm interested in building programming languages."

He actually responded. He was like, "Sure." and it ended up being me and the teammates from the hack-a-thon, and we had a great lunch with him. The one thing that I did, going into the lunch, was actually write down, or rather think up a list of questions that I wanted to ask him. So I had the opportunity to show him that I wasn't wasting his valuable time. We kept a pretty great conversation going and I got to learn a ton of interesting things about his experiences building Python, and the language he tried to build before Python that was the precursor, and the early days of Python.

So that was the one experience that I've had, and I think the one thing that I got out of that, with the respect to how you reach out to people, is just be very specific and enthusiastic and curious. So, that was a really cool and fun experience.

Yeah. Jason, do you have any experience with that?

I would say my closest experience to that would be at the first company that I worked at. We adopted the web framework FubuMVC, which is just a C# alternative to Microsoft's ASP.NET, and it was a really different approach to building out web software. When we adopted it, it was 0.1 or 0.2, really early in its life cycle. The developer who had created it, Jeremy Miller, was a very impressive mind to interact with, and because it was so early on there was a lot of open source, back and forth, and getting his perspective on how things worked.

It was enlightening to have him be able to do things like review a code contribution that I'd made, and give a better approach for handling the problems that I was working on, and just really having somebody who understood things like "Design Patterns" from Gang of Four really well. He could go and look at a problem and say, "Yeah, that's actually a fit for the visitor pattern." and that's not something that I, myself, generally find myself thinking of. Actually, he wrote an excellent blog post that I was able to refer back to, because he was one of the ones that made me understand that.

So, while it wasn't a direct, me asking to meet directly with him, but through the open source exposure I was able to be in contact with him. And actually, shortly after I left the company, they hired him on at the company that I was at, so I was like "Ah, I just barely missed rubbing elbows with him." But I did in the long distance sense.

Cool. Yeah, so when I first moved to Utah, I realized there were all these meetup groups here about all sorts of programming languages and things. It was the first time I was in an area with a big tech scene. So, I just started going to as many meetups as possible, and one of the meetups was just that you would get together and you work on your side projects, just all in the same room, and you ask each other questions or help each other out. I remember there was a guy there who was a technical co-founder of a startup, and he looked over my code a little bit one time, just a few seconds really, and helped me figure something out, and we connected on Twitter. I remember he said one that I had some "technical chops" and that felt really good to hear him say that. That really motivated me to keep going as a craftsman.

I think that's something we could, in general, use more in the field is praising each other of our accomplishments.

Yeah.

Yeah I think I saw a tweet by David Walsh that was something to the effect of, "Nobody thrives on low self confidence, so do your best to boost each other up, and pulled request reviews and things like that" and I thought that was a really great tweet and was along the same point that you were trying to make, Jason.

Yeah, I try to use a lot of positive emojis in my comments on GitHub and in tweets, because it's really hard to tell the inflection of the person when it's just text. So, the thumbs up and the ta-da and the clapping emoji, I use those liberally.

Mm-hmm (affirmative).

So, I really like this "sweep the floor" pattern, which is you're new to a team, you're trying to prove yourself, you want to make some sort of useful contribution and prove your worth, so I always find it useful when there's someone joining a team, or if I'm the person joining the team, where you're not really familiar with the code base, you're just looking at it and trying to get familiar with it at first, but you can at least, with fresh eyes, look at things and fix some little CSS things, or upgrade a dependency, or update the readme or update the onboarding documentation. I just love this pattern. It's something you should definitely be aware of when you're joining a new team.

Yeah, that's something that I've employed a lot, especially when I'm trying to join a new open source project, to one of the common tips is just pick the low hanging fruit, or easy to solve issues in the project and address them. So this is actually a pattern that applies really, really well in open source.

The one place that I've struggled with it, personally, is making sure that I don't stagnate and become just the person who sweeps the floor all the time, just because I feel like I've definitely been in situations where I've been the person who takes on small tasks and upgrades and things like that, and then people just piled those kinds of things on me, even though I probably was capable of doing much more complex things.

So I think it's a tough balance between sweeping the floor to get your foot in the door, but also making sure that you're not permanently doing that.

I think that there's value in trying to get that part of culture of your team as well, that those small tasks that are maybe put on the side because of other, more pressing priorities, that they - once again, going back to the praise thing - that they are celebrated to where if somebody goes and makes your test suite run twice as fast because they took out all your time outs or sleeps or whatever, and made everything still work, or they just generally improve the project, making sure that that's a thing that the team you're on is concerned with.

It's less of a thing when you're brand new on it, you may not necessarily have that influence, but even when you are more experienced on a team, or you've been on it longer and there are newer people, also being willing, yourself, to go back and do the floor sweeping thing, and say it's not above everybody. When others do it, praising them, but also allowing yourself to step back and do it, so you are allowing other people to step up, kind of like it mentions in the "finding mentorship," is when first you're searching for mentors when you're new, but you also have a responsibility to help others level up, and I think part of that is recognizing that if there are people on your team that are stuck in the role, or happen to only be picking up smaller things, to give them something a little bit bigger. Let them jump off the deep end and let them try their hand at something a little larger.

Yeah, I think it's the responsibility of people more experienced on the team suggesting bigger items for new people.

Yeah.

Just saying, "Yeah, I think you can do this" will give them more confidence to try it.

Yeah.

Yeah, I also liked what you said about praising within your team, those little sweeping the floor tasks, because those aren't providing any business value. No customer's going to notice, no executive's going to notice, your manager may not even notice or praise that, but it's still important.

I think, too ... I don't know if we spent a lot of time on the "nurture your passion" part, but sweeping the floor can definitely help with that, too. If you're on something that's a slog to deal with for one reason or another, that by doing some of that clean up work and making everybody's lives easier as developers, that can, personally, improve your motivation. The test suite example that I gave, there was another member on my team that did improve our test suite run time pretty dramatically, to the point that other people do want to write test on the project now, where previously they didn't because they took so long to write and run.

Yeah, it's amazing. That's cool. Okay, so anything else in this chapter?

No, I think we got to the end.

Cool. I like at the very end it wraps it up by talking about humility versus ambition.

Mm-hmm (affirmative)

Or not really versus, but both of those things are good. You want to have ambition but also be humble.

Wise words.

So what are some action items that you want to work on that we'll talk about next week?

I would say one thing that I might end with is an action item for myself to take out of this, just so I can have some accountability. So, for me, I would say that I would like to try the suggestion at "finding a mentor" or taking the approach of reaching out to somebody who maybe intimidates me a little bit, or I'm intrigued by their work, and set up some sort of discussion with them, whether it be a Skype call or something, within the next time period before our next recording. I will definitely set a goal to do that and I will follow up next episode.

Okay.

So I've actually been really in the zone with a lot of the patterns that we picked up in the last episode of this podcast and one of the things I've been diving to a lot, is "jumping into the deep end." More recently I've been finding ways to push my learning forward, and just really aggressive, high speed ways, and it's been really fun to jump off the plateau and go into complete free fall, and also blog about going into that free fall and what I'm learning. So that's something I want to continue doing, jumping off the deep end and continuing to try out difficult problems.

One thing I want to do is, under "sustainable motivations" it says to write down a list of things that motivate you. Write down a list of 20 things and narrow it down to 5. I really want to do that, because I tend to burn out based on what my motivations are, so I need to find motivations that are really sustainable.

I look forward to hearing that list.

Thank you so much for listening. We'll be discussing chapters 5-7 next time, and then we'll be chatting with author Dave Hoover. Don't forget to enter to win one of the signed books over at orbit.fm/bookbytes/giveaway. The instructions there will ask you to leave a review on iTunes.

I actually just wanted to read a review really quickly. We've got a review from username: Base SixtyFour.

"Excited to see this happen. Looking forward to future episodes."

Thank you so much Base SixtyFour for listening and leaving that review! I hope that this is a useful podcast for you.

You can follow the show on Twitter at bookbytesfm and you can find the show notes and transcript for this show at (orbit.fm/bookbytes/3)[orbit.fm/bookbytes]/3

See you next time.

(Exit music: Electro Swing)