Mason McLead from software.com shows us the editor-integrated suite of tools that help you become a better developer. We find out what music makes you code better (and worse), how data reveals the habits of the world's top coders and why Saturday is code day.

Hey, everybody. And welcome back to another episode of the Ruby Rogues podcast. This week on our panel, we have Dave Camura. Hey, everyone. We also have Luke Stutters.

Hello. Charles Max Wood from dev chat dot TV. And this week, we have a special guest, and that is Mason Mcleed. Hey, everyone. And thanks for having me on.

Yeah. Now we've had you on a couple of other shows. We've been talking about basically getting more done. I'm kinda curious as we dive in. 1st, do you wanna just give a little bit more of an introduction?

I I kind of, glossed over all the cool stuff you're doing at software.com and all the tools that you provide to people and things like that, as well as the research that you're doing on productivity. But, yeah, you wanna just give us the quick elevator pitch, and then we can dive in? Sure. Yeah. So I'm Mason.

I'm the CTO at software.com. We make tools for developers, and it's all around time tracking and efficiency and productivity. So the core thing that we do is track telemetry about how you code and give you that feedback and that observability about how the development process is working for your team and for you as an individual. And we also got editor extensions across all the main editors that give you access to that data right in line. And also, we have a tool called flow mode which connects to Slack and your calendar and starts to block out times whenever you're coding so that you don't get distracted and because I think everyone's had that feeling where you finally get into the zone like you've got everything in your head and then you get a bunch of Slack messages or meetings coming up and then you lose it all.

And that's really valuable time that's that's been lost. So we've got tools to help you do that. And a lot of the research that we're doing is looking at the impact analysis of meeting time versus how people can get, stuff done during the day and which is also a leading cause of why developers work at night a lot of the times or on weekends. And and then the impact of other distractions like Slack and meeting or sorry, working at the office versus working remote when that is an option depending on what country you're in. And, yeah, all sorts of other stuff going into that.

So a lot of really interesting data that we can see and all of assumptions that people have that can be proven correct through the data or actually debunked, which is I think a really interesting part of it as well. Right. And like I said, you know, we had you on adventures in DevOps. We had you on I can't remember which of the other shows we talked to you on, but most of those conversations kinda went the same kinds of ways. I'm a little curious as we dive into this with Ruby Roads.

Are there are there things that we didn't get to in the other shows that we we could talk about here, and then maybe we can circle back around to kind of the big ideas that we got to on the other shows that are gonna help folks? Well, there was something that I actually found out yesterday with my data scientist and Breaking news. I know breaking top line research here. So I was looking at what we've got certain measures that we see in the data and we'll be able to mark sessions of your coding. We have a thing called code time which is when you're in the editor, you're looking at files, you're doing research, not necessarily editing the code.

And then we have a section of time called active code time, which is when you're actively editing. And so one of the things you can do when you've got those is look at the ratio that people spend in the day of how much of their code time is also active code time, which is is kind of a proxy for focus and the time that it takes for them to ramp up to productivity in that session. So how long does it of reading does it take to get you into editing? And I was looking at that per day of week and found that for that particular ratio, Saturday is the most focused day that developers have. So of developers that that code on the weekend, Saturday has a far higher kind of focus factor than any day of the week, although Tuesday is a close runner-up.

So from that, I think we're we'll we'll be able to dive further into it, like, okay, why is that the way it is? But just on the observation and kind of the assumptions that you have about Saturdays Tuesdays, there's less people bothering you. There's less meetings. There's less messages. And so if you want to work on Saturday and that works for your lifestyle, great.

It seems to be a good one. If you don't and that's just a byproduct of you not having gotten stuff done during the week because you're distracted all the time. It's like, how do you make a Saturday like environment during the week so that you can have that same amount of focus to be as productive on those days. And, like, those are some of the the small behavioral shifts that you can start to put into your work week as a team and as an individual, so that you can get more focused work done during the week and then actually take time off because you're a person as well. And do you need to do other things?

I got a I got a question for you here. So as I as I understand, you get the software.com, you've got loads of really cool tools that can kind of look at people's commits or some other metric you're looking at to assess productivity? Yes. So we've got several metrics that go into it. And in the coming weeks, we'll have it all connected to git commits and those sorts of things.

We're doing that internally right now. Just kind of refining the product before we put it out there where we can look at like, if you if you kind of arrange how development works in in line of kind of a physical factory, it's not the same because you're not recreating the same thing over and over again instead of creating endeavor. But right? If you kind of look at it that way as a metaphor and say there's all these inputs that go into it And that for us is the time, the amount of characters and lines and, like, just the raw materials that go into it. And then you look at the outputs.

And I think so far the best sort of abstraction for what an output a unit of output is is a merged pull request. It's a chunk of work that someone has thought is enough to stand on its own, and it's good enough gone through quality checks to get merged into the default branch, which would then go to production. So those are the inputs and the outputs of this factory. And that those if you look at the traditional definition of efficiency and productivity, it's how much input does it take to get to some unit of output. So as soon as you have that, now you've got the full view of the development cycle, what is going in, what is coming out, and you can start to get a lot of really interesting measurements about the overall system and then each of the steps along the way.

So when you hear about things like cycle time, which is typically when someone's looking at at that from another tool, they're looking at when the commit was pushed to when it was merged. And I don't know how how you like to commit, people do it differently, but I usually code nearly all of everything before I do the first commit, and then I commit, make a PR, push it, and then I'll get feedback and maybe make some changes. But the bulk of the work of the input side is before that first commit, which is completely missed by these other tools. And it also gives you a, like, depending on how your behavior is, it gives you a a false number about what your cycle speed is when really there's this You would've done all the work in that one commit to stop. Yeah.

Exactly. So getting a realistic number and just observing what the team is actually doing gives you an empowerment to go and actually make positive changes to it. And that's really at the core of it, this is what this is about. I went on code climate update. It wasn't my idea.

My colleagues did, and it gave my code a d. And quite honestly, that kind of put me off all of these kind of code assessment tools. I'm now a bit scared that if you've got a software.com and showed them my work, they'll say that, you know, Luke's only productive on Tuesday morning. And even then he doesn't do much work. Is this it sounds like a great tool for managers.

Is it gonna help the the software grunts, the frontline coders like me? Yeah. I think that is a really interesting point. That's something that we think about a lot and you're right about, you know, co climate or any of these other tools. They do have a very manager first approach to it all, which is something that we actively avoid.

So first of all, with our with our tools and I I think everyone should do this, is that we don't show individual data to anyone except that individual. If the team is looking at the data, they see aggregated anonymized data at the team level. So the team is an object or an entity that is creating code together. And looking at it at individual parts is not as helpful for the metrics that you would actually wanna track, and that's really a manager task to do. And I don't think automating that out to a bunch of stats is a healthy or productive thing to do.

I I make stats, like, that's what we do. I don't think it's right for that. It could be a supplement, but it doesn't replace being a manager. And, yeah, so for us, we don't we only show the individual data to the individual so that they can see it for themselves. And then the thing that I'm really proud of is that we have the what we call editor ops tools.

So we've got extensions that are running in your editor. So just like chat ops brought a lot of automations and and cool stuff into Slack or whatever, we bring that into the editor so that you can start to control your environment from there without context switching. Like, we have an extension called music time that allows you to control your Spotify from the editor with, like, keyboard shortcuts or some clicks. And it also shows you in a correlative sort of way what are the most productive songs that you listen to or genres. And, like, mine is put a code with Alice Cooper on?

So you can check, software.com/top40. We have the top 40 songs ranked by productivity for the week. And That's crazy. Sometimes, like, Allison I love it. Will be on there.

It depends on on what data we get for that week. It it's always updating every week. And but you can see it for yourself. Like, mine is my best genre is Hang on a second. Ed Sheeran.

Ed Sheeran's in the top 3. Good god. You know, what I what I think it is, and I don't have the data yet to prove it, I think it's there's songs that are really familiar and you've heard a 1000000000 times, so you don't have to actively think about what's going on. It's just in the background, and it's the the smooth tones of Ed Sheeran. Then it allows you to kind of mute out everything else, and that takes the place of background noise.

And then you can have your mind available to focus. And I think whenever you see that, like, it's not always new songs, although peep popular songs tend to rise up because they people listen to them. But a lot of older songs as well that people have listened to many, many times, And it's just their go to thing in order to get into the zone. What is your song to get go on. Go on, Dave.

I do have to push back a little bit because the number 24 slot is the real Slim Shady. I don't know how well my coding would go if I'm listening to that. I'm not saying Eminem's spat or anything, but that song in particular, I'm just I'm sorry. I I don't have the full buy in yet. He just had me at Emax Spotify.

Just saying. Mhmm. Control x, control play. But yeah. Whatever.

Mhmm. I do have to say, though, that I mean, it's it's interesting. Right? These are all things that you measure or don't measure. I also just wanna back up to the kind of the team stats.

Right? Because there there are a couple of things. One is is that my team where we pair or mob everything. And so measuring that kind of productivity, I may not be the person who's actually even in the editor. Right?

I may be participating over the call or pushing you know, I may put the PR together, but none of the commits are actually commits that came off of my machine. Sounds like an excuse. Like that. What did you do, Sean? Maybe.

It could be. But my point is is that by measuring the velocity of the team or measuring the output of the team, measuring the team as a whole, If I'm out for a week, they can see what the impact is. Right? Mhmm. Or somebody else is out for the week, they can see what the impact is.

Even if they're not seeing specifically, oh, there are fewer commits by Chuck or fewer commits by one of the other guys. Right? Yeah. And even just looking at the metrics at the team level aligns with the purpose and virtues of pair or mob programming where you're doing this as a team. It's not a bunch of individuals writing a bunch of different code.

It's it's everyone coming together to do this. And measuring the velocity and the lead time and the throughput at that level seems to me to be the the right level to do it at. Well, I've been on teams where we didn't pair. Right? We didn't pair.

We didn't mob. We just do the work, but we were still collaborating, collaborating, collaborated, dating, whatever. We were still talking to each other about what we were working on. We were still, hey. I'm stuck on this.

Can you help me out? Hey. How does this go together so that I can integrate with it? Hey, how how does this gonna get integrated on CI? How is this gonna get come together when we deploy it?

Hey, you know, how does this work? Hey, do you know a good algorithm to solve this particular problem? And so there's always going to be interplay between the members of the team, whether you have them sitting together or on a Zoom or Teams or Skype call. And so the reality is is if you're not measuring it as a team, you're not measuring all of that other stuff, and you're going to miss really a big part of how this all kinda comes together. Because at the end of the day, everything that I'm working on and everything that you're working on and everything that everybody else is working on on this particular app or set of apps, it it all goes into the same bucket, and we're all measuring that progress in on the same rubric.

Yeah. Exactly. And if you took that case where you and and your your other half of the pair have been programming for 2 weeks on a particular sprint, and the other person's always been the typist in that case, then if you're looking at the way that other tools traditionally do this where it's per person, you're gonna see one person did everything and the other person did nothing based on who committed what. And that wasn't the case at all. Like, this is definitely a team effort.

And so if you just abstract it away to the proper level, then you don't fall into that trap of having this false stack rank of individuals assuming that they're all doing their own individual stuff which is never the case when you're on a team that's working well together. And the communication side of it is a it's kind of an invisible and I think undervalued in a lot of times aspect of team building that that really you'll you'll see the effects of it when it's going well at the team level, but you can't really see it if you just look at all the individuals by themselves. I've never tried or looked into this because I've never had the need to. But within Git or GitHub, whatever version control methodology you're using, can you assign multiple authors to a single commit, which would then in turn maybe solve that issue? Since we've been digging into this a lot, there's a big difference between what Git by itself is and what GitHub or Bitbucket does on top.

Yeah. Like, Git itself is this wild web of there is no default. Well, actually, in in I think in the newest version, there is now the concept of a default branch in Git itself. All of the structure and the hierarchy that makes it really workable at scale came from the providers on top of it, which I found really interesting because I was trying to just figure it out at the git level and it's just it's really really difficult because it's designed to be very widespread and and non hierarchical so that it can be as scalable as it is. GitHub or Bitbucket, you'd be able to have multiple authors on a pull request.

It's kinda their main object. In the commit level itself, you've got an author and a committer. They can be the same. They usually are. They could be different.

It's basically if you take someone else's commit, rebase it, kinda rewrite history, they're still the author but you're the committer. So you can get kind of mixed identities in it that way. But, otherwise, you gotta use what abstractions and additions other companies put on top of it. Yeah. It's pretty interesting.

I guess you would just have to assume, okay, no one ever works alone. They're always pairing, so both people get credit or whatever. Yeah. I mean, the thing about the way that I look at, like, someone getting credit for like, an individual getting credit for a PR for a commit or something like that. I think it makes sense when the individual's looking at their own data, but from a a team perspective, if if the group is getting it done well together, then I think that's the main thing that matters.

And if there's someone that's not, like, pulling their weight or there there is a performance problem with the individual, you're gonna be able to know that without looking at the stats here. Like, I'm sure we've all experienced that over the years, and I've done that personally in years ago. I got a tool that did, like, the stack ranking based on commits and all that stuff. Basically, just to prove what I already knew and that I, as the manager, needed to to let this person go because it wasn't a good fit for the team. And, like, the the data that I pulled in that that did that was really just a crutch.

Like, I already knew. I was just I didn't feel confident in myself as a manager at that point to do it. The data didn't really help it. And and then actually, the team knowing that that tool was in place and that I had access to it and, like, no one else did because that's the way the tool was set up. They actually really really didn't like it and we kicked it out after 2 months.

So there's a there's a trust factor there and in a transparency that with a with a responsible and and well put together team, you don't really need to hide the stuff when it's abstracted to the team level. Everyone can benefit from it, so there's no point in hiding it. So I think as long as you stick with the individual data belongs to the individual and team to the team, then it all works out pretty well there. So one thing that I'm wondering about then is so let's say that we have this aggregated team data. Right?

We know how the team's doing. We can kinda see how the team flows, how things generally work. I mean, what do we do with it? Do we just try different things to see what makes it better, or will it actually give us indicators of what's trying to make things better? Yeah.

Then that's that's always the big question. Like, okay, and now how I now I have data. I can see stuff. What do I do? Like, because that's always the point of the data is to get something out of it, not just to see it.

So there's particular things that we show like your code time to meeting time ratios, which generally for your development team, you want them to probably be coding more than meeting and at least have to Yes. Yeah. So there's specific things that you can do there and we'll find out when you as an individual and then also your team has their kind of peak hours in the day. And then you can use our tool to block out the the calendars for everyone during that peak time so that no meetings can get put there. So it's just protected code time on everyone's calendar so that you've got that set aside where you know that people are generally at their their peak productivity, their peak output.

So that's one thing to do is just protect that time. Using the flow mode tool in the extensions gets you to block out notifications and distractions whenever you are in the zone and we're actually coming out very soon. We're experimenting with it internally where we can detect when you're about to get into what we call flow session. This is a high productivity, high focus section of coding and automatically enable it so your computer will just react to what you were doing and start blocking out notifications and put you into flow mode whenever you ramp up into it. So that you don't get that ping right at the time that you're right into it.

So that's something that's really interesting. Right now it's a button click. So you click that and it does it. So those are the things that you can do. And then once you have the data and you're seeing trends over time, that's when you can actually start to do experiments internally with your team to see what does optimize it.

And when you break down your, like, the the lead time for code into the different sections of here's the input time that it takes, here's the full request review time, and and then how long does it take from there to get merged into the default branch. You can start to look at the different sections of the cycle and say, okay, this part is taking too long and you can hone in on where as a as a system of processes you've got something a little bit awry And then you can really hone in. Okay. Why are reviews taking so long? Which is an a common complaint.

Or from the time that I open the PR to the time it's first reviewed, it takes this much time. Or once it's reviewed, it's still not getting merged for 2 days for some reason. So, like, what's what's going on there? So you can start to really hone in on different behaviors that are adding unnecessary delay into the process and watch what happens as the behaviors change. So there's a lot of really cool stuff that you can start to do once you just see the data and then have a few little tools there to start to control the environment around it.

Alright. That's pretty cool being able to block out your colleagues with a click. If only if only I have that at work today. The is there an API? Not yet.

Nah. I know. We're we're working on automating some of the things around flow mode to give you a webhook URL. So you click that and you can start to control other stuff that you wanna do. So you could send that through Zapier, connect it to all sorts of things.

We actually have someone, one of our people in our community who automated his entire room whenever he entered flow mode. So he would click the button, it would do the stuff that that we automated it to do, block out notifications, set time on the calendar. And then he would have it set his phones to silent mode, and he had a smart bulb in his room, and it turned it purple and dimmed the lights. Because and it also whenever you do it, it puts a purple icon in your Slack so that people know that you're coding. And so he automated his entire room to put himself into flow mode with that.

So that there's a there's a lot that you can do from that. And so we're we're excited about building that out as well. Yes. API comes in. We have reports functions so you can export your data across, different projects and different time frames and things like that.

Which is actually helpful if you're on a if you're a consultant or you work for a consultancy and you need to publish hours or time spent on stuff for invoices, you can start to do that as well automatically without clicking a button to start and stop timers. So this is this is operating off a Visual Studio, is it? So we've got extensions for Versus Code, Visual Studio, IntelliJ, Sublime, Atom, and Eclipse. It's not Vim. No Vim.

We used to have it a long time ago and we'll we'll probably bring that back. And so many people use them and emacs so No. Keep it out. That'd be my excuse. I'll be like, why aren't you doing any work?

It's ours in BIM, doesn't work in BIM. You know how it is. As far as we can see from installs, I mean, Versus Code is just taking the market. IntelliJ is still there as as the second place, but Versus Code by far is the most popular one that we see. Oh, yeah.

I think we've we've got a bit of a on our website and marketing, we've got a bit of a Versus code sort of bent to everything. So it's no surprise that it's our biggest one, but it's, like, 89% of installs is through that one versus anything else. Scary. Yeah. Back to the light bulb thing.

I don't know how it would feel about having a little light bulb also measure my efficiency. So, like, if I'm typing a lot of code do really good, then all the lights turn green, then I start slowing down and things go to, like, an angry red. I just I don't know how I would like that. I like the better mode. Listener, Dave has just made his back rid of his room go green and red in synchronicity with what he was saying.

I was very impressed. Yeah. That's automation. It says the one that's green, and it just turns green. No.

I'm joking. I have a Stream Deck in front of me. Yeah. Yeah. I mean, I I suppose you could do that if you wanted to.

I wouldn't recommend it. Like, if you're fluctuating it up and down, it's probably distracting. But just going in stress level. Yeah. Like, it's red.

It's red. I'm not doing good. Oh, no. Get it back to green. Yeah.

That's that's doesn't actually help with going. Do your lights go red when your test go red, Dave? What test? So most of the stuff you're talking about here is stuff that, I guess, seems pretty common sense to most developers. Right?

You know, you're coding to meeting time. Maybe your your music some music's gonna help you get into flow, others won't. Protecting kind of your peak times. A lot of this stuff makes a lot of sense. Are are there any counterintuitive ideas around productivity that people kinda get hung up on?

It's like your data's telling you one thing, and people's intuition will tell them something else. Well, I I think there's there's 2 things there. There's some things that are as as they escalate, they don't go linear. They go exponential. That's pretty interesting.

And there's some data that we've got that that disproves, like, common held beliefs about how developers work. Like, if you watch television or movies about developers, they'll be sitting there all day and all night, days on end, coding constantly. And, yep, that's me. Yeah. Oh, wait.

Wait. Not exactly. Me too. Yeah. Or you're like you're Hugh Jackman and you're guzzling wine while creating the world's best worm or whatever it is that he was doing in a 3 d model on 12 screens.

That's the image that people have whether it's like the crazy graphics or not that we're there all the time doing it. And we do work long hours which you can see the the code day length especially as releases come up, it stretches to, like, 12, 13 hours, meaning, like, from the first keystroke to the last keystroke of the day, it's that long. But the amount of active code time cumulative through the day on average is is under 2 hours. So the amount of focused editing time that people have on average is less than 2 hours a day, and a lot of times a lot less than 2 hours a day. And if you break it down into whether that's at work or at home, more than half of it is, let's just say, outside of normal working hours.

So the amount of distractions and other stuff that we do, but instead of coding is pretty big that we push into the nights and weekends to get a lot of our work done because that's when we can have time to focus, which is why Saturday is the biggest focus day that we see. And I think that's a a travesty unless your normal working day is Saturday. And I think with this whole past year and the pandemic, a lot of companies moving to a work from home, especially if you are on a computer a lot. And so now where your recreational area used to be is now also your work area. I found having a actual separate place where I do my work and where I do my relaxation is very important.

Mhmm. So I will never take my laptop out into the den and watch TV while I'm working because to me then that's very distracting. Or when I'm supposed to be watching TV, I would be working. So I think having you know, if you're able, if you do have a living space where you can set aside even just a small corner to where when you sit there, you know that you are focusing on work, I think can also help keep you in a mental state that you don't always feel like you're working because you're not in that one place where you do your work. And I think that's, you know, mainly when you were talking about working for a employer, not just yourself, because you had the certain level of expectations there, but having that separation of concern of relaxation and work area space, I think, needs to be a physical boundary if you have trouble with that.

Yeah. I agree. I think that's huge. And one of the things that we see is we've kind of looked at different cohorts, different kind of behavior patterns that we see. And one of the best performing cohorts in terms of, overall output which is kind of a crude measurement, but that's the measurement we're going with, is those that perform typically within working hours consistently throughout the week and are less sort of spiky in their activity, like pulling an all nighter and and those sorts of things.

The people that work consistently 5 days during normal working hours and and hardly ever miss a day, those are the ones that have the highest, what we call velocity scores and which is like a, oh, man. I'm gonna forget the name. It's principal component analysis doing a vector projection thing. It's machine learning thing that my data scientist has told me several times what it is, and that's that's all best I've got right now. But basically, it's a it's a culmination of a bunch of inputs into a score.

And the but, anyway, that cohort of users has generally the highest average score on that set of inputs because they're consistent. They don't go over a bunch and work crazy, crazy hours because then you get too tired and you can't like, your next day suffers a lot which we see in the data as well. I can see that in my own data because I still do that sometimes where I'll go to like 2 AM or something like that. And then the next day is just awful and the the second day after that kind of recovers and then I'm back to my normal. So I'm like missing out on 2 days in exchange for a few extra hours at night.

Not the best exchange. So, you know, there is that separation of, okay, work time needs to happen at in in a set of time and if you can, in a place, and then separate that from everything else. I actually just switched out my laptop for a Mac mini desktop because I don't ever work anywhere else except for in my office. So it's non mobile now, and I I guess I have my phone, but, you know, at least setting up some boundaries there. And I think, yeah, that's an important thing to to see and and it also expresses through the data that we have.

And I was gonna say the other thing that was interesting in our data that's not as obvious is some of the patterns that we see that don't grow at a linear pace but go exponential is with pull request review times. If you look at how long it takes for a pull request to get reviewed, the the time as you would guess increases as the size of the PR in terms of lines of code, like how many changes there are increases. So from 1 to 200, it's certain value. From 2 to 5, it's a slightly bigger value. But when it goes above 500 lines, the time to review grows 10 x in one jump.

So there's there's some particular inflection points in the size of code going through the pipeline that start to take an inordinate amount of time to get through the pipeline because the processing of it is so much harder, like, as a person to go and review and and the complexity of it grows by so much. So there's certain kind of base rules that you can start to find out at at your organization by seeing the state of like, we're good in this space. So if you can keep your PRs and change sets below a certain amount, they'll generally flow faster. And the more that you have these, like, smoother flowing chunks of changes going through, the better cumulative overall you're gonna do as your production throughput at the end. So there's there's a lot of really interesting things there that you can see once you have this data because not everything's linear.

Most everything that we see falls to power curve. It's funny because I'm just imagining a torque curve because so before the we started at the top, we were talking about cars and performance and stuff. So I'm I'm seeing it as a torque curve where the y axis is the amount of time required to complete the pull request, and the x axis is the number of lines of code. Mhmm. If you've ever seen a torque curve, it will go up significantly, but then it kinda levels off and then it has a steep drop.

So I think that's more realistic to the code reviews I've seen where it follows a certain amount of time increases as the number of lines increase, but you get to a point where the amount of time for really large poll requests just it's almost instantaneous. Yeah. No. Actually, that is expressed there. I was gonna say that, but when you get these giant ones, people go, whatever.

It's probably fine. Click. And, like, that's probably not great for the end result as well. No. I can't see why that would be a problem at all.

Yeah. I wish my code I I wish people would review my PRs that way. Oh, it's Chuck. Yeah. He always writes good stuff.

Done. That's always. Always. Anyway, I I I did wanna ask another question, though, about your when you were talking about how people generally get, like, 2 hours of editing slash code time per day. Does that mean that the other 6 hours is, like, mental time or Stack Overflow time or Google time?

Or is that, like, realistically how productive we are? It's the time that's captured there is the kind of the culmination of whatever research you're doing there. So if you're on Stack Overflow and you're researching how to solve a problem or or reading the docs, if that's what you do, I have some friends that do that, Then gonna be investing time in there and then the output of that is your active code time where you figured it out and you've made the edits and throughout the tests. And so it's it's kind of a distilled set of time of everything else that you've put into it. But we do track other things that that are going on during the day like meeting time in in general.

Developers meet, like, 30 or 40% more during the day than they have active code time. So that's a big other portion of your day. And then we're starting to track Slack data as well. So we'll be able to see how much time is being spent in that as well as how much does that help or hurt your individual productivity. Like, if you have a a question and you get it answered via Slack really quickly and then you have a productive session because you got that answered, or you could be coding and then you get a bunch of unrelated Slack messages that pulls your attention away and it ruins your session.

So like there's there's positives and negatives that that we can start to see from that. And then of course that's another big portion of the day is communication collaboration through that. But yeah, so it's it's hard to say whether that 2 hours is a good thing or a bad thing. We're just saying that's what it is. And it's interesting that that's what the number is versus 6 hours, 8 hours, which is what a lot of people believe about developers.

I kind of I think I'd probably be Hugh Jackman, really, when you do the 9 to 5. I think I'd I think I'd rather be there. This is this is the image I have of myself. 3 AM, cigarette in one hand, mixed drink in the other, maybe 2 keyboards and a laptop on top left. I mean, crikey.

Now that now that I've learned that sensible office hours, the key to programming greatness, so I'm kind of reconsidering my career, really. Those 12 screens, I'm I'm jealous, but then I also realized that I probably only use, like, 3 of them maximum and probably only 2 of them regularly. So Mhmm. I'm gonna become rich and famous rich and more famous after I create a YouTube plug in for Versus code that enters random keystrokes. There you go.

Okay. Side note. So my phone buzzes and gives me the option of typing on the iPhone keyboard whenever one of my kids does a search on any of the apps on the Apple TV. And it's pretty fun to be sitting in the back of the room when my phone buzzes, and I pull it up and start typing their name in there while they're trying to type in the name of the show they're trying to find. And then watch them kinda go anyway.

I know. I mess with my kids like that all the time. I'll just walk up to my wife's bed and say, hey, Siri, start the car. And in my pocket, I'm hitting like the auto start button on the remote or, hey, Siri. Open up the garage door, and I'm just hitting the garage door button on our remote.

Our kids, you know, some of them sometimes they believe it, but not often. Nice. Well, anything else? It needs sorry. Go ahead, Chuck.

No. I was just gonna move us along, but go ahead. It needs a Ruby API. Is is it it needs Yeah. It needs some kind of automation layer for me to talk to it.

I definitely definitely won't subvert it to my own personal game. I promise. Okay. Okay. Good to know.

Alright. Mason, are there other things that we should be aware of or or talk about here before we go to pics? Well, I mean, just to bring it back around to Ruby stuff since we're on the Ruby podcast, we the new version we we just launched, last week is now a Ruby on Rails app. So it actually there is Ruby involved in this. Nice.

Yeah. And you guys are smart. Node JS back end with a React front end before. And you know, I this is something that I'm gonna be publishing soon on our blog, but the we have, of course, productivity metrics between for our own team, between the different systems that we've been working on. So I'll be able to do a compare and contrast on our own team's productivity using Node and React versus Ruby on Rails.

So, like, just more fodder for the Internet to argue about. Shots fired. Mhmm. Yeah. I think some people are gonna be yeah.

Our biggest show is a JavaScript show, and they have feels about whenever I bring up, you know, I just get more gun and rails. Yeah. I mean, I think that's something that we'll be we'll be starting a series on this of the languages that we see, the frameworks that we see, the different technology pieces that our global users have installed that we can see the differences in their productivity metrics with and without those things. So there'll be plenty of interesting conversation about what's the best JavaScript framework. The newest ones, always.

Always. I am curious how far down the rabbit hole you went on the technology, you know, just to switch gears there. Right? Did you is it straight up just rails server rendered and that's it? Or using, like, stimulus Hotwire, stimulus reflux, any of that stuff?

We're using stimulus and Hotwire for all of our graphs and everything. So whenever you load the dashboard, all the data is getting pulled async and loaded through HTML partials that show up through Stimulus and and Hotwire the whole thing. And we also have a feature where, like, you connect your GitHub and it pulls the last 90 days of your history so you can see stats on that. And it's got little loading bars. We wrote 0 JavaScript for the whole thing and it's a completely animated loading bar that's in in sync with all the data that's being pulled through.

I had my usually he my engineer is his name's Daniel. Let's see. My engineer. His name's Daniel. He's a person.

He he hates writing front end code, but I got him to do this because he didn't have to write any JavaScript and he was like, I'm a full stack developer now. And he was really happy about it. Is JavaScript. Too much JavaScript. Yep.

We've been playing the just basic stimulus, turbo links, make a back end request, replace HTML kind of stuff, and, boy, that's enough sometimes. Yeah. I mean, once getting into it was a little bit you gotta kind of shift how you think about building it. Once you do that, it's made developing all of the graphs and everything and like the first paint on on load is really really fast because all the heavy stuff is coming in async. And it's because it's just replacing the existing HTML, it's not shifting any of the the structure around.

It's it's come along really nicely. I'm I'm really liking it. Cool. Well, maybe we'll have to have you back on and talk about rearchitecting off of Node non to Rails. Yeah.

That'd be fun. I'll bring our metrics with me to see what it looks like. Sounds good. Alright. Well, let's let's go ahead and jump over to some pics, do some shout outs.

Luke, do you wanna get us rolling? I do. I've I've been trying to use the Rubyist app on the iPhone. Do you have this app? The Rubyist app?

Uh-huh. So this is, oh, man. I've forgotten who wrote it. This one of the pretty sure it's one of Japanese notes that everyone knows. Anyway, this is Ruby on your iPhone.

We have API hooks into things like Siri. So you can kind of automate stuff from your from your iPhone, and you can also kind of write Ruby on the iPhone. Right? It's using the mruby interpreter. So that's how they've got it in there.

They've just kind of linked the whole of mruby into the app. And I'm getting absolutely nowhere with it. I've I've not got to do any and it's me. It's not the app. It's definitely me, but it's a fantastic thing to play with when you're when you're waiting for stuff to happen.

So that's my pick for this week. It is the Rubyist app. It is free on the app store. Awesome. I'm gonna have to go play with that.

Dave, what about you? So I just have one pick, and the backstory for it is someone hit our mailbox and broke it. And it was a aluminum bracket that was holding the actual mailbox up, and it just kinda shattered in half. So what I ended up doing was making a trip to Home Depot, and I got some aluminum solder stuff that I was gonna try to solder it. But I thought, you know, I've never soldered aluminum before.

I don't know how well that's going to work. And so the alternative is to use an epoxy. So I got some JB Weld steel epoxy and this stuff, I, I think the mailbox mount bracket is stronger than it was before. Like I tried breaking it off after I let it cure for a few days and I just, I can't even make any like bins or anything to it. So JB Weld epoxy is amazing and it's really cheap for how much and you need and stuff.

So Yeah. I use that to basically glue anything that superglue won't do. Superglue is good for, like, plastic. JB Weld will glue pretty much anything. It's amazing stuff.

And it comes in 2 bottles, and you just mix it, and then you smear it where you want. And yeah. That stuff it's it's amazing stuff. Love that stuff. But, yeah.

Did you have any other pics? Didn't mean to cut you off. All right. Nope. It's okay.

I'm gonna jump out here with a few pics. The first one is and I don't it's funny because I don't remember what I picked week to week. And so I'm sitting here going, do I pick that? I'm just finishing a book on Audible. It's called fanatical prospecting.

It's a book about sales. So if you're getting into sales, and I'm getting way into sales just because of the, dev influencers accelerator, really, really digging that. It's a 6 hour book on Audible and I'm really it's, it's been really, really helpful. So I'm enjoying that. Also been enjoying the book who not how, by Benjamin Hardy and Dan Sullivan, which is also, kind of a business slash management book.

So if you're looking at how to do something, a lot of times you're better off finding somebody who who can do that instead and freeing up your time and effort. A lot of times, you're not gonna find somebody who can do it a 100% as well as you. Right? But if you can find somebody who can do it 80% as well as you, and you can free up that time, you're better off. And so I've I've been enjoying that as well.

We watched a movie with my kids the other day, and I've been in, It was funny because they were all like, we didn't really but my my, middle daughter, she watched it. Yeah. Like, every other song that came on, she's like, I didn't know that song was from this movie. It was Fiddler on the Roof. Oh, well, that was the rich man.

Do you know that? Yep. So, it was pretty funny. Not really her style of movie, but she really loves show tunes. And so she'll have the echo play show tunes over and over and over again.

And so, yeah, she didn't realize that, like, a bunch of the songs she enjoyed were from that particular movie. So that was pretty funny to have her go, oh, that's from this, like, over and over and over again through the whole thing. So, yeah, really funny stuff. And then, the last pick I have, and I've probably picked this before, but I've been diving into more and more automation stuff with monday.com. We are actually moving all of our production processes for devchat.tv for the podcasts over to monday.com.

And, like, literally right now, Mikaela is putting all of the upcoming episodes into it so that, the automation stuff will happen. So emails will go out When somebody schedules a new episode, it'll go out to the guest and let them know, hey. We're gonna send an email in a couple of days to the host so the host can put questions in. But anything you want them to prep on beforehand, when it goes through the whole process, After we record it, the the link to the media gets put in, then it notifies the editor. The editor gets done.

He puts his links in, and it notifies the show notes people. Their stuff gets put in. Show notes people may be the hosts. It may be somebody else. It just kinda depends on the show.

And then when it's all ready to go, then it tells somebody to schedule it. And then after it's scheduled, tell somebody to post on social media. And, yeah, the whole 9 yards, it's all managed in there, notifies people through email and, Discord. Some of that had to happen through webhooks with Zapier, which is the other pick. But the nice thing about Monday is that it gives you a visual look at where everything's at, and you can actually build dashboards around your, processes.

So it's it's been really nice. I'm still working out some of the kinks. I hired somebody, speaking of who, not how. I hired somebody to help me set all this up. So, it's been really, really handy, and, we're gonna be moving ahead.

I am trying to figure out how to get the hosts in there without having to pay for a whole bunch of extra accounts, And I think I can add viewers without having to pay for them. So that's probably the way we're gonna go. And then if they need something changed, then they can just discussing games. I I think yeah. I think I think you all can just bug Mikaela and she can add the stuff.

But, anyway, that's kinda what we're looking at right now. And it's it's just been this process to get it all in, but it's it's been really slick. Like, once we got some of this stuff together, it's it's been really, really slick. So I've been really happy with that as as a tool. So I'm gonna pick all of those things.

And, yeah, that's what I got. Mason, what are you what are your picks? Yeah. So I didn't know that we could pick random physical objects like JB Weld as well. So I'll have 2 today.

First one, in the tech world, MaterialiseDB is a real time streaming database that does transformations with automatically updating materialized views. Super cool and experimenting with our data streams with that now and really liking what I see. Super, super snappy. And you can get, like, real time results from massive amounts of data in milliseconds. So it's it's really cool.

And the other thing which is a random physical object is darn tough socks. They're these wool socks made from somewhere in the northeast and they have a lifetime guarantee. I love these things. I go hiking a lot. I live out in, like, the mountain area of San Diego and go hiking and mountain biking a lot.

And they're the most comfortable socks, and they last for years years years. I've got a pair that I've had for 7 years now, and they're like new. They're awesome. You should check them out. Nice.

One more question. If people wanna check you out or check out software.com, where do they find that stuff? Yeah. So software.com. It's a good place.

We have a newsletter called SRC that brings research that we find as well as news from across the tech world. And I typically post on LinkedIn. You can find me Mason Mcleed on LinkedIn, and that's where you'll see my posts. Awesome. Alright.

Well, we'll go ahead and wrap up. Thanks for coming, Mason. Thanks for having me. Big thanks to our panelists. We'll go ahead and wrap up here.

Till next time, folks. Max out.