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?
Treadmill
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/.