Hi, the author here.

You're raising a great point. While I'm not living together with my partner, we do have a little family and I'm very much with you that it's super hard to get anything done with kids around.

Unless you get up super early, stay up super late after kids are in bed, or use the time when they aren't around (e.g. kindergarden), I also think that it's almost impossible to fully focus on something for a longer period.

I guess it kind of boils down to finding the right routines. That certainly doesn't make it easier...

Hi, the author here.

Sorry for the late reply, I didn't realize people were actually commenting here...

So coming back to your question:

In my case, I'm lucky enough to work for a company that is entirely distributed and decentralized and doesn't actually tell me when and how long to work as long as the output is sound.

Obviously, in practice you most often have to put in some hours to get stuff done (that's what I'm being paid for after all). So while my work schedule isn't enforced, I chose for myself to work at these hours (not just for my employer) because I tend to function best at those hours.

Now... do I want to reserve several hours of each day for work for the rest of my life? Certainly not. But that's what work right now for me and it can and will totally change in the future.

That's how I wrote and self-published my book as well! Although, I created a script that turns md to epub/mobi/pdf using pandoc.

Here's how I did it in case anyone is interested: https://pascalprecht.github.io/posts/writing-an-ebook

This is great. Thanks for sharing

Oh that's so cool! Didn't know that publishing on Amazon was so straight forward!

I've done a similar thing wrote about it here: https://pascalprecht.github.io/posts/writing-an-ebook

Instead of using Latex, I went with markdown as the source to generate PDFs, Mobi and Epub from that.

Thanks for sharing your experience!

Adding Status.im for completeness

https://status.im/

Checks all the privacy boxes

Hey everyone,

I'm documenting my journey of learning the Rust programming language with blog posts that are easy to understand (hopefully), especially for people without a systems programming background (like me).

I'm accumulated a bunch of articles already an decided to create an every growing twitter thread where people can follow my journey and learn alongside with me.

Hopefully this is useful for some people out there.

Hi everyone,

I made it a challenge for myself to author and publish an ebook about Git in two months. This has worked out wonderfully and now I'd like to share my process, workflow, learnings and key takeaways.

I hope there's some useful tips for potential authors here!

Hi, Pascal the author here.

I'm probably not very good at expressing that the book is not only about rebasing. While it is the main focus, the book covers a lot of other things that aim to give you a really good understanding of the tool (which I believe is necessary to make sense of (interactive) rebasing).

And just like you said, you can totally get around with adding/committing/pushing changes without ever touching the rebase command. Perfectly fine.

If you want to be more flexible and productive with your work, you might want to learn how to rebase though.

Hi, Pascal here. The author.

Just to clarify this: The aim of rebasing is not a clean commit history. It enables you to make one in case you've been creating lots of work-in-progress commits with no semantic meaning, which makes it harder to work with it.

However, even if you stick to that, it's not like rebasing isn't of value anymore. You might still be interesting in squashing your commits or splitting them up or simply rebase on branch on top of another for various reason.

That said, I'd recommend to not advocate not to rebase if it's based on the assumption that it's only useful for clean commit histories.

Hey, Pascal here, the author.

I understand this reaction. And just like you've pointed out, it's actually not a whole" book about a single command.

In order to get a good understanding of rebasing, I believe it's good to have a solid foundation of how git works, which is pretty much what the first half of the book covers.

I could've left that out and only talk about rebasing without going into all the other topics but then, for someone who isn't experienced with the internals of git will have a hard time following what's going on.