Hiring and nurturing junior developers

Hello and welcome to this episode of Go Time. I am one of your hosts, Johnny Boursiquot, and joining me today are my regulars, including Mr. Jon Calhoun. Say hello, Jon.

Hey!

And coming back in full force, we’ve got Carmen Andoh.

Heeey! It’s good to be baaack! Missed you all!

Nice, good to have you back. And making his second appearance in less than a month, or something, is Stevenson Jean-Pierre. How’s it going, man?

Hey! Thank you for having me.

Awesome, awesome. Today is kind of a different show, in the sense that we’re here to talk about junior developers, specifically hiring and nurturing junior talent - how do you do that on your teams, how do you structure your environment, how do you structure your organization to allow for junior developers to succeed in that environment? Why hire junior developers? What do they bring to the team? How do you make the experience for both your organization and your team and them a successful one, one that is productive, one that is gonna benefit the both of you?

Today we have a few things to talk about. I’m gonna start opening the floor up by basically saying why is it that seemingly, in my eyes, every employer out there these days is hiring senior talent only? Literally, every post I see, it’s like, okay, looking for a long list of skills and experiences, and of technologies, and buzzwords… I mean, sometimes I look at this and I’m like “Who, even experienced, can actually meet all of these qualifications?” It’s just getting kind of silly, kind of ridiculous. I’m not sure who is putting together these – leave it to me to start with a rant, right? …I’m not sure who is putting together these job descriptions, but the list keeps getting longer and longer and longer.

That aside, if you are a junior developer and you’re looking at that list… I mean, that is intimidating. Anybody on this panel, please enlighten me and tell me what is going on out there.

I think most companies have the expectation that if they only hire senior talent, then most people will be able to hit the ground running quicker, they’ll be able to contribute sooner, and they’ll have less training to apply to that person to get them up to the speed that they want to.

[04:06] And the not-so-secret secret is that as an industry, we’re pretty bad at training people and teaching people how to do things, so we just hope that we can hire senior people that come with all the pre-training applied from somewhere else, and that we can just benefit from somebody else’s work or from some other company’s previous efforts in training that person up.

Yeah. And to piggyback on Stevenson’s comment, I also feel like many companies - not only are they bad at training, but they do not have performance and promotion incentivize to train. So if you were an engineer, you need to show technical impact, and that does not include - and that’s unfortunate - growing new talent. That seems to be in the purview of a hiring manager, or a recruiter, getting them there. But once they’re there, in a company - and these are companies both large and small - there isn’t anything that’s formalized in terms of incentivizing the people that are already there to grow the new talent, and acknowledge that and promote that. So I think that’s also adding to this problem that we have as an industry, in terms of growing the workforce and growing our set of gophers.

I suspect there’s also a volatility aspect, where you assume that if you hire three senior engineers, that yes, it’s gonna cost more, but you kind of have a known “They should be able to perform at these levels, and the project should get done on time”, whereas junior developers - it’s kind of a guessing game, where you’re thinking “If they end up being a great developer and they pick up things really quickly, then maybe they’re performing at a really high level.” But if they don’t, it could cost you some senior developer time to train them, and you don’t know exactly what that’s going to be, so it makes estimating time very hard… Which I don’t think that’s impossible to get around, but I just think people view it that way - for this quarter, we have to get these things done; I can’t afford to have training on the schedule.

Yeah, you mentioned quarters, and that’s also something that we are horrible at. We just have no patience, and we have no eye for the long game. We just work in quarters, and we work in sprints, and we work in semesters… We maybe are long enough to work in a year, but then projects get delayed, and we didn’t estimate right… So all of this attributes to the short game, instead of the long game.

Recently, at least in my last job, at which I spent like three years, there were some junior developers on my team. I worked with these talented individuals quite a bit, and I also had senior developers on my team. Literally I could not, from day to day, other than the occasional pairing and the occasional discussion on design, things that really come with experience, once the juniors got going - really, I couldn’t see a difference in terms of the code commits, or when I did PRs… There was nothing, ever, anything in my mind that says “Oh yeah, I’m reviewing a junior developer’s code.” That whole notion that somehow they’re not gonna be adding value to the team - that’s patently false.

I think the onus is on us, the people who do the hiring, the hiring managers. I’m not necessarily talking about the recruiters and whatnot, because a lot of times these folks don’t really know what they’re recruiting for in terms of technology, in terms of what to look for, and skillset… It’s not their fault; that’s not their job. Their job is not to know the ins and outs of the technology. So it’s our job as the hiring managers, the people who are trying to decide whether this person is gonna be a good addition to the team or not, to sort of be real with ourselves and say “Hey, I know that adding one junior developer to this team of five is not gonna have that much of an impact on timelines, or something like that.”

[08:12] Like Carmen is saying, play a long game; this developer is gonna become a lot more productive if they grow alongside other developers over the next 6 months, 8 months, to a year. So playing that long game…

It’s almost like we don’t see the value… So let me ask it more bluntly - why hire junior developers on your team? What’s the value?

I love the concept of “zen mind, beginner mind”, and this is whether you are a junior developer or you’re just new to a company - you have this ability to see “Why is it this way? Why isn’t that documented? Wait, how does this work again?” And you sort of forget, because you have what we call institutional blindness. You’ve acclimated to the point where you can’t see where your blind spots are anymore. So having them fresh – and this also works for somebody who’s senior, but it’s particularly great for a junior developer, because that really tests your onboarding materials, and how well you can scale, and these processes, and the ability to communicate… So it really is good engineering for all of the other things and how well your company, your dev team, your processes, your bureaucracy work altogether. If you provide a culture of asking, that really can help so much.

Companies aren’t won or lost at the brilliance of the tech stack, or even the brilliance of the developers; they’re won or lost in communication. They’re won or lost in the ability to get things done and work cross-functionally… So these are the things that dev, new/junior developers really can bring to the surface and help improve… Because we design these kinds of things for them.

I don’t know if this is gonna come off right, but another reason to hire junior engineers is because, for the most part, they are this kind of clean slate engineer developers. As a company, you’re trying to build a certain positive culture, and you’re trying to do certain things. I think having people that aren’t already jaded by the industry can help you foster that culture that you’re looking to build, and grow those people into the type of senior engineers that you’re hoping out of the company… But that definitely requires that long vision for the company. You can’t be measuring things in quarters, like Carmen has said, but you have to look at things in the longer term; “What can we do with these engineers in 2-3 years, and how can we make sure that when these engineers become senior, we know from the top down we have the type of culture that’ll be very open and welcoming to other people in a way that you really see the company vision going” I think too often companies don’t really look at it in that way.

Just to add one more point, I think cost is a big part of it, too. If you have a team that can take junior developers and get them up to speed and get them performing, even if they only get to 80% of a senior developer’s performance, or they still need some help, they’re more than likely way, way cheaper than a senior developer. And that won’t always be true - I’m not saying you should exploit them, or anything - but I think that’s part of being a junior developer… You’re learning on the job, and you’re gonna be a little bit cheaper for the company.

So I think the companies that do it right are gonna be the ones that can ship things for a lot less money. And then not only that, but like you’re saying, they’ll have senior developers that are great for the company in the long run anyway, so it helps them in multiple different ways… But that requires them to think long-term.

[11:49] That’s a very interesting point. As a hiring manager, costs never actually come up with regards to how we pick our candidates. You have an open headcount, and the headcount gives you a salary range… And sure, you can come under that salary range, but nobody’s gonna be congratulating you for coming under budget, or anything like that… From my experience, at least.

I’ve never been in a situation where costs really factored in. It was actually the opposite for us, where because we had the open headcount, we would rather go senior, because a headcount is a headcount, regardless if you hired a junior or not. And there was no such dichotomy or situation where we could say “Hey, we’ll get two juniors for the price of a senior”, because the all-in cost is always more than purely the salary.

It was all interesting to me, because before I became an engineering manager I always thought that that was a trade-off that can be made, where you could have maybe lower-cost salary-wise individuals that can maybe be a kind of multiplying factor… But from an organizational perspective, it seems like the organizations I’ve been at, at least, never factored cost in when doing that kind of hiring activity.

What size were the companies you’ve been at? Are they all fairly large?

My previous place was an enterprise, very much - 13,000 employees, so very large. My current place now, we’re 600 employees.

Okay.

So there’s a difference there, but I still haven’t seen that kind of real focus on the individual cost.

Where I saw this the most was with startups that are less than ten employees… Where bringing on a junior developer and training them is hard, because when you’re that small, a good chunk of your company has to help with that. But at the same time, when you’re a startup with a very small engineering team and a small budget, you can’t necessarily afford the engineer who’s like “My starting compensation packet has to be $250,000, no less.” And as a startup, you’re like “We can’t do that. We can give you equity that might be worth something, but that’s about it.” And junior developers are usually a lot more willing to take that chance, if they can learn a lot.

And I do think startups are a great place to learn a lot about the entire stack, which is one of the things I really like about them. The downside is it doesn’t necessarily look as good on a resume. A Google or something like that on the resume will get you in the door pretty much anywhere… But some startup that flopped is not really gonna get you in many doors.

So it’s kind of a trade-off in that sense, but I’ve always seen that startups - that’s where you can make those cost analysis benefits and try to decide basically “Is this gonna be worth my time to get somebody a little bit cheaper, that we can bring on board and get them up to speed and have them taking over things, and very quickly growing?” But it really depends on what you’re working on. Team size is just a huge – because like you said, whenever you’re talking about headcount, you really have no motivation to do that, which is unfortunate.

Both of you also bring up a point about the type of company and where they’re at… So is a junior developer better for a startup? I have been mentored that maybe the best place for them is in a larger place, where they’re maybe outside the critical path, where they have more of the bandwidth for people… And I’m not sure, because I actually went into a startup as a junior, and it certainly had its trade-offs. I remember having a trusted advisor saying “You know what, in order to grow your career, you really need to do X, so that you can have less stress.” Because it can be a bit stressful. Especially when the startup environment is one where you don’t know if you’re gonna survive past the runway.

So that’s also a super-interesting thing, when you are a junior developer or you are a person hiring junior developers - being mindful where you’re at and your capacity, both headcount-wise, or resource-wise, to take on a new developer.

[15:51] I wanted to also say - before the show started, Jon said something super-interesting… He was in a conversation with someone who considered themselves a junior developer, but only to find out that they had ten years of PHP experience. So they were sort of using junior developer as “I don’t know this tech stack, therefore I’m junior.” I wanted to briefly maybe ask everybody’s thoughts about how they operationally define a junior developer.

If you’ve been a developer for ten years, if I’m putting something brand new in front of you, like a new language, or a new server technology, or whatever it is, I’m not considering you a junior. You’re an experienced developer, you just happen to not have a ton of experience in this brand spanking new thing I’m putting in front of you. We should definitely not get those things confused at all.

An experienced developer is an experienced developer, regardless of the technology, regardless of the stack you’ve been working in. We’re talking about years of experience here. Because at the end of the day, if you’re going from language to language, for the most part you’re gonna have to learn some syntax and maybe some brand new ways of thinking, but you’re gonna bring with you a whole heck of a lot of experience in terms of years spent learning how to work with a particular kind of technology.

The interesting thing here, which is something you also brought up, Carmen, is that a lot of times when folks are applying for jobs, depending on your background, your ethnicity, your gender, you will find people that are hesitant to apply for certain jobs because they don’t check all the boxes. Carmen, you came across a study - and I think I came across it as well; I can’t, for the life of me, remember what it is… But it showed that women, in general, applied for a lot fewer jobs, because they thought they did not check all the boxes; literally, every single requirement of the job… Which, in this market – I mentioned in the opener, every single job description that’s coming out has a long list of requirements and is really, frankly, unrealistic at times… You would have to be – I mean, I don’t even know how to explain this.

If you are a woman and you see that long list, you can’t approach it; it’s unapproachable. How do you even reason…? Which to me is what’s making this whole – it’s like a death spiral; the job descriptions are getting ridiculous, and you have folks that are not applying for these jobs because they don’t see themselves meeting all of the qualifications… How do we reconcile this? This is kind of madness.

When we talk about seniority, in my mind it’s about actual lived experience in terms of working, and things like that. Tech stack rarely matters. Once you learn patterns and learn to identify patterns, I think that’s what as a hiring manager I optimize for when hiring people, rather than them being very good at a particular language or a particular tech stack.

In my personal opinion, I don’t care if you’re some kind of programming prodigy; if you’re one year in development, there’s no way you’re senior, because you just haven’t seen enough things over time to build these patterns and pattern recognition for things.

That applies to SRE and things like that, too. Time is what really builds experience, so… I can’t imagine a world where somebody has been an active developer for ten years and still considers themselves junior, because there has to be enough experience in that ten years where they’ve seen things, and things have broken in very interesting ways for them to build that context and build that kind of experience.

[19:46] Going back to Johnny’s point, I think one thing that bothers me to hear that, that people aren’t applying for jobs because they tick every box, is that I don’t think there’s a single job I’ve got where I ticked every box. And still, to this day, I don’t know if I could apply to any job that I would tick every box, because there’s always gonna be some random thing that I can’t tick. And that’s a little bit depressing, I guess, because that means there’s probably great developers out there who just aren’t applying for stuff because somebody’s setting them up for failure with these requirements that are just unrealistic.

I think one of the things I’m seeing as a trend in more of these job descriptions - GitLab was really good… It was for an infra engineer position, and they explicitly said “If you do not have all of these skills, apply anyway.” That line did more than anything to help increase different personalities, people who maybe were suffering from impostor syndrome, regardless of gender or specific economic status, or ethnicity… And I think that was great. So that’s one way that you can combat that.

The other way is also to restructure to what Jon said, and also to what Stevenson said, which is we care about whether or not you know how to go about that rigor of solving problems, or maybe you’re curious. There’s just this idea of being able to – or communicate. Which bleeds into the next thing - what are the things that make a junior dev succeed? What is that time? What happens during that time that makes a senior developer? Is it 10x engineering coding skills, or is it something that’s a little more subtle?

We’re stumped. [laughter]

It’s a hard question to answer, because there’s just so much to it. If I saw developers who I thought were great - these are guys who are on the top of their game, I felt like they were the strongest developers on the team… Rarely was it because I saw them pumping out a lot of code. It wasn’t any metrics like that. It was almost always they understood things, they could help others… If you had a problem, they were the ones you could talk with and they could help you come up with a good solution… There were a million small things like that, that weren’t “Hey, I know how to code in Go really well.” It’s “I understand the problem space we’re in, I understand programming in general, and problem-solving, and I’m good at helping other people solve their problems, and putting that all together.” But actually defining what that is or how you get there is just so hard.

It is.

Yeah, I definitely agree with that. At my current organization we have everything from SDE-1 to SDE-6, but after SDE-3 or SDE-4 I rarely see any technical difference between those people. What I do see though is the behaviors, the collaboration, their ability to digest issues and give it back in a way that’s understandable for the business, for junior developers and everybody else. I think that’s when you start kind of really seeing the experience there; you see that they’ve encountered some of these problem sets before, they’ve encountered them in ways that they could come back and help identify those issues and even just help make sure that everybody else understood those issues.

Some of the best developers or engineers I’ve seen over the years, they have this ability to multiply the productivity within an entire team, without them often not even doing any of the coding. It’s amazing. They are a force multiplier. They can get other people to be productive, and basically rowing in the right direction.

Sometimes we call these people principals, sometimes we call them leads… Whatever title we want to put in front of them. And sometimes I’ve actually seen folks who don’t have the title do that job as well. It’s amazing. There’s something beyond just the hard - I’m sorry, how do I put this - coding skill itself; just being able to put code down, type it out and be able to express what you’re thinking in code… There’s something that goes beyond that, where you can bring other people along with you, that makes them productive, too.

There’s something about that that is actually worth its weight in gold. Those are the people we need to – maybe what we should try to do as organizations, as teams, is to try and push folks towards that model. I’m not sure if there’s a formula. That’s such a hard skill to try and develop. Like Jon is saying, how do you get there? Experience maybe? Empathy? Is it part of the person? I know some people who are good at that, and even though they are very skilled, they’re not so good at bringing others along, kind of thing… So there’s certainly a mix of qualities and character traits in there, I’m sure, but – to me, that’s valuable. When we jokingly talk about 10X, which we all know is kind of a ridiculous term, but how do we get somebody to 10X everybody else around them? What does that skill look like?

I think as organizations, we have to optimize for that sort of behavior. I see all too often some organizations will promote the purely technical people up to certain levels, without having the human skills that are necessary to become that 10X engineer… And I think that’s fundamentally the wrong approach if you’re looking to grow your organization in a way where people can be valued contributors.

Back to the point that I made about not seeing a terribly big difference between SDE-3s and SDE-4s versus SDE-6s, the big difference I do see is that ability to lead, that ability to take people with them. If you’re a hiring manager, or even if you’re an engineering manager that’s looking to promote team members, you have to make sure that you’re actively fostering that behavior as part of your career development process, part of your promotion process. If you purely focus on the technical, you might have some really good, standout engineers, but that doesn’t create a kind of mindset where you’re taking the whole team with you, and taking the whole organization with you.

[28:11] I think there needs to be a very good balance in career development frameworks and from an organizational perspective where they balance those human factors - the empathy, the ability to teach the raw technical talent that may be present in engineers, and we try to foster those two things together; then you end up with those high-level engineers that are both empathetic, and have the ability to teach and learn… And I feel like that’s definitely a muscle we don’t flex enough as technical places, where we make sure we’re giving even senior engineers the ability or the knowledge set to learn how to teach, and learn how to help share the information that they already have.

We purely focus on them building up their technical skills with projects, and things like that, but what are we doing to help train them to learn how to teach, or learn how to share information in a way that becomes that force multiplier.

So this is a skill that is not incentivized, to any of you.

I don’t think it’s incentivized in engineering organizations, for the most part. I think we’d lock up and find those people that from their own altruism, or whatever you wanna call it, they get in that role and they wanna teach… But I don’t think it’s something that we often incentivize as organizations, nor do we even have training groups built around engineering, if you look at it. If you’ve ever been in a large enterprise, HR will have dedicated training, and other groups will have dedicated training, but when it comes to engineers, they’re like “Well, just figure it out. Do some documentation research and figure it out.” We don’t put these kind of training structures around these things, where we’re helping senior engineers become better teachers, or we’re helping engineering as a whole find the language to properly teach things.

So if you could just make whatever decisions you wanted, what sort of changes would you go about making to get junior developers up to speed, but then also to keep them growing into those people that can mentor others? Is it just larger training budgets? Is it more pair-programming sessions? Is it just more time for letting them discuss and have one-on-one with the senior engineers? Because there’s a lot of options out there.

You see that Bill Kennedy does training courses, and there’s online courses… There’s a lot of different ways that you can take a junior developer and potentially offer them training that we don’t do now… So where would your first steps be?

Part of my steps would be in building up the team, making sure that they’re incentivized to learn that skillset. My last organization had a very well-balanced career development framework, where they highly focused on behaviors, as well as raw technical talent.

When I’ve looked at other career development frameworks at other organizations, sometimes I think they kind of over-indexed on just pure technical talent, when they behaviors are just as important. And I think that’s also a thing that helps build proper culture in engineering teams. You may have the brilliant a–hole on your team, and things like that… People kind of over-value those people, because they’re cranking out a ton of code, and cranking out features, but are you alienating newer members on that team from being able to learn? So I think optimizing for that thing, making sure that you’re striking that balance between behaviors and pure tech talent…

Also, I don’t believe that pure tutorial-based learning, just reading things will actually give you that experience that you need. I think experience is built, like I said, over time, and running into issues… So having projects that you can give to junior engineers, and give them time to really cut their teeth on those projects, and if they run into issues or if they don’t optimize it first, I think that’s fine, but it’s a muscle that needs to be exercised and they need to learn how to encounter issues, how to deal with those issues, how to overcome those issues and get that sweet release of finally getting over that hill, and them solving an issue.

Of course, senior engineers could help, but I think it’s something very much that you need to help them grow naturally into getting into that mindset of continuously learning and figuring things out.

[32:06] I think this came up the last time you were on the Go Time podcast, Stevenson… I think you had mentioned doing pair-programming sessions or mob programming sessions, and that sort of thing… Which I really liked, because it’s intimidating for someone who’s junior, but at the same time it’s a great way of – you can throw them into something that might be over their head, that might be challenging, and they’re still getting that experience you’re saying they need to get; they’re solving a real problem. But it’s not like you’re throwing them into the deep end and they don’t know how to swim, and you’re just walking away; you’re there, you’re the lifeguard, you’re helping out when they need it, so there’s a lot of help there.

I guess you had mentioned that you guys did mob programming sessions…

Yeah, it was.

Can you talk a little bit about those and what the experience was like?

Yeah, so pair programming, mob programming to a certain extent, and also solution roundtables, are part of the same dynamic, where you’re doing group learning, or just group solutionizing, in a way. So you start with pair programming, where you have somebody that’s more senior, or – I guess the seniority doesn’t actually matter with pair programming, because I’ve even seen senior engineers pair program. But if you’re talking about junior engineers and bringing them up, you would pair junior engineers with more senior engineers, and they will work together on an issue. Hopefully, what the senior engineer is doing is talking through the solutions as they’re working through things, talking through their mindset and their mental models around the issue that they’re encountering, and talking through how they’re approaching it, and things like that.

Mob programming takes it to another extreme, where it might be a whole team, it might be something – and where I find it mostly beneficial is when as a team you come across a new problem domain that you haven’t encountered before… My teams have always been teams of SREs and people that are dealing with a lot of back-end issues… And if collectively you’ve come across an issue that you haven’t seen before, getting junior engineers and the rest of the team all in the same session, kind of talking through how we’re approaching this, what we’re looking at and why we’re looking at this thing - it helps build and share context for the team, so that in the future everybody benefitted from that, as opposed to just individual pairs of people benefitting from some knowledge set, than maybe parts of the team.

Oftentimes, when you build teams, you find teams to be highly complementary. Not everybody has the same exact skillset, so when you approach an issue together as a team, people that are focused on a particular skillset can help the ones that are not as good in that same skillset, so you might even have senior engineers where one person is deeply technical in one area, where the other ones aren’t, but building that shared context helps everybody on that team.

On a more pragmatic level, how do we help – because this is a Go Time podcast… We are talking about things in more general terms, but how do we help junior engineers break into the Go ecosystem? Maybe there’s a certain understanding or knowledge about how you would go and maybe search packages on GitLab or GitHub, or whatever. What are some of the things that are Go-specific?

I’m very bullish on this, but…

Be bullish. Go for it, Jon!

I hate when people tell other developers not to use third-party packages, or not to use Testify, or something like that, strictly because most of the time when people wrote things like that, they did it because they were coming from a Rails environment, or something, and it helped them wrap their head around Go. And then they turn around later and tell everybody “Don’t use this.” And it’s like “Clearly, it helped you. You wrote it for a reason (or somebody wrote it for a reason) and it became popular for a reason.” So it irks me, because I feel like we’re expecting them to take everything we learned in 2-3 years of experience with Go, and we’re like “Oh, we’ll just jump straight to the end”, and it doesn’t work that way. Any of tools that helped them gradually get there and wrap their head around things - let them use them.

[36:02] I think as a community we need to realize that sometimes doing things the wrong way, or doing things not quite the Go way is not necessarily a bad thing, if it helps you get to that point.

In my experience, that is becoming less of a problem than it used to be. And yes, I do agree with you, Jon, there was a time, especially in the beginning, where folks that are – I don’t wanna say Go purists, or something like that, but there were folks that basically adopted the language and loved the language for some very specific reasons… Because of the lack of a lot of these things, that they were used to from other languages, from other communities; it’s almost like they were getting a breath of fresh air, like “Oh, I don’t have to deal with all these frameworks and all these things.”

When new folks were coming in, they were like “Yeah, don’t bring that stuff in; don’t cargo cult it, don’t bring that stuff in. Learn Go for what Go is, learn to love it for what it is, before you try to bring these things in. Use the standard library as much as possible, and so on.” While some of those statements are still – I’m still a believer in the standard library and using it for a lot more, rather than reaching for third-party packages right away. I think there’s a time and place for everything, but absolutely - taking the stance that you shouldn’t try to leverage any of these libraries I think is foolish, because the Go community has grown quite a bit… And with that, there’s a lot more learning material out there right now, there’s a lot more blog posts, there’s a lot more videos, there’s a lot more tutorials, and this and that, and with that, a lot of different opinions that are coming in as to how you do Go. And what works for one set of folks may not work for another set of folks. Not every team follows the same idioms.

There is such a thing as idiomatic Go, but even right now I’m starting to see shifts in what that means for certain teams. Because as the years go by and people learn what’s working for them and what’s not, the adaptive practices of one team, and the things that show up out there in the form of learning material, podcasts, blog posts, or whatever it is that’s gonna reflect some of those ways of thinking.

To answer the question of “How do you get into Go?”, if you’re coming into the Go community for the first time, you’re like “Okay, I’m brand new. Maybe I’ve coded before, but I’m brand new to Go”, and you wonder where to start, I’m gonna do a shameless plug and say “Hey, try to get into a GoBridge workshop”, for example. One of the best ways to learn is to actually teach. I’m sure a lot of you have heard that before, that are gonna be listening to this, and all of us in the panel are very well aware of that - one of the best ways to learn is to actually teach.

A lot of times you will know a little bit more than the person you’re teaching, and that’s a good thing. You wanna be right at that edge there, because you’re both learning, and a lot of times when you’re about to teach something, it forces you yourself to sit down and try to understand it better, so that you can actually impart actual valuable knowledge.

Like I said, there’s so much material out there right now, that trying to understand it all before you know what’s “the right way” to teach something is gonna be a fool’s errand. So pick a topic, and say “Okay, at the next workshop, or at the next meetup (it doesn’t even have to be a GoBridge workshop) I’m gonna pair with somebody and I’m gonna help them understand this topic.” And now you have a very narrowly-defined topic that you’re gonna research, find out whatever differing views that you wanna bring in… And it basically says “Hey, this is what I’ve understood this to be. Some people do it that way, some people do it the other way…”

[40:11] So you’re able to teach that very thing, and that gets you in the mindset of actually – it makes you a better programmer, because you understand Go a little better. It makes you a better teacher, which ties back to what we were talking about before - developing empathy for how you basically bring other people along with you on your learning journey, how you augment your team… These things are gonna help build that skillset.

So these are some very practical ways you can actually level up as a beginner, as a newbie, as somebody who’s brand new to Go. These are some very practical ways you can actually level up your skill.

I guess a related question - how do you help people that are getting overwhelmed with too much stuff? Specifically, just some examples off the top of my head - I’ve had people come to me and say “I wanna learn Go”, and then they rattle off this list of all these things they think they need to be using. And this is why I’m really bullish about frameworks, and I tell people to let them learn whatever specific things they want, or using whatever tools they want… Because I’ll often hear people say “I wanna use React. I wanna write a Go API. I’m gonna deploy with Docker and Kubernetes…” They’ll rattle off all these things, and I’m just like “If you don’t know any of these things, you’re gonna have one heck of a time…” It’s like a list that I’m like “This would take me at least a year to figure out all this stuff”, and I’m like “I’ve been coding for a while. I don’t know how long it’s gonna take you.”

So how do you help people, I guess in that sense, of picking the thing to learn? Picking out a small enough piece to actually grow, but also not get too far. Johnny, you said if you go to a meetup, this is the one thing you’re gonna teach somebody, or this is the one thing you’re gonna learn… How do you pick that one thing?

Is there a word for that, by the way? I’ve often found that you try to learn one specific thing, but because the whole ecosystem around that thing requires some other knowledge, you end up having to pick up all these different things.

Yak shaving. SREs call is yak shaving.

Yeah, I definitely use that term in the SRE world, but I’m just wondering if there’s a broader term for that… Because if you wanna learn how to do just a simple web style project, not only are you learning how to do RESTful responses if you’re doing an API-driven thing, but then you have to learn some UI framework to present the information, and then you have to learn how to deploy it… That’s like so many things that are just undifferentiated heavy-lifting to your end goal.

Your end goal is just to have some text return on a web page, but all of a sudden you’re knee-deep in React, you’re knee-deep in what REST actually means, and what methods you should be using, you’re deploying these things (like you said) with Docker, and it’s just… It’s counter to your goal, because your only goal is “I just wanted some information back on my web page.”

You wanted to do a Hello, World on the web, and the next thing you know you’re running a Kubernetes cluster. [laughter]

Yeah…

I remember back in the day when you wanted to do a Hello, World, you literally put “Hello, world” in some H1 brackets and you were done. I can’t imagine coming in now, trying to do Hello, World via some proper language, and things like that.

You can on the Playground, right? And this does not require any installation of Go, or anything. You only worry about what your personal local environment is. I think that’s really helpful.

The other thing is using a code exercising site, *cough* Gopher Guides *cough*. We have a co-host here that runs Gopher Guides… But especially for junior devs, like you said, Steven, you wanna isolate the learning, and you also wanna scaffold it. You cannot move on to the next thing until you have this thing mastered. So it is like a syllabus, and that is what educators like Jon, and Bill, and everyone, have to – it’s not just what you’re learning, but it’s a sequencing problem, it’s an ordering problem. You have to make it cumulative along the way.

[43:59] So for juniors, I always say, start off with toy exercises. Even if you are coming from another language, you’ll just pick it up quicker. But this teaches you the foundations of coding, and also the grammar and syntax and semantics of Go, or any other language. And then it also shows you the quirks - strings, and runes, and things like that in Go. And from there, then you build on to “Maybe I do better with applied learning. I wanna do a little project.” One of the things I like doing is a command line app… But again, that means that you have to install Go, and you have to start – but that is helpful, because you’re learning two things. You’re learning how to use command line, and the dev workflow. You’re also learning how to wrangle that in Go, and testing, and everything.

But just a simple command line – something that has JSON… And it’s a lot, but a command line seems to be the next one… The third thing I’ve said, and I’ve said it before here, is a Slack bot. Because the feedback is very – it’s sometimes even better, because you can understand Slack as a concept and as a chatbot… But that also has another layer, which is you’re now consuming an API and having to use that API.

So it’s little things, that you think are little, and then you realize it can be very overwhelming for a dev. And that’s just coming from local host. Now, what if you wanna productionize that app? Are you gonna put it on the cloud? Then you’ve gotta learn a cloud API. So yeah… I think the first thing would be a coding exercise series, and then follow along in your terminal, or follow along in the Go Playground, and then work from there. But yeah, that’s the name of the game, is what I would call scaffolding, or sequencing the order of materials.

You’ve literally just laid out how I teach these things, incrementally… Literally. I’m like “Let’s start out on the Playground. We’re gonna do some Hello, World, we’re gonna see how the fmt package works, we’re gonna print some things out.” Then we go onto this command line. Now let’s build a command line application. You learn how to work with packages, how to do these things. Now let’s actually integrate it into something. I don’t know how to build pretty React interfaces. I rely on Slack for that, right? So now let’s build a bot. Let’s build a slash command. And then from there I’m like “Hey, you know what - we need to actually run this thing somewhere, because Slack needs to actually talk to some back-end server. Now let’s deploy that.”

So literally, that is the path I follow. I introduce things incrementally, because like you’re saying, it is overwhelming to try and understand and learn… Pick up one thing that you actually want to do, that you can actually wrap these things around, these layers of complexity around… The command line, graduating all the way up to actually deploying your own server thing is a nice path, even if you’re gonna find some yaks along the way; you can still delay shaving them, because you have a trajectory, you have somewhere that you’re trying to get to.

I think when we circle back to some of the pair-programming conversations, and things like that - that is definitely on the do column. These are the kinds of things that you wanna do to make sure that you’re not overwhelming junior engineers when you’re approaching a solution… Because all of this context that we have in our mind around how things should work and how things interact with each other - if you imagine yourself at the beginning of your career, when you didn’t have that context, try to be empathetic to that; try to understand that you can’t just use words like “just”, because then you all of a sudden make the person feel really bad, like it should be this simple thing… But no, you have all this context built up in your mind, and it is “just” to you, but to somebody else it’s the whole world.

There’s this famous meme, like “Just draw the owl”, and you start off with a circle, and then the next step is “Draw the rest of the owl.” And I hate that kind of thing whenever I’m encountering a new problem set, because I do feel “less than” when I’m reading those kinds of things. So we have to be mindful of putting ourselves in those shoes of when you first started, and remembering that these things are years built up of context.

[48:16] I was just gonna say, we have someone in our Slack channel that says “All of this is really good, but sometimes it’s hard to find the motivation to continue with such material alone.” Does anyone wanna speak to that?

Yeah, when Johnny was talking about composition and building up scaffolding, I remembered how I loved getting a sense of instant gratification when I was working on programming projects when I first started. I wanted to see something that looked as pretty as the stuff that I’m seeing online. I didn’t just wanna have an unstyled thing on my HTML page, I wanted something that looked nice…

And I think this is where JavaScript really excels - you have all these platforms like Glitch, and these other platforms where you can take maybe parts of a project and remix it in a way where you add your own flair to it, but you’re getting that sense of continuous learning and that sense of instant gratification by being able to take some of these things and going from there… Whereas if you’re doing a CLI from scratch, or you’re doing this thing from scratch, you spend a tremendous amount of time just scaffolding what the CLI should be able to respond to, and there’s no gratification there. It’s just the kind of trudge work that you have to do in order to get to the other side.

So I think we have to find projects that allow for people to come in, make modifications to and get what they want without them having to set up that full level of scaffolding. I remember - that’s why Rails took off. You could Rails-generate, and before you know it, you’re just editing some .erb files and you’re getting what you wanted from the whole thing, and not having to worry about “How does a web server run? How do I expose ports?” and all those things.

I’m gonna throw something out that perhaps might not be expected… That you can get an accountability partner. That means you commit to actually – if you’re going through a tutorial, or you’re going through some sort of an online lesson, or you’re going through a blog post and you’re trying things out, whatever the case may be… Maybe you’re going through some formal material, maybe you’re going through a book - whatever learning style suits you best - if you don’t have some sort of external accountability, somebody to check in and say “Hey, you told me you’re gonna be done with this two weeks from now. It’s now two weeks. Are you done?” If you really wanna make it challenging, put a price pack on it. Say “Hey, if I don’t do this within the month, I will give you $100.” Trust me, you will hustle. [laughs]

[51:57] I so understand that question that you picked up from Slack, Carmen… I struggle with this myself. I have so many things I’m learning at the same time, I have so many things that I’m doing… Literally, I have to have tools in my browser to close tabs down if I don’t read them after a certain time, because I have too many things open, too many things that I wanna learn.

This is something I do, maybe it’s just me - I’ll start reading an article, and I’ll notice that “Okay, I remember seeing something else…”, and I’m halfway through it, I’ll move on to something else, and I’ll start that one. And then halfway through that one I’ll jump to another one. All of a sudden, I’ve got like 12 tabs open, I haven’t finished any one of them, and I keep generating new ideas, new things to – “Oh yeah, now I need to find that documentation in the package.” I’m bouncing around like some crazy person. And I’m like “Okay, it’s been so long…”, I’ve been doing it so long, and I know exactly that I’m doing it wrong, but the human nature in me just keeps yanking me around like a puppet.

So the way that I’m trying to do this now is basically committing, having some sort of external commitment and saying “Hey, I will get this thing done. I will write this post. I will do this video. I’ll do whatever it is”, and having some sort of external accountability to keep me going.

It sounds like your brain needs a Stack Overflow error. [laughter]

But it’s so funny, because we’re sort of talking about these things, like accountability partner, maybe a study buddy, maybe a pair programming, maybe a trainer/mentor, and it sounds just like losing weight, or getting in shape if you will. I think there’s something to it there. Having to master anything follows a little bit of desire, a little bit of engineering things, so that you don’t have to power willpower, some discipline involved… So that’s kind of another thing; you have to try to really push through it, and then also maybe use Gopher Slack if you’re really stuck. There’s both the newbies channel, but sometimes it could be something that you work on and it’s a project, and you can ask…

There’s always helpful people, and it’s how I, when I really got blocked – I remember I was stuck one night; it was like 9 in New York time, and a European… I won’t say his name, but it was like 2 o’clock Europe and he just was like “I’m up. I’ll help.” And then he’s like “Well, I don’t know, I’m gonna need to see your screen. Do you wanna pair and you could show me your screen?” I was like “It’s two in the morning for you, or three in the morning…” He was like “It’s fine…” But he helped me get over that block, and that felt really good, because I don’t have a meetup community in my town, like Jon does. So these are all things that you can do and you can try as a junior dev, or someone coming new into the language.

That’s also a good point. The frustration that you get when you’re stuck on an issue, and almost all the avenues that you’re used to are not real-time help things… And I think using the newbies channel in the Go Slack is really good, but – like, Stack Overflow; you’ll post a question and then you’re refreshing the page, hoping that somebody saw it and answered it… It does get kind of demotivating, so I think that’s a very good point about finding avenues that provide some real-time feedback, potentially.

The newbies channel has always been really good for me. I hang out there sometimes and just read questions… And I’ve even learned new things in that channel, so I think that’s a very good one. I think the advent of Slack and some of those more real-time systems really help get people over that hump a little bit quicker, because waiting back for a post and just never – I don’t know if you remember back in the day, experts exchange - just never getting a response, is demotivating.

Really…

To add to that - so I have courses and I teach Go, but I’ve been very active in trying to encourage people to post all questions in Slack in a public channel. Not because I don’t wanna help, but because I know that getting instant help is really important. And a lot of times, when there’s hundreds of other people there who have all done the same stuff, they can help.

[56:01] So not only do you get instant help, but somebody who has just learned the material can reaffirm that they’ve actually learned it and try to help you, so they’re teaching and learning from that… It just ends up working all around, on all these fronts.

And it’s challenging, because sometimes you get a question where you’re just like “I can just answer this right now”, and you have to be like “Go back and ask this in a public area, where you can contribute to everybody else, and somebody else can read your question”, and sometimes that is tricky.

So going back to what we were talking about - picking up these projects and getting that instant gratification, and keeping motivated though… Is there anything we can do as a hiring manager or as a team to make that more possible?

Some ideas that came to my mind - you guys all mentioned Slack bots… I assume that if your team has Slack, you can almost take any new junior developer and be like “Alright, your first task is to make a Slack bot that just adds your own personal flair to our team channel”, just something along those lines. So it’s not anything overwhelming, but it’s something to be like “We’re all gonna see the results of this, and it’s a useful way for you to get on board, and it adds some of your flair to the team.”

Mine took it one further - we didn’t have any bots set up when I worked for a startup, and they just said “What if we wired the results of our build (pass/fail) and put it in a bot, and put it into a builds channel?” So I started building up little bots for this and that, and it was really good, because I just rinse and repeat, and you really get better, and then they would just keep – I guess this idea of critical path… So you don’t wanna be pushing or deploying something that’s going to cause an outage as a junior, and I think as a senior developer, on a team that’s trying to nurture junior developers, you wanna give them developer experience, and real-world things, and things that make them – because people wanna feel helpful; they wanna feel like they’re contributing, and they’re adding to why they’re hired… But they also don’t want the life or death pressure of like – you know, maybe your system isn’t set up for a junior to deploy and roll back easily… I’ve seen that, and they just feel awful when you put them in that.

So yeah, the idea of there’s a critical path, and junior developers should try to stay off of it for the first 6-12 months. There’s always places where you can improve… And this isn’t necessarily giving them stuff that isn’t going to help them grow. I know that sometimes it would be like toily, kind of manually stuff - no; anytime that you can try to automate things, or improve things, improve communication - that would be great.

It’s interesting, because we have internship programs at my current employer, and something that we do is the actual opposite of what you mentioned. We try to put them somewhere in the critical path, so that they feel like their contributions are valued, and that they feel empowered to do certain things. I’m not saying put them in a critical path to the point where they’re getting pressure applied to them, but making sure that – even for interns, a lot of people like to give them these side, hobby projects that never actually go to production, that never actually do anything… But we make sure that whatever they’re working on is just like what everybody else would be working on, so that they feel empowered, so that they know that their contribution actually went somewhere.

I think that feeling of being empowered is a huge thing that adds to the motivation, like we were talking about earlier. It makes people wanna continue, because they know that they’re having some sort of impact.

I think the critical difference then is to make sure that your release process is one that can be friendly to mistakes, for that.

I definitely agree with that. And if it’s not friendly to mistakes, then even for non-juniors, you have process and procedure type of issues that should be looked at. We always in the SRE world say that if somebody was able to take a system down by doing this certain set of behaviors, it shouldn’t be that person that’s been blamed; it should be like “What was it about our process that allowed for this kind of thing to take the whole thing down?”

[59:46] We’ve all probably heard the story about some junior developer deletes a database, or something, and you’re just like “If they could do that, that shouldn’t have been what they were doing.” It’s kind of like - you have to choose… You can be mission-critical, but it’s gotta be something where, like Carmen said, the deploy process works with it. It can’t be something where “Here’s an SSH key. Go ahead and just SSH into the server, and that’s the prod server. Do what you want.” That does not make sense for a junior developer.

When you said that we’ve all done, like we’ve dropped the database or something like that, I think we all chuckled nervously. Yep, we’ve each done something like that. Like Stevenson’s saying, if something like that is possible in your environment, that means you don’t have enough guard rails in place. It shouldn’t be that easy to do these things, and perhaps working with – if somebody has just joined your team, and they’re able to get to the point where they can actually take down your system and cause damage, you don’t blame them; you thank them, because they’ve uncovered a hole in your process, they’ve uncovered a hole in your onboarding. So you work with them.

Maybe the members of the team have gotten used to the existing way of doing things for so long, so they don’t see the holes anymore, because they always do it right or semi-right all the time, so they don’t see the holes. This ties back to the value of a junior developer. In the mind of a junior, in the mind of a beginner, there are many possibilities. They can approach a problem from angles you’ve long since forgotten how to do. There’s lots of ways to actually tackle a problem in the mind of somebody who’s not worn on a particular path. In the mind of the senior, there’s very few ways to do things. “Well, this is the right way. One, two, three. Boom, done. Because this is the way I’ve been doing it for ten years.

So the more juniors you have on your team - and I’m not saying put all juniors on your team, all that time; that’s not what we’re saying here. We’re advocating for a mix. But really, you want to have that diversity of opinion, that diversity of approaches, of ways of solving problems. That’s something you’re gonna get when you have a good mix of skillsets and a good mix of experience on your teams.

I think what you’re saying about a mix is important too, because you can’t – it kind of depends on where your team is, and you have to choose the right time to bring on junior developers, in the right mixture… Because if you bring on a bunch of junior developers and you don’t have the senior developers to back them up and support them, you’re gonna have a lot of people sitting around doing nothing, feeling frustrated, not really feeling useful. So you have to kind of pick it as like “Are we in crunch mode?” Is everybody working crazy 60 hours a week right now to try to get some new feature out? Well, chances are you aren’t gonna have time for a junior developer as much then. But right after that release cycle, maybe that’s a great time to bring on a junior developer and be like “Okay, we’re all taking a little bit of a break now, a breather, because we just did that crazy release.” It’s a good time to get somebody up to speed and start helping them out.

So I think just keeping that in mind, and getting that right mixture of – maybe your team of six senior engineers can support two or three junior developers; that’s what you found works. But I think that takes some experimentation to figure out where that balance lies.

Indeed.

Yeah, I think that’s definitely a sign of organizational maturity, when you know how to absorb new people, and know how to train them. It’s something that I think not enough organizations maybe place a focus on.

I know one of the things we didn’t really talk on is how do you – if you’re a manager, you’re running a team, you have to get things shipped on time… And we don’t have a lot of time left, but quickly, I guess… How do you guys - if you guys have been in the situation - balance this need to ship stuff, versus this need to occasionally set tasks aside because they’re more junior developer-appropriate?

If there’s a task that’s present and you have junior members on your team, then by all means, I think it could still be given to that junior member, even if you are in somewhat of a crunch time, and things like that. I think organizationally, you have to add a little bit of buffer maybe to your delivery dates, and things like that… But it shouldn’t be that extreme, to the point where it’s gonna impact the business.

[01:04:11.06] And if, as a team, you feel like there’s gonna be business impact because you have to set this thing aside for the junior member, then that’s I guess where you have to get a bit creative and get a better understanding for how you can still make sure that this things happens while getting that learning done. That’s where mob sessions and pairing and things like that come in handy. While the overall team velocity may be reduced a bit, that learning that comes out of it, if you bring it back to your organization as a benefit, as a whole, then I think the organization has much more appetite for that style of thing… Because sure, it was crunch time this time, and you feel like this junior might have reduced our velocity, but imagine what increase we’re getting in our velocity once this engineer has the context to help with our next crunch time, or what have you.

So we have to be making sure, as engineering managers, we’re fighting for our team, we’re advocating for these kinds of processes, and making sure that nobody’s seen as just kind of a hindrance to the organization in that way.

I definitely second using these opportunities, especially for the items that have been identified as sort of low-lift in comparison to the more advanced tickets, if you will. These low-hanging fruit tickets are perfect opportunities for pairing, because they allow – those things might be small tasks for the experienced folks, but they’ll be the right size for the juniors or people that are new to the team. So those are perfect pairing opportunities…

The thing we didn’t touch on explicitly on the pairing front is that when a junior and a senior pair together, it’s important that the senior not touch the keyboard, so to speak; it’s important to let the person who is in the learning seat drive. They’re the ones who need to move the files around, they’re the ones who need to type every single thing; they are the ones who need to reason through… You’re more of an observer, and saying “Hey, this is some context that you might not be aware of. I’ve been here a while and I know the codebase, and here’s something you might not be aware of. Oh yeah, there’s a package that does this.” But allow them to drive, allow them to learn and ask questions, and you’re just guiding, not doing for them.

Yes…

Another point to back that up is another thing to put in the Do or Don’t column in the pairing… Don’t do the Stack Overflow thing where a junior might have a very specific question about how to do something, and then you come in and tell them to use this package, or tell them to use this way, or completely trash their whole solution in favor of some optimized approach, because you learned this after years of experience. Meet them where they’re at. I say this to SREs all the time, to meet people where they are; help them from the point that they are. And if you have education to impart on them afterwards, then do so as a separate thing, and help them refactor, but don’t ever try to just completely cut them, do away with somebody’s mental model of something because you feel like you know a better way.

I can give a good example of this… It was whenever I was very junior; I think was an intern at the time, and I basically ended up writing my own CSV parsing. And we all know that’s dangerous, but it was a relatively–

As one does… [laughs]

It was a relatively basic file that I was dealing with, so I didn’t have a lot to mess with… But somebody could have easily come along and been like “What are you doing? This is an idiotic thing to do.” But the way it was presented to me was like - they helped with the specific problem I had, they encouraged me and said that I was doing a great job, and then it was like “But by the way, you might wanna check out this library that does all the CSV parsing for you, because that’s a really complicated subject.”

[01:07:52.26] Just doing it the right way can really go a long way into making people not feel like their time was wasted. You can encourage them and be like “You’re learning a lot doing this, and it’s a good thing, but you’re eventually gonna get to a point where what you’re doing might not be the best approach.”

And even that doesn’t feel like a waste of time, because think about what you learned about file.io, and opening files, and things like that… That will apply to a future project where you may not have even understood that you were learning these things while doing something like CSV parsing.

That’s right. And I think that learning is important, and patience, if you are the person helping to learn. My child - it is so much easier for me to tie her shoe in five seconds, and excruciating sometimes to have her try to fumble and tie her shoe, and it takes five minutes. And that is the very same thing that you have to let go of and be okay with with someone trying to get muscle memory, maybe working around a file editor like Vim, where you know keyboard shortcuts and all these things. You just need to be patient, because they’ll pick it up, and once they do, they’ll be just as fast as you. But if you drive for them, if you tie their shoe for them, they’re never gonna learn.

That’s right.

I kind of wonder if parents end up being better at this guidance thing simply because every parent learns that there are a million things you could do faster for your child, but you have to let them learn. Because I think Johnny and I were talking at one time about chores - there are a million chores where you’re like “I could just do this faster”, but that’s not the point. And it’s really frustrating sometimes, but you still have to do it.

I don’t think teaching should be frustrating, but there are definitely gonna be times where you’re like “I could have this fixed in five minutes”, but instead this bug is gonna sit in production for three days until this junior developer handles it… But it’s worth it.

Yup, because you’ve increased your bus factor. Sometimes when I see a 10x developer, I look at a tired modern mom, who does all the chores and all the things, when they really should be delegating and distributing. And it takes longer, but in the end, that 10x developer is not gonna get burnt out.

I think that gives us even more incentives to become teachers, because when you think traditionally of teachers, they teach, but they get no benefit out of the people that they teach in the long-term, except for a societal benefit. But when you teach at an engineering organization, there might be a direct benefit to you; it reduces your workload, it increases your bus factor, and things like that. So I think that’s more incentive to teach, and teach properly, because in the long run it’s gonna help you as an engineer.

Indeed.

So you heard it here first, folks - you become a teacher, or you become a parent, and that’ll make you a better mentor, a better teacher for your team. What do you think, Jon, Carmen, Stevenson - do you think we’ve hammered this topic and hopefully provided some value to listeners? I’ve learned a few things as well during this call; what do you all think?

Yeah, definitely.

Yeah, this was great.

I definitely learned a lot. I wish we had solutions to the “How to make job postings that were realistic”, but… Aside from making it like a “Here’s a list. If you can pick three of them you’re good”, but I don’t know if we’ll ever get people to change that. It’s just always gonna be ridiculous requirements.

But the one thing to take away though is that even if you see the ridiculous requirements, apply anyway.

Yes, definitely. If that’s the one thing people get from this episode, it’s completely worth the entire listen. Just apply.

Apply anyway.

And I guess as an engineering manager, look at your current scheme and look at their skillset, and see how realistic your job posting is compared to your team. Would your current team even be together if you had this kind of job posting?

Nope… [laughs]

Well said…! Good points!

Johnny, you mean you have not been using Go for 20 years? [laughter]

[01:11:50.04] Yeah, I don’t know anybody who’s been able to do that… Not even the authors. In any case, I think we did a good job here. I think we can pat ourselves on the back maybe.

Alright…

Are we allowed to do that?

It’s a wrap?

It’s a wrap. Yeah, I think we did it.

Woo-hoo!

Yeah, thank you for joining us, Stevenson, yet again, for another episode.

This was good.

Thank you, Carmen, for coming back and gracing us with your presence.

Maybe in the future we’ll get to do an episode on the flipside - being the junior developer and ways to basically make yourself more appealing to the companies that are hiring, and all that stuff.