Three Keys to Being a Productive Software Engineer

In this one-on-one episode of the Versioning Show, David and Tim look at what it means to be a productive software engineer. They discuss the key factors of relevance (keeping focused on what’s important), quality (making sure your code does what it needs to), and time (having the space to code without interruptions), as well as supportive cultures, reviewing code, avoiding (too many) meetings, flipping birds, and La-Z-Boys.

Show Notes

• #holidaycode hashtag from Episode 20
• Episode 26 with Azat Mardan
• Deep Work
• trigger habits, from Episode 17
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

you could define productivity as getting a lot of things done in a short amount of time, but that doesn’t seem to really encompass what being productive is all about, because I can do a lot of work and that work can be terrible.

---

you need to ensure that the work you’re doing is specifically relevant to a specific set of tasks.

---

a gigantic piece of good productivity is a culture that supports it. I can’t be productive at work if every time I’m pulled into a meeting, there’s no meeting agenda enforced. We all need support to be able to ensure that we’re productive. An unproductive organization does not yield productive individuals.

---

If you work for a company and you have a hard time getting things done, that could be an organizational problem, in which case, sitting here and trying to write down lessons for productivity is not going to be much of a help. What would make sense to do in that situation is talk to someone, talk to a higher-up.

---

if I’m focusing on being productive about the work that I’m doing, I’m going to invest in the quality side of the work. Being productive isn’t necessarily always about speed.

---

if what you’re doing is going to break the codebase and cause technical debt in the future, then in terms of the product that you’re building, it is not relevant to the product even if it is relevant to meeting a particular deadline.

---

in some situations, in some scenarios, it is simply not possible to be productive.

---

if you are forced to do an insane amount of quick work, in a very short amount of time, and that work that you’re doing is not going to be temporary, meaning there’s no one who is going to look after it to ensure that it is refactored or iterated, but it becomes cemented into your production application, that is more than likely a scenario in which it is impossible for you to be productive.

---

For me, the problem is that a lot of these meetings come up ad hoc, and they come up randomly, and they come up quickly, and they’re organized by somebody who doesn’t have the authority to organize the meetings.

---

I think a good meeting is something that will prevent ten other bad meetings.

---

Having uninterrupted time to work is what an engineer likes the most.

---

I recently made the decision to go on a social media fast, because I noticed that I had the tendency to interrupt my day with random little checks on Twitter and Facebook to see what was going on out there.

---

Of course, those open floor plan workspaces that are so popular these days, that is another issue for productivity for a lot of people.

Transcript

David:

Hey, what’s up everybody? This is M. David Green …

Tim:

… and this is Tim Evko …

David:

… and you’re listening to Episode 28 of Versioning Podcast.

Tim:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

David:

Today, Tim and I are going to be talking a little bit about productivity as an engineer — what it means, what it means to us, the things we’ve seen work, and the things that we’ve seen not work. So let’s go ahead and get this version started.

Tim:

David, we need a philosophical question to ask ourselves.

David:

I think a very good philosophical question is What does productivity mean?

Tim:

Oh, that is a good one. You know what, I was actually thinking about this before we got ready for the episode.

David:

Well, given that we agreed that we were going to do an episode on productivity, I’m glad you were giving it some thought.

Tim:

Hence being productive. I guess you could define productivity as getting a lot of things done in a short amount of time, but that doesn’t seem to really encompass what being productive is all about, because I can do a lot of work and that work can be terrible.

David:

Absolutely. Or you can do a lot of work that doesn’t really have any value, like the old joke about paying engineers by the number of lines of code that they write on a daily basis.

Tim:

Yeah that’s very true. Maybe we could say that being productive is about getting quality and relevant work done in the time period that you have allotted for yourself to complete it.

David:

That works for me. That gives us three factors to play with. We’ve got quality, we’ve got relevant and then we’ve got time factor.

Tim:

I’m trying to come up with an ironclad legal definition, one that we couldn’t come up with caveats for.

David:

[Laughs] Let’s start with this one and see if we run into some problems.

Tim:

All right. So first off, I believe is relevance.

David:

Okay, relevance as a factor in what is productive?

Tim:

When I think of relevance, I’ve worked at companies where I see co-workers who are very busy all the time, whether that be getting pulled into side meetings or answering a bunch of emails or volunteering for off-the-cuff tasks. Most people at work are always very busy, but I really feel that if you want to get work done and be productive, then you need to ensure that the work you’re doing is specifically relevant to a specific set of tasks. Meaning, I can’t walk into work on Monday and tell myself, “I’m going to get a lot done today.” I want to go, walk into work on Monday and say, “I’m going to get X done today.” That means that the work I want to be doing is not answering emails or maybe reviewing a whole bunch of pull requests or getting pulled into a thousand different meetings or volunteering to go grab the team lunch. I want to be making sure that the work that I’m doing in order to be productive is relevant to that specific set of tasks.

David:

Coming up with something that’s relevant to what the team actually needs is definitely going to be a part of that, because I agree, you can’t just go in and start throwing papers around and feel like you’re being productive. If you don’t have an agreement about what everybody wants, everybody has been moving forward on, if you don’t have a shared consensus on what a product will be, you don’t really have a sense of what productive could be. Because you could be very productive on something that you consider, individually, very important, but that isn’t going to be of any value to your team or to your company. That could be as true if you’re working for yourself as it is where you’re working for a larger organization, because you could be going down a rabbit hole in something that’s caught your attention and be very productive on that one rabbit hole, but not be productive in terms of your overall vision for what you want to be accomplishing.

Tim:

I think that would mean that defining relevant work is all about setting up specific tasks. If I want to be productive, I think step one is outlining a specific set of tasks that, if completed, means the job at hand is done.

David [3:57]:

I think the tasks might be jumping too far ahead, because tasks is once you’ve broken down what the vision and the goal is. I think maybe productivity has to start with having that shared vision and that goal, and part of productivity can be defining those tasks.

I’ve worked as an agile coach, and I love helping teams figure out how to define what it is that they’re trying to accomplish and then how to break it down into something that they can manage to do and figure out how they can estimate it. For me, the productivity starts when the product owner starts thinking about, “What is going to be the next iteration of our product?” Then, funnels out through the different stages until the team actually has come up with tasks and defined them and estimated them and then starts working on them. All of those pieces feel productive to me.

Tim:

I think that makes sense. So then how would we go about defining what we need to get done?

David:

It’s an authority kind of a thing, I suppose. Somebody needs to have the authority to decide what is or is not relevant, and since relevance is what we’re talking about at this point, you have to be able to have somebody who can say, “This is within the scope of what we need to be working on and this is outside of the scope.” And then you need general agreement on that being the case, so what we need to work on can be defined more clearly and then funneled out to people, so that they can break it down into individual tasks that they can start working on — tasks that they are prepared for, that they have the resources for, that they understand, that they’ve estimated adequately, and that they have the time for.

Tim:

I’m glad that we’re touching on this, because I really believe that a gigantic piece of good productivity is a culture that supports it. I can’t be productive at work if every time I’m pulled into a meeting, there’s no meeting agenda enforced. We all need support to be able to ensure that we’re productive. An unproductive organization does not yield productive individuals.

David:

Absolutely, I agree. And you bring up meetings. As somebody who’s done agile coaching, I am guilty of being the person who has organized more meetings than you can count, but I make a point of making sure that they’re productive meetings. You brought up the point of having an agenda: the meeting has to have some result that people are going to walk away with, and everybody has to agree that it’s a good investment of their time to participate in those meetings. Otherwise, the culture has to decide as a group that those meetings are no longer valuable.

Tim:

I would say first and foremost, if you’re listening and you are working in an organization that is not productive, don’t beat yourself up if you are finding that you yourself have a hard time with productivity at work. If you’re self-employed, well I’m not going to say anything about that! [Laughter] If you work for a company and you have a hard time getting things done, that could be an organizational problem, in which case, sitting here and trying to write down lessons for productivity is not going to be much of a help. What would make sense to do in that situation is talk to someone, talk to a higher-up. Talk to anyone you can in your organization and outline, “Hey listen, we’re unproductive. It’s built into the company and we need to fix that.”

David:

That’s excellent advice. When I got into agile coaching myself, I was working as an engineer on a team. I did not have as my formal role being a scrum master, being a coach or anything like that. I saw suffering around me, and I saw engineers working in an unproductive way in an environment, where they were being pushed down and suppressed and not able to get their work done. I teamed up with a bunch of other folks — a designer, a couple of other engineers — and we just pushed the agenda forward — that this was something that needed to change. It took a lot of pushing, because there was an entrenched system in place, but it’s possible to do.

When management sees the value to them of having productivity meetings and having the ability to understand what people are working on and have a shared vision, you can spread that out as a culture into an organization.

Tim [7:50]:

Yeah, I think it makes a lot of sense. First off, hire David, so your organization can be more productive. It’s a lesson we’ve learned. [Chuckling]

Secondly, so let’s say that we are working inside of a productive organization and we have tasks that have been defined for us. Now, moving on to the individual, I’m looking at my JIRA board, or a white board, or something, wherein I have tasks that are outlined for me. Let’s say, I have five of them. How do I go about being productive? I walk on Monday morning, I have these five tasks, then what?

David:

Well, what stops you from being productive when you have these five tasks? Why do you have five and not just one?

Tim:

This is an excellent example, because right now I have about five tasks at work, so I am the lead front-end engineer at the organization that I work at currently, which means I have a couple of responsibilities. Number one is I need to review all pull requests that touch front-end code. I need to make sure that the linting rules aren’t breaking, and the code makes sense and is readable for the next engineer that goes in and looks at it, and that we’re using common design patterns and that we’re not repeating ourselves too often when writing new methods or classes or things of that nature. Then, I need to build out actual features. For example, one of the things that I’ve been working on lately is internationalization, wherein I had to go in and pull out every single user-facing string out of our current application, which was terrible.

David:

I’ve been there.

Tim:

I have a couple of different tasks based on my responsibilities, but they are all tasks that I need to accomplish. So, if I want to be as productive as I possibly can in accomplishing these tasks, I would say my first inclination would be to rank them in order of how much time they take to complete.

David:

That’s an interesting approach. Let me come at it a slightly different way. Let me ask you, it sounds to me like one of your tasks — what you’ve defined for me here sounds like two tasks to me actually. One is code quality and one is actual code development.

Tim:

Yes.

David:

It feels to me like all of those things that you’re responsible for as the lead front-end engineer, in terms of checking other people’s code, that all comes down to code quality. That’s a sort of thing that comes out of code reviews and pairing sessions with people. Separate from that, you also have some tasks that you’re responsible for developing from the ground up, which then need to be reviewed by somebody else, because you always need a second set of eyes on things.

Tim:

Of course.

David:

Unless you’ve been doing them in a pair programming environment, which I also strongly recommend. But I’m curious, when you say productivity, and about this, do you feel that you’re not being productive when you spend time reviewing somebody else’s code?

Tim:

Oh, I think it’s definitely something that is extremely productive — for a number of reasons. Reviewing other people’s code, number one, I learn stuff always. I always learn stuff when I look at other people’s code. Number two, I get to yell at people about writing single-line if statements.

David:

Yelling at people is always fun.

Tim:

No, but what I actually mean by that is when I see code patterns that might lead to a bad codebase, for example, writing nested if statements. I’m on this if statement theme now, I don’t know why, but for example, if I see if condition, and inside of that if condition two, and then inside that if condition 1 and condition 2, but not condition 3, I’m going to look at that and say, “Hey, there’s probably a better way that we can do this”. And the reason I’m saying that isn’t because I’m being pedantic. It’s because if this is a pattern that continues throughout the rest of the codebase, eventually somebody is going to look at that and have no idea what’s going on, and have a tough time — spend maybe an extra 15 minutes — having to digest it, when instead they could have looked at three separate and not embedded if statements and clearly understood what was going on. so I see a number of benefits to it, but I think the most important one is making sure a clean and concise codebase stays that way, even though a lot of people are working on it.

David [12:02]:

Where do you come down on ternary operators?

Tim:

Well, actually I left a comment today, asking a co-worker to change. There was a variable assignment. We had let variable X equal Y, and then below it, it was if some other condition is true, let variable X equal Z instead of Y. I said, “This is a perfect case for a ternary operator, because rather than conditionally reassigning that variable, we can do it all on one line and say, ‘This variable is equal to either X or depending on what the value of N is, it’s equal to Y.’”

David:

That’s excellent. What I like about this is that you’ve come down strongly against these nested conditionals, but you recognize the value of ternary operators, because they actually add clarity to the code. I think a lot of people conflate those two.

Tim:

Yeah. And not to get too off-topic, but I think code clarity is extremely important, and more so than code brevity. I have written code emphasized on brevity only to look at it the next day and delete it all and start over … more than once.

David:

Well, this is interesting. We’ve shifted, sort of. we’ve gone from relevance to quality, which was our second criterion for productivity.

Tim:

Ooh, yes.

David:

It makes sense that we’re there, because we’re talking about what is productive, and as you brought up, the process of reviewing other people’s codes is part of productivity. It doesn’t mean that you’re not working just because you’re not working on your own code.

Tim:

Yeah, as far as quality goes, I think it is foundational in terms of being productive, because again I can get six things done in an hour. I can close out all of my tickets, eventually get these six things done in such a way that either I or hopefully not, but another one of my teammates will have to go in and redo it. Then, we’ve just taken twice the amount of time to get one thing done, effectively cutting our productivity in half.

David:

Yeah that’s probably about half in fact, and that’s one of the reasons why pair programming ends up being so valuable on teams, because you miss those problems. You get much better consistency across your code, and although you have two engineers working simultaneously on the same piece of code, and arguably not producing that particular piece of code any faster than they would have if they’d worked as individuals, the amount of back and forth discussion that goes into creating that and then the sense that both people are learning something from what they’re working on, so that there’s shared knowledge, ends up increasing the productivity of the team as a whole and increasing the quality of the codebase.

Tim:

So I think it’s important to remember that even though I have maybe a mountain of work to get done, it’s important to focus on not getting it done fast, necessarily. It’s important to focus on being or doing. And the difference there is, if I’m focusing on being productive about the work that I’m doing, I’m going to invest in the quality side of the work. Being productive isn’t necessarily always about speed. It’s about getting things done well. I think we could just stop there. It’s about getting things done well, and part of that means getting it done in a timely manner. Another part of that means getting it done thoroughly and not taking shortcuts.

David:

There are a lot of potential shortcuts, and I think engineers are often encouraged to use those shortcuts, especially when there are deadlines that people are expected to meet. “There’s going to be a release this week, and so we absolutely must get it out the door, so don’t worry about quality for right now, just get it out the door. Then, we can go back and fix it absolutely never.”

Tim:

I think we should spend a few minutes talking about that, because no matter where you are in your career, you either have gone through a situation like that or you will go through a situation like that. It doesn’t matter if you are self-employed or not self-employed, it happens. Again, like I said, we’ll always run into this situation. What’s difficult is that sometimes there’s no other option. If my manager comes up to me and says, “Hey, this thing needs to get done tomorrow. You’ve never seen it before, it’s new, it’s a little bit confusing, but it has to get done tomorrow, good luck.” I might not have a way out of that. That might be a fire drill and something that just needs to happen. It’s going to be terrible. It’s probably going to turn to technical debt, almost immediately, and it may or may not be something that you get to refactor later on.

David [16:34]:

It’s one of the things that I appreciate most about having an agile process in place, is that when something like that happens, there’s a scrum master there to say, “Is this urgent enough that we need to break the sprint and start a new sprint in order to support it, or are we losing resources, so we lose points on this particular sprint and therefore, we reduce our overall velocity for the team?” It’s a question of making those trade-offs and making those decisions. How frequently it happens becomes something that needs to be discussed at a retrospective on a regular basis, because if it starts happening regularly, then it’s an issue.

When you have a team that’s working without any agreement about how they manage their time and what is permissible and what isn’t permissible in terms of taking an engineer off of a task and interrupting their flow in order to work on something that’s urgent, you don’t have the opportunity to make those decisions and to look at it and see what’s happening.

Tim:

I would like to posit an idea, David, and tell me what you think about this. I would say that in the case that you get pulled aside and given something that absolutely has to be completed in an impossible amount of time — [David chuckles] — and you have no way of pushing back on that, the idea of productivity itself I think goes out the window.

David:

I’m supportive of that, actually, because you’ve immediately gotten rid of the quality component of productivity. We’ve agreed that in order to be productive, the work that you’re doing must be of good quality. It’s arguable whether what you’re doing is relevant, because if what you’re doing is going to break the codebase and cause technical debt in the future, then in terms of the product that you’re building, it is not relevant to the product even if it is relevant to meeting a particular deadline.

Tim:

I think we’ve hit a very important breakthrough here. That is the idea that, in some situations, in some scenarios, it is simply not possible to be productive. Now, that is largely dependent on workplace culture. If you work at a startup, for example, and one day, the board says, “We need this feature, we need it now, make it happen,” and, for some reason, it just falls on your shoulders, that is not a scenario in which you can be productive. That might mean that you are working until midnight on a feature that just has to go out, and more than likely is going to be rewritten weeks or months later. That is not a scenario wherein you should think to yourself, “How can I be most productive about this?” Because you are set up, basically; you are given something that, at its core, is of an unproductive nature.

David:

I like this, and I’m going to throw this one back at you, because you brought up an interesting scenario, because you said, “If you’re working at a startup.” There is a situation that is completely valid and productive, in which writing messy, bad code that would introduce technical debt into a production quality environment is not the same as writing messy, bad code that will allow you to do some user experience testing, evaluate something and then iterate on something, so that you can then decide what would be productive code to write in the future. In that case, I would suggest that it’s possible — writing what we’ve before called hashtag #holidaycode in order to get something done and out the door, so that people can start using it and so you can start getting feedback about it — can actually be productive, not in terms of building your production codebase, but it can be productive in terms of moving the company forwards to the point that they know what you should be writing as production quality code in the future.

Tim [20:02]:

So I would say, my counterpoint is this. It is a gamble, because you don’t actually know if this holiday code that you’re writing is going to be something that doesn’t break a core feature, or that it doesn’t cause an intense user experience issue that is going to drive users away from your product. Is this type of behavior something that happens often? Are users often logging on to your products to find that some new decision that has been made that is not well thought out and causes clashes in their UX and drives them away from the goals that you as the business has set for them, the user. I think there are a lot of factors that can make or break this sort of holiday code process. Now, if it’s something for example like, “Hey, let’s turn the email address capture thing into a tooltip instead of a modal”, and you write some messy code to do that, well then maybe, yes. Maybe in that scenario, the process that has been set about won’t trickle down into some sort of technical debt. But if it does trickle down into technical debt and not some sort of iterative and getting better over time process, then I would say it’s still in that non-productive state.

I think again, depending on how it’s presented, it’s a gamble in terms of whether or not it will actually be beneficial.

David:

It sounds to me like what we’re coming down to is that, if you’re going to be in the situation where you have to write unproductive code — what we’ve defined as unproductive code, something that is temporary, something that is urgent — it’s critical that you have a system in place that allows you to isolate that code from the rest of your codebase, so that it can be rolled back independently to the previous state if it needs to be, so that it can maybe be put on a canary server, so that it can be fed out to 10% of your audience and see how they respond to it, see if there’s a problem that comes up. But that testing process is essential if you’re doing this against the code that already has a userbase and already has production quality in place.

Tim:

I think you touched on something key, and that is the idea of its being temporary. I would argue that if it’s temporary, it can still definitely be productive. If, for example, suddenly your deadlines have been shifted up and you need to finish 75% of your application in three days, that’s not temporary. Therefore, I’d say that’s not productive.

David:

Honestly, I can say that there is code in production that I wrote to be temporary as long ago as 2008 [chuckles], and that is still out there. You can go to the domain and you can click on the URL and you can see that code right there in the browser. Temporary is very hard to define. Once you’ve got something out there, it’s going to stay out there until there’s something to replace it, unless somebody takes ownership of making sure that the temporary thing gets replaced with something permanent and robust. Taking ownership of that is part of productivity, in my opinion.

Tim:

I think we can agree that there is a situation in which it is impossible to be productive, but that situation itself can vary. What we know is that if you are forced to do an insane amount of quick work, in a very short amount of time, and that work that you’re doing is not going to be temporary, meaning there’s no one who is going to look after it to ensure that it is refactored or iterated, but it becomes cemented into your production application, that is more than likely a scenario in which it is impossible for you to be productive.

David:

I would agree. And, interestingly, I notice that we’ve managed not to talk about the one aspect of productivity that I think was the first one that we both brought up right at the very beginning, which was organizing your time to be productive. At the very beginning of this, we started talking a little bit about meetings, and how they interrupt our flow when we’re trying to work as engineers. I think that it’s something that we need to bring up more specifically, because the third component of productivity, we had quality, we had relevance, and then we had time in terms of being able to get things done. That means giving an engineer the focus and the time to work on something without interruption.

Tim [24:16]:

I have something to share, and it might be bad, it might be good — I’m going to have to rely on you, David, to tell me if it’s bad. Here it goes. Everyone I have ever worked with, past and present, knows that I despise meetings at the very core of my being. I sort of allow that tidbit about me to persist, because it means that I at least get invited to meetings as optional, meaning if someone wants me to attend a meeting, they will say, “This is optional, you don’t have to come,” or it comes from higher up and I just have no excuse and I have to go. But this is a strategy that’s worked for me. This is a strategy that ensures I am not asked to attend a lot of meetings, only the really important ones, where usually I don’t have a choice of attending or not attending. But it’s also something that allows me to spend a lot more of my time on doing the actual work.

David:

And next year, there will be the SetPoint book How to Avoid Getting Invited to Meetings, by Tim Evko.

Tim:

It’ll even be illustrated. Most of the illustrations will be me flipping over desks.

[Laughter]

David:

Or flipping the bird.

Tim:

Well, we’ll see. I can’t really draw hands, but we’ll try.

[Laughter]

David:

It’s interesting. I think the way that you feel about meetings is the way that a lot of engineers feel about meetings. I’ve felt that way about them myself. The issue comes up about whether or not that meeting has an agenda and is relevant and I can add value to it, I think. When I get invited to a meeting in which I’m just there in order to be a placeholder and to make sure that everybody in the room hears what the one person was saying that could have been summarized by somebody and emailed out to everybody afterwards, that’s a meeting that I do not need to attend. On the other hand, if I’m at a meeting where my expertise is required in order to give feedback about something that’s being discussed, and if a decision is made at that meeting that didn’t have my input, it might affect me and my job later, then I damn well want to be at that meeting.

Tim:

Yeah, that is true. It’s a delicate balance. I am introverted, so I don’t often try to get into situations wherein I get to be in a room for three hours where everybody’s talking about something. I try to keep that to a minimum. But there are often times where I do feel that I should probably be in the room for this because we’re talking about a feature that a front-end developer is going to have to build, and it is going to impact a lot of users. And, I don’t know, I want to make sure that we don’t make half the page fixed position to the window, so that when somebody scrolls, there’s like a landslide that happens. You know, stuff like that.

David:

For me, the problem is that a lot of these meetings come up ad hoc, and they come up randomly, and they come up quickly, and they’re organized by somebody who doesn’t have the authority to organize the meetings. That’s again — I’m going to say it — why I keep on gravitating back toward agile, because I am one of those people who has called an entire engineering team into a two to three hour meeting to sit down in a room and talk about things, annoying all of the introverts in the room at the time. But that meeting had an agenda, and it had a very clear purpose, and it moved forward. It organized things in such a way that a lot of the other meetings that would have come up randomly that would have interrupted engineers in the middle of their work were eliminated — by the fact that we had this one meeting once a week, once every two weeks, once every sprint, that everybody went to and that everybody had a chance to participate in and voice their concerns in.

Tim:

Yeah, I agree. I think a good meeting is something that will prevent ten other bad meetings.

David:

Yes, meetings that eliminate other meetings are the meetings that I’m talking about. The idea that nobody wants to be in the meeting, because, except for the people who enjoy hearing themselves talk and see it as a power play, meetings are generally not terribly productive for anybody. Having uninterrupted time to work is what an engineer likes the most. I think — what have the studies said? — if you’re working on something and you’re focusing deeply, but you get interrupted by somebody who just taps you on the shoulder and says, “Hey, you want a cup of coffee?” you’ll have 20 minutes getting yourself back into that flow state that you were in before you get interrupted.

Tim [28:20]:

Yeah, I would have probably about 20 minutes or so. I’ve never really enjoyed that. I don’t know why, but it’s just the act of tapping — that throws me off pretty big, yeah.

But anyways, it’s not just meetings. There are other things that … Well, let’s say this, if we want to get something done very intently and devote a lot of focus towards getting a specific task done, we want to set for ourselves, I don’t know, a few hours of focus. I’m just going to work on this one thing for two or three hours. After that, maybe I’m going to take a break, maybe have lunch, or just — I don’t know — do what they used to do in the old times and stand up from your seat.

David:

Standing up is a good thing in all sorts of ways. I recently made the decision to go on a social media fast, because I noticed that I had the tendency to interrupt my day with random little checks on Twitter and Facebook to see what was going on out there. I realized that I would get caught in these tiny little whirlpools that would suck me in, and afterwards my mind would be distracted by what I had seen and I wouldn’t be able to focus back on what I was trying to think about for my work.

So I decided to schedule myself out periods of time during which I simply wouldn’t check my social media — you know, turn off the notifications on things. That goes as far as email and anything, but go for several hours and focus. I was surprised because I assumed that it would give me more productivity, but I was amazed at how much more productivity it actually inserted into my day. At the end of the day, I looked at what I had accomplished, I had done more than I had been able to do in a week, trying to think about all of these other things while simultaneously trying to do my work.

Tim:

Yeah, that’s an excellent point. It adds up to hours at the end of the day, really. When you think about it, somebody tweeted about politics, and I’m going to spend 30 minutes pondering the conclusion of their tweet, and then all of a sudden, it’s the end of the day, and I worked on maybe three things.

One of the things that you actually reminded me of, David, is that it’s not just social media. For example, one of the things I recently realized, and that’s helped me become a lot more productive, is work emails. I get maybe 50 of those a day, and for some reason, I had always had it in my head that as soon as I get a work email, I need to read and respond to said work email.

The more I thought about it, that doesn’t really make any sense. If I am working on coding some UI feature, reviewing a pull request or whatever I’m doing, or if I’m in the middle of one of the many three-hour works sprints that I’ve set for myself to accomplish a specific set of tasks, I can let those work emails go. When I’m done with that three-hour time block, look at the emails that I need to, because if at some point someone comes to my desk and says, “Hey Tim, did you not see the email that I sent to you 30 minutes ago?” I say, “No, sorry. I’m working on this feature.” That seems like a fair response, because I’m doing work.

I think we get it into our head that a lot of the time someone’s going to come up to us and say, “You didn’t respond to my email. You’re a bad employee.” If you’re actually working on something relevant and you didn’t respond to an email, you’re actually doing better than if you responded to one email. If the person who asked you to check that email expects you to break away from your work whenever something comes in, they would really need to re-examine that behavior, I think.

David [31:42]:

I agree. This is another one of those cultural issues very much like agreeing what is worth working on and what the goal of the team’s work should be.

One of the things that I know, I’ve worked on a number of teams, where they’ve agreed, everybody is going to be working uninterrupted for several hours at a time, buuuut everybody has Slack running in the background. And everybody’s having these little side chats about things. And of course, every time something comes up on Slack that you need to read, or a GIF comes up that you want to comment on, it distracts you from your work and you create a great social team environment there. But you’re not allowing people to have their productive, uninterrupted time to work on things. I’m a big fan of Slack in terms of the way that it helps teams document and communicate, but it can be an incredible distraction to have that running in the background.

I recently interviewed a fellow. He’s an independent contractor, and he has his clients sign an agreement when he starts working with them that he simply will not respond to any requests for work that come through an email. He has a system set up in place, whereby they can submit a ticket and the ticket has to have certain parameters in it. When that ticket comes into the system, it will be channelled and it’ll be dealt with. But if somebody writes to him by email, he does not respond. Then, when they come back to him and say, “Hey, why didn’t you get back to my emails,” he points out, “You agreed to this. This is the way that we’ve agreed to work.” Having that kind of an agreement upfront makes sense.

Tim:

Oh yeah, I want that agreement very badly, not because there’s another system that I would have in place. Just because emails aren’t fun.

David:

Well, JIRA tickets, for example.

Tim:

Yes, yeah, of course. I’m really glad you mentioned Slack, because the jury is still out for me on whether or not Slack helps to increase productivity. Because, much like the email conundrum, Slack is even more demanding in terms of attention, because if someone messages me, two things happen. I get a notification on my phone five minutes later if I don’t respond, and then an email maybe like 10 minutes later, which means that every time I get a Slack message, I need to respond immediately. Maybe what I should do is, again, I have this concept of like three hour blocks, wherein I am working on a specific thing and specific thing only. During said block, I should probably set Slack to like do not disturb mode or something.

David:

When I discovered that Slack had the option to quit … It’s an application you can actually turn off occasionally, and I started turning it off when I was trying to work. My productivity soared.

Tim:

Yeah, I would imagine so. I work in an incubator, so my co-workers are directly across from me on a small wooden table. So the absence of Slack is not going to cause our company to implode.

David:

That’s true. Of course, those open floor plan workspaces that are so popular these days, that is another issue for productivity for a lot of people.

Tim:

Yeah, I would say, because I think it pushes you into this weird sort of state, wherein if you want to get work done, you have to tune out noise. You listen to music, which is not neutral on your concentration.

David:

No. I can’t listen to music that has any words in it and focus at all. I think one of my favorite things is coffee shop ambience sounds when I’m in an environment like that.

Tim:

Yes, definitely. I’m not sure if there is any science behind this, but I do believe that listening to music is not necessarily a matter of opinion, but it does take your attention away from the task at hand to varying degrees. If there are lyrics in the music, then it’s going to definitely pull more of your attention. If it is for background music or classical, it’s going to pull less of your attention. But I think the existence of it just in the background still pulls a little bit of your focus out of what you’re currently doing.

David:

Sure. If I’m listening to Frozen and I start crying, then I’m going to be distracted.

Tim:

Yes, and you absolutely cannot listen to Frozen and not be distracted. That is a fact. There’s definitely science behind that.

David:

So okay, we’ve talked a little bit about these factors in productivity. What have we come to, then? We’re talking about relevance, we’re talking about quality, and we’re talking about time, right?

Tim [35:36]:

Yeah, so I think to sum up, first off, most important thing, it’s not just about getting a lot of work done. The work has to be relevant. It’s not just about answering a thousand emails and then go into a thousand meetings. You will feel like you’ve done a lot, you will feel busy, but when you look back on it, you will see that a very small amount of work has gone to the actual tasks at hand. It’s spread too thinly to be of any major value. So the work has to be related to a larger goal.

David:

Right. And then, the work also has to be of adequate quality. You have to be able to say that what you’re doing is of the appropriate quality level for the stage of the work that you’re working on. If you’re doing something that’s for a quick test, that can be taken out and put back in, then it can be slapdash, and it needs to be thrown together quickly and it’s appropriate. And that’s still productive. If it needs to be production-quality code, then it needs to be reviewed and tested and it needs to go through the whole integration process. It needs to be given that much respect in order to meet those quality standards.

Tim:

And then that led us into the idea that in some cases, it is impossible to be productive, which is a very important thing to realize, because you are definitely wasting your time if you are trying to be productive when given tasks and scenarios that make it impossible to be productive. In those cases, you’re just going to stress yourself out.

David:

Finally, you need to be able to have the time to work in a focused manner, and you have to have everybody’s agreement on what that means, because everybody has to work together as a team. So communication still needs to happen. There need to be channels for that, but those channels need to be set up in such a way that everybody can share what they need to share without interrupting the flow of an engineer.

Tim:

That means that distractions need to be kept to an absolute minimum — again, if possible — because if that is not possible, that means you’re not working in an environment where it is possible to be very productive.

David:

It’s funny. We interviewed Azat Mardan recently, and one of the books that he mentioned was Deep Work, which is a good classic on the subject, and it’s worth reading about that level of focus and how you can achieve that.

Tim:

Yeah, that’s definitely one that I should probably take a look at. But that being said, I think it’s fair to note that, in some cases, productivity is something that is a privilege. It does largely depend on the environment that you work in. If you find yourself in a bad work environment, wherein you have micromanagement just constantly, or you have no real agile process, you could very well be working in an atmosphere where productivity is just not possible in your current situation. Listening to a productivity podcast under that scenario would really only serve to tell you that there’s not much you can do about productivity when you are set up to be unproductive.

David:

At least then you know it’s not your fault. But there things you can do to help encourage an environment of productivity, and having some definitions in mind, and having some resources that you can refer people out to, is a good place to start.

Tim:

Yes, I would say so. That might mean looking for a new place. We’ve all been stuck in places where productivity is just not a possible thing. And that’s frustrating. It doesn’t allow you to take great pride in your work when you know that you’re building a mess.

David:

And sometimes that place can also be when you’re working alone.

Tim:

Yep, which is why I don’t work alone.

[Laughter]

David:

Well, which is why I use a Kanban board to keep track of my own tasks, so that I don’t get sunk in those situations myself.

Tim:

Very true, very true, those are extremely helpful. Again, productivity is great if you are in an environment where productivity is possible. It’s not always a pick-yourself-up-by-your-bootstraps scenario.

David [39:50]:

And productivity doesn’t always feel productive, especially when you’re working on something that might not feel like I’m writing a lot of original code. Like Tim, you were saying how you were doing code reviews for other people, but recognizing where that is productive, and why it’s productive, and then focusing on those aspects of it can help.

Tim:

It’s a really, really good point. Because, again, I think when we say productivity, everybody always thinks, “Oh, I’m going to get a million things done in 10 seconds.” That’s not necessarily the case.

So I think what we’ve discussed today is we have explained what it means to be productive. We talked about the three qualities of great productivity. Well, we spoke about what it means to be unable to be productive. There are cases wherein productivity is not actually possible.

So, what we’d like to do later on, is we’d like to share personal productivity tips, meaning now that we understand what productivity is, how can we actually go about being more productive? What are the things that we can … What are the habits — like David previously mentioned trigger habits — what are the habits that we could take on that will allow us to maximize our productivity?

David:

You know, Tim, that sounds like a good topic for a show all by itself.

Tim:

I think it does. I think we should find an expert, because it’s clearly not me. I worked from home today and didn’t leave my couch. I guess maybe that doesn’t mean I wasn’t productive, but …

David:

That certainly doesn’t mean you weren’t productive. I also worked from home today, and sitting here in my La-Z-Boy chair, very comfortably produced a lot of code. Not a lot of great code, but it was code that I wouldn’t have produced otherwise, and I can go back and I can refine it.

Tim:

Well, clearly we need somebody to help me out with my definitions of productivity, but in all honesty, we should definitely have someone on the show to tell us about productivity habits. I’m going to start calling it personal productivity, rather than what we’ve been discussing today, which is more along the lines of organizational productivity.

David:

So we need to find somebody out there who’s a productivity expert, who can come and talk with us. If anybody out there knows somebody who can give us their expertise on this subject, please tweet us @VersioningShow and recommend them to us.

Tim:

Or send us an email. Write us a handwritten letter.

David:

That’s true. We also accept gifts.

Tim:

Yeah, we do accept gifts. We haven’t actually talked about this. [Laughter] The types of gifts! We should start an Amazon wish list.

David:

We need an entire show to be devoted to the types of gifts that we want, but I think we can deal with that next time.

Tim:

Yes, next time.

[Musical interlude]

David:

Well, thank you so much for listening everybody. We always enjoy getting to talk technology with all of you.

Tim:

We’d also like to thank sitepoint.com and our producers Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter @VersioningShow, and give us a rating on iTunes to let us know how we’re doing.

David:

We’ll see you next time, and we hope you enjoyed this version.