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.
Top comments (33)
That's an interesting question! I never thought about how my mind works when I try to solve coding problems.
My favorite thing to do when I'm stuck with a problem, is to go for a little walk and to start thinking about it.
My mental model could be described as little piles of requirements, problems and possible roads to take lying on the ground, which I can skim, sort or shuffle. Without having to think about it I tend to grab one or multiple connected problems in the process I either find most interesting or which seem to be the most important. I don't have to think it all through. Knowing that there is a solution and being able to roughly picture it is enough to go on and makes it clearer what other stuff I should or should not worry about and - also very important - what to do next once I get back to the computer.
If I'm unable to solve what I think is a major problem or at least to identify the sensible next step, I try to take a step back (which is a 100 times easier when you are NOT sitting at your computer). Very often I find that I can ignore a problem completely, that a requirement might require some clarification or rethinking or that it might not such a bad idea to go with a much simpler solution instead, clearing all the piles away, which is always a relief :)
To make sure everyone (future me included) is on the same page, I tend to make doodles out of logic and data.
Then I use mindmaps and Mermaid's Live Editor [1] to create flowcharts/sequence diagrams to keep track of my thoughts and to share it with my coworkers.
Here's a recent example of a pdf creation process [2] for this API I'm working on.
[1] mermaidjs.github.io/mermaid-live-e...
[2] bit.ly/2ksIusm
Nice, I've not see mermaid before - I've used planttext.com and draw.io for much the same purpose as well as more "formal" documentation. Whatever the tool, I definitely agree that sometimes you have to really see it to spot flaws in the logic.
Seeing the flow is so much easier for everyone else when we're trying to communicate how we think it should be done.
Nice, Mermaid looks very similar to PlantUML's notation. Maybe the inspiration was derived from PlantUML.
I've never used PlantUML but if it's similar, I'd love it ! I find it so much easier to draw graphs with such notations :/ it's easily commited within a git repository too !
Edit: I just checked out PlantUML. I'm definitely going to try it !
One thing that took me a long time to figure out is that I am a very visual thinker.
For example, in math, an equation doesn't mean anything to me until I can represent it graphically in a way that gives me the essence of what the equation means in the particular context that I care about. After that I can learn some rules for manipulating stuff algebraically, but for me the visual intuition always has to come first.
I tend to apply this even for things where maybe there isn't an obvious connection. For example, when it comes to business rules, I tend to think in terms of hierarchical structures like trees, or in terms of graphs - little boxes with arrows between them... Sometimes I also think about connecting things, or rotating them into place, or moving them around in a list...
I've also learned that for me, it's important to always start with a simple scenario and then to gradually extend it bit by bit.
If some abstraction does not match your mental model, it's likely a sign that it's simply a wrong abstraction.
The right abstraction must be obvious and laughably simple.
I have to draw out little boxes on a real life paper pad, and normally have to write out a few rough pseudocode experimental implementations to see if I'm headed in the right direction. Trying to keep the work in small-as-possible chunks helps too, but not always feasible if you're writing some huge new feature that only works when it's all done... I must admit even after many years I still find it a real struggle to split up big tasks into smaller, more manageable ones, even though I know this can often lead to issues later on...
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 find myself almost always reaching for OOP when I'm trying to reason about code. That's because I have a Ruby background and I still think OOP is a good idea in a lot of places.
In situations where OOP doesn't make sense, I try my hardest to think about data instead of logic and abstractions. I try to reason about that data. That may not make much sense, but I like to imagine that I'm pretty decent at pulling apart implementations and putting them back together with less logic.
I completely relate to this (except I have Python background instead of Ruby).
The Rubber Duck Method!
I came to the realization that if I'm turning inward, and just silently think about structural problems, a lot of times I loose references and get lost. So the solution for this was to explain my problems in words. Loudly.
Think about it: While thinking you often just shuffle around shapeless concepts in your head, often overlooking details. But if you force yourself to articulate your problem, you end up solidifying your concepts as words, and that often leads to a realization.
In the office we call this "The Rubber Duck", because how you do it is you roll to your team members and try to explain them what your problem is. They might be able to help, but most of the time they could have been just rubber ducks, because you end up realizing your solution while explaining, without them saying anything. I'm sure many of you can relate to this.
Yup, I often will grab a co-worker and ask them to just listen to me talk this out and ask any clarifying questions they need, and I do the same for them. Having to articulate it out-loud is so helpful
I like to try to "keep the entire program in my head" if possible; which helps to visualize how changes affect different parts of the code, and what side effects I have to watch out for.
That's one reason I love React - it lets me think in components, instead of in systems; so I only have to worry about one component at a time (for the most part) when developing.
As far as visualizations... huh - I don't think I've ever thought of what I visualize when I code... but I suppose I try to understand what data there is in the program, and how that affects the output. I really like the idea that changing data directly changes the output - which is (again) why a framework like React is helpful: the output on screen only changes when the data changes.
Interesting to think about, thanks! I may edit my answer after thinking about it some more :)
I have always said that I can ”see” systems moving. I cannot actually describe that very well as I don't see code text or any diagrams. Algorithms and iterators are probably easiest to describe as they are little mechanical machines or motors whirling away. My wife can write extremely sophisticated SQL that I simply cannot as I want to ”see” how it works (the actual plan) rather than the abstract specification. She described one really complex query saying ”... and you grab both ends and pull it and ta-da it flips right side out and you have the answer!” 🤔 I wasn't able to grok it.