Hey everybody, and welcome back to another episode of the Ruby Rogues podcast. This week, on our panel we have Dave Kamura everyone. We also have Luke Stutters Hello, Charles Maxwood from dev chat dot tv. And this week we have a special guest and that is Mason mclead.
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, you want to just give a little bit more of an introduction.
I kind of lost over all the cool stuff.
You're doing at software dot 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, Mason, I'm CTO at Software dot 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 observeability 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 and 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, which is also 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 your 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 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 going to help folks.
Well, there was something that I actually found out yesterday with my data scientist and 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 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 in 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 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'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 assumption 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 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 do you need to do other things?
I got a question for you here, So as a understanding it a soult dot 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 get 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 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 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 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 you 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 false number about what your cycle speed is when really there's this.
Doesn't order to work and that one committed to stuff.
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 up day wasn't my idea, my colleagues did, and it gave my code a D and quite honestly, that kind of put me off on all of these kind of co assessment tools. I'm now a bit scared that if you've got a software dot com and show to my work. They'll say that, you know, Looke's only productive on like Tuesday morning, and even then it doesn't do much work. Is this it sounds like a great tool for managers. Is it going to help the software grunts the frontline cod is 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 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 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. By mix 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 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 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 what.
A code with Alice Cooper.
On So you can check software dot Com slash Top forty we have the top forty songs ranked by productivity for the week and crazy sometimes like Alison Alis will be on there. It depends on what data we get for that week. It's always updating every week and that you can see it for yourself, like mine is my best genre is on a second edge.
Ed Sharing'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. Is 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, like,
it's not always new songs. Although popular songs tend to rise up because the 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.
I do have to push back a little bit because the number twenty four slot is the real slim shady. I don't know how well my coding would go if I'm listening to that Eminem's bat or anything, but that's on in particular. I just I'm sorry, I don't have the full buy in yet.
He just had me at Emacs Spotify. I'm just saying control X control play.
But yeah, whatever 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 want to back up to the kind of the team stats, right, because there are a couple of things. One is that my team were wepair 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, like excuse like that, which.
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 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, collaborated to 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 going to get integrated on CI? How is this going to 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 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 typest 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've just abstracted 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 never had to need to. But within get or get hub, whatever version control and methodology you're using, can you assign multiple authors to 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 get by itself is and what get hub or bitbucket does on top. Yeah, like get 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 get 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.
Get hub or bitbucket.
You'd be able to have multiple authors on a 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. It's 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've got to use what abstractions and additions other companies put on top of it.
Yeah, it's pretty interesting. I guess you just had 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 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 like pulling their weight or there there is a performance problem with the individual, you're going to 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 let this person go because it wasn't a good fit for the team, and like the data that I pulled in that 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 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 two months. So there's a 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 actually give us indicators of what to try to make these 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 and 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 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're 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 like 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 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 system of processes you've got
something a little bit awry. And then you can really hone in, Okay, why 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, So 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.
All Right, that's pretty cool being able to block out your colleagues of a click if only if only I have that work today?
Is there an API? Not yet?
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 want to do. So you could send that through zaper 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 at time of 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 excited about building that out as well.
Yes, API comes in.
We have reports functions so you can export your data across you know, different projects and different timeframes 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 book, is it.
So we've got extensions for vs code, Visual Studio, Intelligent, Sublime, Atom and Eclipse. No VIM, we used to have it a long time ago, and well we'll probably bring that back. And so many people use VEM and Emacs, so no.
Keep it out. That'll be my excuse. I'd be BIB doesn't work, BIB.
You know, as far as we can see from installs, I mean, vs code is just taking the market. Intelligence is still there as as the second place, but vs code by far is the most popular one that we see. Oh yeah, I think we 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 eighty nine percent 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, I start slowing down and things go to like an angry red. I just I don't know how I would like that.
Like a listener, Davi has just made his back rid of his room go green and red in synchronicity with what he was saying, I was very impressive.
Yeah, that's automation green and it just turns green. I'm joking. I have a stream 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 downs, 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 it doesn't actually help, but going.
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 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 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 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 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 yeah that's me. Yeah, oh wait wait, not exactly me too.
Yeah.
Or you're like you're Hugh Jackman and your guzzling wine while creating the world's best worm or whatever it is that he was doing in a three D model on twelve 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 code day lengths, especially as releases come up, it stretches to like twelve thirteen hours, meaning like from the first keystroke to the last key
stroke of the day 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, say, outside of normal working hours. So the amount of distractions and other stuff that we
do but instead of code 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 focused 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 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 mainly when you were talking about working for a employer, not just yourself, because you have
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 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 meta 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 those sorts of things. The people that work consistently five days during normal working hours and hardly ever miss at eight those are the ones that have the highest what we call velocity scores, and 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 culmination of a bunch of inputs into a score and that But anyway, that cohorative 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.
Or I'll go to like two am 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.
So you know, there is that separation of Okay, work time needs to happen at 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 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 is 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 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 five hundred lines, the time to review
grows ten x 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, like as a person to go and review, and the complex 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 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 going to do is 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. Most everything that we see follows a power curve.
It's funny because I'm just imagining a torque curve because so before we started the top 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 requests, 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 just it's almost instantaneous.
Yeah. No, actually that is express there. I was going to say that that.
When you get these giant ones people 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 wish people would review my prs that way. Oh, it's shocked. Yeah, he always reads good stuff done. That's always always anyway. I did want to ask another question though about your 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.
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 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 where you figured it out and you've made the edits and throughte 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 are going on during the day, like meeting time. In general, developers meet thirty or forty percent more the day then 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 days 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 kind of I think I'd rather be Hugh Chackman, really, wouldn't you do it? At nine to five? I think I think I'd rather be there. This is this is the image I have at myself. Three am cigarette and one hand mixed drink and the other maybe two keyboards and a laptop top left. I mean, criikee. Now that, now that I've learned that sensible office hours the key to programming greatness, so I kind of reconsidering my career.
Really, those twelve 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.
So mm hmm, I'm going to become rich and famous, rich and more famous after I create a YouTube plug in for vs code that enters random keystrokes.
There you go, okay.
Side note, so on my phone buzzers 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.
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, sirih 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, go ahead? No, I was just gonna move us along, but go ahead.
It needs to reap the API, it needs, it needs some kind of ultimation. Left me to to it. I definitely definitely won't subvert it to my own personal game, I promise.
Okay, good to know, all right, 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 Ruvie 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. Nice.
Yeah, it was no JS back end with a React frun end before boo. And you know, this is something that I'm going to 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 or fodder for the Internet to argue about shots five mm hmm.
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 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 mestrics 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, hot wire, stumulus reflocks, any of that stuff.
We're using stimulus and hot wire for all of our graphs and everything. So whenever you load the dashboard, all the data is getting pulled a sync and loaded through HTML. Partials that show up through stimulus and hot wire the whole thing. And we also have a feature where like you connect your GitHub and it pulls the nast ninety 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. See my injurer. His name's Daniel, his 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 nice, very JavaScript. Too much JavaScript.
Yeah, we've been playing the just basic stimulus turbolinks, 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've 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 structure around. It's 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 non to rails.
Yeah, that'd be fun. I'll bring our metrics with Mesta. See what it looks like. Sounds good? Right, Well, let's go ahead and jump over to some picks. Do some shout outs, Luke, do you want to get us rolling?
I've been trying to use the rubyest app on the iPhone.
Do you have this app? The rubyest app?
So this is oh man, I've forgoten who wrote it. That's one of the pretty sure it's one of Japanese pads that everyone knows. Anyway, this is Ruby on your iPhone with API hooks into things like Sirius, so you can kind of automate stuff from your from your iPhone and you can also kind of rite Ruby on the iPhone. Right, it's using the m ruby interpreter, so that's how they've got it in there. They've just kind of linked the whole of m ruby into the app. And I've getting
absolutely nowhere with it. I I've 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 when you're wedding for stuff to happen. So that's my pick for this week. It is the Rubyest app. It is free on the app Store.
Awesome. I'm gonta have to go play with that, Dave, what about?
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 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 steal epoxy and this stuff. 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 can 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 would 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 because stuff, it's amazing stuff.
Love that stuff. Yeah, did you have any other picks? Then? Mean to cut 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 tw 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 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 fighting somebody who who can do that instead and fringing up your time and effort.
A lot of times you're not gonna find somebody who can do it one hundred percent as well as you, right, But if you can find somebody who can do it eighty percent 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 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 that was a bitch 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 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 probably picked this before, but I've been diving into more and
more automation stuff with Monday dot Com. We are actually moving all of our production processes for devchat dot tv, for the podcast over to Monday dot com, and like literally right now, Mikayla 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 hosts 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's tells somebody to schedule it, and then after it's scheduled, tell somebody to post on social.
Media, and yeah, the whole nine yards.
It's just 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 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 change then they can just discuss the game.
I think, yeah, I think I think you all can just bug McKayla and she can add the stuff. But anyway, that's kind of 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 going to 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 to today. First one in the tech world, materialized dB is a real time streaming database that does transfer informations 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 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 of in like the mountain area of San Diego and go hiking a mountain, biking a lot, and they're the most comfortable socks in 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. To check them out. Nice. One more question.
If people want to check you out or check out software dot com, where do they find that stuff?
Yeah, so software dot 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 mcleid on LinkedIn and 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