Drew Clements: Building a career and community

Show Notes:

In this episode, we talk to Drew Clements about the challenges junior developers face, learning through building Protege.dev, and the importance of community support. Drew is a career transitioner, father of two, and full-time developer who spends his spare time building Protege.dev, the platform curated with remote jobs for junior developers. We also talk about approaches to problem-solving, when to ask questions, and using live-streaming as an accountability tool.

Links:

Drew:

• @drewclemcr8 on Twitter
• Protege.dev
• drewclem on GitHub
• drewclem on DEV

Stu the Rubber Duck!

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:14

Hello, and welcome to season 1, episode 6 of the Virtual Coffee podcast. I'm Bekah, and this is a podcast that features members of the Virtual Coffee community. Virtual Coffee 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. Here with me today is my co-host, Dan.

Dan Ott: 00:41

Thanks, Bekah. In this episode, you'll hear from Drew Clements. Drew is a career transitioner, a father of two and full time developer. And he spends his spare time building protege.dev and hopes to become a strong advocate for junior developers everywhere. In this episode, we talk about building a career and also Drew's experience building protege.dev the platform curated with remote jobs for junior developers. Drew talks about the struggles of junior level job searching, the importance of supportive company culture, and learning and public, while building Protege.

Bekah Hawrot Weigel: 01:15

We start every episode of the podcast like we start every Virtual Coffee. We introduce ourselves with our name, where we're from, what we do, and a random check-in question. Today's question is, what is the most beautiful place near where you live? We hope you enjoyed this episode. Hey, I'm Bekah, I'm a front end developer from a small town in Ohio and the most beautiful place near me, I don't really know. But it snowed a lot last night. And so all of the pine trees look really, really beautiful. So I'm just gonna go with pine trees covered with snow.

Dan Ott: 01:59

That's awesome. I love how everything looks with snow on it. Hi, I'm Dan. I am a front end developer from Cleveland, Ohio. I say Cleveland every time I'm actually from Lakewood, which is first city, West of Cleveland. And so there is a park called Lakewood Park that's on the lake here. And it's very beautiful. There's lots of, it's big, and there's lots of cool little spots to hang out. So that's that.

Drew Clements: 02:26

I'm Drew. I'm a front end developer with Foster Commerce. The most beautiful place near where I live. I live in the south. So my options are limited here. So I'm like five minutes from St. Simons Island. But the beaches aren't necessarily pretty. They just have expensive resorts. And I'm like, I'm just out to Savannah. So they have a pretty rad downtown. But okay, I got one. I got one. On the other side of the state from me, which is still relatively close compared to you guys. We have, they call it the little Grand Canyon. It's a little hiking trail. It really does just look like a miniature version of the Grand Canyon.

Dan Ott: 03:08

Nice. That's cool. That sounds cool. Yeah.

Bekah Hawrot Weigel: 03:11

Vacation 2021. Well, welcome, Drew, we are very happy to have you and fun fact about Drew, he designed the Virtual Coffee logo. So thanks for that.

Drew Clements: 03:24

I do what I can. (laugh)

Bekah Hawrot Weigel: 03:27

We always like to start off with the origin story of how you got into tech. So can you give us a little background?

Drew Clements: 03:37

Yeah, that's, I feel like my story into tech is like a story linked to a story linked to a story. So growing up, I played in bunch of punk rock bands. One of the last bands I played in, I met a guy from the local music scene named Sean. Sean moved away to California and became a developer. Right before he did that, I tattooed him. Me tattooing landed me in apprenticeship as a designer a few years later, which then let me, that's where I was kind of introduced to like HTML and CSS. So I was like, hey, I'm learning this stuff. I remember Shawn was doing something like this. So then I reached back out to him. Me and him started kind of talking again. So from there, I was able to kind of work into a developer role with that same company. And left tattooing. So it's, it's a guy I met through the local music scene in 2010 ended up getting me into developing a decade later. Yeah, so I spent seven years as a tattoo artist, transitioned to graphic design. From graphic design, I used to know that Sean, the old connection, to get my way here. And I don't think I could have made that happen if I had all the money in the world and 10 years to plan it, but here I am.

Bekah Hawrot Weigel: 05:08

That's awesome. So if we ever have a Virtual Coffee on-site conference, are you going to offer tattoos? All Virtual Coffee logos?

Drew Clements: 05:18

(laugh) Yes, I will do that.

Bekah Hawrot Weigel: 05:20

All right, we have it recorded. So now you can't back out. Okay, so I'm also want to know about how you found Virtual Coffee. I feel like I have known you longer, a lot longer than Virtual Coffee has been going on. So. But how did you end up at Virtual Coffee?

Drew Clements: 05:42

How did I end up with Virtual Coffee? It's funny enough that we're recording this on a podcast because I met you through reaching out to find people to interview for a podcast I was going to start. So, so I have the recording actually. I don't know if it, I don't know if it ever got editing. I don't (laugh). I just had it right here on the desk. No. So, I guess in 2019, I was going to start a podcast, I reached out to you. We connected on Twitter. That never ended up happening. But we, when I saw you posting, so at the beginning of 2020, I was, I was working two jobs. I was working full time as a designer, part-time as a developer. An awesome, both of those job within like 24 hours of each other. And with a wife that was five months pregnant, that was kind of like a gut check. But around that same time was when you'd posted about Virtual Coffee. So like, you know, I have a lot of spare time on my hands, Bekah posts a lot of awesome stuff, we had a great conversation when we recorded our podcast episode together. So I was like, yeah, let me, let me check this out and see what happens. And now you can't get rid of me. (laugh)

Bekah Hawrot Weigel: 06:59

I think that podcast episode that I recorded with you, I had just been working with Dan for a couple of months. And I like was still trying to wrap my head around things. And I remember you asking me questions and I were like, I don't even know the words that I should use to answer those questions. So... (laugh)

Drew Clements: 07:17

If it's any consolation, there's still a lot of times I don't know the words I should use to answer questions. (laugh)

Bekah Hawrot Weigel: 07:23

Yeah, that's for sure. Same. Same. (laugh) But it was. It was like, it was really great podcast interview because you're just some fun to be around, I guess. So, I'm happy that you are here with us today. And at Virtual Coffee.

Drew Clements: 07:40

Happy to be here. Like I said you can't get rid of me.

Bekah Hawrot Weigel: 07:45

(laugh) Um, okay, so fast forward a little bit, you got another job, your career changer. And you're like, oh hey, I bought this domain called protege.dev. So on top of all of the other things that I'm doing, I'm, I'm gonna start this community building project. So, why and how?

Drew Clements: 08:11

Why and how? Well, so, I originally bought the Protege domain... To the back up just a little bit. I had an old side project called ColtXP. It's a really bad name. Never name anything that ever. But that's what the original podcast that I interviewed you for, was going to kind of be in parallel with that. And so I, I knew that it was a bad name. So I was trying to think of something, something else I could call it. The idea of that project was that it was gonna be pretty much a place where people could connect to work on open source issues together, kind of like a junior finding a senior willing to, you know, give them some time. So I was just trying to think the, the name ColtXP, uhm... I think I just used like a Thesaurus or something like, what's another word for someone that's learning something or something like that. And Colt was somehow on that list. It was like an inexperienced person or something like that. Again, horrible name. Don't ever call anything yet. So I came across the word protege, you know, pretty obvious. I don't know why I didn't think of it in the first place. So I was looking around on different domains. Actually, no. I went to Netlify. And I was like, let me see if protege.com is available. Obviously, it wasn't. So I was like, let me see if protege.dev is available. It was. For 15 bucks. I was like that's not bad at all. So I hit the next button expecting there to be like insert payment information. And it said, congratulations. I was like uh... okay. I guess this is a thing now. So I kind of went back and forth on do I want to make that something new with that name, do I want to rebrand the old project under Protege, which was the original idea. But then, but then COVID happened, and I lost, I lost both of those jobs. So I think, I think I accidentally bought the domain in February and then in March was when I lost work. So, you know, I was looking, I lost work, so I was looking at all the job boards all the time. And it was, you know, you see senior, senior, senior lead, tech lead, bla bla bla bla. And I was like, there's like, there's nothing, it's so hard to find anything for someone at my skill level. So I was like, you know what? I'm just gonna build the job board that I wish I had. And that's, that's kind of how it ended up getting started. I lost, I lost my job and gave myself a new one (laugh). A new one that doesn't pay anything.

Dan Ott: 10:58

I love that, I love the idea of like, you just, you have a problem, you know, and so you just decided to fix it (laugh), to fix it yourself, right?

Drew Clements: 11:07

That's, that's pretty much what happened.

Dan Ott: 11:09

Yeah, it's amazing. And then on top of that, you know, you know you're going to gain experience for yourself, you know? And building it, right? We were just talking to Vic. And he's talking about a lot of this sort of the same thing, right? Like the, he frames it a little differently. But the indie, you know, indie hacking mentality, right? Of, you have a problem. And so instead of, I don't know, wandering around, or just being sad, you know, right? Like, you just kind of go and, go and dive into it, right? And hopefully, it becomes a successful product. And also, you know, you're giving yourself like, experience and scratching your own itch and all that stuff. That's great.

Drew Clements: 11:46

Yeah, the, when I first started out on Protege, my mindset was, you know, I'm going to build this thing in React, I need, I needed a React project on my portfolio. So I told myself, like, I'm gonna, I'm gonna build this out. And if it works, awesome. If not, then I have something on a resume that will maybe at least helped get me hired, which it actually did, fairly, fairly early on. So I think I started building it in March. And either at the end of March or early April, I was connected with a company called Layer Frame out of Florida, super awesome team. And the workout done on Protege, even at that point, before it was even done. Just the fact that I was doing that, you know, building that product, but also the work I'd put into it myself, pretty much jumping in blind was one of, one of the reasons that they can even consider to bring me on the team. So it saved me almost immediately.

Bekah Hawrot Weigel: 12:51

I think that's so great. I think there's a tendency when you are starting out as an entry level dev to just keep going through the tutorials, right? And there's nothing wrong with that. But there's so many different people that are doing those same projects. So if you're able to do something where you're building something that you're interested in, or something that solves a problem for you, you're a little bit invested in it, but it also shows that, hey, look, you know, I tackled this problem, and I kept adding to it and growing with it. And I think that really shows, you know, a really good representation of who you are as a coder.

Dan Ott: 13:30

Yeah, you mentioned like, when you were describing talking to the company who hired you after that, that you went into the, the Protege project going in blind. And I was, I was wondering, like, what you like, in hindsight, like, what do you think of when you say that, like, what pieces were you missing, you know? Now that you've gone through the whole process, and it's been a product, you know, for however long, I just looked at my watch to see what month it was. I don't know what I'm doing. But, you know, it's, it's been a, you know, it's been live for how many months?

Drew Clements: 14:03

Coming up on a year. I think March will be a year.

Dan Ott: 14:05

Okay, yeah. So I guess my question is (laugh), my question is like, what, what do you know, now that like, would change your approach, if anything, you know? If you would start, if you were starting protege.dev right now?

Drew Clements: 14:19

How much time do you have? (laugh) It was, so, the initial build was just a regular Create React App. That was intentional, because I wanted to force myself to learn some of the lower level plumbing. I wish I would have known more about state management in React. Like I kinda... So, right before this episode, we were talking about how some of the, some of the parts of it are really just a juggling act until, you know, it either dies or does what it's supposed to do. So I think, if I would have known a little bit more around that, that could have been, I don't think it's an unstable system. But it's not as good as it can be. And I'm actually in the process of rewriting some of that work now. And I expect I'm going to be able to eliminate probably about 40% of what's there now, and have something that works better in, you know, with better practices in place at the same time. Also I didn't really know much about, like component systems, like I knew what components were, but I didn't really have a good idea of how to utilize them correctly, which is another thing I've been kind of cleaning up as I've been doing this rebuild. We're converting from React, Create React App to Next right now. So I mean, even just last night, I was looking at some stuff like why didn't I just make this a component rather than pasting it seven times in the same place? Yeah. So, just, just little stuff like that.

Bekah Hawrot Weigel: 15:58

It's interesting. I used to write screenplays with my brother. And one of the first bits of advice someone told me or I heard, it was write your whole screenplay, and then cut 50% and then rewrite it. And like, as you're talking through this, that kind of makes sense to me in terms of like, okay, you have something down and you learned a lot in that first process. But what you learn should enable you to really tighten things up and getting it working efficiently or, or making it an effective story and codes not that different from that.

Drew Clements: 16:30

Yeah, that was what Andy's, the co-founder, he came on really early on with me. One, one thing we were very adamant about when we were starting up was that we're going to try to build as much of this as possible without a library, if we can. So that's why, that's why a lot of the state management with some of the forms are a bit of a juggling act, because we knew there was, you know, Redux and other things like that out there. But we wanted to kind of put ourselves in the uncomfortable position of having to build it, the only having to build it with whatever we had available to us then, without grabbing something off the shelf. And... I mean, he would probably agree, we both probably, we learned, we learned a lot of wrong ways to handle state React. We learned a lot of ways that you can do it, but probably aren't ideal. And now we're, now we're getting into the phase of, you know, now, now we can do it the right way with an understanding of why it's the right way.

Dan Ott: 17:37

Yeah, that enable that, that agreement at the beginning, and between you and your partner was is like, a very, very cool thing to do. Especially, you know, it's nice to have alignment and that sort of thing, you know? But I mean, I always, always, always say the best way to learn anything, on any sort of deep level is to do it, just like you guys have done. And state management in particular, I mean like, a lot of things are like this. But state management is one of those, where there's a million ways to do it. None of them are right or wrong, really. And the, but you never really, you never gonna have actual full insight into why you, why to make one choice or the other. Why to use Redux versus, you know, anything else. It, by reading tutorials, you're never gonna figure it out, right? Like, you're never like, somebody could say use Redux for this x, y and z, you know? Don't use Redux here, you know, and you could sort of try to follow them. But you're never gonna, you don't understand why until you've gone down the road of hacking it together, and then getting to the spot where you're like, okay, this, I see now. Like, this is not working out, or this is like more of a pain than it should be, or, you know, or whatever. Or I don't trust it as much, which is, which is one of the, like, one of the, one of the things that's hard to explain until you feel it, right? So you have that, you're talking about that form state. And just not like, you know, it can be better, you know, like, it's working and stuff, but you know, like, there's some, there's some area where it's not exactly sure what's going on or can't track, you know, all the different pieces of state or all the different, you know, figures (??) that go on. Like, that's really great.

Drew Clements: 19:17

Yeah, and even when we're, even while I'm coming through it now, I'm realizing, I'm kind of reflecting back on where I was last year, and like I can kind of like see the growth that I've had over the last year. It's like, as I'm, as I rebuilding part to this, I'm looking at, I'm looking at some of the state and I'm like, okay, this, this definitely needs to be, you know, handled somewhere else in a more safer way. But this is actually perfectly fine to just be, you know, in this one component, and that's all it needs. And it's... I don't know. I, me a year ago would be like so jealous of me right now (laugh), that I'm like able to set them in a position to like to know the difference of one and why.

Bekah Hawrot Weigel: 20:02

I think that's a really good point too, because there's always this tricky thing where you feel like, oh, I have not, I haven't grown enough. But look, you're talking about this one year journey and how much you've learned, you know? You've grown a lot through that. And sometimes it feels very slow. But really, you're, you're moving a ton.

Drew Clements: 20:21

Yeah, and this is actually my, this is my first year as a full time developer. So before this, I was either, um... I was working part time, which was, you know, like, maybe 15 hours after I got done with a full time job. So like, you know, I was already probably coming in at, like, 60% mental (??) capacity. And then the job I had in the agency before that, it was a developer role, but it was, it was with a bunch of proprietary stuff, and some older languages. So like, a lot of it didn't really... So I mean, a lot of it was just customer support to begin with. And the smaller majority after that was, you know, it was in, in such a sandboxed and specific place that a lot of it couldn't really translate over. What I, one thing I wanted to double back on you said there, the, the alignment between me and Andy, a lot of that was able to happen was because, I mean, I was, I was very junior when I just decided to go full tilt on this, but Andy was the same way. Andy was working full time as a project manager, you know. He had written some code before, I don't know the full extent of his, of his experience before that. But when he approached me, he was like, hey, I've had a similar idea. I'm kind of in the same spot. So when, when we were kind of like spitballing ideas, we were like, you know, let's keep it simple, check. Let's build as much as we can without libraries, check. So I think, I think part of the reason we were able to align on so many things in the beginning is that we were, for the most part in pretty much the exact same spot, career wise. Shout out to Andy, by the way. He just started full time as a developer, I think, within the last few weeks. So congrats on that.

Bekah Hawrot Weigel: 22:15

Yeah, for sure.

Dan Ott: 22:16

Congrats to Andy.

Bekah Hawrot Weigel: 22:17

Andy is also very awesome. Okay, so simultaneously, you are establishing a career as an early career developer, and you are tackling a big problem in the industry, right? So can we talk a little bit about the challenges of balancing both of those things?

Drew Clements: 22:40

Um, I don't know if there's a balance as much as I just put as much weight on both all the time (laugh). Which is why I'm probably on like, a beeline to burnout at some point (laugh). I don't know. It's, I don't know, I haven't really thought about it. There's not much for balance. Or I guess I don't really have a process for balancing it. So like, I'm really bad about saying yes when people ask me for stuff. So like, I joined up with Layer Frame. And then, thanks to a tweet that you sent out Bekah, I was propositioned for some other contract work that ended up happening like right alongside that. That turned into the full time role that I have now. So I'm like, okay, cool. I won't have two jobs anymore. Like a month after that someone else was like, hey, I got some contract, or do you want to jump in on? I'm like, absolutely (laugh). Let's do it. So. I've had a bad habit of keeping two jobs.

Bekah Hawrot Weigel: 23:42

Yeah. It's so hard to balance. I'm not, I'm certainly not good at that either. And that's one of the things that I'm working at figuring out I like go through these cycles. I'm like, all in for six weeks. And then for an entire week I feel like I can't move. And that's obviously not healthy (laugh). I'm trying to find better ways of doing that. But also, there's just this weird, I don't know, tech just move so fast all the time. And you want to level up as a new developer. And at the same time, you're so aware of the problems of, I don't know, like being an entry level developer position that you want to tackle them when you have that passion. So there is this weird, you know, how do I do all of these things and still take care of myself.

Drew Clements: 24:34

That's, that's one thing I've planned to focus on this year is getting the stuff done that I want to in a healthy way. I will say one silver lining to taking on all that extra contract work is I've, I've walked away with probably at least two to three things that I didn't know before I started the project. I really forget where that sentence was going (laugh). That was gonna be a good one too.

Bekah Hawrot Weigel: 25:01

(laugh) And that's we, all the time.

Dan Ott: 25:04

Yes.

Drew Clements: 25:07

Oh, no, so, it allowed, it allowed me to work with a couple of different or, you know, just developers with different styles. So when I was with Layer Frame, I was working with Rob. And I feel like Rob was just like a mastermind with everything. So like, anytime I had a, anytime I had a problem, he had a solution for it. And he was really good at walking me through how he got to the solution. So I walked away with some really good troubleshooting skills from that. And then when I, on this last contract role that I just, at the end of last year, I was working with a guy named Nick. And he's just, he's just super knowledgeable around React. And like, some of, there's like so many tools and methods in React that I didn't even know were a thing until I was able to work with him. So it, I overload myself a lot, but so far, I've walked away, I've walked away in the green from it.

Bekah Hawrot Weigel: 26:07

I want to come back to this idea of talking about Rob and one, just like learning in general. So, do you have a measure or a point where you think, okay, I have been trying to figure out this problem. And I know that this other person knows the answer. So at what point do you ask? Like, how far down the rabbit hole do you go before you ask for help?

Drew Clements: 26:31

So at my full time job, we have a one hour rule, if you get stuck for more than an hour, then reach out to someone. And I think that's kind of been rubbing off on me, for my side projects. I'm in a couple of different communities, that I kind of know which one will probably more than likely have the answers I need, or will be, dependent on the time of day, may just be more available. So I usually try to hit it. If, you know, right at the one hour mark, depending on how hard I'm spinning my wheels. Some, sometimes, I know there's been a few times, like I just, I hit a wall and like I don't even know how to start scaling this thing. So I'm just gonna immediately reach out, but then there's sometimes like, you know, I go through, I go through my troubleshooting process. And if I still can't really get anywhere, I have a couple different places I can reach out to the... What I love about the communities that I'm in is that in most cases, it's rare that they're just gonna give me the answer, but they're more so going to work through it with me, and almost kind of rubber duck me to the answer. So that's always super awesome.

Dan Ott: 27:47

Nice. Yeah. Like, I mean, that one hour mark? Seems like a good, like rule of thumb, you know, for that sort of thing. That question comes up a lot, you know, and with, with newer, early career developers, you know, I mean, that exact question comes up a lot. A lot of people are wondering it, and it's hard to sort of baseline it. I feel like the answer can sometimes change depending on the company, if you're, I mean, if you're working like this is not for side projects, but you know, at a job. And I've been finding it very, like, it seems like a good thing to have an actual rule for, like you said, that, that's where you learned it from, have it written down, you know, and make it make sure it's okay for early career developers to ask questions, you know? And like, let them know when to do it, right? Because you know what? I mean, nobody wants to ask a question right away every time they don't know anything, you know, but it always is going to be like, like, doing the rubber ducky thing is just like such a useful tool for any developer of any, any skill or you know, learning level. It just that one hour mark seems, seems cool. I don't know.

Drew Clements: 29:01

Yeah. Speaking of rubber ducks, my, we did uh... Two years ago, we did Secret Santa for the family. My sister got me, she didn't know what, she didn't know what to get me. So she just googled like, coder gift ideas. And she got me this. It says, it says, Hi! I'm Stu, your debugging friend. Tell me your steps and we'll find the bug together! It's, it's right here on my desk. And he does exactly that.

Dan Ott: 29:30

That's amazing.

Bekah Hawrot Weigel: 29:31

I um, I have a problem of, I think, early in my career. It was I don't know if I should ask a question. And now that I'm a little bit in, it's the stubbornness in me that I have to tackle like, I can do this, you know? (laugh) Like, I don't have to ask a question. This is a real check of, I don't know, what does that like hubris or something? (laugh)

Drew Clements: 29:53

(laugh) Yeah. No, I have uh... The first kind of developer role I was in, the senior dev I worked with, he was, he was very much trained the old-school way and brought up with the old-school mentality. So any, anytime I would come to questions with him, he would assume that like, I got to the question, or I got to the problem and immediately ask the question. And that's kind of how he would react to me. Like, there's a lot of tension there. Like it got to the point where I didn't want to ask him a question, because I knew what, I knew the vibe and what the response was going to be. What was actually happening is like, I was spinning my wheels for like, two hours trying to not have to ask him a question. And then when I did ask the question, it was like, you know, grief conflict? A whole bunch of tension. So it's, I don't know, it's, it's been like a breath of fresh air, slash a huge relief that, A, I've found the communities that have found and have places that I can ask questions, but B, now with a company that like, that had, that has their own rule for when you should ask questions, and a lot of times, they're, they're gonna chop that hour down to like, 30 minutes, or like, any time I'm on a project, they're like, hey, one hour rule is actually 10 minutes here, when our rules actually 20 minutes here, and they actually want you to ask questions they have, we have an entire thread (??) in basecamp, where it's just different developers asking different questions. And there's, it's just super awesome thing to be a part of.

Dan Ott: 31:33

That's really, that's cool. That's really cool to hear. Like the per project or something, they'll, they'll just say, okay, for this project, we know it's like new or something, or a lot of moving pieces. So change the rule, you know? Based on that.

Drew Clements: 31:43

Yeah. And they, they're, they're really aware of like, skill level and expertise with the different, with different tools and stuff. So if they're bringing me on to a project that uses you know, like a legacy build that they know, I haven't really seen a whole lot, then, then that's when they'll say, hey, your, your windows 15 minutes for this, or if they're moving, in some cases, even some of the more experienced devs on to something where it's a little more intricate UI work, where they're mostly, you know, data backend stuff like, hey, okay, well, now your windows 10 minutes, and met, but mine will still be the full hour so that they're, they're really aware of like where everyone's at? And like, adjusting their windows accordingly.

Dan Ott: 32:31

That's really cool to hear. I feel like asking questions is almost a skill to learn as well. Sort of similar to googling (laugh) is a skill as a developer, you know? It sounds, everybody who is been a developer for long enough knows what that means, like, knows what a person means when they say that googling is a skill, and you have to learn how to google. Do you feel like you have become better at asking questions? Once like, especially once you start working with maybe a company that value that, you know, value that interaction?

Drew Clements: 33:04

Yeah, absolutely. And, and I would even say, I got better at asking questions, even while I was in that environment. Because uh... Well first, I want to say, like me and that developer, we, it was a really strange relationship. Like, every, every Friday, we would go grab lunch together, we were best buds. And we liked the same music. We were both guitarist, and we would sit, we would sit there, you know, we shared an office. It feels weird to say that I shared a room with anyone right now (laugh). But you know, the entire day, we would just sit there and talk back and forth like it was, we really were just friends, friends inside, inside the company. But when it, when it came to that, that, that was like, that was the only point of friction in that relationship. Which was, which was really strange to me. But I think it's, the only thing I can chalk it up to is that that's just how he was, that was the company culture. He was, he was trained in and brought up in himself. So that's the only way he knows to try to help others learn. Um, but yeah, I think even in that environment, I think I got better at asking questions, because I would, I would ask something and his response would be like, well, what is, what is x mean? What is y mean? I would use the wrong words all the time, which is very frustrating.

Dan Ott: 34:30

Can you give an example of that?

Drew Clements: 34:31

So like, I would say something like, you know, the this, I'm passing this argument, but it's not coming out the right way, when what I meant was the method. But I was using the word argument and his response to be like, well, obviously, that's not gonna work. You don't need an argument there. That's the, I'd be pointing at it on the screen like, that, right there. That's what I'm trying to do. He's like, what? That's not an argument. I'm like, okay. Fair enough. So (laugh), like that kind of stuff.

Dan Ott: 35:02

(laugh) Yeah.

Bekah Hawrot Weigel: 35:03

Yeah. You know, we also see like the issue with entry level devs and the problem of comfort level with whoever they're working with. And I have a lot of feelings about that. But one of them also is that not everybody is meant to be a mentor, right? You know, some people have like a natural ability, some people can have training and get good at it. But some people, you know, they don't desire it, or they feel like it takes away from their experience. And so they're aggravated by it. But a company not only has to make a space welcoming for new developers, but it also has to support the upper level devs, who are providing the mentorship and the guidance and making sure that, you know, that culture shows that how you treat people and talk to them.

Drew Clements: 35:52

Yeah. That's the, um, so, one of, Sean, the guy that I mentioned earlier. He was always really good at, if I ever came to him with a question, he was, his response was always, you know, well, let's look at it together. Or, you know, let's talk me through the steps you're trying to do and let's see if we can find the hang up there. So I think he's one of those people that just naturally has like, well I mean, he's, I know he's been a guitar teacher for a while. So maybe he's just developed those teaching skills.

Dan Ott: 36:23

Yeah. Going back to having a company support the senior devs in those roles, I feel like that's an important thing. I guess tying it back to the framing of making it a rule, like having the rule of the one hour thing, for instance, right? That gives the younger developer, younger, the, you know, early career, newer developer a guideline to follow, right? But it also implies that the question should be asked, you know, and that, and that the question also should be, you know, answered or whatever. So, again, that has to become, I mean, you can just hope that the senior developer in whatever position is good at it and everything, but having it be part of the company culture, having it be expected, you know, that's part of a developer's role is supporting a junior developer, or however it works out. But that part of the developer's job is doing that. Not that answering a question, or helping a developer through a problem is taking time away from doing your job, right? I feel like that can be something that can come up, right? Where if it's not framed correctly, maybe when you were asking a question, he was just feeling like he had stuff to do. And this was getting in the way of doing his stuff or something, you know? And which is not actually correct, right? Like, it's part of his job. I mean, I don't know what the exact situation was there. But like, it should be part of...

Drew Clements: 37:58

There was definitely a lot a lot of moving projects with only one experienced and one learning developer.

Dan Ott: 38:07

Right. Right. Right. You know, and not having it explicit, is a recipe for that sort of thing to happen, you know? You could maybe have be lucky. That's what I mean, like, depending on just hoping (laugh), hoping that it works out. It doesn't, that doesn't seem like the right call. And hiring junior developers is important, but they need like, the people hiring them need to be, you know, prepared, right? Need to be prepared to support them, but also prepared to, you know, have a plan for the senior developers too. Because it's hard. It's also another whole skill to learn. And, you know, having some guidelines like that, I feel like is such a good, such a good thing to, and sort of almost easy thing to pull off, right? Like an easy way to really improve the situation is just like, this is how it works. Ask a question, you know? (laugh) Like, ask a question after an hour, you know? Answer the question after, you know, that when the junior developer helps like it, or asks, you know? I just like that. I like the clarity of that, you know? I think that's really cool.

Drew Clements: 39:12

Yeah. And that actually reminds me one, one thing before I knew about the one hour rule, one thing Sean always did to me that I didn't know until I, you know, months and months later, is that when I would ask him a question, he would, he would, he would set like a timer, like he'll reply within one hour if he doesn't hear back from me. And I didn't know that was the thing. So like, I, I just asked him a question, I keep trying to work on it. And then there were a lot of times where like, oh, nevermind. Got it. And then like, at, what, I think it was after I'd left the contract role with him, he's like, yeah, I used to give you like an hour anytime you ask a question and towards the end you got to where you were responding back within like 10 minutes that nevermind, you found the answer. But touching back on what you were saying about companies needing to, you know, like proactively support junior developers. That's one of the things we're doing on Protege. So all of our, all the listings there are curated and like, approved by us. That's one thing, when, when a company lists with us, one thing we gotta do, one thing we do is, you know, first we read through the listing and make sure it kind of lines up with, with the goals we have for Protege. But then we also kind of like dig into the company's website, and you know, maybe their LinkedIn to try and get an idea of the company culture like. Are, are they posting this role because they just want to pay someone cheap? Or are they posting this role because they genuinely want to find someone to build them up into the best version that they can be? And we try to, we try to make sure we have a good idea of, of, of the answer to that. For, for every listing.

Dan Ott: 41:03

That's really cool. I mean, and that's like, I feel like one of, one of the things that makes Protege, you know, special is the curation and the sort of insight into the, the junior developer mind, if you will (laugh), you know? It's, like you said, it's not just a, I don't know, collection of, of things that people want to find cheap worker, you know, something like that, right?

Drew Clements: 41:30

Yeah. I'm a,

Dan Ott: 41:31

It's really cool.

Drew Clements: 41:32

I will always refer to myself as perpetually, perpetually junior developer. So hopefully, I will always be able to keep that mindset. But we have, I was actually just talking to some people in the Virtual Coffee group not too long ago about, about some tools and features we can add, to hopefully help empower both sides of the process in our interface to build.

Bekah Hawrot Weigel: 41:55

So okay. So, if you had a magic wand, and you could get everything you want for Protege, what does it look like?

Drew Clements: 42:02

If I get everything I want, in terms of features or success?

Bekah Hawrot Weigel: 42:07

Whatever you want. Let's do it all. You've got a magic wand. It's your choice.

Drew Clements: 42:10

If I had a magic wand, there, there'd be accounts for both candidates and companies, there'd be, there'd be tools on both ends to do both empower and protect both sides. I don't really feel like the companies would really need much protection. But in some cases, like maybe the candidates do, especially from, you know, like ageism, or, or something like that. Yeah, so some, some tools around like empowering candidates against discrimination. So like, maybe there, maybe only like their work history and like, some kind of like generic questions they answered are available. And the company can't really see what their you know, name, name, gender, age, or location or anything like that is until, you know, they schedule an interview with them and have something kinda like on the books or something like that. Or even, even a tool to where maybe candidates can say like, you know, I'm in this time zone, but I'm willing to work in up to these are you knows different stuff like that. I haven't looked at the, like the company side of a lot of the job board competitors, which I don't really consider them competitors. Because like, they, they have their niche. They're doing their thing, we're, we're trying to solve a completely different problem. So we'd really just like all the tools for everyone (laugh). And that's it.

Bekah Hawrot Weigel: 43:41

All right, excellent. I mean, it is so hard to search for a job as an entry level or junior developer, because they don't make it clear. Or you do have those problems where they're like, yes, we want an entry level developer, but you have to know all of these things just because they want to get you to do work for less money. And that's such a problem. And we see people over and over going into those environments and just being, you know, totally frustrated, and it's affecting their health because it's such a terrible place to work. But then it's so hard to find another job. But it's jus, I don't know. It's just this, this huge problem.

Drew Clements: 44:23

Yeah. Ideally, we want to build a network of companies that we know without a shadow of a doubt, like just support juniors, like from the ground up in every direction. And that's, that's really what we want for it is just, oh, you're, you're a new candidate, you're looking for a job, okay. Well, we know these 15 guys, or, you know, these 15 companies are, are hiring and we have a good working relationship with all of them. And we know regardless of where you end up, any of them are going to take care of you.

Bekah Hawrot Weigel: 44:56

Yeah, that's so awesome. And it's nice to have connections with communities where you can see junior developers who need jobs, and you know that you can vouch for them too, right? Like, there's a difference. You'll get the, I'll get those Twitter messages like, hey, I saw you asked about your friend wanting a dotnet job. I want one too. Can you recommend me next? Like, no (laugh), I don't know you.

Drew Clements: 45:20

(laugh) I actually just had a, I guess was kind of a screening call last week with a company that they just like, they hit me up on Twitter, like, out of nowhere. And I spent like the last 10 minutes of that interview, like talking someone up from Virtual Coffee, because that referred them to apply to the application. So like, the lady I was interviewing with, she's like, okay, she was about to do like her little goodbye speech. And I was like, wait, before you go. Let me tell you about this person. And I was like, they do this, they do this, they have this experience. Look at their application. Forget about mine.

Dan Ott: 45:59

Nice.

Bekah Hawrot Weigel: 46:02

Okay, so another thing I want to talk about, because you are just doing like stacks on stacks of things. Okay, so you're building a career, you're building a community slash movement. And it's an also an open source project, and you're streaming some of this. So you're like, okay, let me make this even more difficult (laugh). So I'm going to add the open source maintainer thing, and I'm going to stream it. So what was the idea behind adding those components? And, you know, I, both I'm interested in like, how has that been challenging? But also like, how has that helped you as well?

Drew Clements: 46:42

Well, we decided to make an open source, because we wanted a way... Well, one of the questions we kept asking ourselves early on was like, what can we do to let the companies know that the candidates they're considering here are, you know, worth, worth the hire, and one of the ways we thought we can do that was make it an open source project to where those candidates can actually contribute to the platform itself, you know, we, we display anyone's who's contributed to the project is on our contributors page. And the idea behind that was that companies could, ideally in our heads is that played out, companies come here, they, they want to post a job. And then they see it on the contributors page that, oh, so there's actually six applicants here that have actively helped to build the platform I'm listing this job on, you know? Maybe, maybe that'll help give them some preference or something. And even if it doesn't, then, you know, we're doing our best to, to help junior developers, so even if it doesn't help in that regard, it gives them the opportunity to work on a real world app that they can add to their resume. I mean, even if it's just, you know, I think there's been some contributions that were just accessibility fixes. But, you know, that may have just been, you know, from code perspective, all they did was changed the Tailwind class, but, you know, they also set up the project locally, they also, they also, you know, at least have an understanding of Git and how that whole process works. So that was, that was a lot of the reasons why we decided to do that. I decided to stream it, because... Partly because I was unemployed and bored, partly because I wanted to force myself into some accountability. So like, now, there's a lot of people out there that know this is a thing, so I don't want to say they're depending on me, but they know it's a thing. And if... I'd feel really bad if I started building this thing that was gonna help the community and then just like, let it go. So now I have all these people that know it's a thing and they can just say, hey, how's, how's that going? And my response can never be, oh, I turned it off. So that, that's, that's never gonna be a thing.

Dan Ott: 49:08

I like that idea of the streaming for, for accountability, you know? I mean, the side project issue, you know, of abandoning in or not, or whatever, and you're right. You're, you already have, you have an audience of, you know, you have people coming in, but that the, the streaming, I feel like is, is a interesting bit to add, just for like the accountability, part of it, you know? I think that's really cool.

Drew Clements: 49:34

Yeah, and there's, there's actually parts of the application now that wouldn't exist if it wouldn't have been for, for streaming because I'd hit a bug or get hung up on something that I probably would have never found, but there have been, there been people in the chat that were, you know, helping me debug some stuff. And if you look on the contributors page, the last three entries on it, it actually just says special commit. Those are there because those are, those are three people that were consistently there for, I think the first two months, I was working on building a stream to pretty much every day. So those three people were there for probably 85% of that streaming process. And we're doing a lot of like, you know, coaching or problem solving with me through the chat. So that's what, that's why we put them up there. Yeah, and we've had, we haven't really done much marketing for Protege. I feel, I feel weird trying to market a thing I built, but it's kind of, kind of through Twitter, and through streaming, and through a couple of other communities, we, we've somehow managed to, we average around 400 users per month, which, you know, in the, in the larger scale of Google Analytics probably isn't a whole lot. But for, for something I started building out of nowhere last year with no marketing, I think that's pretty good numbers. So we're really, we have a phase two, we're kind of like ramping up for now, which is part of next, the next migration as part of that. So we want, we want to get those numbers up not because we want, you know, good analytic points, or whatever the business side of that is, but if we can get that number up, then that's more people that are, that's just more people we're helping or, you know, maybe it at least giving hope that you know, someone's out there doing something on, on the behalf of them.

Dan Ott: 51:34

Absolutely. And, you know, the bigger community gets like around that or audience or whatever, you know, the more, it's sort of exponentially increases the exposure without even doing ads, or you know, anything specific did grow it, you know, yeah. That's really cool.

Bekah Hawrot Weigel: 51:54

All right, Drew, thanks for being here with us. We really enjoyed having you. And congratulations on everything that you've done with Protege and for your one year, anniversary, or birthday, or whatever you want to call it going up. So where can our listeners find you?

Drew Clements: 52:11

You can find me on Twitter @drewclemcr8, drew-clem-c-r-8, because you know, all the good handles are taken. You can find me, I haven't been streaming a lot lately, because of, you know, work and two kids. But I'm on Twitch at twitch.tv/ducky_87. I used to do some gaming streaming like, four years ago, and I just never changed the handle. And now just kind of like it, so... And you can also find me, you can find me in the Virtual Coffee sessions. Do you ever want to pop in and join one of those? Usually on Tuesdays. I can't make, I usually can't make Thursdays.

Bekah Hawrot Weigel: 52:56

Yeah. And also there's some open issues on Protege. So if you're interested in contributing, it's a great project. It's got a great community behind it. And there's lots of people there too, willing to help and answer questions. So we're very glad that you came here on this podcast and that you've been working on this project. So thanks, Drew.

Drew Clements: 53:17

Thank you.

Dan Ott: 53:18

Thanks, Drew.

Bekah Hawrot Weigel: 53:23

Thank you for listening to this episode of the Virtual Coffee podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel, and edited by Dan Ott. If you have questions or comments, you can hit us up on Twitter @VirtualCoffeeIO. Or you can email us at podcast@virtualcoffee.io. You can find the show notes. Plus you can sign up for our newsletter to find out what Virtual Coffee has been up to on our website at virtualcoffee.io.

Dan Ott: 53:53

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.