David Alpert - On pairing and providing support

Show Notes:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

• Virtual Coffee: virtualcoffee.io
• Podcast Contact: podcast@virtualcoffee.io
• Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw
• Dan: dtott.com, Twitter: @danieltott

Transcript:

Bekah Hawrot Weigel: 00:06

Hello, and welcome to Season 6, Episode 1 of the Virtual Coffee podcast. I'm Bekah --

Dan Ott: 00:15

Woohoo! [Dan and Bekah chuckle] We're back!

Bekah: 00:18

We are back. We are back featuring members of the Virtual Coffee community. A community that is an intimate group of developers at all stages of their coding journey. And they're here, on this podcast, sharing their stories, and what they've learned. And we're here to share it with you. Obviously, here with me today [chuckles] is my co-host, Dan.

Dan: 00:41

Wuddup, Bek. How's it going?

Bekah: 00:43

Do you do that every Season 1 intro?

Dan: 00:46

I ... hope so. Probably not. But now I will.

Bekah: 00:51

Yeah.

Dan: 00:52

From here on out. Yes.

Bekah: 00:52

Will you remember that, in Season 7?

Dan: 00:54

No.

Bekah: 00:55

Hmm. Okay.

Dan: 00:55

But, it probably won't be the only time I say, 'Wuddup, Bek,' [Bekah chuckles] either, so, you know? How's it going?

Bekah: 01:02

It's going great! Because we're launching the new season of the podcast.

Dan: 01:11

Woohoo! [Dan and Bekah chuckle] Yes, we are. It was -- Season 5 was pretty awesome. And Season 6 is also gonna be awesome [chuckles].

Bekah: 01:21

It is true. It is always awesome. We are consistent in one thing, and one thing only. And it is having awesome people on our podcast.

Dan: 01:29

Yes. Agreed. So, yeah. So we are starting Season 6 off with ... an awesome guest [laughs], of the name, David Alpert. David is a director -- no, wait. What is he? I lost it. David is the Director of Engineering, sorry, at Northfield IT. And one of the many Canadians we have in Virtual Coffee, and also on the podcast [chuckles]. Not the first, won't be the last. And yeah, we had a really great time talking to David.

Bekah: 02:04

Yeah. David is one of those conversations that could have continued on, for sure, beyond the hour. He has so much insight into — not just like the technology field, but in working with other people. And he -- I really appreciated his thoughtfulness in how he approaches other people, and supporting them.

Dan: 02:27

Yeah. Absolutely. That, I mean, like, that- that's gotta be one of the first things I think of when I- when I think of David is- is, yeah. Thoughtfulness, and- and ... I don't know. I, you know, like thoughtful and- and empathetic is- is -- what the -- he's one of the, I mean, he's- he's always on Slack, and he's ... I- [chuckles] I dunno. Like, everybody loves him. He's always so great to talk to. Anytime you -- anytime you're kinda working through something or have some existential crisis [chuckles]-

Bekah: 02:55

Yeah.

Dan: 02:55

-I feel like David's one of those- one of those people that will show up and ... you know, act- like, actually have constructive ways to maybe work through some- some hard problems and stuff. It's- it's really- it's really nice having him around.

Bekah: 03:07

Yeah. And- and the -- that empathy that he brings to the situation is really ... authentic and true, you know? Somebody might check in and see how you're doing, but, you know, if you get a message from David, he means that. And I think that goes a long way to supporting people, and helping them feel comfortable, and allowing them to, you know, grow and- and learn in those ways, and support them.

Dan: 03:36

Absolutely. Okay. What is our random question? How do we start the episode [chuckles]? Bekah, how are we gonna start this episode [chuckles]?

Bekah: 03:48

[Chuckles] Well ... well --

Dan: 03:50

[Laughs] I don't know.

Bekah: 03:54

Why don't- why don't we, in the first episode, intro talk about the other guests too?

Dan: 04:01

Oh, totally. Yeah. [Bekah and Dan chuckle] I don't know. I haven't done this for a while.

Bekah: 04:07

We're excited about this episode, and the rest of the season. So, we're also going to be talking to ... Bogdan about navigating tech career paths. We have quite a bit of career path episodes this season. So, we're gonna be learning about what it means to be a demo engineer, a developer educator, we're gonna be talking through interviews, and open source contributions. So, I think this is a pretty well rounded season to ... I don't know ... get you excited about all things.

Dan: 04:43

Yeah. I'm excited about all things.

Bekah: 04:44

Am I spinning chair? I've got a spinny chair this season.

Dan: 04:46

You have -- yes. Bekah got a spinny chair and she has not stopped spinning since she got it [chuckles].

Bekah: 04:50

It is the best thing. I just continue to spin.

Dan: 04:52

Yeah. Yeah. It's- it's -- well, it is what it is. I feel like you're doing a good job of, like, rotating around your microphone and staying in a good speaking position though. Though --

Bekah: 05:03

Yeah. I'm trying to keep my head straight on the microphone. See-

Dan: 05:04

So, well done. Yeah, yeah. Yeah.

Bekah: 05:05

-my body turns, but my head ... do- does minimal turning.

Dan: 05:10

Yeah. No. It's -- you- you're doing a good job.

Bekah: 05:13

Thanks. That's all I needed to hear today. But we are going to start this episode of the podcast like we start every episode of the podcast and every Virtual Coffee. Say our name, where we're from, what we do, and answer a random check-in question. So we hope you enjoyed this episode and the rest of Season 6. Today's random check-in question is, if you could magically become fluent in any language, what would it be? My name is Bekah. I am a technical community builder from a small town in Ohio, and ... I think I would go with Polish, only because I'm mostly Polish and I would like to know more of it. It's definitely not the most practical, but it's probably the most meaningful.

Dan: 06:14

All right, Polish.

Bekah: 06:16

Yes. See, that was the most straightforward-

Dan: 06:17

[Laughs] Yeah, yeah. Yeah. I know, I know [chuckles]. I don't --

Bekah: 06:18

-I've ever been in an intro.

Dan: 06:20

Yeah. Okay. Hi, I'm Dan. I do web development things in Cleveland. And, yeah. I don't know. Languages are hard. I -- this is an attractive question to me because I- I'm bad at, like, learning languages. I took like three years of German, and, like, I struggled with Spanish in college, and I don't -- I took three years of German. I don't know. I can still count to 10, I think. But, you know, Spanish would be -- I think- I think I'm gonna choose Spanish. I, you know, it just, it -- I- I like going to Mexican restaurants [chuckles]. I like, you know, and there- there's a lot of Spanish speaking people, you know, in America, and, although Japanese would be cool too. I- I love, like, listening to Japanese, you know? People speaking Japanese. I like -- I just like the way it sounds. So, that'd be cool too. And- and it's so different than English that, you know, that's one -- that's really hard for me to wrap my head around ever ... being able to speak [chuckles]. So I'm- I'm kind of tied 50-50, Spanish and Japanese. That's gonna be my answer.

David Alpert: 07:20

Well, since Dan said to you, I'm gonna say to you. My name is David Alpert. And I'm- I'm a software developer and DevOps engineer in Winnipeg, Manitoba. And I was having a hard time picking just one. So since Dan set the example-

Dan: 07:39

Yeah.

David: 07:40

-my first thought was Indonesian. Because I spent some time in Indonesia and I remember just enough Indonesian to say some things to Ayu, for example, in our community. But I'm no -- by no means, fluent. And it would just be so much fun to be fluent a-again, or more, in Indonesian. But then, Bekah, when you mentioned Polish, I- I thought Hebrew because that would connect me with some of my family and some of my tradition, so -- that I've drifted a little bit from. So, Hebrew and Indonesian.

Dan: 08:10

I like it.

David: 08:10

I will go there.

Bekah: 08:11

Yeah. Thanks, David. Normally, I- I ask our guests to choose one thing, and then I choose four or five. So [chuckles] --

David: 08:19

So we turned the tables today.

Bekah: 08:22

Yeah. Welcome to the podcast. Thanks so much for being here with us today. We always like to start with the origin story of our guests. So tell us a little bit about your origin story, and how that brought you to where you are today.

David: 08:38

Well, I was thinking about this question. I love that you start with the origin story, and the way you frame it as origin. I can remember using the Logo computer language to make the little turtle-

Dan: 08:53

Yes. Yes.

David: 08:54

-draw back and forth. I don't remember a lot about it, but I remember being really excited when I discovered loops. And I didn't even know they were called loops, but I could draw flowers with not very much ... code. So that was pretty exciting. And then I went to, you know, high school, and grew up, and lots of things happened. I went to university and took a computer science degree. I wound up taking a computer science degree. And that taught me a lot of fundamentals about computer architecture, saying, like, hardware architecture. There was a computer engineering course in there too. And also basics of data structures and algorithms. So I feel like I got a leg up on that, before there was any of the ... now all the code camps and everything, the freeCodeCamps, and the Flatiron School, and everything that I hear about, all the resources that are available today. I didn't have those back -- at that time, so -- but I was fortunate enough to be able to go to this university program. And I studied not only computer science, but also it was kind of a liberal arts-y program. And I got exposed to all sorts of other things that were not technical in the world. And I got very distracted, and I didn't want anything to do with technology, and I wanted to go find something more meaningful to do. So I went and I traveled. And that's when I wound up in Indonesia with an exchange program, with ... Canadian Crossroads International — a cultural exchange program, designed to expose people to different cultures. And ... as I was proceeding with my life, I noticed a common thread that ... I would constantly notice that people around me, that I cared about — friends, family — would be stressed or unhappy with technology. And they would be frustrated, and they would start to internalize it. Like, "Oh, I'm not good at this." Or, "I must not be very smart because I can't figure this out." And I would look at what they were struggling with, and I was frustrated. I got frustrated because it wa- I knew enough about technology to know that it didn't have to be that way. And that what my friends and family were struggling with was ... design decisions that somebody had made that hadn't really thought about how they would land on a real person. And that's really what prompted me to get back into technology. And from there, I've done a number of technology jobs -- technology related jobs, web, front-end — now we would call it front-end development. At the time I was starting to learn about front-end engineering, and that was back when ... I remember before Firebug was introduced, like back before Chrome dev tools. And then Firebug was a really big deal. jQuery and Firebug changed the way we did web development, back then.

Dan: 11:42

Yeah. Yeah, it did.

David: 11:43

And now -- well, from- from there, I got tired of front-end, then I got interested in backend. So I went and did backend. I did a lot of C#. I did years and years of C#. In fact, I found, recently, a commit somewhere in GitHub from 16 years ago that I did in C#. I've been writing code for a long time. And from there, I went to various software developer jobs and took some project management training, got involved in the local Winnipeg agile community, and found my way into builds and deploys. And that's what got me into DevOps. And now, here I am.

Dan: 12:24

That's awesome.

Bekah: 12:24

That's -- I was gonna say great, but --

Dan: 12:28

That- that -- oh, it's great. It is great, also. It's great and awesome. No, that- that's a cool ... that's -- I- I love having people on ... I mean, I love having [chuckles] all of our guest. It's- it's always fun for- for me having people on, who started like when you started, when I, you know, back a long time ago. I- I -- Logo, I hadn't thought about for a long time. I- I definitely did Logo in, like, the computer lab in- in middle school. What I was -- I had a question for you. What was it? Oh, it was ... okay. So you mentioned like, red- like, learning fundamentals and learning computer science stuff, sort of maybe a ... I don't know what the -- hard computer science [chuckles] ... I dunno what a good term is for it. But, you know, this -- the kind of stuff that, at least back in the day you learned in computer science courses in college, right, versus today, where there's so many different, like, places to go. So many different ways to learn, so many different approaches to learning, even. And I guess the thought that I had was, what do you think, like, can you imagine trying to learn from scratch now, and would you want to? If you were starting over right now [chuckles], right? But you have all the stuff available. Would you rather go that fundamentals level and learning stuff, probably in languages that you're never going to use in, you know, in- in practical levels, but you're getting all the fundamental stuff? Or would you, like, there's bootstrap- bootstrap -- no. Boot-camps [chuckles]. Sorry. Bootcamps, a-a-and everything like that, that will put you more in a practical place to- to get, you know, where- where you're learning some JavaScripts, and learning React, and stuff like that, even before you ... know ... maybe some of the more esoteric pieces of computer science, you know? And so, this is not a judge- like, I'm not asking you to like, place judgment on anything, but just, like, from a personal- personal standpoint. Like, where- where- where do you -- like, where would you land? Like, where would you personally rather ... start, if you could start- [chuckles] if you could start from scratch, you know, now?

David: 14:19

This is a really good question, Dan. And it's come up a number of times in Virtual Coffee, because we have a number of people who are career changers or- or early career people in the- in the community. And they're constantly wondering, "What do I do next?" and "What do I look?"

Dan: 14:32

Yeah, absolutely.

David: 14:34

The way you phrased it though, for me, if I were to start now ... I- I -- one of the things I notice about the technical landscape today, compared to when I started, is it seems to have exploded in technologies, and frameworks, and libraries, and possibilities. And I think it would -- I would lean towards practical first.

Dan: 14:58

Mm-hmm.

David: 14:59

Because I think that would help me learn enough about one thing to start to work. And really, once you get into -- once you cross that difficult barrier of finding your first job in technology, then you can get paid to learn-

Dan: 15:16

Absolutely. Yeah.

David: 15:16

-as you work. And- and then you can ... I don't know, maybe ... I think it would be worthwhile to take some survey course of the fundamentals, some high level survey course so that you introduce the -- or you- you're introduced to the words and phrases, because I find that the computer science degree helps me in two ways. One, that having those fundamentals often helps me understand new frameworks. Cuz I kinda understand how computers work underneath, and all of the languages and frameworks. So learning any particular practical framework gets, I think, easier with that fundamental background.

Dan: 15:56

Yeah.

David: 15:56

But I don't think it's required to learn how to work in any of those things. I just think that it helps me. The other place I notice is that it helps me in searching for things when I go to Google, sometimes. The terms and the phrases, I think. I'm drawing from that training back then. So, that's where I think maybe a survey course ... without having to go deep in all those things, because you -- I only remember the things that I use. And-

Dan: 16:20

Yeah, absolutely.

David: 16:21

-we joke -- I mean, we work in- in DevOps where caching is a thing. You know, one of the- the two hard problems in computer science [Bekah and Dan chuckle], right? And we joke about, 'My memory only holds so much,' and, 'I expire things for my mental cache when I go and-

Dan: 16:39

[Chuckles] Yeah, absolutely.

David: 16:39

-learn something new.' You know, you ask me a question about something that I supposedly studied, and, 'I have a cache miss, and I have to go look it up.' [Dan laughs] But I do find that things that I have learned and then purged, often come back easier-

Dan: 16:52

Yeah.

Bekah: 16:52

Mm.

David: 16:53

-or more easily. So-

Dan: 16:54

Yeah.

David: 16:55

-that's a long winded way of to say-

Dan: 16:56

Yeah!

David: 16:57

-I would start practical, today, because there's so many ... widespread things. I think it would take a long time to go from fundamentals to something practical, today. But-

Dan: 17:06

Mm-hmm.

David: 17:06

-I think if you start today with something practical, you could add- but, maybe, just a quick survey of -- you don't need to kn- understand all the data structures and algorithms. But like, if you can name three of them, cuz you know they exist, then you can search up implementations of them or details about them, when you need them.

Dan: 17:24

Yeah.

Bekah: 17:24

Good idea.

Dan: 17:25

Oh, I think that -- I love that answer. I, you know, and I think I tend to agree with you. I per- I mean, also personally, I- I ... got interested in computer development stuff because of the -- like Logo, you know, seeing something happen right away, you know [chuckles]? Like, hitting save, and then like looking at it, and, you know, whatever. And so-sometimes -- or- or writing code on a chalkboard and stuff like that is like ... was -- I drifted away from it in college because ... I was computer science major to start as well. And, you know, it- it just got less and less- [chuckles] less and less like, fun, you know? I dunno. But you're right. Like the -- knowing the ... like, for instance, the Big-O notation, right? Like, analyzing ho-how a -- ho-how long a function takes to do a thing, you know? I don't think anybody that's writing React code for their job needs to know the names of all the different -- you know? Or even ... [chuckles] like, they don't need to know the -- even the phrase 'Big-O', right? But knowing that will help you- will help you sort of think through and go -- like- like, having that in your brain would ... in the background, and it's okay if it's expired cache [chuckles], but you'll still like, see something and start like -- it's like code smell, kind of, you know?

David: 18:36

I know.

Dan: 18:37

That -- it's just like a weird phrase, but like, a phrase that makes a lot of sense to people who have been doing it for a while i-is- is you'll start to get like these instincts or whatever these- these -- like, i-it's okay if you don't know the exact phrase or I don't remember the exact name of it -- some specific [chuckles] algorithm or anything like that, but ... okay, I know just sort of almost intuitively that this thing is going to take, like, way longer ... than it should. And I probably can do it a different- different way, you know? That- that sort of thing.

David: 19:01

Right.

Dan: 19:02

I think that's the sort of thing that would hit on your idea of the -- like, doing- doing a high level, you know, survey course, something like that. You'll get exposed to some of that stuff, even if ... and you don't need to know, like, the down and dirty details, you know?

David: 19:15

Even if we take something that is, like, computer sciencey heavy, like Big-O notation, it's very, almost ... theoretical or a-

Dan: 19:27

Right.

David: 19:27

-an academic. Like, it's a very academic way to approach this-

Dan: 19:30

Exactly.

David: 19:31

-technology thing. Not a very practical way. But, knowing that -- like, being able to -- like, knowing that something called Big-O notation exists, being able to have one sentence about it, will help you identify when it might be ... in, like, a part of the problem you're dealing with, and give you enough words to go and Google the details of how it intersects with the problem you're with. And you don't need to be able to explain it in detail or --

Dan: 20:01

Right.

David: 20:01

Do you see what I mean? So-

Dan: 20:02

Totally.

David: 20:03

-just knowing that it's a thing or knowing that caching is a thing without knowing how caching works or knowing that ... I don't know. The- the one that came to mind as you were talking is that string concatenation is expensive in C# [Bekah and Dan chuckle], for whatever reason. Because strings are immutable in C#. They're treated as immutable objects. So every time you're joining strings together, you're allocating extra memory and copying everything over. So it's a very expensive operation. That detail of C# would never have stuck for me if I don't think -- if I didn't know a little bit of fundamentals about how memory allocation works.

Dan: 20:41

Yeah. Yeah.

Bekah: 20:42

I think, too, once you are working, you- you're coding more rather than you're learning. Those concepts become easier to understand, because we- if you're learning, they- they are kind of theoretical, right? Because you have no use to apply them. Or if you are building a project for a bootcamp or something, it's a tiny little project. So it doesn't exactly correlate m-much- much of that stuff with what you're doing. So when you have that, like, practical application and you're learning that, like, "Oh, okay. I understand where this would be applied or where I would need to reference this idea." And, at least for me, it becomes a little bit easier once I can see ... all right. Th-this is where we need to think about this.

David: 21:31

This- this goes to my understanding of how we learn as humans. Like, we learn better when there's emotion involved, we learn better when there's motion involved, we learn better when we have real experience to hang ideas off of. And that just makes intuitive sense to me. That also is why I say go practical. And learn just enough theory to have language ... to know when you need to go deeper.

Bekah: 21:59

I am [chuckles] -- so, like, writing down, I -- you just gave me a new talk idea, and the title has to be like motion and emotion. And it has something to do with learning, because I think both of those things are, you know, does tie it to our memory. It does allow us to connect with it in a different way. And I know that there are people out there, there were people when I was learning that would said, "We have to learn how to think higher level and theoretically, and how to apply that." And I don't -- I mean, my background, I taught college English for 10 years and so I- I can think theoretically [chuckles]. It's something that I had to do, but I don't think that we 'have' to do that, you know? I- I think that that's a little bit gatekeepy.

David: 22:47

Absolutely. And- and it also presupposes that there's only one way to learn and only one way to think. And- and that seems to be an idea that was stronger years ago, and now we know better, one of those ideas. Now we recognize that there's a whole spectrum of how people think, and process information, and learn, and view, and interact with the world, and experience the world.

Bekah: 23:10

Yeah. And you have a- a lot of experience with this, especially at Virtual Coffee. For our listeners who aren't in the Slack, we have a co-working room where anybody can join at any time. And it's an open Zoom room. And sometimes people are there to hang out, sometimes people have questions and they jump into pair. And David i-is one of our cur- our top co-working room attendees, I think. And you've helped a lot of different people in the co-working room. So, first of all, thank you. And second of all, you know, this all ties into what we've been talking about. How do you kind of approach people who come in and have questions? Because there are so many different ways of, you know, talking through things and learning.

David: 23:51

Oh, my gosh. Well, thank you. I love the co-working room. It's one of my favorite parts of co- of Virtual Coffee and this community that you've created. I never know what's gonna happen when I go in there. But I always know it's gonna be friendly.

Bekah: 24:04

[Chuckles] Yeah.

David: 24:05

And friendly faces. And in the middle of a pandemic, certainly, when I was locked in my room, it was a lifesaver to be able to dial it -- like, walking virtually into a room and- and meet friendly people. And, one of my favorite co-working room memories is I, you know, often you go in, and there's people who are not sharing a screen, and they're just talking. Or sometimes I go in, and there's people who are all on mute, and just enjoying being together. And other times, I- I- I logged in once, and Meg had her laptop on her front porch and she was gardening. And I logged in another time [Dan chuckles], and Aurelie was making crepes [Bekah chuckles] in her kitchen. It was lovely. So, it blew open for me that this was really a- a place where people could connect, which is ... at the heart of this community. But to focus back, you asked about how do I approach ... pairing or working with people from lo- a lots of different backgrounds and lots of different technology? Well, some of it is cuz I've been doing this for a long time, so I've seen a bunch of things. I -- some of it is that I'm in a job where I'm actively working in several different languages. And I'm in a job where I'm working to support developers. So I -- for five years, that's really been my role. And even, Bekah, the other day you were talking about DevRel. And I realized, some of what I've been doing falls under that bucket of really looking for ways to help people who are having problems. And I find there are some common threads, like a lot of it is ... really slowing down my thought process to take the time to meet somebody in their thought process as best I can. To really try to hear ... not what I think the problem is, but try to hear what someone else thinks the problem is, and try to look at it from their point of view, as best I can. And try to look with them at whatever they're looking at. So I will often say, "If you're having trouble, can you share an error message? Or can we share a screen and I can look at the same thing you are." Because words becoming adequate for talking about technical things. English words in particular are so imprecise sometimes. That we can say the same word and mean different things. So I often find it really useful to share ... a screen, and pair program, and look at the sa- look at the same thing at the same time, or to share a stack trace, or a, you know, the -- an error message. That's really useful. I think I've drifted from the heart of your question though.

Bekah: 26:48

I mean, I think it's great. I mean, you're really taking a- a person-centered approach to each person that comes into that room. And the idea of like listening and understanding is something that I- I think a lot of people struggle wh- struggle with. Myself included. Because it's like, "All right, let's just dive into this," right? And get going without, like, taking that time to understand what's happening with the other person first.

David: 27:14

I really think that's important. At some point in my growth and career, I discovered the Agile Manifesto, and people have -- I've since read lots of things, you know, positive and not so positive about the Agile Manifesto. And I don't mean to go down that rabbit hole, but the first value statement really stuck and resonated with me that we value people and relationships over processes and things. That is kind of a radical idea. If you- if you take that, and nothing else, that we value people in relationships over attachment to any particular way of doing things, and you start there, and you really look to meet the other people that you're working with, no matter what their role is, no matter what their background is, and realize that we're all part of a group or a team or a community that's trying to accomplish something together, I think all of the other practices around software development and delivery can emerge. If you start with who's at the table, then you really make space for everybody who's at the table. And that could be a hard thing, cuz we're not always used to doing that. There is a lot of gatekeepy, like language and habits in technology. I try to do my part to break that stuff down.

Bekah: 28:36

Yeah, I think a lot of times too -- sometimes it's certainly intentional and other times it's not, it's- it's just habits that have built up personally or through careers or with the teams that you have worked on before. So, you know, there's a- a need for constantly evaluating ourselves and how we approach the people that we are talking to or working with.

David: 29:05

I noticed something else, too. That ... pairing, really well, takes time -- takes me time.

Bekah: 29:11

Mm-hmm.

David: 29:11

I have to really slow down, and let go of any pressure, and really be present with another person. And that takes time, and energy, and effort. And if I'm under a deadline to deliver something, it can be challenging to make that time and that pressure. But I think it is so worth it to ... balance individual contribution, and individual delivery, and individual speed with all of the rich benefits you get from building community as you work. And from building relationships, and sharing knowledge, and building experience, and supporting everybody to grow in confidence and skill. There's so many benefits from actually working together.

Bekah: 29:57

Absolutely. And next month, our monthly challenge — this will be in June — is Month of Feedback. And so we read "Radical Candor". I -- we've mentioned it so many times. It's been a favorite of ours. But when you're working with so many different people, you are providing a lot of feedback and that can be hard sometimes, right? Because that feedback has to be critical. How do you approach, you know, giving honest feedback, but still supporting the person that you are providing the feedback to.

David: 30:29

That's a great question. I started reading "Radical Candor" with someone on my team because you have talked about it so much. And it is the ... I struggle a bit with the directness of critical feedback. That's where I found that book was really useful in giving me some examples of how to be direct without being confrontational, right? And-

Bekah: 30:55

Mm-hmm.

David: 30:56

-to stay heart-centered, to stay person-centered, and to really have the other persons to be committed to the other person. I find I really practice the idea -- well, practice which means I'm not always good at it, but I work at it. I practice the idea that everybody is where they're at, on their own personal journey. And everybody is right where they're supposed to be in the moment. And exactly the people that show up are the people who are supposed to be there. And the people who are on your team are the people who are supposed to be there. Like, really try to embrace, and accept, and love what's happening. I think that's really important. To be more practical though, I find, still, I'm noticing a lot of self-doubt and self-criticism that happens in technology. And so one of the things that I really try to do when I'm pairing is be encouraging. Above all else, to be supportive and encouraging. Because the biggest thing that I believe will help people learn is to grow that confidence. That it's okay to make a mistake. It's okay not to know something. That's actually part of the job. And the faster that you are honest and open about what you don't know as well as what you know, then the faster that everybody can see how to help you and the faster you can learn. And so I really just try to -- always try to be supportive, and patient, and guide people towards what seems to be the next step so that they can build their understanding, and get stronger, and bigger. Because that kind of pairing, and feedback, and support, it's not about me ... in that moment. It's really about trying to work with somebody and support them to take whatever the next step is for them. And if I'm deciding what it is, then ... that's not right. What I do sometimes though, is I might point people in a direction. Based on the journey that I've walked, I might say, "You know, have you thought about this?" or "Let's go look at that," or "I'd like --" yeah. I do more direct coaching sometimes with people on my team at work where I say, "I'd like you to learn this," or "I'd like you to learn that." You know, in that context, I feel like there's a framework, and it's part of my role and responsibility to be more directive. But I still try to partner with people, always to say, "There's what you want to learn and what you're interested in, and there's what I see as an opportunity for you, and let's bring those together and make out a plan." It's in --

Bekah: 33:30

Yeah, I love that.

David: 33:31

Yeah?

Bekah: 33:32

But -- I was just gonna say, acknowledging the person where they're at on the journey is a huge part of that. And- and what your relationship is with that person. Because, for sure, we communicate differently with people we've been working with for a while or somebody who's new on the team or someone we're meeting for the first time. You know, all of these things play a role into, I think, how we provide feedback and what the expectations are ... of us, you know? If I ... am resop- responding to a student's paper, there's an expectation of how I'll respond to that paper, versus if somebody says, "Hey, can you give me feedback on my blog post?" it's going to be a little bit different. I'm going to provide feedback either way, but the tone is going to change, for sure.

David: 34:19

But through it all, that concept of people and relationships first is really important. Like -- and that's what I have enjoyed about, the part of "Radical Candor" that I've managed to read so far, is that it does start with that people-centered approach. And that ... valuing the person that you're giving feedback to you and valuing the relationship for what it is, not needing to make it something that it isn't, in whatever context, but valuing it for what it is. And valuing that the other person involved is a human on a journey, just like you're a human on a journey. And, you know, there was a time when I didn't know what I was doing and people were gracious with me. So I tried to return that favor. Pay it forward, in that sense.

Dan: 35:07

Yeah. And I- I'd say another- another ... another piece of this is, you know, when you talk about meeting people where they are and things like that, it helps when you know them [chuckles] already, right? I-it's easier to have connections when you ... well, I was gonna say when you are connected, I don't know. [Dan and Bekah chuckle] I dunno. That sentence kind of broke down in the middle there. But ... I was thinking about two things when- when- when you were talking. Fun thing, Bek- Bekah and I worked to-together -- and I don't even know why I brought this up, but [chuckles] Bekah and I worked together. And it took us -- I dunno. How long do you think it took us before -- I mean, at least a year or something before we were really like --

Bekah: 35:48

I feel like right before the pandemic hit-

Dan: 35:49

[Chuckles] Oh, yeah. Right. Yeah.

Bekah: 35:50

-we were, like, eight months in, and we, like, we finally hit that stride. And then- and then [chuckles] ... and kinda messed up.

Dan: 35:55

Yeah. And- and some of- and some of that is, like ... some of it is me -- you know, so Bekah had just started in- in, like, in dev and had just kind of gotten outta bootcamp and stuff. And so some of it was me, like, learning how to do that better, you know? Learning to do all the stuff that David's just talking about. And some of it I think is- is just that connection over time, you know, kind of just grows, and grows stronger. And that's another thing I appreciate about Virtual Coffee. And- and I- I think it helps is, when you know people, you know, it's- it's- it's a little bit ... easier to do this [chuckles], I guess. And to get practice at it when you know a person. And so- so you don't have to, maybe, necessarily -- like, I- I -- when I pair with somebody, I've paired with people, you know, kind of cold, right? So, people I don't know, and for the first time, and there's always a bit of like level setting, you know? And I- and I- I try to be very -- I mean, I- I wanna be very careful about it. And I, you know, it's ... like, you- you don't wanna assume that they -- that a person knows things that they don't know, you don't wanna assume that they don't know anything either, right? And so, it's that, like -- it's that -- I- I just -- I called it level setting cuz I'm like -- a-and I've -- now I've just started explicit do-doing it. Like, I- I- I wanna be very like clear that I'm, you know, I- I just wanna figure out where we are, you know, where you are, where- where, like, what level I can talk at, you know? And it's -- there's no judgment at, you know? It's just what -- it's just somebody who's just learning for the first time is gonna have different questions and different thought processes than somebody who maybe is a Ruby expert, but is just starting a JavaScript. That person is going to have completely different questions, you know? You know, and- and so, it's always ... I don't know. It's always kind of interesting to -- when you're connecting with different people. So when you have a -- when you're at work and you're in a team, kind of, you build a rapport over- over time, right? And when you are in a lot of random internet communities, you can still be valuable and you can still have valuable connections with people you don't know. For sure. But --

David: 37:59

Well, this overlaps, I think, with- with you were talking about, Bekah, in that DevRel session you gave the other day, too. That there's a part of community building and a part of developer relations that is ... going out and reaching out to people that are not yet a part of the community. And trying to create an opening ... connection with somebody that you don't know. Dan, as you were talking, I'm reminded that one of the things that constantly surprises me still, years later, when I -- about software development, is how long it takes to get started with new people. Especially with new people. When I-

Dan: 38:40

Mm-hmm.

David: 38:40

-sit down to pair with a new person, say, a new person joins my team, or I'm in the co-working room for the first time with somebody new, it's not unreasonable to take one to three hours to just set out your machines to work in this -- a compatible way, and set up your language like you were talking about, to figure out what level of detail and abstraction to speak at.

Dan: 39:08

Right, right.

David: 39:09

And hear each other, and to develop a common understanding of the problem, and to work through build and compile issues in a new environment. Like, all these things that are not typing, that are not-

Dan: 39:22

[Chuckles] Yes. Yes.

David: 39:22

-reading and writing code, become really, really important and take real time when you care about the relationships of the people you're working with. And I'm constantly surprised by, you know, how little I get da- how little progress we make in the code when I sit down to pair with people at work, say, for the first time.

Dan: 39:47

Absolutely.

David: 39:47

And how much time it takes to build that initial rapport, and common ground, and common language, and common environment. And the reason I keep talking about it here is cuz I really want to normalize it for anybody who's listening. If you try pair programming, and you sit down with another human, expect it, to be awkward, at first.

Dan: 40:07

Yeah.

David: 40:08

I-it will be. And that's okay. That doesn't mean you're doing it wrong. And that doesn't mean you're failing. It -- that's part -- that means it's working. That's part of figuring out how to work together with another human. And it does -- it's like any other muscle or skill. It does get easier over time. Dan, you spoke about, you know, you- you're working to get better at how to ask those questions more directly. How to figure out and navigate that awkwardness faster. I- I ha- I feel like I can navigate it faster now than --

Dan: 40:36

Yes, absolutely.

Bekah: 40:38

I think --

Dan: 40:38

Yeah. You're saying?

Bekah: 40:39

You know, coming from the other perspective. Like, it's- it's a two way conversation, right? And so, when you're first starting out, it can be really hard to ask those questions. And if there's anything, I feel like I've learned over the last couple of years, it's ask those questions, whether or not you think it's gonna make you sound ridiculous or incapable. You're going to learn and grow faster that way. And so, you know, having those conversations and being open about where you are too, if you're on the other side of that- that pairing screen is essential. Do you have any tips for people who are on that side of the screen? So opposite of you, David, about, like, how- how do you ask those questions or what can help make this a successful session by having these -- this conversation?

David: 41:32

Well, I like everything you just said, Bekah. All of that is really important. Asking questions. The faster you ask a question, the faster you'll find out if the person that you're pairing with i-is, you know, how they're gonna react to you? And the faster you'll find out if that's gonna work for you, and it's gonna be a pairing session that you wanna stick with. Or if the person's not gonna treat you well, not in a place where they have the skills to treat you well, and- and you can get out of there, right? The faster -- it's all about feedback and shortening feedback loops. So that's one part of it. It's the faster you can ask questions, the faster you can say what you know, the faster you can say what you don't know without, you know, with as little emotion or ... I mean, we're all emotional people. I don't mean to say you have to be abstract. But there's that thing that we do sometimes ... I've done it when I was learning Indonesian. I did it. When I was almost embarrassed to share what I knew, embarrassed to try to speak in a new language. And I think it's very similar with technology. If you're not familiar with language or concepts, it can feel embarrassing to try. But please do. The faster you try, and the- the faster you take risks, the faster you'll find out who will support you in those risks. And- and how fast you can grow.

Dan: 42:46

Yeah.

Bekah: 42:47

That's great.

Dan: 42:47

And I just wanted to add, that- that advice applies not just to beginners too. It's -- it can be embarrassing for me. I mean, I can feel that embarrassment, you know, trying new things, and- and- and some hesitancy, and things like that [chuckles]. So, it's great advice. I just did -- and it applies to everybody, and we all go through it. You know what I mean? So --

David: 43:05

And we go -- that's important that you bring up, Dan. Cuz we go through it, not just once. It's not just something you go through-

Dan: 43:10

Right, right.

David: 43:11

-as you're entering your technology career. And that's why it's so important to get practiced at it. Because you will experience that throughout your career. Cuz we're always learning, and technologies are always frame- changing. New frameworks, new libraries. You mentioned earlier, a JavaScript or a Java developer who was learning Ruby, I think? And ... when I first started learning Go -- I've programmed C# for years, when I first started learning Go, I bang my head against things. It felt awkward, didn't know how to ask questions. I have been known to rant about TypeScript [Bekah chuckles] and Webpack in Virtual Coffee threads. And I kind of laugh as I do that, because that's me, where I could- I could write C#, cold, probably in -- from memory, from just having -- like, I know the syntax so well, cuz I've done it so long. And I can't, for the life of me, figure out Webpack. Or -- and I struggle with TypeScript bindings. And I was working with JavaScript back before it was popular. So, you --

Dan: 44:16

Nobody understands Webpack, David. [David and Dan laugh] It's okay.

David: 44:21

It's good to have community in that [Bekah chuckles]. But yeah, every- every time you go to -- every time I've gone to a new project or gone to a new company or changed jobs, there's that learning curve again. Every time I pair with somebody new, there's that learning curve. I was just banging my head this past weekend against one of the old advent of code problems and feeling like I don't know what I'm doing, you know? And I've been doing this a long time. So by getting comfortable with that feeling is really valuable.

Dan: 44:49

Yeah.

David: 44:50

It's good- good work to practice.

Dan: 44:53

Agreed. Yeah. I'm- I'm digging into TypeScript for really the first time over the last month or two, too. So we have -- TypeScript Tuesdays is my little plug. [Laughs] Every Tuesday at Two PM Eastern with Kirk, who is -- who's like a, you know, he's- he's done a lot of -- he- he is a fan of, you know, strongly type things. And I have been ... long time not fan of that, so [laughs] ... but some of it- some of it is avoiding it -- is- is, you know, you open -- I open up -- I've been writing JavaScript for 20 years. I open up a TypeScript file, and I'm like, "This looks like ... nonsense to me."

David: 45:24

A-ha. Thank you [laughs] [clap hands].

Dan: 45:24

I can't understand it, and I close it. But I -- and I- and I, like, I'm -- in-instead of like digging in or asking questions and making myself, you know, possibly look like I don't know everything, I close it, and run away, and say, "TypeScript is dumb [Bekah chuckles]. It- it's dumb [chuckles]," you know? [David laughs] That's what I've done for the last 10 years or whatever. And so, finally I was like, "Okay. Let's- let's- let's dig in." And so -- you know what I mean? Yeah.

David: 45:45

Okay. And full on every time I've ranted about Webpack, or TypeScript, I'm aware that it's because I haven't spent the time to learn it.

Dan: 45:53

[All laugh] Yeah.

David: 45:56

[Laughs] Sometimes it's fun to put on that grumpy old man hat-

Dan: 45:58

Oh, absolutely.

David: 45:58

-and say, "Yeah, I've been programming JavaScript since before there were types. I don't -- who needs types? [Bekah chuckles] Like, write your angle brackets. I -- whatever [David and Dan laugh]." No. It's -- but none of that one does like -- really, there's an element of humility that's important to practice in this industry. Because there's so much lack of humility abounds, arrogance abounds, gatekeeping abounds. And anything we can do to be humble with each other and really support each other ... to work together and to grow together is a- a net positive. That's [unintelligible].

Dan: 46:30

Yeah. Yeah. And- and I think a lot of that arrogance, and gatekeeping, and some -- i-i-is- is because -- the root cause of it is insecurity, right?

Bekah: 46:40

Mm-hmm.

Dan: 46:40

And- and not wanting to- not wanting to look ... dumber. Look like you don't know things [chuckles]. And I've- I've fallen in that trap. I- I try, like -- I don't- I don't know. Maybe I- I haven't- haven't noticed. But I- I don't usually -- for me it doesn't manifest as gatekeeping, hopefully, or things like that. It just manifests me avoiding topics [chuckles]. I don't wanna- I don't wanna, you know, learn or don't know or whatever, you know? And that practicing humility and practicing ... admitting or- or, you know, being public about not knowing things is- is been something I've been personally working on for the last couple years. And- and it's -- and it feels good once you- [chuckles] once you turn the corner. Once you realize it doesn't actually like-

David: 47:18

No.

Dan: 47:18

-you know, hurt to not know, literally, everything in the world [laughs].

Bekah: 47:22

What I will say too, one of the greatest learning experiences I've had over the past couple years is watching conversations in Slack between people who I see as experts in the field asking each other questions, right? Like, "Oh, okay. This is how you ask that question." Or, you know, "They don't know everything." And that does help provide more of an awareness that I can ask those questions too.

David: 47:47

Hmm. That reminds me. I wanna go back to that -- a part of the question that you asked, Bekah, that we didn't really address. Which is what makes a good question. And ... [clear throat] if you think about everything we've been talking about, the faster you can help somebody ... acclimatize to how to speak to you, the faster you'll get your question answered. And so how do you do that? You learn to add more detail in the question, which is like your initial offering to somebody. When you're asking somebody for help, the more you can put into that question to say, "I thought about this," "I tried this," "Here's the command I used," "Here's the output that I got." Like, the more language that you use, often it's a better question. Because you're giving somebody more context and the ability to understand better where you're at, and what you're really dealing with. I- I get questions in my job. Sometimes I get questions like, "The integration environment is down." [Bekah and Dan chuckle] And I look at that, and I say, "Okay, thank you [chuckles]." [Cough] The integration environment where I work has probably like 75 microservices or more, across -- like, grouped into several different applications. And so, integration is down could mean any number of things. Are -- is that a -- is -- are you getting an- an authentication error? Is that a, you know, do you have an HTTP status code you can share? Do you have -- can you tell me what application was trying to call what application? Can you tell me what was the actual response you got? What was compared to the expected response you got? Can you tell me what language you're working in? Can you tell me what version of the language you're working in? Can you tell me what libraries and tools you're using that might be relevant? You know, all of that detail is helpful. Partly cuz it teaches the people who might answer your question what language they can use with you, because you're exposing what language you know. And it's also giving people more ... detail to hang onto. There are problems that I can solve. And I have done in our Virtual Coffee's Slack, where just seeing the error message reminds me of something I've already seen. And I can point somebody without even needing to be at a computer or look at their screen. I can at least offer a few keywords or say, "Go try this," or, "Go try that," you know? And sometimes that's enough to unblock somebody. But if-

Dan: 50:06

Absolutely.

David: 50:06

-if the person who asked the question didn't include the actual error message, then I've seen also where that can turn into a thread of 55 messages long with people talking past each other. So-

Bekah: 50:20

Yeah.

David: 50:20

-as somebody who wants to ask a question, I don't expect you to have solved the problem. It's not this idea that, you know, "Don't come to me with problems. Only come to me with solutions." Like, it's not that business. Not at all. But it's ... share with me what you've already thought about.

Dan: 50:38

Totally.

David: 50:38

And share with me as much detail as you can about what you know and what you don't know. About the problem that you're asking. Cuz that will help me learn ... where you're struggling and how to speak to you about it.

Bekah: 50:53

Yeah. Thank you so much for being here with us today, David. This was just fantastic. I feel like we could have done three hours worth of this conversation. But I do appreciate your time and thanks for helping us to kick off our new season.

David: 51:06

Oh, my pleasure.

Dan: 51:08

Yeah. Thank you, David. Thank you for listening to this episode of the Virtual Coffee podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel. If you have questions or comments, you can hit us up on Twitter at VirtualCoffeeIO, or email us at podcast@virtualcoffee.io. You can find the show notes, sign up for the newsletter, check out any of our other resources on our website, virtualcoffee.io. If you're interested in sponsoring Virtual Coffee, you can find out more information on our website at virtualcoffee.io/sponsorship. Please subscribe to our podcast and be sure to leave us a review. Thanks for listening and we'll see you next week!

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.