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.LinksSoftware Top 40Software.comLinkedIn- Mason McleadPicksCharles- Fanatical ProspectingCharles- Who Not HowCharles- Monday.comCharles- ZapierDave- J-B Weld Luke- RubyistMason- Materialize Mason- Darn Tough VermontBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Hey, everybody, and welcome back to another episode of the Ruby Rogues podcast. This week on our panel, we have Dave Kimura. Hey, everyone. We also have Luke Stutters. Hello. And Charles Maxwood from DevChat.TV. And this week, we have a special guest, and that is Mason McLeod. 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 kind of curious as we dive in. First, do you want to just give a little bit more of an introduction? 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 want to 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.
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 then 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 then the impact of other distractions like Slack and meeting, 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 a lot 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 kind of went the same kinds of ways. I'm a little curious as we dive into this with Ruby Rogues, are there things that we didn't get to in the other shows that 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 going to help folks.
Well, there was something that I actually found out yesterday with my data scientist.
Breaking news!
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 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 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 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 and 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 focus work done during the week and then actually take time off because you're a person as well and you need to do other things
I got a question for you here. So as I'm understanding it, at 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.
Yeah, 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... If you kind of arrange how development works 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. It's a creative 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 the 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 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 that from another tool, they're looking at when the commit was pushed to when it was merged. And I don't know 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... Depending on how your behavior is, it gives you a false number about what your cycle speed is.
You've done all the work in that one commit at the start.
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 the other day. 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 people go to software.com and show them my work, they'll say that, you know, Luke's only productive on like a Tuesday morning. And even then he doesn't do much work.
It sounds like a great tool for managers. Is it going to help 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 CodeClimate or any of those 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 tools, and 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 want to 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 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 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 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 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. Do you write better code with Alice Cooper on? So you can check software.com slash top 40.
We have the top 40 songs ranked by productivity for the week. That's crazy. Sometimes Alice Cooper will be on there. It depends on what data we get for that week. It's always updating every week. 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 three. 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 billion times. So you don't have to actively think about what's going on. It's just in the background and it's 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, it's not always new songs, although popular songs tend to rise up because 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 pushed? 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 bad or anything, but that song in particular, I'm sorry, I don't have the full buy-in yet.
He just had me at Emac Spotify. Just saying. Control X, control play. But yeah, whatever. I do have to say though that, I mean, it's interesting, right? These are all things that you measure or don't measure. I also just want to back up to the kind of the team stats, right? Because there are a couple of things. One is that my team, 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 things like that well 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?
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 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, collaborative 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 does this kind of get integrated on CI? How is this going to 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 kind of 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 all goes into the same bucket and we're all measuring that progress on the same rubric. Yeah, exactly.
And if you took that case where you and your other half of the pair have been programming for two 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 going to 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 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 and 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. Git itself is this wild web of there is no default. Well, actually, 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 get level. And it's just, it's really, really difficult because it's designed to be very widespread 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 pull request. It's kind of 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. Basically, if you take someone else's commit, rebase it, kind of 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 got to 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 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 team perspective, 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
pulling their weight or there is a performance problem with the individual, you're going to be able to know that without looking at the stats here. 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 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 let this person go because it wasn't a good fit for the team. And The data that I pulled in that did that was really just a crutch. I already knew. I didn't feel confident in myself as a manager at that point to do it.
The data didn't really help. And then actually, the team knowing that that tool was in place and that I had access to it and 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 two months.
So there's a trust factor there and in a transparency that with a responsible and well put together team, you don't really need to hide this 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 kind of 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 to try to make things better?
Yeah, that's always the big question. Like, okay, now I have data. I can see stuff. What do I do? 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.
Oh, please.
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 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 peak productivity and 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 a 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 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 pull 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 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 two days for some reason. It's like, 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.
Right. That's pretty cool to be able to block out your colleagues with a click. If only I had that work today. Is there an API?
Not yet. I know. 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 want to 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 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. 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 there's a lot that you can do from that. And so 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 timeframes and things like that.
which is actually helpful 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 operating off a Visual Studio hook, is it?
So we've got extensions for VS Code, Visual Studio, IntelliJ, Sublime, Atom, and Eclipse. There's no Vim. No Vim. We used to have it a long time ago, and we'll probably bring that back. And so many people use Vim and Emacs, so...
No, keep it out. That would be my excuse. I'd be like, why aren't you doing any work? Oh, it's in BIM. It doesn't work in BIM.
You know how it is. As far as we can see from installs, I mean, VS Code is just... taking the market. IntelliJ is still there as the second place, but VS Code by far is the most popular one that we see. Oh yeah. I think we've got a bit of a, on our website and marketing, we've got a bit of a VS 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 I 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 to be demoted. Dave has just made his background of his room go green and red in synchronicity with what he was saying. That was very impressive. Yeah. That's automation.
I say the word green and it just turns green. No, I'm joking. I have a screen deck in front of me. Yeah.
I mean, I suppose you could do that if you wanted to. I wouldn't recommend it. Like if you're
fluctuating it up and down is 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 doesn't actually help with coping do your lights go red when your tests go red they what tests
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 music, some music's going to 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 there any counterintuitive things?
ideas around productivity that people kind of get hung up on? It's like your data is telling you one thing and people's intuition will tell them something else.
Well, I think there's there's two 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 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. Yep, that's me. Yeah.
Oh, wait, wait. Not exactly. Me too.
Yeah, or 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 3D model on 12 screens. That's the image that people have, whether it's the crazy graphics or not, that we're there all the time.
And we do work long hours, which you can see the code day lengths, 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 under two hours.
So the amount of focused editing time that people have on average is less than two hours a day, and a lot of times a lot less than two hours a day. And if you break it down into whether that's at work or at home, more than half of it is 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 travesty unless your normal working day is Saturday.
And I think with this whole past year in 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.
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... 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 mainly when you are talking about working for an employer, not just yourself, because you have a 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 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 were 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 those sorts of things. The people that work consistently five days during normal working hours and hardly ever miss a day, those are the ones that have the highest, what we call velocity scores, which is like a, oh man, I'm going to forget the name.
It's principal component analysis doing a vector projection thing. It's a machine learning thing that my data scientist has told me several times. what it is. And that's, that's all the best I've got right now. But basically it's a, it's a combination of a bunch of inputs into a score.
And that, 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. Cause 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. Cause I still do that sometimes where I'll, go to like 2 a.m.
or something like that and then the next day is just awful and the second day after that kind of recovers and then I'm back to my normal so I'm like missing out on two days in exchange for a few extra hours at night not the best exchange but
So, you know, there is that separation of, okay, work time needs to happen 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 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 see. And it also expresses through the data that we have. And I was going to 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 one to two hundred it's certain value from two to five it's a slightly bigger value but when it goes above 500 lines the time to review grows 10x in one jump.
So 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 as a person to go and review 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 your organization by seeing the state of like, we're good in this phase. 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 going to do as your production throughput at the end. So there's a lot of really interesting things there that you can see once you have this data because not everything's linear and most everything that we see follows the power curve
It's funny because I'm just imagining a torque curve. So before we started the talk, we were talking about cars and performance and stuff. So 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. If you've ever seen a torque curve, it will go up significantly
But then it kind of 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 pull requests, it's almost instantaneous. Yeah.
Yeah. No, actually that is expressed there. I was going to 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 people would review my PRs that way. Oh, it's Chuck. Yeah, he always writes good stuff. Done. Always. Always. Anyway, I did want to ask another question, though, about when you were talking about how people generally get like two hours of editing slash code time per day.
Does that mean that the other six hours is like mental time or stack overflow time or Google time? Or is that like realistically how productive we are?
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 reading the docs, if that's what you do. I have some friends that do that. Then going to be investing time in there.
And then the output of that is your active code time when you figured it out and you've made the edits and drew out the tests. And so 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 are going on during the day, like meeting time. And in general, developers meet 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 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 there's positives and negatives that we can start to see from that. And then, of course, that's another big portion of the day is communication and collaboration through that. But yeah, so it's hard to say whether that two 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 six hours, eight hours, which is what a lot of people believe about developers.
I think I'd rather be Hugh Jackman, really, wouldn't you? Dude at 95. I think I'd rather be there. This is the image I have of myself. 3 a.m., cigarette in one hand, mixed drink in the other. Maybe two keyboards and a laptop top left. I mean, crikey. Now that I've learned that sensible office hours are the key to programming greatness, I'm kind of reconsidering my career, really.
Those 12 screens, I'm jealous. But then I also realized that I'd probably only use like three of them maximum. and probably only two of them regularly.
I'm going to become rich and famous, rich and more famous, after I create a YouTube plugin for VS 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 kind of go, huh? Anyway.
I know I mess with my kids like that all the time. I'll just walk up to my wife's van 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? Sorry, go ahead Chuck. No, I was just going to move us along, but go ahead.
Okay.
Good to know. Mason, are there other things that we should be aware of or talk about here before we go to picks?
Well, I mean, just to bring it back around to... Ruby stuff since we're on the Ruby podcast. The new version we just launched last week is now a Ruby on Rails app. So it actually, there is Ruby involved in this. Hey, nice. Yeah, it was Node.js backend with a React frontend before.
And this is something that I'm going to be publishing soon on our blog, but 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.
Yeah, I think some people are going to be, yeah. Our biggest show is a JavaScript show and they have feels about whenever I bring up, you know, I just get more done in 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 will be plenty of interesting conversation about what's the best JavaScript framework.
The newest one, 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 hotwire, the whole thing. And we also have a feature where 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 zero JavaScript for the whole thing. And it's a completely animated... loading bar that's 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 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 zero JavaScript too much JavaScript? Yeah.
Yeah, we've been playing the just basic stimulus, turbo links, make a backend request, replace HTML kind of stuff. And boy, that's enough sometimes. Yeah.
I mean, once getting into it was a little bit, you got to kind of shift how you think about building it. But once you do that... it's made developing all of the graphs and everything. And like the first paint 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 come along really nicely.
I'm really liking it. Cool. Well, maybe we'll have to have you back on and talk about re-architecting off of Node and onto Rails. Yeah, that'd be fun. I'll bring our metrics with me to see what it looks like. Sounds good. All right. Well, let's go ahead and jump over to some pics and do some shout-outs. Luke, do you want to get us rolling?
Dude, I've been trying to use the Rubyist app on the iPhone. Do you have this app, the Rubyist app? I don't know. So this is, oh man, I've forgotten who wrote it. It's one of the, pretty sure it's one of the Japanese guys that everyone knows. Anyway, this is Ruby on your iPhone with API hooks into things like Siri.
So you can kind of automate stuff 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 have not got it 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 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 going to 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 an aluminum bracket that was holding the actual mailbox up. And it just kind of 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 going to 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 think the mailbox mount bracket is stronger than it was before. I tried breaking it off after I let it cure for a few days. And I can't even make any bends 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 super glue won't do. Super glue is good for like plastic. JB Weld will glue pretty much anything. It's amazing stuff. And it comes in two bottles and you just mix it and then you smear it where you want and stuff. It's amazing stuff. Love that stuff. Yeah. Did you have any other picks? I didn't mean to cut you off. All right.
I'm going to jump out here with a few picks. 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 six hour book. on Audible and I'm really, 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 can do that instead and freeing up your time and effort. A lot of times you're not going to find somebody who can do it 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 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 really but my my middle daughter she watched it 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 Well, I was a rich man. 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 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, Michaela 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 going to 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 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 kind of 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 to social media. And yeah, the whole nine yards is 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 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 going to 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 going to go. And then if they need something changed, then they can just... I think you all can just bug Michaela and she can add the stuff.
But anyway, that's kind of what we're looking at right now. And it's just been this process to get it all in. But it's been really slick once we got some of this stuff together. It's been really, really slick. So I've been really happy with that as a tool. So I'm going to pick all of those things. And yeah, that's what I got. Mason, 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 two today. First one in the tech world, MaterializeDB. is a real-time streaming database that does transformations with automatically updating materialized views. Super cool. I'm experimenting with our data streams with that now. and really liking what I see. Super, super snappy.
And you can get real-time results from massive amounts of data in milliseconds. So 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 in 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 and years and years. I've got a pair that I've had for seven years now and they're like new.
They're awesome. You should check them out. Nice. One more question. If people want to 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 McLeod, on LinkedIn. That's where you'll see my posts. Awesome. All right.
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. Until next time, folks. Max out.