Most Productive Days of the Week for Developers – Rob Zuber, CircleCI

This is Techstrong tv. Hey guys, thanks for the thrill. We are here with Rob Zuber, the CT O for Circle ci, and we're talking about what are the most productive days for developers.

Turns out there's some math that helps us figure this out. Rob, welcome the show. Thanks for having me, Mike.

Good to be here. How do I know what the most productive days for developers are gonna be? I mean, is there some sort of, you know, secret algorithm somewhere that somebody put together?

Or is there some more rational way that's a little more obvious? Walk us through this a little bit. Yeah, I mean, it, we know, uh, based on everything that we see, so, uh, what we're looking at is the overall pool of everyone that's, you know, using Circle CI's platform and um, and the days that they're, you know, delivering software versus the days where they're delivering a little less.

It's not like it's off and on, but, you know, the, the days where we see the most activity and the most, uh, you know, the most code getting written, the most stuff going out to production, most pipelines being run. All right. So don't hold us in suspense.

What are those days? What do they look like? Or are they, you know, Mondays or are they Fridays or are they holidays?

Yeah, I mean, it's an interesting bland, it's, um, what we, the days that we saw pop out that felt interesting were Wednesdays and Fridays sort of amongst the, you know, there's a few specific days, um, and, and in particular across the summer. Um, and I think what's really interesting about that, I mean, I could name specific dates, but I don't think it's really gonna matter. I mean, that's just forecasting, but, um, you can find that information from us.

Um, I, I think what's interesting is I, we think of summer in particular as a time where, you know, things to get a little more quiet. People maybe do a little bit less, but to me that says something about that as an opportunity for folks to get things done, right? Like, I, here we are sitting in kind of early June, you know, I was at a conference yesterday, I've got a middle school graduation to go to today.

Like, there's a lot of stuff going on in people's lives. I think that sort of settles, um, as we head into this next part of the, of the, you know, the cycle of the sea seasons. And that's an opportunity for folks to, to maybe look a little bit more inward and get some things done.

And I think being prepared, you know, to your question of managers and why it matters, being prepared for that and giving people a little bit of that space, um, you know, where things have calmed down to really take advantage of that and, and get some stuff done, I think is a, is a great opportunity. I Don't know, have you looked into this, but do you think that there's any difference in the quality of the code that shows up on a Wednesday versus a Friday? Because, well, Friday is kind of like, you know, I'm rushing to get out the door, I'm going away for the weekend, and this is as good as it gets rougher now.

Y yeah, I mean, I, I think there might be a little bit of the element of, I really, you know, on a Friday afternoon and when I think of Fridays and summer, I'm thinking, oh, if I could get this done now, then, you know, I can take off a little bit early, beat the traffic, you know, whatever that, whatever that scenario might be. Um, um, but one of the nice things about, you know, CI software delivery pipelines is that I know I'm delivering something of quality, not just something that got the job done and out the door sort of thing. I mean, that's why you want to have this stuff in place.

Um, and so I think it's some combination of, you know, that maybe for the Fridays, it is the end of the week, but also they tend to be a little more quiet, right? Uh, people aren't, you know, setting up 3:00 PM meetings on Friday afternoons in the summer cuz they know there's gonna be a few people out already, whatever. So that is a great opportunity to get some things done to sort of like clean up the stuff that's been sitting on your list.

And so I think that's why we see a lot of that activity happening. I don't think it really turns into a, a quality degradation. So is there something I should be doing as a leader of a DevOps team knowing that these are the particular days where more code may be coming through the system?

How do I kinda adjust my processes to deal with, you know, what is a human condition? Yeah. I think again, acknowledging that there are period like that, that it's cyclical, right?

I mean that's really what we're seeing is, is, uh, productivity moving up and out and, and that's productivity in terms of, of development, right? I mean, engineers do different things throughout the course of the week and recognizing that, um, yes, we need to get together and do some planning. Yes, we need to get together and sort through, you know, longer term strategy, whatever it might be.

But really having those windows where folks can be productive, uh, from a development perspective. Like, okay, we have the plan now we need to go execute on the plan and having a stretch. I mean, you and I have talked before about sort of flow state and like really being in something.

And I think we see the result of that when, you know, when I look at the Wednesdays, one of the things that pops into mind is when I, most of the companies I know that happen, no meeting day happens to be Wednesday, right? So maybe there's some, some overlap there, which is just, you know, one, then I'm at my desk, not in a meeting doing some work, but two that long stretch, right? Can I create that long stretch versus the, oh, it's cool, we'll just have a 15 minute check in here and then one a little later here and one a little later there, which doesn't give that space to kind of really get into flow and, and get some things done.

So I think that's, that's more for the devel, the manager or developer team. And then if you're in DevOps, platform tooling, things like that, you know, probably if everyone's gonna be getting the best work done on, you know, on specific days, whether those Wednesdays, Fridays, it's probably, this is us looking at an aggregate, you know, your organization, you know your individual organization better than I do. If you know what those days are, those are probably not good times to have maintenance windows on your developer tools.

You know what I mean? Like, like don't do a bunch of upgrades on the days where people are really, you know, cranking. If you're trying to introduce new stuff, do it on days where there's gonna be, you know, capacity for interrupt and people can adapt to that sort of thing.

I mean, you might think of Friday actually as the day where, ah, not a lot of people are working. Not a lot of people are, you know, cranking. So this would be a good day for us to do a bunch, you know, a bunch of upgrades to tooling change our process, whatever that might be.

And those things are all going to be interrupting the folks that you're trying to really serve, right? So I think it is a good question about who's your customer, if you're that you know, that again, platform team DevOps, whatever organization you're in that's not doing direct customer delivery, and when are the good windows for you to be making changes, introducing new things, you know, obviously in service of that customer at some point, but if you're doing it when they're trying to get really locked in and get something out the door, then you're actually hurting them more than you're helping them. It does seem there's a lot more focus these days on developer productivity or is maybe there's always been that focus, but it feels like the noise level is certainly a lot higher.

Why do you think that is? Um, I think that we have, uh, well one, a lot of things have gotten more complex in terms of software delivery over the last, I mean, pick, pick a number of years because it's always going up. So, you know, uh, the way that we build systems, a lot more people are building distributed systems, which adds complexity.

A lot of us are, the tooling landscape is always changing more adoption of third party tools, third party libraries. So there's a lot more to know and understand potentially as a software engineer. And a lot of those things are sort of chipping away at our ability to just sit down, get in that, you know, we'll keep using flow state and just focus on delivery, right?

We talk about cognitive load overhead, there's just large organizations coordination. So all of that stuff has been detracting from our ability and I think it's made it, or our, yeah, I mean our ability to produce, right? So productivity and has made it more and more evident over time.

And then I would say in the last few years we've had so many other distractions that are not even the complexity of our system, you know, from pandemic to economic cycles, you know, whatever it's been. And each of those has impacted us. So we're finding that we're trying to take these concentrated periods of time and really get stuff done and we're less tolerant, I think of all the little things that take away from that.

I gotta go find this team and get them to do this thing for me because it's not self-serve. I don't understand this new library that someone put in place and I don't have the tools or the means to kind of figure that out. And so I think we're just, we've become a lot more aware of the cost of that.

Um, and then there, you know, in just, I mentioned economic cycles previously, like in, in an economic cycle where you're thinking, you know, less, let's just hire more people and more how can we actually really be productive with the folks that we have? Then that becomes even more pre predo or yeah, I guess more dominant in your, in your thinking, right? So I think all of those things continue to come together to tell us it matters.

Um, and I think we've also recognized that individual developers enjoy being productive, right? It's nice to focus not, not the like, oh, I can go, you know, 24 hours straight on like multiple cans of Red Bull, but if I'm not, if there aren't all these things getting in my way and I can just do the thing I'm trying to do, that's much more fulfilling for me as an engineer. So I think we've, we've learned a lot about what makes us productive and that it's actually, you know, healthy and fulfilling and all these things, again, to the point of delivering things of value, not, you know, you can look at productivity from a total number of hours of the day, which is not what we're talking about more from a, of the hours I'm putting in, are they really valuable or am I spinning in circles and wasting a bunch of time and constantly interrupting all those things.

And so, you know, I think we've become very aware of where the value is there, um, and we've seen what can have impact, right? We've, everything from what we were talking about here, just in terms of having the space and time to get focused and really get things done to, you know, DevOps platform teams, like different parts of the organization or different approaches, uh, to enabling me as the product engineer, let's say, to really focus on delivering value versus, yes, I'm building this front end for my customer, but I'm also trying to figure out how Kubernetes works and how to get a CI pipeline in place and just like I'm all over the place and nothing is done for me, which makes me very slow to get the thing done, which is the real value for the customer. Do you think this is slow on the pace of innovation?

Because, you know, a lot of times the developer may have a great idea, but then they'll sit there and say, well, you know, by the time I spun up the entire environment that I need to go do this thing, it's, you know, maybe I'll just sit on the couch as I was. Thanks. I, I think, yes, I don't know if it's as extreme as I'm just not going to do it, but I do think you see places where the overhead is daunting exactly as you describe it, you know, oh, this would be really great, but I can't even think about a reason about how to get that done.

And that's exactly the opposite of what you want. You know, we, we think about our mission as getting, you know, basically turning software delivery into an idea problem, not a, not a process problem. Like, if you can think of it, you can get it to your customers, right?

Because we're in the business of taking all of those intermediate pieces away. We can't take away everything. We can't, you know, solve your organizational structure problems or whatever you might have, but a big chunk of that is, you know, the underlying tooling, the consistent process to just get stuff out the door.

Um, and absolutely I think people, yes, they might, they might slow down or to your point, even reach that threshold where they say, yeah, this sounds like it would be really valuable, but the overhead to get it done is so high that I'll just, I'll do something that's simple, something that I know I can achieve versus the thing that actually is really gonna move the needle. Um, and so basically eliminating a lot of that, again, whether it's structural, whether it's the underlying tooling that you have in place, whether it's your sort of philosophy about how to deliver all of those things can impact, and when you get them right, then you absolutely accelerate the, the pace of innovation. Do You think there's a correlation between the concerns over developer productivity and the rise of platform engineering?

Are these two things kinda joined at the hip in some way? Uh, I believe so. I think, um, a bit, you know, to that earlier point of cognitive load and as an engineer trying to build something for customers, how much do I need to understand how many different systems do I need to work with?

A lot of what good platforms teams do is sort of push up that level and abstract away a lot of that complexity. That's not specifically related to the thing you're trying to do. It's all prerequisite, right?

I need to have these systems in place in order to deliver, but if I need to understand all of those as someone delivering end product to the customer, then it's gonna take me a lot more work. And then multiply that by how many teams we have in an organization, right? If ev like, if people in each of those teams are solving the same problems, then that's all energy and effort that's getting wasted.

That could be put into delivering value to customers. If one team at a platform layer can solve it for all of those other teams, then you're, you know, you're, you're having a significant impact on, on productivity. I think one of the greatest sort of challenges for platform teams at the moment, because it's a, it's like a new but not new concept, I guess.

I mean, we've, we've named a thing that lots of people were doing, um, but once we name it, lots more people try to do it, if that makes sense. Like, oh, okay, I see what they were doing. That makes sense to me.

Now let me go try to do it. But, um, I think we know how to have a platform team. I don't know if we know how to have a great platform team.

And one of the, the things that really stands out for me in that is, is understanding who your customer is, right? When your customer is another developer in the organization, and truly like from a product thinking sort of perspective, understanding what their needs are and, and delivering against those needs. I think as engineers, particularly engineers solving problems for other engineers, which is our business as well, it's easy to think I know exactly what they need and sort of skip past the, like, getting to a really clear problem statement, um, and focus on, you know, tooling or practices or whatever.

And I think it's really important within your organization to go sit with that customer and really understand where they're running into problems and figure out where you can have real value. Cuz I think your impact can be orders of magnitude to higher if you truly understand the problems of your organization versus these are generic, you know, capabilities that every platform team needs to have or however you wanna think about it. Um, do you think maybe we're too obsessed with tracking certain DevOps oriented metrics and not enough on the developer productivity side, and maybe we're either not measuring enough things or maybe just measuring the wrong things?

I think, well, engineering metrics are, uh, that's an entire episode and conversation of its own for sure. I, I think the, the best thing that you can do from an engineering or or developer productivity metric perspective is understand the highest level view of, um, what it means to be delivering value for your customers, right? And then figure out what useful proxies are for that.

And so talking about DevOps metrics, I'm sure you know, Dora metrics are sort of rolled up in that, which is a sign of, again, some productivity and some quality sort of countermeasure against that, right? Like, you know, your Friday afternoon question from before, like, are we delivering a lot but delivering it really poorly? Which interestingly, you know, lots of people are kind of afraid to deliver on Friday afternoon cause they really wanna leave and they're nervous about, you know, causing a problem.

But I think those high level metrics are, are good enough. And what you need to understand then as a leader, as a team member, wherever you might be inside an organization, is what does that tell us about us? And what is what are we doing that's causing that ch usually changes are more interesting than strict numbers, right?

And so I think when you try to get obsessive about ev like measuring every detail, then you get lost in the metrics. Whereas I think saying, okay, we know that good looks like this and when we're not good, now it's a conversation. Like I think that's what we've really learned through the process of agile, right?

Yes. We should see this kind of barometer is, I guess what I'm getting at from a, the door metrics perspective. Like, yes, we're delivering quickly and yes, it's good quality, okay, we're not delivering quickly.

There's no obvious fix to that. I can't tell you, if you came to me and said, my team isn't delivering as quickly as we used to, what should we do? My answer would be have a conversation like I, I don't know below that level, but there's so many possible causes that I think trying to instrument every single one of them, um, is gonna end up causing you, you know, more harm because then you're gonna obsess over every one of those metrics than good where you'd say, okay, we really understand our system, we understand our team and what makes us successful and what doesn't make us successful because one week it's going to be that we just had really bad understanding, or we totally misunderstood each other about what it was we were trying to build.

And so, you know, we got halfway through the process and then we had to start over, which is totally different from the next week when we didn't have the tool that we needed to achieve a thing or we're waiting on procurement of something. Like it could be any of those things, right? And I like, am I gonna say make sure you have measurements on your procurement turnaround and like level of understanding of your tickets and you would just end up in the sea of, um, of measurement.

It feels a little analogous to what we've learned about like SLOs and system metrics. I mean, if engineers listening, I think can appreciate it from that perspective, right? What's the impact on the customer?

Are they getting a great outcome right now? Are we delivering according to their expectations, then fantastic. I don't need to go look at, you know, what the disc read, right?

Speed on this particular, you know, system is right now I use all those measurements to debug when something is wrong, right? When that high level measure says, oh, it doesn't look like or whatever, we're not meeting the need, the expectations of our customers, right? Like, we're not responding in good time.

Okay, cool. That could be one of a million things. My skill as an engineer is to go figure out which of those things is causing the problem.

Yeah. Do you think that maybe AI will have some role in saving ourselves from all these metrics? I mean, can we just start surfacing in plain language soon?

You know, these are the four things that aren't going well. Uh, I think the role in discovery is pretty fascinating, um, particularly in complex systems, right? I think, you know, one of the things that AI does well is process a lot of information.

Um, you know, we use AI at a high level, like o obviously the big, the big talk right now is in generative ai. Um, so processing huge amounts of data, honestly, whether it's truly AI or somewhere in between, but like we've gotten better and better at processing data and we're getting even better at it daily at the moment. Um, I think absolutely surfacing information versus trying to say, oh, I need to go look at, you know, again, use the dashboard system analogy.

I need to go look at all of these metrics across all of these different systems versus something high level when the high level thing is bad saying, okay, what's, what's not like, where are the anomalies, right? What doesn't look normal right now would be a great question to be able to ask. And I do think that's, that's something we can hand off to a machine and get a response back to say, oh, this doesn't look like it did last week, sort of thing.

Versus clicking through dashboards or, you know, whatever. You might have to try to get there. Um, so if you're, if you are measuring, and I guess to, to kind of bring it to that, back to that point, it's useful to have measurements.

I don't know that it's important to look at every measurement all the time. It's useful to have that data and then yes, you could feed that data, you know, into I'll air quote ai because that's a pretty broad category of approaches, but you should be able to, to get help from machines, let's put it that way, to process that data. All right, folks, well, you heard it here.

At the end of the day, developers are people, they have habits and they have things that they like to do, and they might even have lives outside of application development. So maybe you just might wanna take a survey of them and see if they're happy or not. Hey, Rob, thanks for being on the show.

Thanks so much for having me. Great to chat as always. All Right, back to you guys in the.