I've had to juggle the two schedules he describes for about a decade now. I haven't been wildly successful, but there are some tactics that seem to make it work

I've had to juggle the two schedules he describes for about a decade now. I haven't been wildly successful, but there are some tactics that seem to make it work okay. - Write code in smaller chunks. This has been a huge change in how I do software. Almost all my code now starts out as an outline in a series of comments: "// do this", "// then do that". I write software "outside-in" now; if I need to slurp a file in one format into a database in another format, I start with the bits that read the file, then add the code that translates/interprets/processes the data in the file, then separately add code that talks to the database, then glue it together. At each step I dump output to the screen. So, I start with a stupidly simple file-dumping program and iterate it until it does the whole job. - Write less code. Find a framework that you get along with, and stick with it. This takes away all the joy of learning new things, but you can still get work done. Develop and nurture your personal code library like you're tending to a garden; your personal code library should be highly modular, and as simple as possible, so that you can use pieces of it as often as possible in your projects, so that it's constantly being improved. Reuse as much as you can from each project. - Do your thinking on the toilet. Or in the shower. Challenging programming often has two separate aspects, the part where you try to understand the problem you want to solve, and the part where you write code to solve it. You don't need to be in front of a computer to do the first part. Likewise, when you're in front of the computer, try not to do the second part -- just sit down and bang out code under those outline comments for as long as your schedule allows. - Keep a notepad nearby. I carry a Remarkable everywhere now. I can sit in a meeting and write things on it and it's a lot less rude than typing on a laptop or my smartphone. People probably figure I'm just taking notes in the meeting, but I can be flowcharting or braining out the next piece of code. A paper notebook works fine for this too. - Aggressively guard what's left of your productivity. My cell phone sits behind me or out of sight; my email tab is closed or on another virtual desktop; headphones are in. Any problems that I regularly encounter in my development environment get time set aside to permanently solve them in a way that's convenient for me. If I find that I need to be able to rapidly switch between different versions of some software, I work and work on my tooling until it's just a short commandline statement to do it. As a recent example, managing unique random passwords for everything was starting to cause a little bit of friction; a few dozen times a day, I had to switch to KeePass, scroll down to or search for the appropriate password, copy it, switch windows, paste. The other day, I wrote "pcp", for "password copy", which takes the title of a password for an argument, opens my KeePass file, locates the password, and copies it to the clipboard. I only touch the KeePass UI now to update the file. - And finally, say no sometimes, or push back a little bit on your boundaries. If you can, find a place to work where you're most productive, whether it's a different office in the same building (so that co-workers aren't popping their heads into your workspace), or from home, or a coffee shop. Make yourself unavailable once in a while so you can get caught up. Take time away so that you're not also fighting off the inevitable fatigue from doing lots of context switching all day long. Avoid getting talked into meetings that are optional where you aren't likely to have much influence.