You could be more productive
In this episode, we chat with Neal Ford, software architect at ThoughtWorks, and author of The Productive Programmer, about how to build better habits and different tools and resources that can boost your productivity.
Jess Lee is co-founder of DEV.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Neal is Director, Software Architect, and Meme Wrangler at ThoughtWorks, a software company and a community of passionate, purpose-led individuals, who thinks disruptively to deliver technology to address the toughest challenges, all while seeking to revolutionize the IT industry and create positive social change. Before joining ThoughtWorks, Neal was the Chief Technology Officer at The DSW Group, Ltd., a nationally recognized training and development firm.
[00:00:01] JL: This season of DevDiscuss is sponsored by Heroku. Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?
[00:00:18] BH: Fastly is today’s leading edge cloud platform. It’s way more than a content delivery network. It provides image optimization, cloud security features, and low latency video streaming. Test run the platform for free today.
[00:00:31] JL: Triplebyte is a job search platform that allows you to take a coding quiz for a variety of tracks to identify your strengths, improve your skills, and help you find your dream job. The service is free for engineers and Triplebyte will even cover your flights and hotels for final interviews. So go to triplebyte.com/devdiscuss today.
[00:00:47] BH: SSH is a de facto solution for GitHub access and remote administration of Linux systems, but creating and managing SSH keys is painful. Switching to SSH certificates completely removes the need for managing keys and it’s more secure. Smallstep is an open source security company offering single sign on SSH. Visit smallstep.com/dev to create a free account and try it for yourself in under five minutes.
[00:01:18] NF: The trick as any kind of knowledge worker, and that certainly applies to programmers, is turn the noise off.
[00:01:38] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all our lives as developers. I’m Ben Halpern, co-founder of Dev.
[00:01:45] JL: And I’m Jess Lee, also a co-founder of Dev. Today we’re talking about habits and productivity with Neal Ford, Software Architect at ThoughtWorks and author of The Productive Programmer. Neal, thanks for joining us today.
[00:01:55] NF: Hi. Glad to be here.
[00:01:57] BH: Neal, can you tell us a little bit about your background in software?
[00:01:59] NF: Sure. How much time do we have? I took a very circuitous path through university because I was paying my own way and fell in love with computer science. And so I graduated in 1993 with a degree in computer science and started working right away for a consulting company, building software for clients. I’ve been in that capacity in one form or another ever since 1993. I gradually worked my way up through developer and into architect and then I was the chief technology officer for a small consulting training company. And then 15 years ago, I joined a ThoughtWorks, which is a well-known international consultancy and I’ve been working there ever since.
[00:02:37] JL: And from what I understand, you just finished writing your eighth book, Fundamentals of Architecture.
[00:02:42] NF: That’s right, number eight, and I’m working on number nine right now. Most authors are either one and done because it’s so horrible or they become serial writers, and I’m clearly in the serial writers as well.
[00:02:52] JL: Can you describe a little bit about what a software architect does?
[00:02:55] NF: It’s a big sprawling topic because it touches on pretty much every aspect of software. And in fact, it’s the nexus for a lot of really important decisions in software. So not only do you have to be good at things like software design, but also have the ability to sell your idea. And no matter how brilliant you are as a software architect, if you can’t convince someone who owns a checkbook that your vision is good, you’re never going to get to implement it. So certainly it its root, it is about the structure of software and designing the structure of software, but it’s also about evangelizing that design and figuring out what tradeoffs are and doing presentations about that design and documenting it. So it’s a very big subject area, which is why you can write a 400-page book that is still considered concise.
[00:03:44] JL: Neal, I don’t know if this is possible, but if there were two insights you wanted people to walk away with from your book about architecture, would you be able to share what those are?
[00:03:54] NF: Oh, absolutely. It’s actually quite easy because in part of writing a book, what we wanted to do is not just a dry collection of facts, but actually have a narrative. Along the way, we ended up codifying to what we refer to as the laws of software architecture. So that’s a perfect way, you want to do things. So I have two laws of software architecture. So it couldn’t be better. The first law of software architecture is that everything in software architecture is a tradeoff. And the first corollary to that law is if you think you found something that isn’t a tradeoff, it just means you haven’t discovered what that tradeoff is yet. A classic example of that is for years and years, everybody thought that code reuse was purely a force for good. We should try as hard as we can to reuse as much code as we can within our organization. But what they didn’t realize is that everything in software architectures tradeoff and they didn’t really think about the tradeoff of that. So what is the tradeoff of maximal code reuse? It’s high coupling. Well, if you’re trying to build an architecture that can move fast, that you can iterate on quickly, that you can do things like multivariate testing and try out new things and do experiments, et cetera, you need an architecture that is very decoupled so that you can move fast. So the goal of reuse is exactly counter to the goal role of being able to be agile and moving fast in that software system. So understanding what the tradeoff is for use, you have to balance those things. The second law of software architecture is that the why is much more important than the how. And this really shows, back to your definition of software architecture, it’s not just the structure of how things are wired together, because if you show me an existing software system, I can explain to you exactly how it works. But there’ll be some parts of it I cannot explain why that architect made that choice versus this other choice, because I don’t have the full context of why the context of that decision. And so it turns out that while the how is very interesting to why and architecture is much more interesting and something that you’re much more interested in capturing.
[00:06:14] BH: Yeah. What are you working on right now at ThoughtWorks?
[00:06:15] NF: Mostly, what I’m focusing on right now is not a single project, but rather advisory stuff for other projects. So certainly around a software architecture but more than that, specifically around evolutionary architecture. So my penultimate book was the one called Building Evolutionary Architectures, which I wrote with Dr. Rebecca Parsons and Pat Kua. And it’s really about the mechanisms for how you build architectures that you can evolve over time. So most of my consulting focus now is around evolutionary architecture.
[00:06:54] JL: We’re actually here today to talk about habits and productivity, which you obviously have a big interest in, given that you wrote an entire book called The Productive Programmer back in 2008. What led you to take on this topic?
[00:07:05] NF: It’s interesting how that book came about. As I said before, I started my first professional job in 1993. So I grew up through computers with command lines and not graphical user interfaces. And it really annoyed me in 2008 when I would see developers rather than running their computer, they were walking their computer. They were using their computer, using the affordances that were created to make your computer easier to use for your grandmother, not to be a high productive professional who sits in front of a computer for eight hours a day. So it frustrated me that more developers didn’t know command line tricks. This is back when most developers were using some variant of Windows and didn’t even realize that you could install Cygwin and get UNIX utilities on Windows and what kind of power that gave you and the way the UNIX command line worked. Not a lot of developers understood that. So actually I was speaking at conferences then, this popular conference series, No Fluff Just Stuff. And there was another speaker, David Bach, who’s based in the Virginia area. And he and I shared this common passion about programmer productivity and finding better ways to use your computer. And so he and I had this idea of, “Hey, let’s get together and write a recipe book for developers for all these little productivity recipes, how to do this, how to do that, et cetera.” So, okay, that’s a cool idea. So we started working on this book. Well, then two things happened. First thing was David and his wife got pregnant with triplets. They were trying to have kids and going through treatment, and hey, it worked. And so David now has other hobbies rather than writing a book on productivity. The other thing that happened was as I started writing down all these recipes, I realized that all these recipes were impossibly specific, that there were great if you had this exact problem, but one of the chances that I’m going to hit upon the exact problem that all these developers are going to find. Fortunately, though, I had been building a whole bunch of these recipes toward building IP for this book and I took a step back. This is a very architecture kind of thing to do. I didn’t realize at the time, but took a step back and thought, “Well, are there any common elements within all of these recipes that I have, that I can float out and just do as general principles of productivity? Regardless of the recipe, are there some underlying principles that tie those things together? And that led to the actual writing of The Productive Programmer book. And that’s actually primarily what that book is about. It’s actually what’s called in the industry “a duplex book” where the first part are these four principles of productivity, which I’ll talk about in just a bit. And then the second half of the book is basic little essays that give advice about how to approach dogma and software and some sort of advices sort of stuff like that. David was nice enough at the end of the day to end up writing the preface for the book when it finally got published a several years later and he was up to his eyeballs in triplets.
[00:10:09] BH: Given that this book came out over a decade ago, what would you say are the really fundamental principles that most ring true today?
[00:10:16] NF: I really got lucky in that if I’d been really specific with the tools and only focused on the tools back in 2008, that book would have had a shelf life of exactly six months. But by exposing those things as principles, I actually went back to my four principles and they all still work. Some of the tools are different and have changed, but the principles are still absolutely still spot on. Let me give you an example of that. So almost every developer utilizes code snippets within their IDE, where you can build a little trigger that spits out some code into a template. A lot of IDEs have a template where I’ll need to create a new class, you create any wizard, and you type in some fields and it generates all that class stuff for you. Almost every developer for me were that. Why not take that and make it operating system wide? There’s a great utility called TextExpander, which is the one I use, but there are these text expansion utilities all over every operating system. And you get that exact same templating effect you get for code, but for anything that you type a lot on your computer. So for example, my street address. I never typed my street address. I typed the abbreviation for my street address and let TextExpander expand it for me. TextExpander is particularly good because there are two parts of using a tool like that. One is finding it. The other is getting in the habit of using it. And the beautiful thing about TextExpander is it actually sits and watches what you type. And if you keep typing the same stuff over and over again, it’ll pop up an alert that says, “Hey, I noticed you keep typing that same phrase over and over. You want me to just maybe create a snippet for you so you can stop doing all that typing?” The other great thing it does is create a feedback loop. It sends you a report once a month for how many minutes you save by not typing. And for me, it routinely is over two hours a month that I’ve literally say by not typing my street address in over and over and over again. As a consultant, I get paid by the hour. And so that’s literally two hours of more productive time that I have in a month. And you start multiplying that through several other productivity things and you start getting some real effects. And so that was an example of my productivity principle called “Acceleration”, find ways to accelerate and automate all the things that you do on a regular basis. And in fact, my rule of thumb in that book is still true. Every time you find yourself you’re doing the same thing for the third time, find a way to automate it, because if you’re going to do it three times, you’re going to do it 3,000 times. And if you can find a way to automate it once, you never have to do it again. You just have to watch and make sure the automation is working.
[00:13:02] BH: You find the accelerate principle liberates your thinking, like it certainly saves you key strokes, but how does it affect the way you think as you develop software and as you move about your applications?
[00:13:15] NF: Well, I think part of it is just fluency with getting around a keyboard. One of the huge, huge advantages of doing pair programming, which we do a lot of at ThoughtWorks, is you can instantly see what the other person is doing and it ups your skills tremendously. I don’t know if you’ve ever paired program with somebody who’s an expert and an IDE like IntelliJ, but it is remarkable how fast you can move around. You can navigate. You can get stuff done. In fact, there’s a really common tool that we use within ThoughtWorks because this is such a common, learning experience for pairs. There’s a little utility call KeyCastr that runs as a floating window in the upper right hand side and it literally shows the combination of keys that were just struck on the keyboard about a half a second after they were struck. What that allows is your pair, who’s watching you and you do some magic trick, you go, “How did you do that?” Now you don’t have to ask. You just glance up and you can see the key chord they use to perform that magic trick. Now keyboard shortcuts roll around a development team like wildfire, because as soon as one person learns a new trick, they start pairing with other people who pick up that trick. And before long, it’s all over the entire team. You want that level of fluency with a computer if you’re going to be using it all day to be productive. A great example of that, and I can’t believe I even have to say this, I still know software developers who don’t know how to touch type. That is insane to me. They have to watch their fingers to be able to type and can’t watch what they’re doing. It is a learnable skill. Do it. That’s the one of the least things you can do, but it’s a good example of getting out of the distractions to get you toward being able to think about things. And that actually gets toward one of my other principles, which was this productivity principle of focus. This is something you really have to guard as a software developer because your most productive time is this state that’s called “flow state”. This was identified and named by the psychologist in Chicago years ago and wrote a book called “Flow”. That’s what developers crave is that ability to sit down and concentrate and just get miraculous things done and where you almost wake up and snap out of a trance and it’s amazing how much you’ve gotten done. That’s that flow state. And your modern environment is perfectly designed to keep you out of that state as efficiently as possible. Never have email notifications turned on if you’re trying to code, because every time that thing pops up, it pulls you out of flow state. This is where computer designers have hacked our ancient psychology in a terrible way, because you’re hyper wired to notice little movements out of the corner of your eye. Operating systems abuse that and they pop up notices, notifications, and banners and all this stuff that are designed to keep you nonproductive. So the trick as any kind of knowledge worker, and that certainly applies to programmers, is turn the noise off. Don’t leave your email open. It was never meant to be a continuous information stream, close it, and then open it every two hours, deal with it in a focused way and then close it again. And Slack is where productivity goes to die. I cannot tell you how much I hate tools like Slack. They can be used for great good. In fact, I know a lot of teams that are remote, they use Slack for great use, but the constant barrage of interruptions is poison to serious intellectual work. You’ve almost got to treat your work like a tunnel where you go into the tunnel and turn everything off and then emerge through a tunnel every once in a while to check on the world and then go back in the tunnel again. That is the secret to productivity. And if you don’t believe me, try a few days of doing that and then go back to your interrupt-driven life that you were in before and see how much you get done.
[00:17:26] JL: So we’re an asynchronous distributed team and it takes a lot of mental energy on the users and to ensure that we don’t treat Slack like a synchronous tool. Like we have to keep it really top of mind that we don’t need to respond right away. And I think that’s sort of what you’re describing and just us like noticing little movements, that little thing that pops up on your window. What are some of your recommendations to make it less focus killing? Is it really just turn everything off when you need to get into that flow state?
[00:17:56] NF: The context switching has a cost. If you context switch all day, every context switch from Slack, back to your IDE, to email, to your calendar, back and forth, every context switch has a little cost associated with it. Every one of them takes a little piece of your energy and vitality. So by the end of the day, you’ve used it all up by context switching the context switch list. So the Pomodoro Technique is a great way to think about this. This is a productivity trick that a lot of getting things done folks love is the work for 25 minutes, take a 5-minute break. I actually don’t think that’s effective for develop. I do hour long Pomodoros. Why work for 50 minutes and then do a 10-minute break? I find that longer sustained chunks of time allow you to get in flow and stay there much more effectively. So I actually think the 25 minutes is too short for developers because you just get into the meaty part of the problem. And if you have to stop for five minutes, you’re just going to break your concentration again. There are studies that show that it takes 15 to 20 minutes to get back to the same level of concentration you were after answering one Slack message out of your flow state. So it is so vital and important to guard that. That is your most precious resource as a developer and you have to organize your world to guard that like it’s the most precious thing you have.
[00:19:31] JL: Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that. It allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], which explores code, technologies, tools, tips, and the life of the developer. Find it at heroku.com/podcast.
[00:20:04] BH: Empower your developers, connect with your customers, and grow your business with Fastly. We use Fastly over here at Dev and have been super happy with the service. It’s the most performant and performant-edge cloud platform. Fastly CDN moves content, data, and applications closer to your users at the edge of the network to help your websites and apps perform faster, safer, and at a global scale. Test run your platform for free today.
[00:20:30] BH: I’d say within our organization, it’s important for us to really try to establish these things as organizational best practices so that developers don’t have to create situations where they fake meetings or going on conference calls and stuff and we use Slack, but we try to make it really explicit that we expect people to be asynchronously replying to things and that being always available is not necessarily what we’re looking for from anyone. Getting it to work is always a constant give and take. But I feel really grateful that we’ve thought about the schedule of the programmer as something you just can’t take for granted.
[00:21:13] NF: Absolutely. Another thing to do, so if you’ve ever looked at a manager’s schedule, their lives are ruined. It’s one meeting after another one, after another one, after another one. As a manager, don’t ruin your developer’s lives. Create quiet time. I used to work in a consulting office and we had quiet time from 9:00 AM until 11:30 AM was quiet time and from 1:00 PM to 3:30 PM was quiet time. And quiet time meant no meetings, no interruptions, unless it’s an emergency. That was expected to be flow state for everybody. Meetings happen between 11:30 and 1:00 or after 3:30, but no meeting unless it was emergency happened during quiet time. And that was expected to be the structured kind of working time during the day. And there’s a side benefit to that as well. So your body is a fantastic feedback mechanism. And this is one of the things I tell people about when they asked me, “How do you end up writing so many books?” And part of this is just regularity. So there’s nothing that benefits more from regularity than coding and writing prose. So you hear writers talk about the muse showing up, the inspiration showing up as if by magic, but I’ll tell you exactly what the muse is physiologically. So if you sit down every day at 9:00 AM and write for two hours, if you do that for a couple of weeks at about 8:45 AM, your brain is going to start organizing itself chemically and with hormones to do this thing that it’s decided, “Well, it looks like we’re doing this all the time now. So I’m going to get set up for doing that.” That’s exactly what they mean when they say the muse shows up as you’ve gotten your brain chemically organized to be inspired. If you set up an office so that every day from 9:00 till 11:30, no meetings, no interruptions, that gets physiologically sick in the developer’s net office and they will literally become more productive during those times because their bodies will adapt to this idea of, “Oh, that’s the super deep concentration time of day,” and your body will start optimizing toward that because it’s a giant feedback mechanism.
[00:23:21] JL: So this is actually a really great timing. About two hours ago, I just sent a Slack message to our entire team that we have a new company policy, which is no meetings on Fridays.
[00:23:32] NF: There you go. That’s the beginning.
[00:23:36] JL: We really try not to have like recurring meetings and really try and limit them and this is just sort of one additional way to, especially during this time, to like encourage folks to like take the extra time and get some deep work done. But it sounds like you were starting to go into just creating better habits, like waking up, writing two hours, and your body gets used to it. What kind of other things do you think form better habits?
[00:23:59] NF: I think one of the things that it’s important for everybody to learn is exactly what does it take to form a habit for you yourself? For me, if I do something for about two weeks consistently, it becomes more like habitual and I don’t have to think that much about doing it. I actually just have formed a brand new one, very consciously doing what I’ve been trapped at home. I had a sort of a bad habit of just sort of sitting around in the morning and gradually easing into my day. And I say, “You know what? The weather’s nice. I’m going to start doing a morning constitutional every day.” So I’ll do a two-mile walk every morning, starting around 7:30 AM. And so I started doing that. In the first few days I did it, it’s like, “Oh, this is kind of weird,” but today I did it and didn’t even think twice about it. So that’s now a natural part of my routine. My body’s used to that and my brain is used to it and now it feels weird if I don’t do that. One of the things is sort of metacognition hacking is figure out what it takes to establish a habit in your own brain. Learn the things that pull you out of productivity. So toward that, how do focus again? There’s a great piece of software called “Concentrate” that runs on the Mac. If you know that when you’re trying to get stuff done, that there are some sites like Opera News or CNN or ESPN or Amazon’s running a sale, you know there are some sites that are deadly to your productivity, Concentrate allows you to create a list of sites that it will prevent you from going to for until the time when it runs out. So you can set a two-hour timer on Concentrate and it will not allow you to go to ESPN.com or your email until the timer’s up. Now you can reboot your machine and get control of it back, but that’s the only way to get to those places. So if you know that you suffer from temptation, just remove the temptation. That’s another great way of sort of knowing yourself and knowing what your strong points and weak points are, and then taking advantage of those things.
[00:25:55] BH: Do you find there’s any burnout in kind of achieving this high state of productivity or is there a balancing in terms of getting your sort of mental state back out of being in flow? Is there a toll that needs to be repaid?
[00:26:09] NF: Well, certainly it’s taxing. But the more you stay in flow state, I mean, you have to recover from it, but that’s actually something you can train yourself to is to stay in flow in longer and longer chunks of time. There are definitely physiological limits to that. When I first started speaking at this No Fluff Just Stuff conference series, there are some cases where the presenters there have to do a five 90-minute talks in one day back to back to back to back. When I first started doing that, there’s no way I could do that. That just requires way too much effort and concentration. If I’ve tried to do that, I’d be a zombie vegetable by the end of the day. But you build up endurance for that, just like you build up endurance to run a marathon. So I think that the more time you spend in flow, you’re actually building your capability to be in flow and stay there and feel like you’re in a kind of a natural state. And certainly fatigue affects that. So later in the day, it is the harder it takes to get into that flow state. Another one of those really important metacognitive things I think it’s super important to understand is, are you inherently a morning person or a night person? I’m very much a morning person. My highest level of concentration, my best work is done super early in the morning. So that’s what I try I do my best stuff. I know people who are very much night people that their best stuff comes after midnight. You should learn that about yourself and then lean into that and take advantage of whichever one it is.
[00:27:29] JL: Yeah. It really sounds like so much of this is about knowing yourself both mentally and physically. What are some of the worst habits that you’ve seen developers have that you’d recommend us to pay more attention to?
[00:27:43] NF: So one of the good things about software developers is they like software. One of the worst things about software developers is that they like software, particularly new software. And so most programming languages have IDEs like IntelliJ or Eclipse or Visual Studio Code or whatever that is. And those are all highly specialized tools for writing your particular platform and language. So you should become a stone-cold expert at that IDE. Go into that IDE and find the page that lists all the keyboard shortcuts that exist in that IDE. Print it out and put it next to you. And then every time you do something, if you can do it with the keyboard shortcut, do with that because you were just learning that muscle memory. But the thing that drives me the craziest about is. So IDEs are special purpose tools. But the other thing that you do as a developer is manipulate text. And it drives me crazy. The Programmers Editor do sure think that every five years some new Programmers Editor comes out that everybody gets all excited about. For a while, it was TextMate and then it was Sublime, I guess Atom is the current cool kid right now. That is ridiculous because there are two editors, Emacs and VI that have literally been around for half a century. And they have been honed to the point where they are the sharpest tools on earth. And if you learn one of those two editors deeply, it replaces swaths of other kinds of software that you end up using and you can become much, much more productive. I think it’s silly to learn a brand new fundamental tool every five years when you could learn a really, really super powerful tool extraordinarily deeply. Every new tool that comes out like Atom has some whizzbang feature, like the big thing when Sublime came out was, “Oh, it can show you the 20, 000-foot overview of your source file. Oh, isn’t that sleek?” It took almost a week for somebody to implement that in Emacs. Every single feature in all the shiny new editors that come out get implemented in Emacs and VI within a couple of weeks of the new editor showing up because they’re incredibly flexible, very programmable kind of environment.
[00:30:15] BH: What’s your monitor setup?
[00:30:17] NF: I’ve gone through several monitors setups over the course of my life. I like two monitors. Mostly now though, I have a laptop hooked up to a 4K monitor and I mostly use a 4K monitor now. I use the laptop screen for one display and I have a big of a 4K monitor now. I’m using a utility called Magnet on the Mac that lets you tile windows and snap them to corners. So for example, in a 4K monitor, if it’s big enough, you actually have four 1080P screens tiled together. And so using Magnet, I can use the command key U, I, J and K, and that snaps it into upper left, upper right, lower. So I basically have four displays on one 4K monitor, and then I use multiple desktops. So another thing about productivity is consistency. If every single window’s in a different place every time you want to deal with it, you’re wasting time searching around for that stuff. And desktop too, for me, is always full screen Emacs. And on the Mac, if you hit control in the number, it goes directly to that desktop. I keep my browser open, tiled with several other tools and that’s always on desktop one. And so I know which desktop has, which combination of tools I want. Doing command tab is a terrible way to move between your applications because it changes the ordering of them every single time you hit command tab. Consistency is the important thing about productivity. So I don’t use command tab switch applications. I use my launcher instead. So for me, whether I’m launching an application or switching to a running one, I don’t care if it’s already running or not. I want that application. And so I just use my launcher. I use LaunchBar on the Mac. Launchy is one on Windows. I use LaunchBar on the Mac and I just use to both switch applications and launch them. And see, what I’ve done there has gotten rid of the, “Oh, is that running? Let me Alt Tab. Let me look for it and balance. All of it one past it and now I’ll Alt Tab again.” All of that is gone because on Firefox, command space, FF or Firefox, and I’m running in Firefox.
[00:32:33] JL: I’m feeling really inspired to just optimize my setup right now. When you said the command tab thing, I was like, “Oh, that’s me.”
[00:32:41] BH: Do you find yourself ever running into work that kind of just rose you out of your rhythm, like unexpected applications that just kind of take a different context?
[00:32:51] NF: Oh, certainly. I mean, things will happen in your life, personal life. It can get disrupted. I mean, it’s super easy to take hits on productivity. Well, I find when that happens is I try not to fight it too much. I try to just step away from it. One of the best things to do is actually step away from whatever technology you’re at and go take a walk or go outside or do something that’s not technology related to kind of reboot yourself and reboot your enthusiasm. So rather than get frustrated at something, I’m more likely to get up and walk away for half an hour and then come back to it or take some other tasks.
[00:33:25] JL: We talked about how some of the principles still hold true from your book, like accelerating and focusing, but if you were to make some updates and then new addition 10 years later, what are some of the things you would add today?
[00:33:39] NF: Probably I would add something about a stronger rant about choosing a good tool and using it well. Software development is a craft and craftsmen learn their tools well. And so just because something is easy doesn’t mean it’s powerful. So stop using the mouse. Learn to navigate everything via keyboard. Every time you take your hands off your keyboard, you’re killing your productivity. So don’t learn something brand new, but rather make one of your existing skills better. So spend 30 minutes a week learning some brand new thing that you didn’t know before about your IDE. If you keep doing that before long after a year of doing that, you’re going to know things that other people are going to marvel at. I think it’s important to keep doing that on a regular basis, just like craftspeople keep enhancing their tools.
[00:34:48] JL: Join over 200,000 top engineers who have used Triplebyte to find their dream job. Triplebyte shows your potential based on proven technical skills by having you take a coding quiz from a variety of tracks and helping you identify high growth opportunities and getting your foot in the door with their recommendation. It’s also free for engineers, since companies pay Triplebyte to make their hiring process more efficient. Go to triplebyte.com/devdiscuss to sign up today.
[00:35:13] BH: Smallstep makes SSH easy for teams and solo developers using SSH certificates instead of key pairs. Single sign on once a day to access all of your SSH servers. Behind the scenes, Smallstep transparently manages your credentials and logs all access. Your connection is secure with the added benefit of short-lived credentials that live in memory only. It’s free for personal use and you can try it out in under five minutes. Visit smallstep.com/dev to learn more.
[00:35:44] JL: Now we’re going to move into a segment where we look at responses that you, the audience, have sent us to the question we made in relation to this episode.
[00:35:51] BH: The question we asked was, “What are your risk habits as a developer or what are your best habit building and productivity hacks?” Our first response is from Jennifer Tran. “One of my worst habits as a developer is being too much in my head and forgetting about my body. I mean, ignoring need to use the restroom, having bad posture and forgetting to eat at times.”
[00:36:15] JL: Yeah, that sounds like one level deeper than what you were, you know, like we’re trying to be very aware of our body, but these are sort of basic human needs. Yeah.
[00:36:24] NF: This is a great example of what I was talking about before of knowing your own strengths and weaknesses. So if you find yourself have a tendency to go too long without eating, set an alarm on your computer to remind yourself to step up and go eat. Hopefully, you won’t have to set an alarm to remind yourself to go up and go to the restroom, but if it gets to that, it may even get to that. But you could use technology to fix some of the things, some of your worst tendencies. So one of the things I use, I have an Apple Watch and it has the feature that it yells at you if you haven’t stood up every at least once an hour, I use that every time it goes off. I stand up and do a stretching routine to stretch my back and my quads and all that stuff, my hamstrings, which get too tight when you’re sitting down too long. So that’s a great way to just keep a regular physiological reminder.
[00:37:09] JL: David answered both questions. Their response to worse habits was, “I spent too much time upfront optimizing my unfinished code instead of getting it to work first and seeing if the optimizations even would’ve mattered.”
[00:37:21] NF: You know there’s a famous quote from Donald Knuth, “A premature optimization is the root of all evil.”
[00:37:28] JL: And on the habit building and productivity hack, they wrote, “Out of sight, out of mind, right? So when I don’t want to work on something, I place it inside the top drawer of my dresser. Whatever is my goal for the week, for example, reading a book, I leave it on top of the dresser. I use my dresser as the focal point of goals. Why? Because I can hide things inside and place things on top and it’s right by my bed.”
[00:37:51] NF: That’s a great example of a hack where he knows what works for him and what doesn’t. So that’s awesome. He’s learned about how he can force himself to ignore things and pay attention to things.
[00:38:01] BH: Recently we’ve had talk around pull request etiquette in my team and I’m definitely guilty of getting carried away with what I’m doing and adding too much to my PR. I’ve got to try to remember to break my work up into smaller digestible pieces, which will ultimately get everything merged much quicker.
[00:38:17] NF: I think that’s a great example of a bad habit that developers get into of taking off too much chunk of work. So now the question becomes, “How would you figure out a way to fix that?” So maybe if you’re doing something like TBD, start forcing yourself that every time you get a test to pass, go ahead and check again, even if it’s not complete and maybe even do that on a small branch that you’ve created locally just so you can get it checked in and get that part out of your mind. So figuring out a way to increase that cadence is a fine little hack that gets you to increase that cadence. The other thing you might think about doing is if you really like writing long pull requests, start putting a TLDR at the top. For the people who don’t want to read the entire thing, put a “Too Long, Didn’t Read” tag at the top, which is a one or two-sentence summary, and then put the full text under it. Find out if there are people on your team that actually do find it valuable. And if they do, start building a multimodal pull request.
[00:39:16] JL: So the Garden Man wrote in, “Reinventing the wheel! I didn’t know Django existed. I was trying to build a web app using basic Python.”
[00:39:25] NF: That’s classic. There are lots of things out there. How do you find out where they exist?
[00:39:29] JL: Yeah. One of the principles that we have here at Dev is to build on good solutions and the way we explain it is that we want to build on top of good solutions so that we’re not constantly reinventing the wheel.
[00:39:41] NF: Yup. Not invented here is a big problem.
[00:39:44] BH: Donald writes in to say, “Trying new tools with no real use case or goal in mind. It always ends up being a huge waste of time.”
[00:39:53] NF: Go back to what I said earlier. The good thing about developers is they love software. Bad thing about developers is they love software.
[00:40:00] BH: Thanks so much for joining us, Neal.
[00:40:02] NF: Yeah. My pleasure.
[00:40:12] JL: I want to thank everyone who sent in responses. For all of you listening, please be on the lookout for our next question. We’d especially love it if you would dial into our Google Voice. The number is +1 (929) 500-1513 or you can email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Please rate and subscribe to this show on Apple Podcasts.
[00:41:07] SY: Hi, there. I’m Saron Yitbarek, founder of CodeNewbie, and I’m here with my two cohosts, senior engineers at Dev, Josh Pitts.
[00:41:15] JP: Hello.
[00:41:15] SY: And Vaidehi Joshi.
[00:41:16] VJ: Hi everyone.
[00:41:17] SY: We’re bringing you DevNews. The new show for developers by developers.
[00:41:22] JP: Each season, we’ll cover the latest in the world of tech and speak with diverse guests from a variety of backgrounds to dig deeper in the meaty topics, like security.
[00:41:29] WOMAN: Actually, no. I don’t want Google to have this information. Why should they have information on me or my friends or family members, right? That information could be confidential.
[00:41:37] VJ: Or the pros and cons of outsourcing your site’s authentication.
[00:41:41] MAN: Really, we need to offer a lot of solutions that users expect while hopefully simplifying the mental models.
[00:41:48] SY: Or the latest bug and hacks.
[00:41:51] VJ: So if listening to us nerd out about the tech news that’s blowing up our Slack channels sounds up your alley, check us out.
[00:41:57] JP: The show launches at a couple of weeks, and you can find us wherever you get your podcasts.
[00:42:00] SY: Please rate and subscribe. Hope you enjoy the show.