Code is so abstract, which is why we use metaphors and mental models.
Are you capable of describing some of your mental models or visualizations that form as you code?
I know, this answer may be tough to articulate, so I'm not expecting perfect answers, just a discussion.
Latest comments (33)
I find that an unreasonable number of useful mental models boil down to graphs (the graph theory kind and not the line plot kind) where nodes depict system components and edges depict interactions between those components. Alternatively, nodes may depict states and edges the transitions between states (a state machine.)
Create diagram, I'm using grafcet diagram which is so much better than flowchart or UML (free figma kit grafcet.online)
Just like @nestedsoftware , I'm a very visual person. If I say I understand something, you can be sure that I can draw you a model of what that thing is. When I code, it's very much like I was in Tron, I live in a visual world of code. It's hard for me to describe, but let's try. When I'm using a collection's method like map or reduce, I'm visualizing all the items very much like the illustration on reactivex.io/. I'm also able to zoom into the data structures and logic of the code. I also do a lot of blackboxing where I visualize every piece of logic as just its inputs, a label of what it does and its output. And then I recurse.
Visualizing a solution some technical architecture is quite relevant to me in my role as a tech lead. I always struggle with this, but I always look to improve my visualization skills to keep the project team's ride a smooth one. For me, translating what is in my head to paper is the most challenging aspect.
Since being diagnosed, I have attributed my ongoing visualization struggles to ADHD. That is not to say I am unique or that others do not struggle the same as I do. I always felt that I could solve problems in non-linear ways but strain when trying to replicate my path to a colleague. You could say the same of me when it comes to technical design and architecture. What is clear to me is obtuse and opaque to others based on my explanation.
I had an on and off relationship with UML, believing that it was the solution. I love structure, and boy does UML have structure. Unfortunately, one can spend an inordinate time modeling an entire system in vain before you ever communicate something useful to someone else. Not to mention that BAs, PMs, and clients love when you break out a UML diagram.
I did find something recently that seems to help me make useful visualizations for business and tech people that don't require hours (or days) of effort. It's the C4 model: c4model.com/. It's excellent in that it allows you to diagram a system in whole or part at various altitudes. It is structured enough to keep you from over-designing with enough flexibility to convey a variety of concepts.
I found it quite helpful in my current project and believe the team feels the same. I also used one of these diagrams to demonstrate a concept to business users with success. I highly recommend this model for those in a tech lead role.
In typing this out I realized my brain follows something very similar the MVC structure, regardless of what I am building, but substituting the view for "things that concern users".
I start by either drawing or typing out the workflow, so what steps a user will go through to accomplish the task. A lot of times this looks like a bunch of IF/THEN/UNLESS/SELECT statements.
Then from there I will visualize the data models to support that workflow, usually drawing boxes for tables and lines for joins, thinking about what the application needs to know at each step of the workflow. This also sets me up for visualizing the "controllers" and logic that connects the client workflow to the data model.
This is an exceedingly cool question!
I don't think I really have one, overarching mental model. However, I definitely have a bunch of models I tend to reach for a lot as tools. I've tried to condense a couple of them here:
ASSEMBLY LINE and ORCHESTRATORS
This is a metaphor I tend to use quite a lot, particularly for data transformation. I've used it successfully with scripts, functions, and classes.
I try to structure code so that one top-level component orchestrates lower-level components, but doesn't do any actual work its self. This lets me separate the sequencing or wiring of things from the actual implementation.
For visualizations, I tend to think of my orchestrators as the controls on a puppet, and the parameters to that orchestrator being the strings.
AXIES OF SEPARATION
When trying to subdivide problems, I try to keep in mind that there are multiple axies it can be split on. Some examples are:
1) By system (database, ui, theme, etc.)
2) By use case
3) By business object
I usually end up visualizing this as some sort of geometric thing (a cube or some such thing that I slice up).
Thanks for the awesome thought experiment!
Here is what happened recently to me: I completely underestimated the complexity of one requirement and started coding all the abstractions coming out of my mind, hoping this will resolve the task. Of course, after few hours I realized that I am producing a pile of crap which does not correspond to the requirement at all. Here is how I mitigated this:
Somewhere at this moment I reinvented the Test Driven Development, huh? LoL :)
It's like playing Advent or Zork. I did once spend a week learning JCL on a mainframe and had nightmares of flying though multi-coloured COND double negatives.
I write notes as I go, sometimes they can be raw input for a blog post, usually they are a rambling record of wrong turns and dead ends. I outline, rather than mind map, though sometimes that helps too.
UML gets a bad rap, as the kids say, and it's easy to forget it was carefully designed from years of experience to be the best tool people could come up with for this kind of thing.
Generating your code from UML hasn't ever taken off, but using it to document flows and structure in your code is really useful - and anyone with any experience in UML can recognise the symbology you're using instantly.
Where it falls down is in the difficulty to mesh documentation and code, and the simple fact that diagrams don't go into version control very well.
I came across PlantUML a year or so back - very late to that party. It allows developers to describe their architecture and models in a text-based declarative language, and PlantUML then spits out UML style visualisations in PNG or SVG. I've found that class diagrams, component diagrams, and sequence diagrams are amazingly useful tools to share knowledge, and the ability to place the diagram source alongside code means it can be maintained in the same step.
No more bad diagrams on a whiteboard drawn hastily!
I love PlantUML!
Also, huge +1 on UML being incredibly useful. Learning sequence diagrams was an absolute turning point for me.
I'm pretty sure I mentally model my code as a map.
When I'm reading through the code I'm think about where it will take me, the next land mark, the final destination.
If I take a wrong turn is that because I've read the map wrong or because the code is leading me up the garden path? So I backtrack and look for a familiar place to see if I can get on the straight and narrow.
When I'm writing code, I'm trying to leave good signposts for me when I follow in my footsteps.