02:36 - Responsibility and Communication

12:10 - Onboarding Experience for Remote Employees

15:55 - Measuring New Employee Metrics 

17:41 - Onboarding Onto a Team vs Onboarding Onto a Project

20:51 - What it Means to be a Senior Developer

29:20 - First Impressions and Team Member Categories

33:26 - How do you decide what you spend time learning?

40:57 - Code Reading

Picks

Private Internet Access (Avdi)
Darkest Dungeon  (Avdi)
imprint (Coraline)
The surprising truth about which personality traits do and don't correlate with computer programming skills (Coraline)
TALON Bluetooth Wireless Headphones (Jessica)
The Penderwicks: A Summer Tale of Four Sisters, Two Rabbits, and a Very Interesting Boy by Jeanne Birdsall (Jessica)
Reading to your kids (Chuck)
LinkedIn (Chuck)
RubyTapas (Chuck)
Elixir Sips (Chuck)
Avdi's Newsletter (Avdi)

 

Hey everybody and welcome to episode 233 of the Ruby Rogues Podcast. This week on our panel we have Jessica Kerr.

Good morning.

Coraline Ada Ehmke. I'm Charles Max Wood from DevChat.TV. And we're going to start out talking about onboarding new developers. Coraline, you brought this up. What kind of brought you into this when and [inaudible] about it?

I just started a new job. I'm working at healthfinch now, which is a company that makes software for automating [inaudible] processes for doctors and nurses. And having just gone through an onboarding experience, I realized how critical it is that the onboarding experience be as positive and productive as possible. And I wanted to see, if other people had some ideas on how to make that more effective, [inaudible] and also talk about what [single] challenges are both from the person who's being onboarded and as the [inaudible] doing the onboarding.

I can tell you how not to do it. I've been through that a few times.

Yeah?

Yeah. I had a couple of [inaudible] a year or so ago. And they were, basically it was, “That's the backlog. Go for it.”

Wow. So, just starting out on bugs and features?

Yeah.

With no context?

Right. Somebody spent a half hour walking me through the code and then, yeah. And the other thing was everybody does different parts of the system. So, talk to somebody before you actually pick up a feature. So, it wasn't even that I could just pick up a ticket and run with it, or pick up a story and run with it. It was actually just...

Talk to all these people or one of these people that you don't know who it is and you barely met them?

Yeah. And make sure that they're not already working on it, even though it says that it's available to be claimed in the backlog.

So, do you think that was a reflection of the general culture of the engineering [inaudible] people?

I don't think I ever did quite find [inaudible] there. I gave up on [chuckles] the [contract]. But it was really rough because I couldn't actually contribute anyway. I think I finished three or four stories in three or four weeks. So, they weren't happy with me because I wasn't contributing. But I'd get halfway done with the story and then somebody would jump in and say, “Oh, I've already been working [on that].”

Oh, yeah. I've been there, too. Yeah. Or, “Oh, no. I just rewrote all that code and didn't tell you and didn't even delete yours so you didn't even know and you kept working on it for a week.”

Yeah.

And there's an important point here which is if you start on a new job or a new team and you don't feel productive and they don't think you're productive, that's not your fault.

It's pretty much never your fault because you're the new person and they're the ones with the information. And onboarding a new team member is the job of the team. You can't onboard yourself.

Yeah, I don't want to absolve anyone of any blame if they don't try.

Yeah, yeah. [Inaudible]

But otherwise, I totally agree with you.

I think there are some responsibilities you have as a new dev. And that is [inaudible] so the team can do the [inaudible]. I think that you have a responsibility to ask questions when you don't understand [inaudible]. You feel like you're asking very simple or very stupid questions, it's still your responsibility to get that information. But that has to be a collaborative and cooperative effort.

Yeah, I agree.

Right. And if you ever ask any question and then they make you feel stupid, well that's seriously defeating. Because it tells you not to ask questions. And if you can't ask questions then you can't learn anything and you certainly can't do [the job].

Yeah, I agree.

So, in your experiences [inaudible], who [were] then the people who did the onboarding? Did they pick some [inaudible] a senior engineer to [create] sense of the entire system or somebody that's distributed across the team? Or even, this just came to mind, a newer person who's gone through that same experience of trying to learn this [inaudible] complex system?

I think it really depends on the team and how they approach this. So, I have worked on teams that were successful at onboarding because they essentially put you on the parts of the system that were easy to pick up. So, they're just some kind of crawler or bot or some self-contained part of the system, an adapter that you could write that you basically only had the [inaudible] endpoints on one end and the endpoints on the other end, and not necessarily have a total and complete understanding of the entire system. And that gave you an understanding of at least one edge of the system. And then they could bring you in after that. And so, in those cases the newer people can bring you onboard because they could introduce you to that part of the system.

A few other things though that I've seen or that I've been around are places where you have to understand the whole system or at least understand the overall approach to the problem. And in those cases, usually a guide, I don't know if they need to be a senior person or not senior person or [the newest] person or whatever, but they at least need to know where some of the [land mines] are and then who to refer you want to do something and you have a question. So, they can tell you where the answer is [if they can].

I think one of the things here is that a lot of people, they have a lot of junior developers entering companies now as a result of bootcamps and programs like that. And [inaudible] people in a bootcamp [inaudible] application development. And when you come into an actual company and actual workforce and see your first legacy app, [inaudible] overwhelming. And actually, we don't want monoliths anymore. We want generally service-oriented architectures which I hate that term. But...

Especially if you're presented with a dozen services. [Inaudible] know where to start to implement a feature and what things, what dependencies there are between the applications. The minefield is multiplied in that case.

Yeah. One thing that's tough about services is the connections are there, the dependencies are there, but they're often not documented.

Exactly. Documentation is something that [inaudible] in general. And I think especially the services, [inaudible] effectively document this. It's either [inaudible] this is the API call and this is the [inputs spec]. Or else it's so broad that you can't map it for individual services.

Yeah.

And that is [inaudible] is that you also get in there and it's like, “Oh, well everybody knows this.”

Ugh.

[Yes it was].

Yeah.

That's the only thing [inaudible] against the documentation.

[Inaudible].

But everybody knows that until you get somebody new who doesn't. And then, you know.

And then they don't know what they don't know. They don't know what everybody knows. And they don't realize how contextual that knowledge is. And that's when it's really useful to have the new person writing a wiki and onboarding the next person and generally having that awareness. Or making training materials.

So, I joined Stripe four weeks ago. So, I'm also onboarding still. And [chuckles] Stripe has like, 10 new employees a week. So, the onboarding was done pretty professional. And it's definitely evolving, but there's official people in charge of onboarding. So, at the company level, there's a whole lot of sessions and informational dissemination opportunities that are outside the team. And then in the meantime, I have a spin-up buddy on my team who's working with me to get on board with the particular tasks the team was doing.

Now in this case, there's so many new employees coming on all the time that onboarding is clearly a first-class activity. It just helps that it's that obvious, because onboarding should always be a firstclass activity. It's like if you don't have deployment automation, then any change is going to be painful and you're not going to make any [good] changes and your software won't get good as quickly. It's the same thing. Your team can't grow and your team can't grow, can't get better quickly until you prioritize onboarding and training.

I think maybe one of the challenges is that as developers we tend to focus on what [inaudible] do to us and not recognize that software is essentially a [inaudible]. And onboarding is one of those areas where that becomes really, really clear that it's more about getting the person comfortable, [inaudible] contributor, and maybe less about the mechanics of the [inaudible].

Yesterday I asked one of my teammates if I could just shadow her and just watch what she was doing, and a couple of hours over video chat. And she was like, “Yeah, sure.” And then she was working on something. She's like, “I actually have no idea how to do this task.” [Chuckles]

And I was like, “Cool. You know more than me.” She's like, “Probably not.” But what she did know that I didn't was the company culture ways to find out how to do that task. Where to post in Slack, where to look on our internal documentation sites, what READMEs to read, and how to search all of our internal repos. So, it wound up being incredibly more useful to me, because instead of learning how to do one thing, I learned more about how to learn how to do all the things.

Slack I think presents some opportunities and offers some challenges. At healthfinch we have 67 Slack channels and we're just an eight-person engineering group and about a 30-person company. So, it's pretty hard to figure out, what's the appropriate venue for asking this question? Not just who the right people are, but where do you even start?

Yeah.

But Slack does have that equalizing effect too, that in theory if people are effectively using Slack and [inaudible] team or not, it does give you the opportunity to voice a question to a broader range of people who can potentially answer those questions.

Suggestion, suggestion. So, at Stripe, one of our 400 and something channels is called 'ask anything' and that's a great place. I can always go there and ask where to ask.

Yeah. That's something that I found that is really helpful is just having at least a few people who are responsive enough to yeah, take us to the right place and [direction].

[Inaudible] think the onboarding experience can or should be different [inaudible] employees versus [inaudible].

That's really tricky, I found, especially if you have a team that is mostly all in one place and then you have a few remote people. If you're going to do that, you have to make the remote communication channels [inaudible]. Otherwise, you're just going to have somebody that's sitting out there in la-la land, that isn't connected with the team. You're having conversations in the hallway, you have an impromptu meeting on the couches, and then three weeks later you go and, “Why the heck are you doing that? We all decided we were going to do something a little bit different.” And then it turns out nobody told the remote guy. And that really sucks.

I heard a story recently about a remote developer on a mainly in-person team. And his teammate [inaudible] on one of the video hangouts that basically said, “Slack? Who uses Slack?” And that was incredibly alienating for the remote developer because that was [literally] her only way to communicate with the team. And to see it being dismissed by the team lead was really an indication that remote culture was not something that was valued at all.

That's really sad.

Yeah. And I think that beyond onboarding, if you're going to have a remote culture, you have to do away with those ad-hoc meetings. You have to make sure that things are [inaudible] documented, if not always collaborated on via video chat or via Slack or whatever, [inaudible]. But I think, I don't know. I almost wish that as part of onboarding you could make the decision as to, is this really the company for me, in a way that was not [inaudible]. I wish there was a [inaudible] so that we could feel each other out and say, “Is this person going to be a good contributor?” and “Is this company actually going to support me in my development endeavor?” So, I wonder if a [inaudible] thing for remote developers would be helpful so that both the company and the developer could test each other out.

Mmhmm.

There's another challenge with remote that I've noticed, because I am remote at a company that's mostly on-site. But my team, there's only one of us on-site so we're practically all remote. So, [inaudible] situation. But I've noticed that starting out remote and we don't have a lot of structure, it's very, “Pick what's most important and work on that and here's a bunch of information so that you can determine what's most important.” I'm really struggling to get into the rhythm of, what is it like to be remote at Stripe? So, I've started asking people if I can shadow them and see how they work. But I feel like part of onboarding is getting into the socio-technical system that is the code plus the coders. It is us plus the code we work on. And when we respond to the code and change the code and it gets better, that's awesome. But coming in from outside and not part of that yet, I guess the other side of it would be adopting a new technology.

I love that term, socio-technical system. I think that's really a valuable perspective on what we're expected to be part of as a developer.

Yeah. I got that from [inaudible].

Yes.

So, I need to know the people to ask, to find the [person and the] code. And I need to be able to ask both the code and the people questions. But as I contribute, as I write code or as I publish new code, I'm becoming part of that system and I'm integrating myself. But until... so, I'm like, “Don't stress out, Jess. Yes, you don't know what you're doing yet and you don't know what to do next but you're going to get there,” as I work my way into that system.

One interesting thing that I've seen done by several companies now is measuring the time to first commit to production, or time to first deploy to production. And I'm interested in hearing people's thoughts on whether that's a valuable metric and whether that's a valuable objective to have [inaudible].

On our first, I think it was my second day, everybody, every engineer deploys to production. And what they deploy is their little entry into the hard-coded data that feeds, I think it's about.stripe.com, or the little public-facing website that shows everyone who works at Stripe. So, we push ourselves into production immediately. So, we've technically done a deploy very early. That's empowering.

I made my first commit to production on my third day, because that's [inaudible] Monday. In fact they actually deploy to production on Wednesday, which [inaudible]. But I think that in some places, it's an artificial measure. I don't know. What you described at Stripe, Jessica, seems to me as not to be [inaudible] can try. It's a milestone that you can [inaudible]. But it's [inaudible].

Oh, totally.

[Inaudible] should measure actually [inaudible] adding value to your application then. But I think that might be an objective measure of what the onboarding process, how effective the onboarding process actually is, like how quickly 'til you become productive given the circumstances that we put you in as the new guy.

Maybe [inaudible] measure value in a lot of [different views].

That's true.

Because there's [inaudible]. I wonder Avdi, if you have any opinions on whether there's a lot of things in common between onboarding onto a team and onboarding onto a project, maybe an open source project that people collaborate on, [that you'd] want to continually [bring] people into.

Yes. Both processes suck.

We talked about remote onboarding. Now, that's...

Both processes are full of those horrible tasks that everybody gets out of the way the first time, thinks, “This is terrible, somebody should document it,” and then immediately forgets about it because they've gotten over the hump and they [inaudible].

So Jessica, I think you made an interesting point about onboarding onto an open source project. One of the things that I try and do in my projects is, go into the issues list and add a tag for things that are beginner-friendly, things that don't require a lot of context or a good working knowledge of how the overall system works. Things that you can contribute to right away and feel good about having made a contribution. I think being beginner-friendly in that way is one way you can make that experience better for new devs.

Yeah. As a team member, don't pick up those tasks without asking the new devs  whether they're already working on it.

Yeah. I think what I ask for in my open source projects is for people who claim the ticket, just add a comment that says, “I'm working on this.” And then I have, then we're not typically [inaudible]. I've had situations where two people worked on a feature and I had to pick [inaudible] pull request. And it's not a fun position to be in and it's not fun to be on the receiving end of that either, where you put work into it and then you find out that someone else did it already or someone else [inaudible] at the same time. And your work was basically for nothing.

Yeah. That sucks.

That can be really discouraging. Can you talk about that same situation happening in the workplace Jessica? Is that something that you've actually experienced?

Well, Chuck was talking about having [inaudible]...

Oh, okay.

And I have also experienced that with team members who are more interested in plowing ahead than in collaborating with me.

[Inaudible] the opinion that collaboration is an essential skill for you to have mastered before you can [inaudible]. I don't think we've focused enough on the social aspects of coding. And we have, we need to adjust our expectation for what it means to be senior. You should be a mentor. You should be able to talk to people. You should be able to train new people. You should be empathetic. You should be collaborative. Those are essential skills for being the resource of the organization that comes along with being a senior dev. It's not about your coding experience, your architecture skills in isolation. It's the, how effective you are as a member or a leader of a team.

That's beautiful. I think we should write that up so I can tweet it, because I can't agree enough.

Right. My last job [the people are] thinking about what it means to be a senior dev and unfortunately, we had a lot of disagreements about what that meant, especially being a senior dev who was remote and not adjusting the expectations for some of the relationships that you can form with people in a larger organization when you are remote.

Hmm. There's an interesting point. A lot of orgs are moving toward multiple tracks of advancement. You've got the management track and the individual contributor track. But I think you bring up a point that what a lot of people think of as individual contributor is code but there's somewhere in between that is not management but it is technical leadership and involves bringing the rest of the team up and being that communication hub and collaborating and hooking people together and being really good at communication, as opposed to just writing good software on your own when you have a project that you can just ignore everybody relatively [inaudible]. So, when we call the track individual contributor, [what].

I think we're [inaudible] missing something.

I can jump in here a little bit because when David and I talked about this a few weeks ago on this show where one of the first things I did when I was onboarded at CrimeReports.com was set up the CI machine. That wasn't code. It didn't show up in the repo . All it did was gave us another way of getting feedback from our code so that we could evaluate where we were at. A lot of times, somebody's really good at asking the critical questions. Somebody's really good at facilitating communication in Slack or in person or somewhere else. Yeah, there are a lot of unmeasurable things that make you an individual contributor but don't necessarily show up as lines of code or stories. [Inaudible] that's not...

Because most of our contribution is collaborative. Yeah, and Coraline brought up value. And if you chase value in terms of shipped business features, I think you miss a lot of that. Because really, we've got to evaluate value and team level. So, maybe it should be more like when you bring a new person on board, you're investing resources in that person. Team velocity, if you [inaudible], the team value level is going to decrease for a while. And then at some point it's going to go back up again. Maybe that's the point that we should aim to identify.

Yeah, I think this is where retrospectives are really highly valuable, because then you can start to evaluate. We're going try this, we're going to try that, we're going to try something else. Then [you're like], well this is working, this isn't working, this really isn't working.

Right. And that continuous integration that you set up is boosting the whole team, even though you don't show up on any commits.

I think you bring up a valuable point Jessica in that how you define adding value is a reflection of the company culture. And I would love to see topics like that addressed even before onboarding, through the interview process, by saying, “Here are our expectations for someone in this [inaudible]. Here are the things that we value.” So, make sure that everything you do is in line with those values. Because I really strongly feel, everyone [knows] I have some opinions about “company culture”. If you're not able to express your values, [inaudible] those values and you have no culture [inaudible].

So, I think [inaudible] values not only in the mission statement. I don't mean an objective that some committee has written up, but [inaudible] showing someone the way to act according to those principles. It should be a critical part of onboarding as well. I think it's just as important as understanding where in the codebase you should [make a change].

Absolutely. And if you think those values, that you shouldn't have to express them, that people should just pick them up, “Wait, you're contributors. You just know what to do and you shouldn't have to tell it in code.”

[Laughs] I've been [waiting] for that headband they put on your head and you can just [inaudible].

And you know, [inaudible].

[Laughs] Haven't gotten one yet. I want one.

Yeah, but we have that... yes, that's a good thing. We wish we had a headband to just hook up to our heads  and tell the computer how to work. But we think we have that with people.

[Chuckles] That's so true. That's so true.

[Inaudible] communicate to computers and you can't figure out [inaudible] people?

Yeah. I think one other thing that we fail to recognize a lot, and I think this shows up in a lot of the other areas that we struggle in, in the social justice areas of our community, is that we assume that we can quantify somebody as one thing. And this happens with new people on the team, for example, [inaudible]. So, we just bring everybody in the same way and handle them the same way. And it just doesn't quite work that way. Everybody is going to pick different things up. They're going to learn different things different ways. They're going to contribute in different ways.

And it's the same with bringing people into the community and bringing people into these other areas that we work in and socialize in as coders. And me bringing somebody on who's a lot like me and me bringing somebody on who's a lot not like me, those might need to be two different processes. Or I need to be mindful of how I want them to contribute because they have the differences that [inaudible].

I think that touches on something pretty important, Chuck. And that is, especially if your interview process or your company is trying to focus on [bringing in diverse candidates]. One of the [inaudible] that someone of [inaudible] with, they're a different race or religion or gender or what have you, than you are, is showing them role models who [look] more like them and have more in common with them. So, I think [inaudible] in the onboarding process, too. Like Jessica, you talked about having a spin-up buddy. So, if you are for example a person of color coming to a company, I think it might be important for you to see other people of color being effective in the organization and someone that you can talk to and commiserate with and get [inaudible] so that you don't feel, so your difference doesn't make you feel [inaudible].

Yeah. Yeah, and stuff like, even though my spin-up buddy isn't a woman, he set up a bunch of meetings for me with different people in the organization that I should know. So, while I was on-site I had, you call it a coffee but really it just means, the talking part is important [inaudible]. With various people, and many of those were women.

I heard of one company that actually for the person's first day on site set up a women's lunch for her to attend just to get to know a cross-section of people at the company and also to not feel alone as a rare woman in tech.

Yeah, I think also though, it's important just to know [inaudible], if you sit down and talk to somebody you can immediately figure out, “Hey, you are bent this way. You feel important when you contribute this way. You like to jump into problems in this manner.” And that's not the way I work or the way I think. But then I can actually say, “Then I feel like if you jump in an contribute over here, or you contribute in this way and play to some of the strengths that you have demonstrated you have, then you can feel like you belong.”

Chuck, I think you would make a good senior developer. I think you illustrate a lot of those characteristics that we mentioned earlier.

I'm not sure what you mean by that.

I'm saying that the way you're talking about noticing how a person works, noticing where they contribute, noticing how they learn and how they will react to different learning things, that's exactly the kind of characteristics that I want in a technical leader.

Mmhmm. Yeah, I have done it before and I've had that work out. I've also made the mistake where I assumed that somebody was just like me and then had it blow up in my face because it turned out they really weren't.

Or just like somebody else who was different from you, but [inaudible] their own category.

Mmhmm.

I think Chuck, you mentioned something earlier about people not just falling into one category. One way to go with that is a person can be really good at one thing and really bad in another way. And people just, you know, just because you like somebody doesn't mean they're great in all situations. That's another thing that I've seen be problematic. It's not specific to onboarding in any way. But in general, in organizations. What do you mean that person was mean to you? They're nice. They must never be mean. You must be wrong.

[Chuckles] That just reminds me, my wife used to be a preschool teacher. And inevitably they'd be [inaudible] with pick up [inaudible]. And she'd have the parents come in and they'd be like [inaudible].

Everyone has this perception that they're the nice guy or the nice girl or the bad guy or the mean person or whatever. And it's like, that's not been my experience with them. But...

It's the reverse of fundamental attribution error, of you get an opinion about what kind of person they are and then you can't even see or believe behaviors that would contradict that opinion.

Yeah.

So, that's tricky about onboarding too, is you get first impressions. You get short experiences. And it's easy to start putting people in categories and deciding they're not useful here or they belong over there. Then you really, the team and the person are [inaudible].

And I think you're under so much pressure of being there and new on the job, you may not be at your best because maybe the stress, maybe hyper-focused on what people are thinking of you and trying to second-guess the values that they actually [inaudible] value the most. So, you're not necessarily being yourself in that circumstance.

Yeah.

Yeah, that's [true]. Yeah, so...

I think...

I think a lot of communication plays into that. You have to be talking. Because otherwise you are, you're going to make those mistakes. You're going to make a poor judgment and on the other side yeah, you have to make people feel like you hired them to be them and not somebody else.

Do you think that onboarding would benefit by reusing some of the time of the same people involved in the interview process? Because maybe they have a little bit more context about your background and where you're coming from and they've seen some of your personality and some of your actions?

In an even more high-pressure environment?

[Laughs] [inaudible].

That's [inaudible]. But when you're interviewing wrong, which is a whole other topic.

Yeah, I was going to say that.

[Inaudible]...

It all depends on how good your interview process is. Because you may not have even gotten the right information to begin with.

You mean the resume is not enough? [Chuckles]

Only if it's really, really, really, really long.

I have a four-page resume. With pictures.

Awesome.

It's pretty awesome.

[Inaudible] [inspirations].

Yeah, actually I feel like I'm almost cheating when I come into a company now because not everybody, but some people there already know of me. That's an advantage. People have a first impression of us as Ruby Rogues before [inaudible]. And that oh my god, that helps with the pressure.

I have a [inaudible]. I think it's something that I'm hesitant to talk about because I don't want to come off as I'm bragging about it or whatever. But I definitely have met people who have a good sense of who I am based on the visibility that I have in the community. But that also brings with it a lot of pressure to live up to those expectations.

Yeah, there's that.

We have editing on Ruby Rogues. [Inaudible].

I can't edit myself in real-time.

I don't see it as much as bragging as like calling out my own privilege. Because I'm really lucky to be able to do this.

Oh, I feel the same way. Chuck, do you have some questions for people? Should we shift over or do you [inaudible]?

I was about to suggest that.

Cool.

So, the first question, and we can actually tie this back to onboarding people, but the first question is with all there is to learn in the field, languages, frameworks, workflow methodologies, et cetera, how do you decide what you spend time learning?

Whatever's interesting to me.

[Chuckles] That's what I was going to say. If it's fun.

That's what I do. And I tend to let [inaudible] guide the technology [selections]. So, if I'm working a project that is just mainly informational, that may not be [inaudible] technically, but I may have to [inaudible] up some CSS [inaudible] or what have you. But I think it's also valuable to learn, get a sense of where your company is going with technology. And maybe engage in side projects that will bring you some familiarity with those, because [inaudible].

Yeah. The other one that I've picked is, I know absolutely nothing about that, [inaudible].

Hmm. Yeah, there's a second category besides, wow that's interesting, I want to check it out. There's the category of objective-driven learning which is like Coraline said, okay I really need this CSS to do something that removes this picture out of the top left. That's about the level I'm working on in CSS.

And when I hit those questions, I need to do some research about half again as much re-search as necessary, just go a little deeper. But you understand a bit more broadly the concepts you're dealing with. One level past the particular detail you need. Stuff like, okay, I managed to move it out of the bottom left and I did that with a style tag. And with that style tag I could have done these other three things, kind of level.

Mmhmm.

And I'm not passionate about CSS. Well, not in a positive sense. But it's useful. So, that's driving me to do a little bit of research, but not so much that I give myself a headache.

Yeah, for me any of it really comes down to, is it interesting? Does it give me deeper knowledge in the things that I use every day? Or does it get me back to that beginner status? Because I feel like having that beginner status inspires some creativity for me.

Avdi, you have to chime in on this one.

He only learns enough to do bite-sized videos about Ruby. [Every time].

Yeah, that's it. I feel like I have a few categories of things that I learn. So, there's number one, there's becoming adept at a few things. So, I think it's really important to have a few technologies that you're just extraordinarily comfortable with. So that when the time comes to tackle a problem, you're like, yeah, I know how to use... I have one tool and I know how to use it for this. So for me, for years, one of those technologies has been Ruby. Another of those technologies has been Emacs. These are things that I try to get better at because I want to have that one [inaudible] thing that's like, okay, I don't know all the tools that can solve this problem but I know [inaudible] that can. And I don't have to think about the solution too much. So, there are those things.

And then like what Chuck was saying, I look for some things that I sincerely think will stretch my thinking in some direction. So, if you know Python or you know Ruby, it's not a huge stretch to learn the other. And some people will probably argue with that. But it is a stretch to learn Haskell or something, or Prolog. So, I look for those things that will stretch me. I look for things that where there's not just full maturity but also some knowledge maturity out there. There are an infinite number of things coming across my desk every morning. But I try to look for technologies where I can learn something that won't be, learn some practices that won't be out of date tomorrow.

These days, there are very few areas where I'm willing to learn something that's just totally cutting edge because it's like a generational garbage collector. 95% of the objects get wiped out in the first generation. It's like they turn out to be short-lived. And then you have that 5% of objects that survives into the next generation. And that 5% of objects that survive into the next generation are probably going to survive into the next five generations. So, there are very few things, unless it is directly pertinent to something I'm working on or unless it just really catches my eye and just seems fascinating to me, there are very few things that I will allow myself to just read up on something that's extremely new and untested.

There's a lot of overhead to that too, when the only place that your questions are answered are on the mailing list.

If there, yeah.

Yeah. And you need blogs and yeah. When there's blogs, when there's tutorials, when there's opinion pieces.

Yeah. It's like, if I were working full-time on a React-based website, based frontend, then I would probably be scarfing down all the latest and greatest cutting edge information I could about React. But since I'm not, I'm not really [inaudible] about it. I'm just making sure that I'm aware that it exists and what it's good for. And broadly, I try to stay broadly aware of what's out there, what's available. Yeah, so those are my categories. There's the few things that I want to get really adept in. There are the things that stretch my brain. And then, if I'm working I'm something, that's about the only time that I'll try to stay on the [inaudible], the bleeding edge.

And I actually made, I think I mentioned on the show a while back, but I actually took my list, my mental list of programming languages to learn, and brutally pared it down recently and made a list of, okay, here are the ones that I think are actually going to make a difference in my thinking. And the rest, I'm not going to say that I'm going to learn someday and just going to say I'm not going to learn them unless a particular need comes up for it.

So, I actually, I'm a moderator, an operator on the Ruby IRC channel. And something interesting happened yesterday where someone was asking about what modules and standard lib to study. And they talked about the classes and modules that they had already studied. So, they were making a really systematic survey of the Ruby language, I think, which brings up the question for me of how do you learn a new technology? How do you, I guess we're getting off-topic a little bit here, but [we do] have a question out there in terms of code reading. So Avdi, how do you go about learning something new?

I think that the biggest piece is just writing things, trying to write things in it and finding out where I run up against a wall of misunderstanding and then trying to tackle that wall. I also do a lot of fairly systematic learning. I'm a huge proponent of finding a good book as opposed to trying to patch something together with blog posts and Stack Overflow articles and stuff like that. I really, really like stabilized information sources.

I'll chime in on this because the question was directed at me, [inaudible] James and I and David Brady. And no, we never did make another one. I did an episode of the [Read The Source] podcast with Erik Isaksen and Jamie Gaskins and we talked about Clearwater.rb which is a frontend framework written in Opal. But no, I haven't done much public code reading since then. But yeah, my approach to that is check out the readme, probably run the tests, and then jump in and see what I can make it do, as far as figuring that stuff out. And then if I do go into coding, then I'll just start at the top level. And usually I'd be looking for what it does that I [inaudible]. [Inaudible].

We could tie that back to onboarding discussion to reading the code that is existing in the codebase, making time for that systematic study. Might be a good way to get your hands dirty and I think that [inaudible] will [inaudible] the questions you need to ask.

Reading the existing codebase is particularly satisfying when you are remote because no one can hear what you [laughs] [inaudible] about.

You don't get to [inaudible] for a minute. [Chuckles]

Right.

Alright. Well, it looks like we're winding down on this. Should we do some picks?

Sure.

Alright. I'm just going to go left to right on my screen. Avdi, do you have some picks for us?

I don't think I got around to picking this one last time. I do a lot of traveling around and working from coffee shops and stuff like that. I like my internets to be private when I do that. And for a while I was using something, an anonymous VPN for that called TorGuard. I think I probably picked it at some point. But I have had more and more trouble with TorGuard lately, just having really bad connections. And so, I don't know, like a month ago or something I asked around and pretty much the unanimous suggestion was PIA, Private Internet Access I think is what it stands for. So, I killed my TorGuard account and I got an account with PIA and it's been working really, really well. So, I just, I switch that on when I'm on airplane Wi-Fi or coffee shop Wi-Fi or hotel Wi-Fi to make sure that everything's tunneled through a secure connection.

That's pretty [inaudible].

I'm so [mean]. [Chuckles]

Really though, I feel like it's tough love, because I'm trying to make them better.

Right.

If you don't give them a challenge, then they'll never learn nothing.

They get past the [inaudible]?

Yeah, yeah. And he likes [inaudible], honestly.

[Yay].

Yeah, I'll pick one more thing. I feel like the [inaudible] people are coming [inaudible]. No, I feel like I get an hour every two weeks to play video games these days. But I still occasionally do. And one that I've been playing with is called Darkest Dungeon. And it's a Lovecraftian influenced dungeon hack sort of thing. In many ways, it's like a stripped down dungeon hack kind of game, but they've also expanded it on some unusual axes, particularly there's a lot of, it being Lovecraftian inspired, everybody is sort of, all of the people are always way under-qualified for the job. And  at the point of [inaudible] and near-death for most of the adventure. So, it's an exercise in managing your character's terror and stress and assorted emotional afflictions, which is an interesting take on the genre. But I've been [inaudible]. Darkest Dungeon.

That's available on Steam, right Avdi?

Yeah, that's on Steam. So there, yeah, there's two picks.

Alright. Coraline, what are your picks?

Okay, my first one is a gem that I actually am using right now. I'm implementing this at work. It's called Imprint. It's a gem that was released by livingsocial. It helps you track requests across multiple log lines or even applications, basically by inserting a transaction ID into your logs, into all your log files, log entries. There's a lightweight class and middleware, Rack middleware, to help you set tracing IDs. And the tracing IDs will appear in your app logs and help you [inaudible] calls that originate from a single request. And you can even insert that tracing ID that will persist the calls, API calls, between applications. So, that's pretty cool and that's really, really handy if you have [inaudible] apps or another log [inaudible] application. It can help you tie information together so you can understand exactly what happened when a [inaudible] request. So, that's my first pick.

My second pick is an article in Research Digest. And the way Research Digest works is they survey research papers that are published behind pay walls and give you a summary of what that research was about. And this one in particular was called 'The surprising truth about which personality traits do and don't correlate with computer programming skills', a really snappy title. But [inaudible] it's the work of a researcher named Timo Gnambs who published his findings in the Journal of Research in Personality. And what Gnambs did was [inaudible] the research literature looking for relevant studies that measure people's programming ability and measured their personality traits and intelligence and tried to correlate them.

So, he found 19 studies published between 1974 and 2014 that involved a total of about 1700 people, 27% of which were women. And his research looked beyond intelligence, so [inaudible] things like introversion, conscientiousness, openness, disagreeableness, and [inaudible] they were able to develop their aptitude. The results of the study, I don't want to give away the [inaudible] of the article, but they are surprising if you think of people as a resource but not surprising if you think about developers as human beings first. So, I wanted to [inaudible].

Wait, we count as human beings?

Some of us.

Exactly what kind of beings are we?

Can each of us count as more than one human being?

Myself contains multitudes.

Exactly.

Alright Jessica, what are your picks?

Okay. I'm going to pick these headphones that I'm wearing right now. They are TALON Wireless Bluetooth headset from Firebird. And they just stay in my ears and they're so comfortable. And I do not hate wearing them. And I can get up and close the window without dragging my laptop off the desk. They're made for exercising , for running. I even wear them biking which is probably a bad idea, but they totally worked. Yeah, so the batteries last about three hours and then you plug it into your USB port to charge [or to a microUSB]. But they just work really well and smoothly and I like them. And [inaudible].

Second pick, there's one thing that I've particularly been enjoying lately and it's a book. And it's a kid's book. They say ages 8 to 12 or something, but it totally goes for younger. And my girls and I have been reading a chapter every night in this series. And it's just delightful. It's called 'The Penderwicks'. And it's a family of four sisters and their father. Their mother died when they were little. And the just go on vacation. Or the stay at home. And there's no magic. There's no aliens. There's no zombies or vampires. It's just ordinary people who are adorable and their little dramas that kids... my kids get so excited. And I love reading it. The end.

[Chuckles] I'm going to double down on the pick of reading to your kids. That is honestly one of the best things that I do every evening. And I absolutely have been... we've been reading the Chronicles of Narnia which [inaudible]. And we just finished 'The Lion, The Witch, and the Wardrobe'. My kids are pestering me about which one's next and what's going to happen. Anyway, [inaudible]. So, definitely going to second that.

One other pick I have, and for a long time I really hated LinkedIn but I'm going to pick LinkedIn just because I've been able to connect with a whole bunch of awesome people on there.

You finally figured out what it's for?

It's for... [Laughter]

I don't have a great answer for that other than that I have been able to connect with people. Twitter is still more effective than LinkedIn to connect to people. In fact, as we are speaking right now I have 109 direct messages that I still have to read on Twitter. But let's [inaudible]. But overall, I have been enjoying just... actually, what I do is I go in and I randomly look at the latest people who are second connections and just see what they're putting into their profile and what they've got going on. I don't spend a ton of time doing this, but I do some time. And it's just been nice because sometimes they'll see that I looked at their profile and then they'll send me a message or something. They want to connect. And then I get to actually interact with them and find out what they as developers are looking at these days.

[Inaudible] okay developer.

Okay developer?

For [inaudible].

Oh, right. [Chuckles] I guess. But yeah, so I've made some friends. I've made some connections. And overall, I've just really been enjoying the interactions I've been getting from it. I've also been doing the same kind of thing on Twitter. So, that's why I have some new [inaudible]. But it's been really nice just to connect. So, if you want to connect with me on either of those platforms, then by all means go ahead and do so. I'll put links in the show notes to those.

I also want to quickly pick, I've started a morning routine and one of the things I do in the morning is watch technical training videos for 20 minutes in the morning. And I have this huge backlog of two video series that I have been subscribed to forever and I've been catching up on them. One of them is RubyTapas by Avdi Grimm. And I think I'm on episode 170-something. I'm not sure. I need to check. The other one is Elixir Sips by Josh Adams. And both of those are awesome. And it's really interesting just to have the comparison. Because I'm now to the point where they both come out on a similar schedule. So, I'll have one Tapas and then one Elixir Sips and then one Tapas and then Elixir Sips.

And they're not covering the same topics. But the approaches are different and the way that the languages work are different. And so, it's fun to just get this, okay, now you have to think about this in the functional style. Now you have to think about this in the, if it's a procedural thing in Ruby. Like I just watched testing sleep, the sleep call and all that stuff. And [there was some] dependencyinjection going on there with blocks to get the functionality [for it to sleep] versus count the number of times it slept and things like that. But anyway, so seeing that in RubyTapas and just seeing how the different things work differently from each other and at the same time some of the things that [inaudible] pulled into Elixir from Ruby. And how those are similar and how they're different. So anyway, so that's my staying a beginner because I really am a beginner with Elixir. But it's keeping me fresh and keeping me excited about learning new stuff over there.

So, long-winded picks, but those are my picks. So, I guess we'll head toward wrapping up. If you like the idea of us doing a Q and A, then tweet at us and let us know. And I'll see if we can get another one of these scheduled here in a month or so.

Chuck promises to send out the emails ahead of time.

[Inaudible] exactly, [chuckles] yeah. The best way to be notified of that is either follow Ruby Rogues on Twitter, @RubyRogues. Or you can join the mailing list. In the mailing list, you just get emails about episodes. So, you get an email every week basically. If there's something else going on, occasionally I send something out, but not very often at all. Probably [inaudible] every [inaudible]. But yeah, if we're doing a Q and A, I'll send it out to that list for sure. So, those are probably the best ways to know about it and we'll also announce it [inaudible].

Ooh, ooh, if we're talking about mailing lists, can I plug mine again?

Yes.

So yeah, issue number four of my newsletter just went out.

And everybody who's getting it really seems to like it. I've been getting some really nice comments back. And what's better, I've been getting some great replies which is one of the big reasons that I started doing it, because I really wanted to have more one-to-one interaction with people at greater length than Twitter enables. So, it's very much a reply enabled and encouraged kind of medium. And I'm doing a lot of commentary on stuff there that I'm just not doing on my blog and stuff like that. And people seem to like it. So anyway, you can go to sigavdi.email, sigavdi.email, to sign up to that.

You've been [inaudible].

I have. And yeah, a lot of it's influenced by the software development and [inaudible] construction book that I'm still working my way through.

Me, too.

Awesome. Alright, well I'm going to go ahead and stop the broadcast. Thanks for everyone who watched live if you're getting this. I hope you get it. Catch you all next week.