Not OP and no examples at hand I can share, but I'll try and describe my process:
While not pseudocode per se - my offline coding is predominantly outlining structures and data flows; so how I would structure the application (classes etc - where what code would reside etc). Then I expand from the structure to start moving the data objects themselves around (also giving an overarching structure to the data objects as well), where the flow / control logic starts coming again. Sometimes I'll write a few transformers / mappers there as well if they're needed when sending / fetching data from a few places.
Usually you can speed this up greatly by following the conventions of a framework; for webapps I would design the models/controllers/routes/views, mobile apps would be navigation tree, views (screens), components, and if there's a lot of data, then mappers/reducers etc. So it's usually small descriptions (even one or two words) of what a given class/object/action is doing, where it's coming from and where it's going. I can then expand this to be very specific with fields, routes etc, and what they're all doing.
Having that basic, overall structure done offline means I can approach the coding with purely an implementation mindset and don't have to worry about the "big picture" when doing all the small bits - when you start coding immediately you're on a bit of a discovery path with the big picture, and the implementation details, and changing stuff on the fly etc, which can be rather time consuming / side track into different places and so forth.
Most of what I do is just take data from one place, change it somehow, and present it somewhere else - so it makes the above fairly easy and effective for my work.
Learn python. Seriously, I fell in love with python when I noticed it looked just like my psuedo code.
As to your question of depth, I start at the highest level if abstraction I can get away with, assume that some magic function exists and does what you need. If said function isn't in the standard library, implement it if it's simple, implement it, just know that you're getting closer to actual code the more of these functions you flesh out, and some of them are likely to be libraries, you'll want to look up later.
While not pseudocode per se - my offline coding is predominantly outlining structures and data flows; so how I would structure the application (classes etc - where what code would reside etc). Then I expand from the structure to start moving the data objects themselves around (also giving an overarching structure to the data objects as well), where the flow / control logic starts coming again. Sometimes I'll write a few transformers / mappers there as well if they're needed when sending / fetching data from a few places.
Usually you can speed this up greatly by following the conventions of a framework; for webapps I would design the models/controllers/routes/views, mobile apps would be navigation tree, views (screens), components, and if there's a lot of data, then mappers/reducers etc. So it's usually small descriptions (even one or two words) of what a given class/object/action is doing, where it's coming from and where it's going. I can then expand this to be very specific with fields, routes etc, and what they're all doing.
Having that basic, overall structure done offline means I can approach the coding with purely an implementation mindset and don't have to worry about the "big picture" when doing all the small bits - when you start coding immediately you're on a bit of a discovery path with the big picture, and the implementation details, and changing stuff on the fly etc, which can be rather time consuming / side track into different places and so forth.
Most of what I do is just take data from one place, change it somehow, and present it somewhere else - so it makes the above fairly easy and effective for my work.