Writing a book: how to work on many projects

After quite a bit of pondering, writing and editing, I shipped the Learning as a Software Developer book last week. The whole process took about 6 months to complete, so I had time to experiment with a few ways to work. During that time, it was important for me to keep the blog going and still have time for technical learning and my various homestead-y hobbies. So, in that case, I was in for a marathon, not a sprint.

Spoiler: making a commitment to write regularly was the best way to make progress.

I’ve also tried a batching approach to the problem. The idea was to write a few blog posts in advance the first week, then spend the next week working on the book, and finally do a bit of technical learning. It was working decently at first and I WAS able to batch a few posts in advance, but then life happened and I was only able to write a little bit for the book before having to go back to blog posts. Fail!

Making sure I’d work a bit on everything each week was the best way to make sure I’d keep moving forward. It kept everything fresh in my mind, so I had less catching up to do to go back into the flow and start writing. To limit context switches, I’d pick ONE thing to work on every night instead of jumping from task to task.

important-writingI’m aware this makes me less effective than batching, and that it takes more time to complete some projects, but this way I don’t lose steam and burn out. Right now, I’m living in manager space and not in maker space: I don’t have time to focus intensely on a project for hours every day, so I have to sprinkle important projects here and there to make sure they get done. If I space out working on each project too much, I’ll wake up 6 months later without having published a new blog post or written a newsletter.

Relating to this, I also had to hone my ability to get to work immediately (or at least faster) since I’m working during the gaps in my day. I only have a block of a few uninterrupted hours in the weekend if I’m lucky, so I can’t lose 2 hours getting started every time.

The key here is to have a task primed and ready to go, or at least a well-defined process. For example, to write a blog post, I generally write a draft in one go, and then edit the next time, so I’m either starting a new blog post or completing one.

Finally, what helped me is that all those tasks are similar enough to fall into the same habit. I changed my blogging habit to a habit of writing and coding using the same cues and rewards, so I’ve not lost a habit that took some work to build. It took quite a while to ship everything this way, but in the end it was worthwhile and allowed me to ship the first version of the book to you.

Get my Learning as a Software Developer guide

You became a software developer because you love programming and couldn’t believe people got paid to do this. You first learned programming at school, where somebody else dictated what you should do and learn. After you finished your degree, you finally got a job, and you kept learning fast about building software and your industry until you were up to speed.

But now that you’ve settled into a routine at your job, what is the next step? How do you keep learning and growing as a software developer? Nobody will tell you what you should learn next anymore: you’re on your own. But you’re stuck on an endless plateau, and can’t see a way out of it. You maintain the same old legacy application and fix routine bugs day in, day out, since you’re too valuable in your current role. You can feel your passion and motivation dwindling dangerously fast, but you don’t know what do to about it.

Even worse, you’re falling behind, slowly crushed by the huge treadmill of new frameworks and languages. All those kids fresh out of school are all about React, Rust and NodeJS, while you were learning Java only a few short years ago. You know you can learn new tools without waiting for permission but every time you tried it a fancier tool came out shortly after, making your knowledge obsolete. Silverlight anyone?
You could switch jobs, leaving your crummy legacy code behind to solve new problems. It’s a valid strategy if you can’t take it anymore, and it’ll work for a time. Unfortunately, once you’re over the initial learning phase, you’re going to repeat the same pattern. If you start over as a junior every few years, you’re never going to improve your craft.

But what if you could take control and grow without waiting for a boss to tell you what to do? What if you could keep learning, stay sharp and become passionate about software development once again? You’ll have skills you’re proud of, work on cool projects and be confident in your knowledge and expertise.

If you try to keep up with all the new frameworks and tools you come across on Hacker News, staying up to date is an overwhelming burden. Fortunately, you don’t have to do it all: you can choose the skills to invest in to get the best out of your limited learning time and grow as a software developer.

Understand how to choose the best skills to learn with the Learning as a software developer guide and workbook. You will :

  • Learn to see the big picture, understand where you are and what motivates you.
  • Plan which skills you need to learn to reach your goals.
  • Choose what you’ll learn next deliberately instead of jumping on the latest bandwagon.
  • Pick up new skills with ease using the right techniques and habits.

Grab a cup of coffee and the Learning as a software developer package, and get to work becoming the best software developer you can be!

Purchase now at https://sellfy.com/p/ibXx/.

The joy of batching

The garden is winding down, so I need to can, freeze and otherwise preserve the harvest so it doesn’t go to waste. It’s a time-consuming task: a single batch of pickles takes a few hours, from slicing the cucumbers to processing the jars. Still, it’s a decent time investment since I like homemade pickles. It would not make sense to cook a jar each time I needed more instead of batching it all together once a year.

Batching is a great boost to productivity, be it to create software or to cook. You want to keep thinking about what you’re doing so you avoid cooking each proverbial jar of pickle separately. Does your day look like this?

  • Writing an email
  • Starting on feature #1
  • Writing an email
  • Writing an email
  • Going to a meeting
  • Starting on feature #2
  • Writing an email

It’s hard to avoid this completely when emergencies are rolling in and email and chats are clamoring for your attention. Still, you’ll lose a lot of time working like this even if you feel you’ve been productive all day. Having to switch gears to handle a task takes a bit of time for each, so it’s worth thinking about it.

When all the tools are in place and you’re in the thick of it, writing another validation, answering that last email or completing a feature properly doesn’t take much more of your time. What is expensive is getting started and finding everything you need to do your job. You should always keep in mind how you could group similar tasks together to minimize setup time instead of choosing tasks at random.

Batching can’t be applied to everything: you can’t make sandwiches for the whole year in a single weekend, or stay up to date with new technology by binge learning for a week and then quit learning for the rest of the year. The best way to use it is to complete well-defined tasks that you’ve mastered. If you’re likely to be side-tracked, for example by writing a huge, complicated email while you’re trying to clear your inbox, it may be best to finish that one later instead of breaking your momentum.

My most productive time is in the morning, which is when I can have a few hours to go though my backlog and kill many small, similar tasks without interruptions. I’m sure you have one of those periods too: you should protect it as much as you can because that’s when most of the work gets done.