Speaker 1: Hey everybody, and welcome back to another episode of the
Speaker 1: Ruby Rogues podcast. This week, on our panel we have
Speaker 1: Dave Kamura everyone. We also have Luke Stutters Hello, Charles
Speaker 1: Maxwood from dev chat dot tv. And this week we
Speaker 1: have a special guest and that is Mason mclead.
Speaker 2: Hey everyone, and thanks for having me on. Yeah.
Speaker 1: Now, we've had you on a couple of other shows.
Speaker 1: We've been talking about basically getting more done. I'm kind
Speaker 1: of curious as we dive in first, you want to
Speaker 1: just give a little bit more of an introduction.
Speaker 2: I kind of lost over all the cool stuff.
Speaker 1: You're doing at software dot com and all the tools
Speaker 1: that you provide to people and things like that, as
Speaker 1: well as the research that.
Speaker 2: You're doing on productivity.
Speaker 1: But yeah, you want to just give us the quick
Speaker 1: elevator pitch and then we can dive in.
Speaker 2: Sure.
Speaker 3: Yeah, So, Mason, I'm CTO at Software dot Com. We
Speaker 3: make tools for developers and it's all around time tracking
Speaker 3: and efficiency and productivity. So the core thing that we
Speaker 3: do is track telemetry about how you code and give
Speaker 3: you that feedback and that observeability about how the development
Speaker 3: process is working for your team and for you as
Speaker 3: an individual, and we also got editor extensions across all
Speaker 3: the main editors that give you access to that data
Speaker 3: right and line. And also we have a tool called
Speaker 3: flow Mode which connects to Slack and your calendar and
Speaker 3: starts to block out times whenever you're coding so that
Speaker 3: you don't get distracted, because I think everyone's had that
Speaker 3: feeling where you finally get into the zone like you've
Speaker 3: got everything in your head and then you get a
Speaker 3: bunch of Slack messages or meetings coming up, and then
Speaker 3: you lose it all, and that's really valuable time that's
Speaker 3: then lost. So we've got tools to help you do that.
Speaker 3: And a lot of the research that we're doing is
Speaker 3: looking at the impact analysis of meeting time versus how
Speaker 3: people can get stuff done during the day, which is
Speaker 3: also leading cause of why developers work at night a
Speaker 3: lot of the times or on weekends. And then the
Speaker 3: impact of other distractions like Slack and meeting sorry, working
Speaker 3: at the office versus working remote when that is an
Speaker 3: option depending on what country you're in, And yeah, all
Speaker 3: sorts of other stuff going into that. So a lot
Speaker 3: of really interesting data that we can see and a
Speaker 3: lot of assumptions that people have that can be proven
Speaker 3: correct through the data or actually debunked, which is I
Speaker 3: think a really interesting part of it as well.
Speaker 1: Right, And like I said, you know, we had your
Speaker 1: on Adventures in DevOps, we had you on I can't
Speaker 1: remember which of the other shows we talked to you on,
Speaker 1: but most of those conversations kind of went the same
Speaker 1: kinds of ways. I'm a little curious as we dive
Speaker 1: into this with Ruby Rogues, are there are there things
Speaker 1: that we didn't get to in the other shows that
Speaker 1: we we could talk about here and then maybe we
Speaker 1: can circle back around to kind of the big ideas
Speaker 1: that we got to on the other shows that are
Speaker 1: going to help folks.
Speaker 3: Well, there was something that I actually found out yesterday
Speaker 3: with my data scientist and breaking news breaking top line
Speaker 3: research here. So I was looking at what we've got
Speaker 3: certain measures that we see in the data, and we'll
Speaker 3: be able to mark sessions of your coding. We have
Speaker 3: a thing called code time, which is when you're in
Speaker 3: the editor, you're looking at files, you're doing research, not
Speaker 3: necessarily editing the code. And then we have a section
Speaker 3: of time called active code time, which is when you're
Speaker 3: actively editing. And so one things you can do when
Speaker 3: you've got those is look at the ratio that people
Speaker 3: spend in the day of how much of their code
Speaker 3: time is also active code time, which is kind of
Speaker 3: a proxy for focus in the time that it takes
Speaker 3: for them to ramp up to productivity in that session.
Speaker 3: So how long does it of reading does it take
Speaker 3: to get you into editing? And I was looking at
Speaker 3: that per day of week and found that for that
Speaker 3: particular ratio, Saturday is the most focused day that developers have,
Speaker 3: so of developers that code on the weekend, Saturday has
Speaker 3: a far higher kind of focus factor than any day
Speaker 3: of the week, although Tuesday is a close runner up.
Speaker 3: So from that I think we'll be able to dive
Speaker 3: further into it, like, Okay, why is that the way
Speaker 3: it is? But just on the observation and kind of
Speaker 3: the assumption that you have about Saturdays and tuesdays, there's
Speaker 3: less people bothering you, there's less meetings, there's less messages,
Speaker 3: and so if you want to work on Saturday and
Speaker 3: that works for your lifestyle, great, it seems to be
Speaker 3: a good one. If you don't, and that's just a
Speaker 3: byproduct of you not having gotten stuff done during the week.
Speaker 2: Because you're distracted all the time.
Speaker 3: It's like, how do you make a Saturday like environment
Speaker 3: during the week so that you can have that same
Speaker 3: amount of focus to be as productive on those days?
Speaker 3: And like, those are some of the small behavioral shifts
Speaker 3: that you can start to put into your work week
Speaker 3: as a team and as an individual so that you
Speaker 3: can get more focus work done during the week and
Speaker 3: then actually take time off because you're a person as well,
Speaker 3: and do you need to do other things?
Speaker 4: I got a question for you here, So as a
Speaker 4: understanding it a soult dot com, you've got loads of
Speaker 4: really cool tools that can kind of look at people's
Speaker 4: commits or some other metric you're looking at to assess productivity.
Speaker 3: Yeah, so we've got several metrics that go into it,
Speaker 3: and in the coming weeks we'll have it all connected
Speaker 3: to get commits and those sorts of things. We're doing
Speaker 3: that internally right now, just kind of refining the product
Speaker 3: before we put it out there where we can look
Speaker 3: at Like if you if you kind of arrange how
Speaker 3: development works in line of kind of a physical factory,
Speaker 3: it's not the same because you're not recreating the same
Speaker 3: thing over and over again.
Speaker 2: It's a creative endeavor.
Speaker 3: But right if you kind of look at it that
Speaker 3: way as a metaphor and say, there's all these inputs
Speaker 3: that go into it, and that for us is the time,
Speaker 3: the amount of characters and lines, and like just the
Speaker 3: raw materials that go into it, and then you look
Speaker 3: at the outputs. And I think so far the best
Speaker 3: sort of abstraction for what an output a unit of
Speaker 3: output is is a merged pull request. It's a chunk
Speaker 3: of work that someone has thought is enough to stand
Speaker 3: on its own, and it's good enough gone through quality
Speaker 3: checks to get merged into the default branch, which would
Speaker 3: then go to production. So those are the inputs and
Speaker 3: the outputs of this factory. And if you look at
Speaker 3: the traditional definition of efficiency and productivity, it's how much
Speaker 3: input does it take to get to some unit of output.
Speaker 3: So as soon as you have that, now you've got
Speaker 3: the full view of the development cycle, what is going in,
Speaker 3: what is coming out, and you can start to get
Speaker 3: a lot of really interesting measurements about the overall system
Speaker 3: and then each of the steps along the way. So
Speaker 3: when you hear about things like cycle time, which is
Speaker 3: typically when someone's looking at at that from another tool,
Speaker 3: they're looking at when the commit was pushed to when
Speaker 3: it was merged.
Speaker 2: And I don't know how how you like to commit.
Speaker 3: People do it differently, but I usually code nearly all
Speaker 3: of everything before I do the first commit, and then
Speaker 3: I commit, make a PR, push it, and then I'll
Speaker 3: get feedback and maybe you make some changes. But the
Speaker 3: bulk of the work of the input side is before
Speaker 3: that first commit, which is completely missed by these other tools.
Speaker 3: And it also gives you a like, depending on how
Speaker 3: your behavior is, it gives you a false number about
Speaker 3: what your cycle speed is when really there's this.
Speaker 4: Doesn't order to work and that one committed to stuff.
Speaker 3: Yeah, exactly. So getting a realistic number and just observing
Speaker 3: what the team is actually doing gives you an empowerment
Speaker 3: to go and actually make positive changes to it. And
Speaker 3: that's really at the core of it. This is what
Speaker 3: this is about.
Speaker 4: I went on code Climate the up day wasn't my idea,
Speaker 4: my colleagues did, and it gave my code a D
Speaker 4: and quite honestly, that kind of put me off on
Speaker 4: all of these kind of co assessment tools. I'm now
Speaker 4: a bit scared that if you've got a software dot
Speaker 4: com and show to my work. They'll say that, you know,
Speaker 4: Looke's only productive on like Tuesday morning, and even then
Speaker 4: it doesn't do much work. Is this it sounds like
Speaker 4: a great tool for managers. Is it going to help
Speaker 4: the software grunts the frontline cod is like me.
Speaker 3: Yeah, I think that is a really interesting point. That's
Speaker 3: something that we think about a lot, and you're right
Speaker 3: about you know, co climate or any of those other tools.
Speaker 3: They do have a very manager first approach to it all,
Speaker 3: which is something that we actively avoid. So first of
Speaker 3: all with with our tools, and I think everyone should
Speaker 3: do this, is that we don't show individual data to
Speaker 3: anyone except that individual.
Speaker 2: If the team is looking at the data, they see.
Speaker 3: Aggregated anonymized data at the team level, so the team
Speaker 3: is an object or an entity that is creating code
Speaker 3: together and looking at it at individual parts is not
Speaker 3: as helpful for the metrics that you would actually want
Speaker 3: to track, and that's really a manager task to do.
Speaker 3: And I don't think automating that out to a bunch
Speaker 3: of stats is a healthy or productive thing to do.
Speaker 3: By mix stats like that's what we do, I don't
Speaker 3: think it's right for that. It could be a supplement,
Speaker 3: but it doesn't replace being a manager. And yeah, so
Speaker 3: for us, we only show the individual data to the
Speaker 3: individual so that they can see it for themselves. And
Speaker 3: then the thing that I'm really proud of is that
Speaker 3: we have the what we call editor ops tools extensions
Speaker 3: that are running in your editor. So just like chat
Speaker 3: ops brought a lot of automations and cool stuff into
Speaker 3: Slack or whatever, we bring that into the editor so
Speaker 3: that you can start to control your environment from there
Speaker 3: without context switching. Like we have an extension called music
Speaker 3: Time that allows you to control your Spotify from the
Speaker 3: editor with like keyboard shortcuts or some clicks. And it
Speaker 3: also shows you in a correlative sort of way, what
Speaker 3: are the most productive songs that you listen to or
Speaker 3: genres and like what.
Speaker 2: A code with Alice Cooper.
Speaker 3: On So you can check software dot Com slash Top
Speaker 3: forty we have the top forty songs ranked by productivity
Speaker 3: for the week and crazy sometimes like Alison Alis will
Speaker 3: be on there. It depends on what data we get
Speaker 3: for that week. It's always updating every week and that
Speaker 3: you can see it for yourself, like mine is my
Speaker 3: best genre is on a second edge.
Speaker 4: Ed Sharing's in the top three good God.
Speaker 2: You know what.
Speaker 3: I what I think it is, and I don't have
Speaker 3: the data yet to prove it. I think it's there's
Speaker 3: songs that are really familiar and you've heard a billion times,
Speaker 3: so you don't have to actively think about what's going on.
Speaker 3: Is just in the background, and it's the smooth tones
Speaker 3: of Ed Sheeran. Then it allows you to kind of
Speaker 3: mute out everything else and that takes the place of
Speaker 3: background noise, and then you can have your mind available
Speaker 3: to focus. And I think whenever you see that, like,
Speaker 3: it's not always new songs. Although popular songs tend to
Speaker 3: rise up because the people listen to them, but a
Speaker 3: lot of older songs as well that people have listened
Speaker 3: to many many times and it's just their go to
Speaker 3: thing in order to get into the zone.
Speaker 5: I do have to push back a little bit because
Speaker 5: the number twenty four slot is the real slim shady.
Speaker 5: I don't know how well my coding would go if
Speaker 5: I'm listening to that Eminem's bat or anything, but that's
Speaker 5: on in particular. I just I'm sorry, I don't have
Speaker 5: the full buy in yet.
Speaker 2: He just had me at Emacs Spotify. I'm just saying
Speaker 2: control X control play.
Speaker 1: But yeah, whatever I do have to say though that
Speaker 1: I mean, it's it's interesting, right, these are all things
Speaker 1: that you measure or don't measure. I also just want
Speaker 1: to back up to the kind of the team stats, right,
Speaker 1: because there are a couple of things. One is that
Speaker 1: my team were wepair or mob everything, and so measuring
Speaker 1: that kind of productivity. I may not be the person
Speaker 1: who's actually even in the editor, right, I may be
Speaker 1: participating over the call or pushing you know, I may
Speaker 1: put the pr together, but none of the commits are
Speaker 1: actually commits that came off of my machine, like excuse
Speaker 1: like that, which.
Speaker 2: Maybe it could be.
Speaker 1: But my point is is that by measuring the velocity
Speaker 1: of the team, or measuring the output of the team,
Speaker 1: measuring the team as a whole. If I'm out for
Speaker 1: a week, they can see what the impact is, right,
Speaker 1: or somebody else is out for the week, they can
Speaker 1: see what the impact is even if they're not seeing specifically. Oh,
Speaker 1: there are fewer commits by Chuck or fewer commits by
Speaker 1: one of the other guys, right, Yeah.
Speaker 3: And even just looking at the metrics at the team
Speaker 3: level aligns with the purpose and virtues of pair or
Speaker 3: mob programming where you're doing this as a team. It's
Speaker 3: not a bunch of individuals writing a bunch of different code.
Speaker 3: It's everyone coming together to do this and measuring the
Speaker 3: velocity and the lead time and the throughput at that
Speaker 3: level seems to me to be the right level to
Speaker 3: do it at.
Speaker 1: Well, I've been on teams where we didn't pair, right,
Speaker 1: We didn't pair, we didn't mob, We just do the work.
Speaker 1: But we were still collaborating, collaborating, collaborated to dating whatever.
Speaker 1: We were still talking to each other about what we
Speaker 1: were working on. We were still Hey, I'm stuck on this.
Speaker 1: Can you help me out?
Speaker 2: Hey? How does this go together so that I can
Speaker 2: integrate with it? Hey?
Speaker 1: How does this going to get integrated on CI? How
Speaker 1: is this going to get come together when we deploy it?
Speaker 2: Hey? You know, how does this work? Hey?
Speaker 1: Do you know a good algorithm to solve this particular problem?
Speaker 1: And so there's always going to be interplay between the
Speaker 1: members of the team, whether you have them sitting together
Speaker 1: or on a zoom or teams or skype call. And
Speaker 1: so the reality is is if you're not measuring it
Speaker 1: as a team, you're not measuring all of that other stuff,
Speaker 1: and you're going to miss really a big part of
Speaker 1: how this all kind of comes together, because at the
Speaker 1: end of the day, everything that I'm working on, and
Speaker 1: everything that you're working on, and everything that everybody else
Speaker 1: is working on on this particular app or set of apps,
Speaker 1: it all goes into the same bucket, and we're all
Speaker 1: measuring that progress on the same rubric.
Speaker 2: Yeah, exactly.
Speaker 3: And if you took that case where you and your
Speaker 3: other half of the pair have been programming for two
Speaker 3: weeks on a particular sprint and the other person's always
Speaker 3: been the typest in that case, then if you're looking
Speaker 3: at the way that other tools traditionally do this, where
Speaker 3: it's per person, you're going to see one person did
Speaker 3: everything and the other person did nothing based on who
Speaker 3: committed what, and that wasn't the case at all. Like,
Speaker 3: this is definitely a team effort, and so if you've
Speaker 3: just abstracted away to the proper level, then you don't
Speaker 3: fall into that trap of having this false stack rank
Speaker 3: of individuals assuming that they're all doing their own individual stuff,
Speaker 3: which is never the case when you're on a team
Speaker 3: that's working well together. And the communication side of it
Speaker 3: is a it's kind of an invisible and I think
Speaker 3: undervalued in a lot of times aspect of team building,
Speaker 3: that that really you'll see the effects of it when
Speaker 3: it's going well at the team level, but you can't
Speaker 3: really see it if you just look at all the
Speaker 3: individuals by themselves.
Speaker 5: I've never tried or looked into this because I never
Speaker 5: had to need to. But within get or get hub,
Speaker 5: whatever version control and methodology you're using, can you assign
Speaker 5: multiple authors to single commit, which would then in turn
Speaker 5: maybe solve that issue.
Speaker 3: Since we've been digging into this a lot, there's a
Speaker 3: big difference between what get by itself is and what
Speaker 3: get hub or bitbucket does on top. Yeah, like get
Speaker 3: itself is this wild web of there is no default. Well, actually,
Speaker 3: I think in the newest version there is now the
Speaker 3: concept of a default branch. In get itself. All of
Speaker 3: the structure and the hierarchy that makes it really workable
Speaker 3: at scale came from the providers on top of it,
Speaker 3: which I found really interesting because I was trying to
Speaker 3: just figure it out at the get level and it's
Speaker 3: just it's really really difficult because it's designed to be
Speaker 3: very widespread and non hierarchical, so that it can be
Speaker 3: as scalable as it is.
Speaker 2: Get hub or bitbucket.
Speaker 3: You'd be able to have multiple authors on a pull request.
Speaker 3: It's kind of their main object. In the commit level itself,
Speaker 3: you've got an author and a committer. They can be
Speaker 3: the same they usually are, they could be different. It's basically,
Speaker 3: if you take someone else's commit, rebase it kind of
Speaker 3: rewrite history, they're still the author, but you're the committer.
Speaker 3: So you can get kind of mixed identities in it
Speaker 3: that way. But otherwise you've got to use what abstractions
Speaker 3: and additions other companies put on top of it.
Speaker 5: Yeah, it's pretty interesting. I guess you just had to assume. Okay,
Speaker 5: no one ever works alone. They're always pairing, so both
Speaker 5: people get credit or whatever.
Speaker 2: Yeah.
Speaker 3: I mean the thing about the way that I look
Speaker 3: at like someone getting credit for like an individual getting
Speaker 3: credit for a PR for a commit or something like that.
Speaker 3: I think it makes sense when the individual's looking at
Speaker 3: their own data. But from a team perspective, if the
Speaker 3: group is getting it done well together, then I think
Speaker 3: that's the main thing that matters. And if there's someone
Speaker 3: that's not like pulling their weight or there there is
Speaker 3: a performance problem with the individual, you're going to be
Speaker 3: able to know that without looking at the stats here,
Speaker 3: Like I'm sure we've all experienced that over the years,
Speaker 3: and I've done that personally in years ago. I got
Speaker 3: a tool that did like the stack ranking based on
Speaker 3: commits and all that stuff, basically just to prove what
Speaker 3: I already knew and that I as the manager, needed
Speaker 3: to let this person go because it wasn't a good
Speaker 3: fit for the team, and like the data that I
Speaker 3: pulled in that that was really just a crutch, like
Speaker 3: I already knew. I was just I didn't feel confident
Speaker 3: in myself as a manager at that point to do it.
Speaker 3: The data didn't really help it. And then actually the team,
Speaker 3: knowing that that tool was in place and that I
Speaker 3: had access to it, and like no one else did
Speaker 3: because that's the way the tool was set up, they
Speaker 3: actually really really didn't like it, and we kicked it
Speaker 3: out after two months. So there's a there's a trust
Speaker 3: factor there, and in a transparency that with a responsible
Speaker 3: and well put together team, you don't really need to
Speaker 3: hide this stuff. When it's abstracted to the team level,
Speaker 3: everyone can benefit from it, so there's no point in
Speaker 3: hiding it. So I think as long as you stick
Speaker 3: with the individual data belongs to the individual and team
Speaker 3: to the team, then it all works out pretty well there.
Speaker 1: So one thing that I'm wondering about then, is so
Speaker 1: let's say that we have this aggregated team data, right,
Speaker 1: we know how the team's doing. We can kind of
Speaker 1: see how the team flows, how things generally work. I mean,
Speaker 1: what do we do with it? Do we just try
Speaker 1: different things to see what makes it better? Or will
Speaker 1: actually give us indicators of what to try to make
Speaker 1: these better?
Speaker 3: Yeah, that's always the big question, Like, Okay, now I
Speaker 3: have data, I can see stuff, what do I do?
Speaker 3: Because that's always the point of the data is to
Speaker 3: get something out of it, not just to see it.
Speaker 3: So there's particular things that we show, like your code
Speaker 3: time to meeting time ratios, which generally for your development team,
Speaker 3: you want them to probably be coding more.
Speaker 2: Than meeting and please yes.
Speaker 3: Yeah, so there's specific things that you can do there
Speaker 3: and we'll find out when you as an individual. And
Speaker 3: then also your team has their kind of peak hours
Speaker 3: in the day, and then you can use our tool
Speaker 3: to block out the calendars for everyone during that peak
Speaker 3: time so that no meetings can get put there, so
Speaker 3: it's just protected code time on everyone's calendar, so that
Speaker 3: you've got that set aside where you know that people
Speaker 3: are generally at their peak productivity and their peak output,
Speaker 3: So that's one thing to do is just protect that time.
Speaker 3: Using the flow mode tool in the extensions gets you
Speaker 3: to block out notifications and distractions whenever you are in
Speaker 3: the zone, and we're actually coming out very soon experimenting
Speaker 3: with it internally where we can detect when you're about
Speaker 3: to get into what we call a flow session. This
Speaker 3: is a high productivity, high focus section of coding, and
Speaker 3: automatically enable it so your computer will just react to
Speaker 3: what you're doing and start blocking out notifications and put
Speaker 3: you into flow mode whenever you ramp up into it,
Speaker 3: so that you don't get that ping right at the
Speaker 3: time that you're right into it. So that's something that's
Speaker 3: really interesting.
Speaker 2: Right now.
Speaker 3: It's a button click, so you click that and it
Speaker 3: does it. So those are things that you can do.
Speaker 3: And then once you have the data and you're seeing
Speaker 3: trends over time, that's when you can actually start to
Speaker 3: do experiments internally with your team to see what does
Speaker 3: optimize it and when you break down like the lead
Speaker 3: time for code into the different sections of here's the
Speaker 3: input time that it takes, here's the full request review time,
Speaker 3: and then how long does it take from there to
Speaker 3: get merged into the default branch. You can start to
Speaker 3: look at the different sections of the cycle and say, Okay,
Speaker 3: this part is taking too long, and you can hone
Speaker 3: in on where as a system of processes you've got
Speaker 3: something a little bit awry. And then you can really
Speaker 3: hone in, Okay, why reviews taking so long, which is
Speaker 3: a common complaint, or from the time that I open
Speaker 3: the PR to the time it's first reviewed it takes
Speaker 3: this much time, or once it's reviewed it's still not
Speaker 3: getting merged for two days for some reason, So like
Speaker 3: what's going on there? So you can start to really
Speaker 3: hone in on different behaviors that are adding unnecessary delay
Speaker 3: into the process and watch what happens as the behaviors change.
Speaker 2: So there's a lot of really cool stuff that.
Speaker 3: You can start to do once you just see the
Speaker 3: data and then have a few little tools there to
Speaker 3: start to control the environment around it.
Speaker 4: All Right, that's pretty cool being able to block out
Speaker 4: your colleagues of a click if only if only I
Speaker 4: have that work today?
Speaker 2: Is there an API? Not yet?
Speaker 3: I know, we're we're working on automating some of the
Speaker 3: things around flow mode to give you a webhook URL
Speaker 3: so you click that and you can start to control
Speaker 3: other stuff that you want to do. So you could
Speaker 3: send that through zaper connect it to all sorts of things.
Speaker 3: We actually have someone one of our people in our
Speaker 3: community who automated his entire room whenever he entered flow mode,
Speaker 3: so he would click the button, it would do the
Speaker 3: stuff that we automated it to do, block out notifications
Speaker 3: at time of the calendar, and then he would have
Speaker 3: it set his phones to silent mode, and he had
Speaker 3: a smart bulb in his room and it turned it
Speaker 3: purple and dimmed the lights because and it also whenever
Speaker 3: you do it, it puts a purple icon in your slack
Speaker 3: so that people know that you're coding. And so he
Speaker 3: automated his entire room to put himself into flow mode
Speaker 3: with that, so that there's a there's a lot that
Speaker 3: you can do from that, and so we're excited about
Speaker 3: building that out as well.
Speaker 2: Yes, API comes in.
Speaker 3: We have reports functions so you can export your data
Speaker 3: across you know, different projects and different timeframes and things
Speaker 3: like that, which is actually helpful if you're on a
Speaker 3: if you're a consultant or you work for a consultancy
Speaker 3: and you need to publish hours or time spent on
Speaker 3: stuff for invoices, you can start to do that as well,
Speaker 3: automatically without clicking a button to start and stop timers.
Speaker 4: So this is this is operating off a Visual Studio book,
Speaker 4: is it.
Speaker 3: So we've got extensions for vs code, Visual Studio, Intelligent, Sublime,
Speaker 3: Atom and Eclipse. No VIM, we used to have it
Speaker 3: a long time ago, and well we'll probably bring that back.
Speaker 3: And so many people use VEM and Emacs, so no.
Speaker 2: Keep it out. That'll be my excuse. I'd be BIB
Speaker 2: doesn't work, BIB.
Speaker 3: You know, as far as we can see from installs,
Speaker 3: I mean, vs code is just taking the market. Intelligence
Speaker 3: is still there as as the second place, but vs
Speaker 3: code by far is the most popular one that we see.
Speaker 3: Oh yeah, I think we we've got a bit of
Speaker 3: a on our website and marketing. We've got a bit
Speaker 3: of a vs code sort of bent to everything. So
Speaker 3: it's no surprise that it's our biggest one. But it's
Speaker 3: like eighty nine percent of installs is through that one
Speaker 3: versus anything else.
Speaker 2: Scary.
Speaker 5: Yeah, back to the light bulb thing, I don't know
Speaker 5: how it would feel about having a little light bulb
Speaker 5: also measure my efficiency. So like if I'm typing a
Speaker 5: lot of code, do really good, then all the lights
Speaker 5: turn green, I start slowing down and things go to
Speaker 5: like an angry red. I just I don't know how
Speaker 5: I would like that.
Speaker 4: Like a listener, Davi has just made his back rid
Speaker 4: of his room go green and red in synchronicity with
Speaker 4: what he was saying, I was very impressive.
Speaker 5: Yeah, that's automation green and it just turns green. I'm joking.
Speaker 5: I have a stream deck in front of me.
Speaker 2: Yeah, I mean I suppose you could do that if
Speaker 2: you wanted to. I wouldn't recommend it.
Speaker 3: Like if you're fluctuating it up and downs, probably distracting,
Speaker 3: but just going.
Speaker 5: In stress level, Yeah, like it's red, it's red, I'm
Speaker 5: not doing good.
Speaker 3: Oh no, get it back to green. Yeah, that's that's
Speaker 3: it doesn't actually help, but going.
Speaker 4: Do your lights go red? When your tests go red?
Speaker 4: They what tests?
Speaker 1: So most of the stuff you're talking about here is
Speaker 1: stuff that I guess seems pretty common sense to most developers, right,
Speaker 1: you know, you're coding to meeting time. Maybe your your music.
Speaker 1: Some music's going to help you get into flow. Others won't,
Speaker 1: protecting kind of your peak times. A lot of this
Speaker 1: stuff makes a lot of sense. Are there any counterintuitive
Speaker 1: ideas around productivity that people kind of get hung up on?
Speaker 1: It's like your data is telling you one thing, and
Speaker 1: people's intuition will tell them something else.
Speaker 3: Well, I think there's two things there. There's some things
Speaker 3: that are as as they escalate, they don't go linear,
Speaker 3: they go exponential.
Speaker 2: That's pretty interesting. And there's some data.
Speaker 3: That we've got that that disproves like common held beliefs
Speaker 3: about how developers work, Like if you watch television or
Speaker 3: movies about developers, they'll be sitting there all day and
Speaker 3: all night days on end, coding constantly.
Speaker 1: And yeah that's me. Yeah, oh wait wait, not exactly
Speaker 1: me too.
Speaker 2: Yeah.
Speaker 3: Or you're like you're Hugh Jackman and your guzzling wine
Speaker 3: while creating the world's best worm or whatever it is
Speaker 3: that he was doing in a three D model on
Speaker 3: twelve screens. That's the image that people have, whether it's
Speaker 3: like the crazy graphics or not. That we're there all
Speaker 3: the time doing it, and we do work long hours,
Speaker 3: which you can see the code day lengths, especially as
Speaker 3: releases come up, it stretches to like twelve thirteen hours,
Speaker 3: meaning like from the first keystroke to the last key
Speaker 3: stroke of the day that long. But the amount of
Speaker 3: active code time cumulative through the day on average is
Speaker 3: under two hours. So the amount of focused editing time
Speaker 3: that people have on average is less than two hours
Speaker 3: a day, and a lot of times a lot less
Speaker 3: than two hours a day. And if you break it
Speaker 3: down into whether that's at work or at home, more
Speaker 3: than half of it is, say, outside of normal working hours.
Speaker 3: So the amount of distractions and other stuff that we
Speaker 3: do but instead of code is pretty big. That we
Speaker 3: push into the nights and weekends to get a lot
Speaker 3: of our work done because that's when we can have
Speaker 3: time to focus, which is why Saturday is the biggest
Speaker 3: focused day that we see. And I think that's a
Speaker 3: travesty unless your normal working day is Saturday.
Speaker 5: And I think with this whole past year in the pandemic,
Speaker 5: a lot of companies moving to a work from home,
Speaker 5: especially if you are on a computer a lot, and
Speaker 5: so now where your recreational area used to be is
Speaker 5: now also your work area. I found having a actual
Speaker 5: separate place where I do my work and where I
Speaker 5: do my relaxation is very important. So I will never
Speaker 5: take my laptop out into the den and watch TV
Speaker 5: while I'm working because to me then that's very distracting,
Speaker 5: or when I'm supposed to be watching TV, I would
Speaker 5: be working. So I think having you know, if you're able,
Speaker 5: if you do have a living space where you can
Speaker 5: set aside, even just a small corner to where when
Speaker 5: you sit there, you know that you are focusing on work,
Speaker 5: I think can also help keep you in a mental
Speaker 5: state that you don't always feel like you're working because
Speaker 5: you're not in that one place where you do your work.
Speaker 5: And I think that's mainly when you were talking about
Speaker 5: working for a employer, not just yourself, because you have
Speaker 5: the certain level of expectations there. But having that separation
Speaker 5: of concern of relaxation and work area space I think
Speaker 5: needs to be a physical boundary. If you have trouble
Speaker 5: with that.
Speaker 2: Yeah, I agree. I think that's huge.
Speaker 3: And one of the things that we see is we've
Speaker 3: looked at different cohorts, different kind of behavior patterns that
Speaker 3: we see and one of the best performing cohorts in
Speaker 3: terms of overall output, which is kind of a crude measurement,
Speaker 3: but that's the meta we're going with. Is those that
Speaker 3: perform typically within working hours, consistently throughout the week and
Speaker 3: are less sort of spiky in their activity like pulling
Speaker 3: an all nighter and those sorts of things. The people
Speaker 3: that work consistently five days during normal working hours and
Speaker 3: hardly ever miss at eight those are the ones that
Speaker 3: have the highest what we call velocity scores, and which
Speaker 3: is like a oh man, I'm going to forget the name.
Speaker 3: It's principal component analysis doing a vector projection thing. It's
Speaker 3: a machine learning thing that my data scientist has told
Speaker 3: me several times what it is, and that's that's all
Speaker 3: the best I've got right now. But basically, it's a
Speaker 3: it's a culmination of a bunch of inputs into a
Speaker 3: score and that But anyway, that cohorative users has generally
Speaker 3: the highest average score on that set of inputs because
Speaker 3: they're consistent. They don't go over a bunch and work crazy,
Speaker 3: crazy hours because then you get too tired and you
Speaker 3: can't like your next day suffers a lot, which we
Speaker 3: see in the data as well. I can see that
Speaker 3: in my own data because I still do that sometimes.
Speaker 3: Or I'll go to like two am or something like that,
Speaker 3: and then the next day is just awful, and the
Speaker 3: second day after that kind of recovers and then I'm
Speaker 3: back to my normal. So I'm like missing out on
Speaker 3: two days in exchange for a few extra hours at night.
Speaker 2: Not the best exchange.
Speaker 3: So you know, there is that separation of Okay, work
Speaker 3: time needs to happen at in a set of time,
Speaker 3: and if you can in a place and then separate
Speaker 3: that from everything else. I actually just switched out my
Speaker 3: laptop for a Mac Mini desktop because I don't ever
Speaker 3: work anywhere else except for in my office, so it's
Speaker 3: non mobile now. And I guess I have my phone,
Speaker 3: but you know, at least setting up some boundaries there.
Speaker 3: And I think, yeah, that's an important thing to to see.
Speaker 2: And it also.
Speaker 3: Expresses through the data that we have. And I was
Speaker 3: going to say, the other thing that was interesting in
Speaker 3: our data is not as obvious is some of the
Speaker 3: patterns that we see that don't grow at a linear
Speaker 3: pace but go exponential. Is with pull request review times.
Speaker 3: If you look at how long it takes for a
Speaker 3: pull request to get reviewed. The time, as you would guess,
Speaker 3: increases as the size of the PR in terms of
Speaker 3: lines of code, like how many changes there are increases,
Speaker 3: So from one to two hundred it's certain value, from
Speaker 3: two to five it's a slightly bigger value. But when
Speaker 3: it goes above five hundred lines, the time to review
Speaker 3: grows ten x in one jump. So there's some particular
Speaker 3: inflection points in the size of code going through the
Speaker 3: pipeline that start to take an inordinate amount of time
Speaker 3: to get through the pipeline because the processing of it
Speaker 3: is so much harder, like as a person to go
Speaker 3: and review, and the complex of it grows by so much.
Speaker 3: So there's certain kind of base rules that you can
Speaker 3: start to find out at your organization by seeing the
Speaker 3: state of like we're good in this space. So if
Speaker 3: you can keep your prs and change sets below a
Speaker 3: certain amount, they'll generally flow faster. And the more that
Speaker 3: you have these like smoother flowing chunks of changes going through,
Speaker 3: the better cumulative overall you're going to do is your
Speaker 3: production throughput at the end. So there's a lot of
Speaker 3: really interesting things there that you can see once you
Speaker 3: have this data, because not everything's linear. Most everything that
Speaker 3: we see follows a power curve.
Speaker 5: It's funny because I'm just imagining a torque curve because
Speaker 5: so before we started the top we were talking about
Speaker 5: cars and performance and stuff. So I'm seeing it as
Speaker 5: a torque curve where the y axis is the amount
Speaker 5: of time required to complete the pull requests, and the
Speaker 5: x axis is the number of lines of code. If
Speaker 5: you've ever seen a torque curve, it will go up significantly,
Speaker 5: but then it kind of levels off and then it
Speaker 5: has a steep drop. So I think that's more realistic
Speaker 5: to the code reviews I've seen, where it follows a
Speaker 5: certain amount of time increases as the number of lines increase,
Speaker 5: but you get to a point where the amount of
Speaker 5: time for really large pull requests just it's almost instantaneous.
Speaker 2: Yeah. No, actually that is express there. I was going
Speaker 2: to say that that.
Speaker 3: When you get these giant ones people whatever, it's probably
Speaker 3: fine click and like that's probably not great for the
Speaker 3: end result as well.
Speaker 1: No, I can't see why that would be a problem
Speaker 1: at all. Yeah, I wish my code. I wish people
Speaker 1: would review my prs that way. Oh, it's shocked. Yeah,
Speaker 1: he always reads good stuff done. That's always always anyway.
Speaker 1: I did want to ask another question though about your
Speaker 1: when you were talking about how people generally get like
Speaker 1: two hours of editing slash code time per day. Does
Speaker 1: that mean that the other six hours is like mental
Speaker 1: time or stack overflow time or Google time, or is
Speaker 1: that like realistically how productive we are.
Speaker 3: It's the time that's captured there is the kind of
Speaker 3: the culmination of whatever research you're doing there. So if
Speaker 3: you're on stack overflow and you're researching how to solve
Speaker 3: a problem or reading the docs, if that's what you do.
Speaker 2: I have some friends that do that, then going to
Speaker 2: be investing time in there.
Speaker 3: And then the output of that is your active code
Speaker 3: time where you figured it out and you've made the
Speaker 3: edits and throughte the tests and so it's it's kind
Speaker 3: of a distilled set of time of everything else that
Speaker 3: you've put into it. But we do track other things
Speaker 3: that are going on during the day, like meeting time.
Speaker 3: In general, developers meet thirty or forty percent more the
Speaker 3: day then they have active code time, So that's a
Speaker 3: big other portion of your day. And then we're starting
Speaker 3: to track slack data as well, so we'll be able
Speaker 3: to see how much time is being spent in that
Speaker 3: as well as how much does that help or hurt
Speaker 3: your individual productivity. Like if you have a question and
Speaker 3: you get it answered via slack really quickly, and then
Speaker 3: you have a productive session because you got that answered,
Speaker 3: or you could be coding, and then you get a
Speaker 3: bunch of unrelated Slack messages that pulls your attention away
Speaker 3: and it ruins your session. So there's positives and negatives
Speaker 3: that we can start to see from that, and then
Speaker 3: of course that's another big portion of the days communication
Speaker 3: and collaboration through that. But yeah, so it's hard to
Speaker 3: say whether that two hours is a good thing or
Speaker 3: a bad thing.
Speaker 2: We're just saying that's what it is.
Speaker 3: And it's interesting that that's what the number is versus
Speaker 3: six hours, eight hours, which is what a lot of
Speaker 3: people believe about developers.
Speaker 4: I kind of I think I'd rather be Hugh Chackman, really,
Speaker 4: wouldn't you do it? At nine to five? I think
Speaker 4: I think I'd rather be there. This is this is
Speaker 4: the image I have at myself. Three am cigarette and
Speaker 4: one hand mixed drink and the other maybe two keyboards
Speaker 4: and a laptop top left. I mean, criikee. Now that,
Speaker 4: now that I've learned that sensible office hours the key
Speaker 4: to programming greatness, so I kind of reconsidering my career.
Speaker 1: Really, those twelve screens, I'm jealous, But then I also
Speaker 1: realized that I'd probably only use like three of them maximum,
Speaker 1: and probably only two of them regularly.
Speaker 4: So mm hmm, I'm going to become rich and famous,
Speaker 4: rich and more famous after I create a YouTube plug
Speaker 4: in for vs code that enters random keystrokes.
Speaker 2: There you go, okay.
Speaker 1: Side note, so on my phone buzzers and gives me
Speaker 1: the option of typing on the iPhone keyboard whenever one
Speaker 1: of my kids does a search on any of the
Speaker 1: apps on the Apple TV. And it's pretty fun to
Speaker 1: be sitting in the back of the room when my
Speaker 1: phone buzzes and I pull it up and start typing
Speaker 1: their name in there while they're trying to type in
Speaker 1: the name of the show they're trying to find, and
Speaker 1: then watch them kind of go.
Speaker 2: Anyway. I know.
Speaker 5: I mess with my kids like that all the time.
Speaker 5: I'll just walk up to my wife's van and say, hey, Siri,
Speaker 5: start the car, and in my pocket I'm hitting like
Speaker 5: the auto start button on the remote, or hey, sirih
Speaker 5: open up the garage door and I'm just hitting the
Speaker 5: garage door button on our remote. Our kids, you know,
Speaker 5: some of them sometimes they believe it, but not often.
Speaker 1: Nice, Well, anything else it needs, go ahead? No, I
Speaker 1: was just gonna move us along, but go ahead.
Speaker 4: It needs to reap the API, it needs, it needs
Speaker 4: some kind of ultimation. Left me to to it. I
Speaker 4: definitely definitely won't subvert it to my own personal game,
Speaker 4: I promise.
Speaker 2: Okay, good to know, all right, Mason.
Speaker 1: Are there other things that we should be aware of
Speaker 1: or talk about here before we go to picks?
Speaker 2: Well, I mean just to bring it back around to
Speaker 2: Ruby stuff since we're on the Ruvie podcast. The new
Speaker 2: version we just launched last week is now a Ruby
Speaker 2: on Rails app, so it actually there is Ruby involved
Speaker 2: in this. Nice.
Speaker 3: Yeah, it was no JS back end with a React
Speaker 3: frun end before boo. And you know, this is something
Speaker 3: that I'm going to be publishing soon on our blog.
Speaker 3: But the we have of course productivity metrics between for
Speaker 3: our own team, between the different systems that we've been
Speaker 3: working on, so I'll be able to do a compare
Speaker 3: and contrast on our own team's productivity using Node and
Speaker 3: React versus Ruby on rails, so like just more or
Speaker 3: fodder for the Internet to argue about shots five mm hmm.
Speaker 1: Yeah, I think some people are going to be Yeah,
Speaker 1: our biggest show is a JavaScript show, and they have
Speaker 1: feels about whenever I bring up you know, I just
Speaker 1: get more done in rails.
Speaker 3: Yeah, I mean, I think that's something that we'll be
Speaker 3: starting a series on this of the languages that we see,
Speaker 3: the frameworks that we see, the different technology pieces that
Speaker 3: our global users have installed, that we can see the
Speaker 3: differences in their productivity mestrics with and without those things.
Speaker 3: So there'll be plenty of interesting conversation about what's the
Speaker 3: best JavaScript framework.
Speaker 1: The newest ones always always I am curious how far
Speaker 1: down the rabbit hole you went on the technology, you know,
Speaker 1: just to switch gears there right, did you? Is it
Speaker 1: straight up just rails server rendered and that's it, or
Speaker 1: using like stimulus, hot wire, stumulus reflocks, any of that stuff.
Speaker 3: We're using stimulus and hot wire for all of our
Speaker 3: graphs and everything. So whenever you load the dashboard, all
Speaker 3: the data is getting pulled a sync and loaded through HTML.
Speaker 3: Partials that show up through stimulus and hot wire the
Speaker 3: whole thing. And we also have a feature where like
Speaker 3: you connect your GitHub and it pulls the nast ninety
Speaker 3: days of your history so you can see stats on that.
Speaker 3: And it's got little loading bars. We wrote zero JavaScript
Speaker 3: for the whole thing, and it's a completely animated loading
Speaker 3: bar that's in sync with all the data that's being
Speaker 3: pulled through. I had my usually he my engineer is.
Speaker 2: His name's Daniel. See my injurer. His name's Daniel, his person.
Speaker 3: He hates writing front end code, but I got him
Speaker 3: to do this because he didn't have to write any
Speaker 3: JavaScript and he was like, I'm a full stack developer now,
Speaker 3: and he was really happy about it.
Speaker 2: Is nice, very JavaScript. Too much JavaScript.
Speaker 1: Yeah, we've been playing the just basic stimulus turbolinks, make
Speaker 1: a back end request, replace HTML kind of stuff and
Speaker 1: boy that's enough sometimes.
Speaker 3: Yeah, I mean, once getting into it was a little bit.
Speaker 3: You've got to kind of shift how you think about
Speaker 3: building it. But once you do that, it's made. Developing
Speaker 3: all of the graphs and everything, and like the first
Speaker 3: paint on load is really really fast because all the
Speaker 3: heavy stuff is coming in async. And it's because it's
Speaker 3: just replacing the existing HTML. It's not shifting any of
Speaker 3: the structure around. It's it's come along really nicely. I'm
Speaker 3: really liking it.
Speaker 2: Cool.
Speaker 1: Well, maybe we'll have to have you back on and
Speaker 1: talk about re architecting off of node non to rails.
Speaker 3: Yeah, that'd be fun. I'll bring our metrics with Mesta.
Speaker 3: See what it looks like. Sounds good? Right, Well, let's
Speaker 3: go ahead and jump over to some picks. Do some
Speaker 3: shout outs, Luke, do you want to get us rolling?
Speaker 4: I've been trying to use the rubyest app on the iPhone.
Speaker 2: Do you have this app? The rubyest app?
Speaker 4: So this is oh man, I've forgoten who wrote it.
Speaker 4: That's one of the pretty sure it's one of Japanese
Speaker 4: pads that everyone knows. Anyway, this is Ruby on your
Speaker 4: iPhone with API hooks into things like Sirius, so you
Speaker 4: can kind of automate stuff from your from your iPhone
Speaker 4: and you can also kind of rite Ruby on the iPhone. Right,
Speaker 4: it's using the m ruby interpreter, so that's how they've
Speaker 4: got it in there. They've just kind of linked the
Speaker 4: whole of m ruby into the app. And I've getting
Speaker 4: absolutely nowhere with it. I I've not got it to
Speaker 4: do any and it's me. It's not the app, it's
Speaker 4: definitely me. But it's a fantastic thing to play with
Speaker 4: when you're when you're wedding for stuff to happen. So
Speaker 4: that's my pick for this week. It is the Rubyest app.
Speaker 4: It is free on the app Store.
Speaker 2: Awesome. I'm gonta have to go play with that, Dave,
Speaker 2: what about?
Speaker 5: So I just have one pick. And the backstory for
Speaker 5: it is someone hit our mailbox and broke it and
Speaker 5: it was an aluminum bracket that was holding the actual
Speaker 5: mailbox up and it just kind of shattered in half.
Speaker 5: So what I ended up doing was making a trip
Speaker 5: to home depot and I got some aluminum solder stuff
Speaker 5: that was going to try to solder it. But I thought,
Speaker 5: you know, I've never soldered aluminum before. I don't know
Speaker 5: how well that's going to work, and so the alternative
Speaker 5: is to use an epoxy. So I got some JB
Speaker 5: weld steal epoxy and this stuff. I think the mailbox
Speaker 5: mount bracket is stronger than it was before. Like I
Speaker 5: tried breaking it off. After I let it cure for
Speaker 5: a few days, and I just I can't even make
Speaker 5: any like bins or anything to it. So JB weld
Speaker 5: epoxy is amazing and it's really cheap for how much
Speaker 5: can you need and stuff?
Speaker 1: So yeah, I use that to basically glue anything that
Speaker 1: super glue won't do. Super glue is good for like plastic.
Speaker 1: JB Weld would glue pretty much anything. It's amazing stuff.
Speaker 1: And it comes in two bottles and you just mix
Speaker 1: it and then you smear it where you want and
Speaker 1: because stuff, it's amazing stuff.
Speaker 2: Love that stuff. Yeah, did you have any other picks? Then?
Speaker 2: Mean to cut off? All right, I'm going to jump
Speaker 2: out here with a few picks.
Speaker 1: The first one is and I don't It's funny because
Speaker 1: I don't remember what I picked week tw week, and
Speaker 1: so I'm sitting here going do I pick that. I'm
Speaker 1: just finishing a book on Audible. It's called Fanatical Prospecting.
Speaker 1: It's a book about sales. So if you're getting into sales,
Speaker 1: and I'm getting way into sales just because of the
Speaker 1: dev influencers accelerator, really really digging that. It's a six
Speaker 1: hour book on Audible, and I'm really it's it's been
Speaker 1: really really helpful, So I'm enjoying that. Also been enjoying
Speaker 1: the book Who Not How by Benjamin Hardy and Dan Sullivan,
Speaker 1: which is also kind of a business slash management book.
Speaker 1: So if you're looking at how to do something, a
Speaker 1: lot of times you're better off fighting somebody who who
Speaker 1: can do that instead and fringing up your time and effort.
Speaker 1: A lot of times you're not gonna find somebody who
Speaker 1: can do it one hundred percent as well as you, right,
Speaker 1: But if you can find somebody who can do it
Speaker 1: eighty percent as well as you, and you can free
Speaker 1: up that time, you're better off. And so I've been
Speaker 1: enjoying that as well. We watched a movie with my
Speaker 1: kids the other day, and I've been in it was
Speaker 1: funny because they were all like really, but my middle
Speaker 1: daughter she watched it like every other song that came on,
Speaker 1: she's like, I didn't know that song was from this movie.
Speaker 2: It was Fiddler on the Roof that was a bitch
Speaker 2: man yep. So it was pretty funny.
Speaker 1: Not really her style of movie, but she really loves
Speaker 1: show tunes and so she'll have the echo play show
Speaker 1: tunes over and over and over again, and so yeah,
Speaker 1: she didn't realize that like a bunch of the songs
Speaker 1: she enjoyed were from that particular movie. So that was
Speaker 1: pretty funny to have her go, oh, that's from this,
Speaker 1: like over and over and over again through the whole thing.
Speaker 2: So yeah, really funny stuff.
Speaker 1: And then the last pick I have and I probably
Speaker 1: picked this before, but I've been diving into more and
Speaker 1: more automation stuff with Monday dot Com. We are actually
Speaker 1: moving all of our production processes for devchat dot tv,
Speaker 1: for the podcast over to Monday dot com, and like
Speaker 1: literally right now, Mikayla is putting all of the upcoming
Speaker 1: episodes into it so that the automation stuff will happen,
Speaker 1: So emails will go out when somebody schedules a new episode,
Speaker 1: it'll go out to the guest and let them know, Hey,
Speaker 1: we're going to send an email in a couple of
Speaker 1: days to the hosts so the host can put questions in,
Speaker 1: but anything you want them to prep on beforehand. When
Speaker 1: it goes through the whole process, after we record it,
Speaker 1: the link to the media gets put in, then it
Speaker 1: notifies the editor. The editor gets done, he puts his
Speaker 1: links in, and it notifies the show notes people their
Speaker 1: stuff gets put in show notes. People may be the hosts,
Speaker 1: it may be somebody else. It just kind of depends
Speaker 1: on the show. And then when it's all ready to go,
Speaker 1: then it's tells somebody to schedule it, and then after
Speaker 1: it's scheduled, tell somebody to post on social.
Speaker 2: Media, and yeah, the whole nine yards.
Speaker 1: It's just it's all managed in there, notifies people through
Speaker 1: email and discord. Some of that had to happen through
Speaker 1: webhooks with Zapier, which is the other pick. But the
Speaker 1: nice thing about Monday is that it gives you a
Speaker 1: visual look at where everything's at and you can actually
Speaker 1: build dashboards around your processes. So it's been really nice.
Speaker 1: I'm still working out some of the kinks. I hired
Speaker 1: somebody speaking of who not how I hired somebody to
Speaker 1: help me set all this up. So it's been really
Speaker 1: really handy, and we're going to be moving ahead. I
Speaker 1: am trying to figure out how to get the hosts
Speaker 1: in there without having to pay for a whole bunch
Speaker 1: of extra accounts, and I think I can add viewers
Speaker 1: without having to pay for them, So that's probably the
Speaker 1: way we're going to go.
Speaker 2: And then if they need something change then they can
Speaker 2: just discuss the game.
Speaker 1: I think, yeah, I think I think you all can
Speaker 1: just bug McKayla and she can add the stuff. But anyway,
Speaker 1: that's kind of what we're looking at right now, and
Speaker 1: it's it's just been this process to get it all in,
Speaker 1: but it's it's been really slick, Like once we got
Speaker 1: some of this stuff together, it's it's been really really slick.
Speaker 2: So I've been really happy with that as as a tool.
Speaker 1: So I'm going to pick all of those things, and yeah,
Speaker 1: that's what I got, Mason, what are you?
Speaker 2: What are your picks?
Speaker 3: Yeah, so I didn't know that we could pick random
Speaker 3: physical objects like JB weld as well, so I'll have
Speaker 3: to today. First one in the tech world, materialized dB
Speaker 3: is a real time streaming database that does transfer informations
Speaker 3: with automatically updating materialized views. Super cool and experimenting with
Speaker 3: our data streams with that now and really liking what
Speaker 3: I see, super super snappy, and you can get real
Speaker 3: time results from massive amounts of data in milliseconds, so
Speaker 3: it's it's really cool.
Speaker 2: And the other thing, which.
Speaker 3: Is a random physical object is darn tough socks. They're
Speaker 3: these wool socks made from somewhere in the Northeast and
Speaker 3: they have a lifetime guarantee. I love these things. I
Speaker 3: go hiking a lot of in like the mountain area
Speaker 3: of San Diego and go hiking a mountain, biking a lot,
Speaker 3: and they're the most comfortable socks in They last for
Speaker 3: years and years and years. I've got a pair that
Speaker 3: I've had for seven years now and they're like new.
Speaker 2: They're awesome. To check them out. Nice. One more question.
Speaker 1: If people want to check you out or check out
Speaker 1: software dot com, where do they find that stuff?
Speaker 2: Yeah, so software dot com it's a good place.
Speaker 3: We have a newsletter called Src that brings research that
Speaker 3: we find as well as news from across the tech world,
Speaker 3: and I typically post on LinkedIn. You can find me
Speaker 3: Mason mcleid on LinkedIn and that's where you'll see my posts.
Speaker 2: Awesome.
Speaker 1: All right, Well we'll go ahead and wrap up. Thanks
Speaker 1: for coming, Mason, thanks for having me big, thanks to
Speaker 1: our panelists. We'll go ahead and wrap up here until
Speaker 1: next time, folks.
Speaker 2: Max out