[fn1]

Solving problems iteratively in the same way progressive jpegs render: Start with essential parts, quickly assemble them to a usable draft and iterate on the entire thing by improving quality where it needs to be improved.

This is applies to programming as well as to writing, drawing, making music etc.

Applying this to writing emails can definitely improve your business communication 10-fold:

* write down the important parts you want to convey, even in incomplete sentences

* improve the ideas into sentences

* rearrange the paragraphs/parts/sentences into proper order (written language rarely comes out in the correct order).

* cut unnecessary talk

* iterate on the above 3-8 times, depending on the importance of the email.

[Ancapistani]

> Solving problems iteratively in the same way progressive jpegs render: Start with essential parts, quickly assemble them to a usable draft and iterate on the entire thing by improving quality where it needs to be improved.

This is something that I feel I’m really good at, and I like this explanation a lot.

I’ll add that while being able to look at problems at a high level and then slowly increase “resolution” is a huge advantage, the key in my experience is the ability to switch between those levels of abstraction quickly.

The more complex a system, the more important this ability can be.

Let’s say you’re building out a large new feature that can be implemented in three parts: Service A, Service B, and the communications between them. That’s the highest level of abstraction: we are dealing with three components, each of which has a very high-level purpose/domain.

Once each component has a defined domain, we can disregard the other components when drilling down into each one. This works very well, but invariably we’ll reach a point where we discover than an assumption that was made at a higher level is no longer valid.

At that point, there are two options: we can stay this level of abstraction, leave our component domains unchanged, and “work around” the issue. Sometimes that’s fine and leads to relatively minor hacks or technical debt. Other times, it’s not fine, because the violated assumption can be much more easily remedied by going up a level of abstraction and changing the domains of our components. Often, the assumption that didn’t hold in Service A also impacts Service B, and doesn’t hold their either.

Maybe that will result in splitting the problem into one more service; maybe it will mean that the domains of each service need to be adjusted so the issue is isolated into one of them; maybe it means that we chose to split the problem up along the wrong boundaries to begin with and need to reconsider them entirely.

My point is - starting at the most abstract level and working your way down is powerful, but you don’t always have all the information necessary the first time you walk down that complexity tree.