Vive la différence - and you'll still be able to do it your way!

That's not how I do things in math. I always need motivation first. So I start with the theorem, look at a couple of examples to see why this theorem is interesting, and then the various lemmas leading into the proof. So that means I really like declaring but not defining the public interface first, and then define the private helper functions, and finally definitions for the public interface.

Perhaps the difference is having algorithm in your head and just putting it into code, versus only knowing the top level work to be done and implementing the needed operations later.

If I am writing some kind of service, I would write the main public functions first, using undefined functions in their bodies as needed. Then I would implement those functions below.

I think you mean it in the context of proofs, right? Proofs are indeed often best written in a topological order: a series of true statements, where every reference refer backwards.

You don't often see

    Answer = A + B, 
    where 
    
    A = ...
    ...
    B = ...

albeit you sometimes see it, and it is totally valid. For proofreading something, it makes a big difference: if things are in a topological order, you can simulate a constant memory finite machine. If they are not in a topological order, well, probably you better just rewrite it (or at least I do).

For most other things, I usually prefer the bird-view first, when I am doing or reading some elses math.

Funnily the language Haskell which operates on definitions, is very order independent, it even allows circular definitions. I like it for leetcode and such.