> I'm a visual thinker. For me drawing things on paper makes any problem easier to solve. I would suggest you try the same. Keep a pen and paper near your computer and reach out for them before you start typing code.
I feel the same way. Of course it's easier for visual tasks like this one, but I tend to think of programs developing in space and time as trees and graphs, even for abstract stuff like complex algorithms and data structures.
Though I think most programmers are more language-oriented. It is often hard for me to find the exact syntax required for coding a particular problem which is fully formed in my mind eye as visual steps. Programming languages are oriented to represent each concept with a precise linguistic abstract syntax, instead of representing concrete changes in the program state, and most developers don't seem to mind.
Same boat, checking in. My notebooks are full of scribbles even though I do lots of non-visual programming. It’s my primary thinking aid.
I’ve found this to work out well for me:
- Use languages and tools that let you defer correctness while prototyping. I lose track of “the bigger picture” if I have to context switch to thinking pedantically about syntax and type systems. That’s ok when everything is in place, but is disruptive when experimenting.
- Find good visualization aids, such as sequence diagrams, dependency trees, call graphs etc. Even if you just do it on paper, they can be great tools.
- Read up a bit about dataflow programming. It fits my brain very well, and you can apply the thinking in any language. (Unfortunately existing dataflow oriented programming environments are quite limited and come with other downsides).
Yeah, I've worked with dataflow languages and they're a very good fit for data transformations (not so much for complex runtime control flow). Functional-reactive languages like spreadsheets also make it way easier to reason about than imperative programming.
I like environments where you can keep visualization aids close to the code to which they apply; nowadays, that means using online notebooks a la Jupyter and ObservableHQ, or at least markdown files with a preview plugin integrated in your IDE. There you can represent diagrams as code, like Graphviz and Mermaid.
I long for the day that those visual representations can be accessed programmatically and used as part of the code itself, like VB6 interactive widgets were created graphically yet usable in the application; e.g. creating state machines visually by representing states and transitions as boxes and arrows, then compiling the diagram to add conditions and access their values from code (there are some libraries doing this in some environments and languages, but I'm not aware of one that is portable to many languages). I think we're really close to that being possible with modern languages.
I feel the same way. Of course it's easier for visual tasks like this one, but I tend to think of programs developing in space and time as trees and graphs, even for abstract stuff like complex algorithms and data structures.
Though I think most programmers are more language-oriented. It is often hard for me to find the exact syntax required for coding a particular problem which is fully formed in my mind eye as visual steps. Programming languages are oriented to represent each concept with a precise linguistic abstract syntax, instead of representing concrete changes in the program state, and most developers don't seem to mind.