I really need to start a video series on writing some code as MicroObjects. The way I would when I don't have a good grasp of the domain. It's come up multiple times that someone likes the idea of where microobjects goes, but they really don't like starting with MicroObjects. I suspect some of that's my fault for various reasons. I tout the advantages of the end state. Not a lot about the process to get there.

The process is imperative.
Then RUTHLESSLY refactor.

It's that simple. Write a giant imperative block of code for the functionality you want. 10 lines, 100 lines, 1000 lines. I really don't care. The bigger you go, it's likely going to be harder to refactor... You're likely to need to change a few places at a time as components are extracted. That's fine, just more painful.
I'd stop at about 100 lines. Once you have that much behavior in imperative code, you have enough to start extracting bits. This isn't a absolute limit.
Really - If you feel the 1000 lines is the minimum you can do before refactoring, do that.

We don't start small because that starts to drive primitives and mutation into our code. We have to make assumptions, and we're going to be wrong. Will we have the fortitude to do the sweeping changes the fix needs?
It's not easy. I've gotta a lot of practice throwing away code, but there's still resistance.

We don't start small because we can't know how the objects WANT to interact, we can try to TELL them... but the code doesn't want to listen to us. Get behavior in place and look at where you can find cohesion. Extract it.
Find logical code blocks, extract those. Maybe that's as far as you drive it... for now. I tend to refactor until I can't. That's from practice and familiarity with the techniques.
If you can't see a way to refactor that feels right; Stop. Don't refactor or generalize when you aren't sure it's a better abstraction.
I like the rule of 3 for this. If you're not sure, wait until you have 3. At least 2.
You can't generalize a single example. MicroObjects is all about extracting behavior into easily reusable code. (I have opinions on what reusable code is here)

I play with creating objects, sometimes small and focused ones, when starting out. I'm pushing different boundaries. I'm interested in seeing more reasons why it fails when trying to start with MicroObjects. Because I try is one of the reasons know it blows up in your face pretty quickly. I've had it become the obviously wrong approach implementing the first microobject class.

This post is short because

DON'T START MICRO

Write the behavior you want in an imperative block of code. Follow the practices to refactor out units of behavior. Then extract smaller units of behavior.
Repeat until you can't.

That's it.

One way to view MicroObjects is as extreme refactoring. Write code, then refactor it until you can't.