Ep. #89, Developer-First Metrics with Terrence Chen of GitSense

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line we've got Terrence Chen. Hello, Terrence.

Terrence Chen: Hi Brian. Thanks for having me on.

Brian: Yeah, yeah, pleasure. And you're here on the show and I would love to know what's your background and why you're here?

Terrence: Yeah, so I guess the first thing I guess I would say I'm an entrepreneur.

So what entrepreneurs do is they reach out to everybody and try to touch everybody.

And hence, with somebody like you with a platform that can reach way more than I can, hence why I'm here.

But also I definitely don't want to turn this into a very self promotional thing because I really do want to talk about why I really want to be here, which is about developer-first metrics.

This is something that I'm hoping honestly catches on.

If I do a Google search right now, like nobody even has this three words to connect together.

Brian: Wow.

Terrence: And by talking to CHAOSS... CHAOSS, for those who don't know, is the Linux foundation's community health--

Honestly, I'm butchering everything, but the whole point of CHAOSS is to provide analytics that can help us identify how healthy an opensource project is.

And we've sort of connected through yourself, actually.

You are the conduit for both of us.

And I was able to go on their podcast to share with them what I are good metrics that we as ...

When I say we as developers, because the metric space is very much geared towards leaders. And honestly, I want to flip that around.

And the reason why I want to say that is because I think developers are somewhat shooting themselves in a foot right now by not--

I wouldn't say we should embrace it, but I think we should definitely be more open to the idea of having more measurements that can be properly safeguarded, which is what the whole idea of the developer first metrics is.

So I really don't want to right now rambling on.

So do you think I can keep talking?

Brian: Yeah. Yeah. I mean, I just want to point out real quick that Georg was actually on the podcast from the CHAOSS Community, episode 53.

So if anybody wants to hear about that, what they're working on over there, definitely check it out.

But yeah, I'm also intrigued about your interests in developer first metrics.

Also definitely should be the title of this podcast.

If there's no SEO around that, let's blow that thing up and like make it a thing that's searchable.

But tell us more about developer first metrics and what specifically you're talking about when it's developer first?

Because I know there's metrics of like how many JIRA tickets are closed and like impact and stuff like that.

Terrence: Yeah, no, it's great actually.

I didn't think about the whole SEO thing.

And honestly, I do not want to own this.

I just want to be the one to advocate for this because when it's all over, I honestly want my competitors to go, "Holy crap, we really screwed up."

We focus on short term gain and long term pain because when it's all over, it's developers that you sort of need to get buy-in to because, I hope I don't lose track, but there was a reason why I went into metrics.

But I think that'll come up later when get a bit more background.

But developer first metrics, let's focus on that.

Developer first metrics is three principles.

And maybe we can add more over time.

So if some of your listeners know, we need other principles, but the whole idea is we should have these axes in place to ensure that whatever metrics are produced, they can be something that developers will buy into.

So the very first principle is I say metrics of context.

The whole idea is there's nothing wrong with like counting how many JIRA tickets you close.

There's nothing wrong with counting how many commits you've done.

But you need to absolutely ensure that those numbers can get put into context very, very easily.

And that that's honestly the frustration with a lot of developers.

When they say that, "Hey, you're committing less."

As a developer, that's nonsensical. What does that even mean?

You need to do more commits, or you need to increase the lines of code, these are all nonsensical, but if the context behind it is this person isn't doing anything at all, then yeah, you need to do that.

So the first one is metrics with context. It has to be insanely easy.

If your tool can't support that, honestly, you're just asking for trouble because what's going to happen is the leader's going to tap the developer's shoulder and ask for an explanation.

And obviously the developer's going to be frustrated because you're distracting them for this metric.

So you have to provide numbers of context.

The second principle is it has to be useful for developers.

Like I said, knowing these JIRA tickets and all that can be a good thing if done properly.

But the whole idea is if you produce numbers and if you ask yourself, "Is this going to help a developer either with their career goals, or honestly just with their day to day task?"

Which is what I'm actually more interested in.

I'm more interested in seeing what kind of metrics we can produce to help us review code better.

What kind of metrics can we produce to help us create alerts and notifications better?

Because we're honestly shooting ourselves in the foot by not taking advantage of the fact that we have so much data around us, but we're not able to connect it.

And we're afraid to do that because I think deep down, we know people are going to take this number and massage it in a way that makes sense for them, but not in a way that I think developers can see it.

So there's a lot of pushback for that.

And the third principle is you have to make the numbers insanely easy to verify.

When it's all over, you can't have a black box because honestly it's like a lot of things I get is like, "Why don't you have a score?"

I'm like, what are you talking about? Like how can I quantify a developer with a score?

Because the thing is this is not saying that we can't in the future, honestly.

But if you do, you better be able to show exactly how you caught that number.

So those are the three principles that-- I guess the three principles of developer first metrics.

I'm not sure if that made any sense to you.

Brian: Yeah. I mean, we're breaking down the idea and like approaching this.

So when you say having a score, and I made a off the cuff joke about JIRA tickets, but are we talking about the same thing of like actually having this sort of impact and actually struggling on what they call it in JIRA?

Actually I've had a JIRA PM on the show actually quite a few episodes ago.

But can we dig into more about that and what do you mean by the score?

Terrence: Yeah, no, honestly, if JIRA has a score, then it's definitely not the score I'm referring to.

Brian: Yeah.

Terrence: Was it a good score in your memory?

Brian: So I haven't used JIRA since like my first developer job, and that was the last time I used JIRA.

So I it's a distant memory. So we could move off JIRA because I don't think I can actually give it justice.

But as far as like the metrics go, like I'm a developer, I'm going to take this bug ticket.

How do I know as an engineering manager, or even the developer's taking a ticket, like is this some of thing I should be approaching?

Is this something that you're focused on when it comes to developer first metrics?

Terrence: No. I would say I'm interested in the fact of that every line change that we make has what I call non-code related activity.

Brian: Got it. Oh, okay.

Terrence: The JIRA ticket is not so much this person created JIRA ticket.

The JIRA ticket is more of, "Okay, so to produce those line of code, this person had to participate in this JIRA ticket."

Because writing comments, as we know, can be extremely time consuming, because when it's all over, a single line change, I think this is what frustrates developers so much is we're so focused on just the raw numbers themselves that there's what I call the hidden data behind it, which is the meetings, and also the JIRA ticket itself.

And just replying to a comment in a code review, all these things I honestly believe, should be something that when we look at a line of code, we should be able to trace it back to all those things because it's not--

And I don't want to use this to quantify developers' productivity because productivity is a lot of variables that I don't think anybody should even try to quantify, honestly, because it's too hard, or at least if done incorrectly can be abused.

But we should know that, "Hey, if I'm reviewing this code and if I'm having a bit of a hard time understanding why this code came about, I should be able to go into the meeting notes. I should able to easily go into those JIRA notes. I should be able to easily go into these review comments previously."

And like Sourcegraph. I think you're probably familiar with Sourcegraph?

Brian: Yeah.

Terrence: It's a big Bay Area company.

And they've recently, I think, raised $70 million in the last two years.

So they've found some market fit. And their whole idea is to connect all the source code.

And from my perspective, I honestly want to connect all the effort.

I want us to know exactly because developers are honestly horrible at advertising themselves.

Like imagine a situation now that you're having a one-on-one conversation.

A developer goes, "I think I deserve a raise now."

I think you laugh more because I know the feeling.

Brian: Yeah, yeah, yeah. I've been in that conversation before. Yeah.

Terrence: But that's the whole point, which is developers, they don't come prepared.

They don't come with this book binder of, "Okay, this is what I did."

They sort of just assume that the manager knows.

And a good manager honestly would know, but that also is a problem itself also is when it comes to raises, it's not necessarily the manager that gives it out.

The manager is given an allocation of so much money they can play with, for how many promotions they can apply in their team.

It's still a manager's job to sell the employee, I guess, to the greater organization.

So imagine now this manager has this information with them, such that if this person does not get a raise, and if this person leaves, this is the void that's created.

And we can't do that without numbers.

So this is why I think developers need to somewhat twist it around and say, "Hey, how can we get metrics to work for us?"

That's just the one aspect.

There's most of developers don't want to even focus on that. I think they'd rather use--

How can we use metrics now to use my day-to-day jobs? But that's something which I honestly want to do.

So JIRA comes in, but JIRA is more of just, here's a data point.

And if somebody tries to assign a score for how well they close a ticket, then I don't want to be part of that is my whole.

Brian: Yeah. Yeah. Can we dig in more of that?

Let's talk about bad metrics and what you're seeing today and like maybe the misdirection that's happening when people--

Because like one thing that I see a lot of bad metric is like how many lines committed or how many lines change to show impact on what they did on the project?

A lot of times when I see a lot of open source projects, folks will see like, "Oh wow, there's so many commits on this project on GitHub or GitLab, it must mean that this project is doing such a great job."

And in reality, they could be doing like switching the type script or switching from two to four spaces.

Terrence: Yeah. And that goes back to my third principle, easily verifiable.

A lot of comments I get is more people just game the system. Yeah.

And honestly, that happens because you provide numbers without context.

You provide numbers that are not easily verifiable.

So yeah, if you provide a system in place that doesn't provide those two checks, yeah, people who are, I would say creative with their work will definitely be more, I guess, inflating numbers.

But if you honestly make a system that's completely transparent, are you going to do that? Because what's going to happen is your coworkers can call you out.

And your coworker's going to use those numbers you produce for the one-on-one meetings.

Because when it's all over, I don't want to say that we're competing against one other, but when it comes to raise pools and other stuff and recognition within the company, in a lot of ways, we are trying to set ourself apart.

And if somebody's going to do it in a way that is harmful for others, you now have the metrics to easily highlight that.

Going back to the numbers. I honestly don't think those are bad numbers to think about.

I just think that they're bad because they provide no context because I going back to your perfect example, which is yeah, what if they just made comment changes? But that's the whole point.

And what I keep talking to people about is business intelligence is very much accepted in the business world.

And nobody takes for granted how complex business intelligence is.

But when it comes to software metrics, nobody even thinks to like even say like, should we bring in a specialist to look at these numbers?

No, because somebody says, "Hey, we just look at number of commits. We look at the number of lines of code. That should tell us enough."

But the reality is it's probably even more relevant today than ever.

I would say that we need, maybe this is another SEO thing that pop up, but we need a developer productivity specialist, somebody who knows how to read code, somebody that can look at numbers, because maybe I don't want to a unnecessary segue into why I started doing this, but I ended up working for a FinTech.

And this FinTech was a result of Amazon, Google scaring the crap out of them.

I think everybody's learned a lesson now.

I think Sears, Blockbuster was the two big boys that they realized that, "Man, if we don't embrace technology, or if we don't embrace future trends, we're going to be in big trouble."

So this FinTech, which has close to $1 trillion in assets, they can't hire people.

They can afford people, but they can't hire people. So they're desperate looking for ways to equalize.

And they're, as you probably imagine is, they're saying that, "Okay, maybe we can't make developers better, but at least let's try to find a 'dead weight.'"

So now they're using these numbers to help them drive their own internal process.

And that's the reason why, when I looked at it it's like, this makes no sense. But people do it because it's easy.

GitSense is a pivot of my first startup, which was a search engine.

I don't want to go in too much about that, but selling search is hard. Let's put it that way.

So what I realized was I'm actually capturing every single line change, and I'm not willing to proclaim this.

But I honestly think if we can actually capture everything that's happening around us, we can actually start applying patterns through machine learning, whatever, to help us.

Because what we have today that we never really had in the past is so many people and so many organizations developing in the open.

Like you can analyze a very popular open source project, and you know it's a company that they're treating it like a business.

So the patterns that are happening within it is business related.

These open source development that is more of like I'm working.

My spare time can really throw off the numbers versus like selling DS code.

DS code is not something just sitting around. DS code is Microsoft spending a boatload of money.

And they're treating it like a business. And GitLab is another example.

Like, so you have a lot of-- And also like Elastic Search, et cetera.

These companies, they're producing products that normally in the past would've been done behind closed doors, but now you can sort of analyze and see what kind of patterns we have within it that can then be applied.

And this is where I think I don't want to jump to the conclusion that we can produce productivity metrics, because I honestly don't think we can honestly.

But I think that we need to at least ask a question. What if we start tracking everything?

Are there patterns? Are there ways that we can actually do this in a way that benefits developers?

And that goes back to tools.

Like if I know exactly what's happening right now around me, can I review code more efficiently?

If somebody raises like a code review, can I quickly ask questions? Did they even do the due diligence?

These little things, imagine you look at a code and there's no way for you to trace any meetings, even though you know there's a JIRA ticket that should be, or all this stuff in place.

So I was like, we need to, I won't say embrace, but we need to start asking a question that I think a lot of developers are afraid to ask is can offer metrics be useful?

And I think so if we stick to the three principles, which is the developer first metrics

Brian: Yeah. And something you alluded to as well, that you were talking about SEO, of having a sort of consultant or sort of expert.

I was thinking of like how Gordon Ramsey goes into different kitchens, or even like Kitchen Nightmares, the other guy with the muscles goes in the kitchens and gets people back up to speed, back up to par, and is able to sort of figure out where the sort of dead spots are, or what the sort of missteps are in the kitchen.

I think, honestly, if there was someone who was approaching these developer first metrics and was like sort of expertise, I don't think they need to be like a scrum master or whatever, but that would actually be really a job, I guess.

Honestly, I don't even know in your experience, I don't know if folks actually are using this as a job or a job title itself, but I know a couple startups that could probably use some help in getting back to developer velocity for sure.

Terrence: But it's not just the startups. It's these trillion-dollar companies.

Brian: True. Yeah.

Terrence: Because if you think about it, developers are not cheap.

And doesn't help that Google, Facebook are so flush of cash now that they're really skewing everything.

So everybody sort of needs to play catch up to them to be able to compete.

So imagine a company spending tens of thousands of dollars a year in consulting is peanuts.

And not being able to find these, I would say, areas that can be improved.

But the thing is we can't improve if we don't have numbers.

And the numbers have to be something that we all agree can drive actionable insights.

So in a way, maybe it's bad for me to acknowledge this, I guess, but some of my competitors actually do provide some okay metrics I would say, and some are pretty good in that sense, but the problem is they don't provide this with context and they don't make it easily verifiable.

So when it's all over, a developer sees that tool as nothing more than you're measuring me.

So I think if somebody just takes the effort to just properly capture the data, and honestly, I do believe because that you say that it may not necessarily be--

It might be like a part-time role, but I honestly don't understand why we don't honestly have job listings right now that's saying that developers specialists.

Literally, and in your way, that you're an advocate for developers, we should also have that person that could be an advocate for developers internally, that companies will bring on board.

They know how to read code, which is the most important thing, because the complexity is in the details.

Like once single line change could have been the fact that they needed to do all these other integration tests.

And this is what and expert would know.

But as somebody just looking at the pure one line change, they're not going to know all these connecting factors.

So this person, I honestly think should become a critical role.

And I wouldn't say a person, I would say, you probably need multiple people and a whole new cottage industry.

And that's just my personal thought on this.

Brian: Yeah. Yeah. And I'm right there with you.

And I wanted to kind of veer into some more controversial things too, as well.

And folks know who listen to the podcasts and know I work at GitHub.

And folks can really focus on green squares and green squares being on your profile.

You make a commit and you can see like what code across the entire platform you're using.

I wanted to touch on that and what's your thoughts on contributor graphs?

How could we develop stories, or actually verifiable metrics out of the contributor graph?

Terrence: What do you mean by verifiable? Do you mean like more contextual information?

Brian: Yeah, more contextual information because when I look at my contributor graph in 2018, I've got a summer where I just didn't write any code.

And there it looks like, "Oh."

You know how like you take some time off, or maybe you go travel Europe, and people ask, "Why are there big gaps in your employment history?"

And you're like, "Oh well it's because I took time off and I wanted to find myself."

And in my contributor graph, I've got the same thing.

So I've got six weeks off where I had a kid. And I was like, "I took all that time off from work because that's what they gave me at work."

And there's no code in that segment.

And I can go back there and say, "Yes, I had a whole blip of not writing code. It doesn't mean that I'm out of practice. It means that I just did not want to gets sucked into something while trying to also be present."

Terrence: Yeah, honestly, this is also, I guess, an internal thing that you guys probably discuss as well.

But my thought on this honestly is why should we care honestly? Yeah.

That's my own personal thought. Because as you pointed out is like there's so much detail that can lead up to it.

And the worst case scenario is imagine if somebody has an accident, or whatever reason that prevents them from doing this.

It's better for us to just say, "Okay, they weren't active for this period." And that's it.

That should drive your next question is, okay, it's one thing if you were supposed to be active.

So let's say that six week gap you were supposed to work and you don't have any green squares.

Then yes. I think that's an issue. But GitHub knew, right?

You were on maternity leave, so it's sort of like I know it's weird because you do have developers that they freak out if they don't have a day that is not green.

Because I think it used to be that you need-- It was automatically shown by default, but now it's an opt in.

You need to say that. I want to show my thing.

Brian: Yeah. There's a feature where you could actually remove it from your profile if you would like.

You can also opt in private contributions.

So if you do want to show that you're actually doing something, even though you're not doing anything in the open, that's another option.

And it's a contentious feature on the platform that people love, but then also other people despise.

And I think it's just something that GitHub just sort of built themself into that corner.

But then on the other end, like I know GitLab and GitHub and Bitbucket, they have tools where you can have like an insights tab and it can show metrics and insights.

So with that, maybe I'm too close to the source, but does that provide enough context in what's happening across the team?

Terrence: No. And like, obviously your listeners have to go, "This guy's trying to sell me something."

I just say that because it's what I call pointing out the obvious without understanding of what it is.

And it's a good starting point when it's all over.

But when I go to GitHub insights, I should, as you pointed out, if I see a bunch of squiggly lines, obviously I want to click on it.

And then the squiggly line should take me to the code itself. But it doesn't.

So I guess people sort of say, "I want to shoot for the biggest squiggly line."

And then so if you actually made it very easy for people to click on the squiggly line and it goes to nothing, or it goes through some--

Like there's actually a project that it will create like fake commits for you.

And so imagine being able to click on that squiggly line, it goes to a generator that shows that this person just ran a script.

Like you're not going to do that in the future. And so that's what I sort of meant by transparency.

And this is ultimately what I think is covered by the third principle, easily verifiable.

I know we're probably getting too philosophical about the psychological effect of--

And I do think it's actually a problem though. Like I honestly think that we shouldn't glorify metrics.

Metrics should be what it is, but just to help us drive decision making.

And it might lead to a negative aspect for somebody else because it highlights that they are truly not contributing.

Because I'm definitely not going to games, but I've worked with people that you clearly knew that they knew how to play the game.

They knew how to talk.

But you also knew developers that didn't want to participate in this because they naively assume that their efforts would be properly reflected.

But what happens is the person who can probably best speak to the leader gets a raise and this person's leaves.

And this person goes for another job.

So I honestly think, it's not for metrics, if done properly, can help drive developer sentiment, which I think is something that, that honestly should be what we should be thinking about is how can we use metrics in a positive way.

And honestly, I don't know how to, and I'm not afraid to say that as opposed to some of my competition, which is here's the numbers.

That's the reason why they're able to raise all the money they're able to right now and generate sales because everybody just wants that quick fix.

But the reality is we just need to focus on getting a culture that feels that if you're capturing everything that I'm doing, it's not going to be abused because we have this safeguard in place.

And how realistic that is, I might be speaking very naively in the sense that they'll just use this tool as like a nuclear bomb situation, which is somebody here did all the grunt work to capture all this data.

And now I'm going to just roll up and then use this in some way.

But I don't know, like, honestly, like I'm curious to hear your thoughts because it sort of seems like you are not a huge fan of this type of metrics.

And I think you're right in this aspect.

Brian: Yeah, yeah.

I mean, I've gone through a lot of business space, and you mentioned something also that's been very close to home and my experience as an engineer.

You have the one person who does all the work, and drives all the peer reviews, and also kind of comes in with like the decisions to get everybody unstuck.

And then they go. They do end up leaving to go do bigger and better things and take a bigger role.

And like, looking back as a people manager, being able to see that and say, "Oh, well, maybe we should actually make them a lead.

Maybe we should actually make them encourage other folks to come along for the ride."

But also, I've also been on teams where folks do know how to sort of tell you-- The feature will be done when it's done.

And I think that's a very, very popular response, and you should definitely use that response if you're going to be an engineer if you can get away with it.

But, also people do take their time to get their stuff.

But I don't want to hyper-focus on that because also I understand like some people do get stuck.

Some people do need help. So like being able to identify when folks need help or get unstuck, or perhaps there's like a edge case or something that they just cannot get their themselves through.

That's when to sort of pull the lever, pull in more people to help in this situation.

Well, perhaps maybe your front end, your UI's doing fine.

You don't have to have as many people shipping front end stuff.

So for me, I'm not indifferent when it comes to metrics, but I don't work on a lot of longstanding projects too.

That's the other problem that I come from this, but I just find it very interesting thing to focus on.

I find that if I had the sixth sense, or if I had someone who I can pull and leverage and be like, "Hey, how do I encourage people working on my open source project to get excited about this and then drive them to adopting my mindset and how to ship code?"

And then I've got a bunch of other "Dougies" also contributing to the project and excited to contribute to project.

And I can actually see where stuff kind of drops off. It's all stuff I don't look at very often.

But when I do look at, it does make a difference to be quite honest.

And I did that earlier this year with my open source project. I saw where contributions were dropping off.

I saw where folks who were avoiding portions of the code base. Because it was just flat out confusing.

And when I saw that anybody who touched that part of it, or who didn't touch it, it made it easy for me to then go, "Oh, I should probably write docs on this."

And then that way, if anybody ever touches persistent GraphQl queries, they're no longer on that term.

And they have actually have an idea of what that means.

Terrence: Yeah. Like the whole point you touched about is like identifying stuck.

And I think that's part of the-- I'm not sure.

I don't think it's necessarily a developer mindset.

I think it's just a human mindset, which is, we don't want to admit when we're weak, I guess.

And the whole point is just, yeah, the metrics are in there.

And yeah, if you're a team lead, which is your job is to be a leader.

And if there's enough patterns in place that can help you identify that this person is stuck, then yeah, it's your job to unstuck the situation because it might well be your problem for, I guess, scoping it out too big or whatever.

Or it might just be that hey, yeah, you can improve in this one area.

And that's the whole point. It should be used in a positive manner.

But I think where the frustration comes in is it's the false positives, I think, is what causes a lot of the issues, which is, "I'm not stuck. I'm just thinking."

That sort of thing. It's sort of like so at what point is we're just pestering.

But I think that's the whole point of transparency again.

If you make it insanely easy for this leader to clearly see what's going on and how it's working, they should have the intuition to go, "Yeah. This person is just ... They're doing their spiel, which is, they normally just ... They're thinking through a problem."

But if there is a pattern, which was the whole point.

We don't know what patterns to look for. And we're so afraid to capture the data to help us identify this.

So I think that's the whole point is imagine every company in the world contribute anonymously, our behaviors.

Could we in the future identify what are the most likely stuck patterns?

But these are things we can't honestly answer until we actually start thinking about metrics, which unfortunately goes down another path, which is what do you mean metrics.

So it's definitely an uphill battle. Let's say that for sure.

Brian: Yeah. And as we're winding down this conversation, I do want to give some space for if you can recommend anybody who's doing it right.

I know we've avoided like even mentioning your startup, but I think that we should leave some space to talk about how you're approaching the problem.

Like we talked about developer first metrics, but are there any blog posts or examples that folks can gleam on to sort of walk away with from this conversation?

Terrence: Well, I guess the first thing is that yeah, company's called GitSense.

So it's playing two words, Git and sense.

And unfortunately, I'm a the sole founder, so that's sort of limits my ability.

And I'll be honest right now, I'm sort of on the let's raise money mindset.

So that hasn't left a lot of opportunity for me to do a blog post.

But honestly, having your platform and being able to even just talk about developer first metrics, I definitely don't want people to say, "Okay, that's a GitSense thing."

Because no, it should be an industry thing.

And if somebody else can add another fourth principal or fifth principal or six principal, hey, like I'm all for it.

And now that you started talking about it, maybe this should be something that's hosted on GitHub, a repository that sort of talks about these are what developer first metrics are, but also I don't want to belittle what CHAOSS has done.

So maybe I'm sort of overlapping what they've done too.

So let me think more about it because maybe we should also give a shout.

Brian: Yeah. I mean, the way JAMstack got started is that we created a JAMstack.org site that had a couple paragraphs on the thought process.

If you want to throw that together, I'd love to share with the people who followed me on Twitter and everything like that.

Because I think this is actually, it turned out to be a very, very intriguing and eye-opening conversation on all different fronts for myself.

And I'm really actually really interested in learning more about what you're going to be shipping and what working in.

So definitely best of luck with the raising. And I think we might want to go ahead and transition the picks and these are JAM picks.

I don't know if I properly prepared you for this.

Terrence: I did my research.

Brian: Okay, excellent. So yeah, music, food, technology related, and if you did your research, you want to go ahead and go first?

Terrence: Yeah. Honestly this might sound like the stupidest thing in the world, but I always, if I get a platform, I want to talk about One Punch Man.

It's anime. And the reason why I want people to know about it is because like outside of the techie type people, or people maybe who do not think straight, it's such a silly concept about the superhero.

I want to be superhero, but he's the most powerful being in this universe.

Or actually first of all, are you familiar with One Punch Man?

Brian: Yes. I'm familiar. Yes. The memes. And I've seen a couple episodes.

Terrence: A couple? Okay, all right. I think you have homework to do, bud.

Brian: Yes, I know. There's a lot that I'm behind on, but yes.

Terrence: Yeah.

But the reason why I bring it up is because watching a show makes you forget about a lot of stuff because it's so absurd.

And that's the reason I want to bring it up because I think we get stressed out too much, or we get focused on something that maybe we shouldn't.

And watching a guy who's biggest problem is he's just, he's too strong.

The whole premise is that it just takes one punch for him to pretty much kill every monster in the world.

And it's frustrating for him. And he can't figure out what to do now. His life is sort meaningless because he's too strong.

And that sort of, when you start to think about that, you stop thinking about your other problems. That's the reason why I sort brought it up.

Brian: Yeah. It's amazing.

Because a lot of times-- So like you're just getting started in your company that you're now raising for.

But it's something I've actually thought about in some of the companies I've worked at, like even like with Netlify.

Netlify is a company I used to work at.

And they kind of really started owning the space where they were the competitor to GitHub pages.

They overachieved that in leaps and bounds.

And you eventually got to figure out what your next thing is.

And I think GitHub has a very similar.

Microsoft is also in a very similar place of like, they are doing a lot of really cool things, but they have to continue to do cool things to not only stay relevant, but also not lose focus and also be disinterested.

And it's funny, you bring that up too as well, because perhaps you are a developer and you feel like you've outgrown your team and everything you touch as far as future goes, you're, you're merging in left and right.

And you're the sort of the cowboy code that comes in to save the day.

It might be a really good thing for you to actually-- So like maybe we've been looking at more of it as like a team lead or engineering manager in the conversation.

But as an individual, I think this would be awesome information and maybe an awesome show to get insight on.

So honestly, you might have just ignited something in me that I might be binging this on the next time I sit on a plane.

Terrence: So is this your pick, I guess?

Brian: It could be my pick next week for sure.

Because I might actually crank through a season.

But yeah, I've actually been giving my son-- Actually, I'm going to just jump into my picks.

I've been actually watching a lot more cartoons with my kids.

Terrence: Anime's not cartoon.

Brian: Yeah. Yeah. Apologies. It is not a cartoon. It's actually, it's real life depicted on screen.

Terrence: Hand drawn.

Brian: Yes. But my kid, my oldest, his intro was Pokemon into anything in that realm.

And we've sort of, we've gone into the other different other shows, mainly more kid related.

Like we're definitely a Studio Ghibli family.

Like we've we watched almost all of them.

The ones that are a little kind of dark we've kind of avoided to wait until he's slightly older.

But yeah, big fan of Studio Ghibli on-- HBO actually has I think about all of the movies on Studio Ghibli.

So definitely check that out. But the show that we've been watching is called Bluey.

And Bluey, it's a kid's cartoon. It's based in Brisbane.

And it was like something that I think my kids assumed it was too young for them, or something that it's like we watched one episode and there were just not interested.

And then out of the blue, I guess the no pun intended, we ended up sitting down and watching a couple of them.

And we just got hooked. And like their seasons for whatever reason is like 70 episodes a piece.

So we watched all the first season, and then the second season came up on Disney plus.

So we watched all the second season. And we just continued to cycle through them.

And it's a fun story about two small kids who are dogs rather.

So it's a dog family. And the dad is a-- He doesn't stay at home, but he's home more than the mom.

And so what's cool about it is like the dad is the caregiver.

And when my daughter watches it, like she always wants to wrestle with me and jump on me because that's what they do on the show.

And I feel like since I've been home, we've built a better bond because I haven't been traveling.

And I just love the show. It gives me the fun feels.

So if you haven't watched Bluey, definitely check it out. It's a cool kid show.

Terrence: Have you seen Care Bear.

Brian: Care Bear?

Terrence: It's an old show, but I vaguely remember, but it was probably the most wholesome thing you can think of.

It was always this whole life spiritual lesson at the end.

And it might be too deep for kids nowadays, but I don't know.

Brian: Yeah, they don't make them like they used to I guess I would say.

Yeah, because yeah, all the shows that seem like they're quite different these days and they have, I guess, a different approach to teaching.

Terrence: Yeah. I guess the question is, were we learning the wrong way?

That's a more philosophical question. Because every generation tends to be more accepting.

So maybe we were brainwashed by Care Bear. Who knows?

Brian: Perhaps, yeah. I mean I am way more in touch with my feelings.

I did watch Care Bear. But yeah, way more in touch with my feelings thanks to whatever, the loving bear or whatnot.

But we could wax poetic on all childhood creations and cartoons, and as well as anime and I'll leave it at that.

Terrence, thanks so much for talking about developer first metrics.

Hopefully everybody who's listened got a lot out of this and hopefully we can all create a culture of really focusing on the right story and not on the wrong story when we start shipping code.

And listeners, keep spreading the jam.