Skip to main content

Mental models

Mental models are a valuable tool for engineers.

I do engineering as a day job. Often diagrams, drawings, and other visuals will be created to help convey information to customers and facilitate discussions. Visuals, while always leaving out some details, and in fact the challenge of creating visuals being knowing what details to leave out, helps immensely with audience engagement.

gitGraph commit commit branch feature commit commit commit checkout main commit commit merge feature
A random git feature branch development model diagram

A visual's layout, colors, blocks, arrows etc are far easier to consume than a wall of text. In spite of their relative simplicity when compared to text, they can be constructed to represent complex systems, relationships, processes etc.

We create a lot of visuals to help convey information to others, are we using them enough when conveying information to ourselves?

stateDiagram direction LR state "Mental Model" as mm Idea --> mm Idea --> Visualization mm --> Idea mm --> Visualization Visualization --> mm Visualization --> Idea

How can you make better use of visuals?

Sketch them out

I like to keep scrap paper around for notes, sketches etc. Sketching or drawing on paper, even if you end up tossing the paper out later, lets you quickly iterate on a visual, often much more quickly than making use of a tool like Visio, PowerPoint etc. If you've got an iPad with a stylus or some other electronic drawing tool that can work too. The imporant part is that it has to be quick and not feel permanent. Quick means its easy to get started and stop. Non-permanent allows you to take more risks and be less concerned with perfection.

Make visuals anytime when you don't have a clear mental model

I find that for many cases I can build a mental model of a system or a design by listening to someone explain the design in words. Often that's what I'm doing as I'm listening to someone describe a potential product, a software class, or an approach of code or data structure. It isn't about whether my mental model exactly matches theirs but rather that my mental model includes clearly the aspects that are critical to the topic at hand.

This can work if the person explaining it can do so clearly, and if the system is sufficiently simple. If the discussion is to help determine how to design something it may not be clear to the person explaining it. It may also be complex and multi layered. As soon as this occurs I find it helpful to apply the 'sketch it out' approach on paper, and/or ask the person to try to draw or sketch it out themselves.

Conclusion

I hope that this might encourage you to make even more use of visualizations. I'm no graphic artist or designer by any means. However I still enjoy putting together visuals, especially when they help to explain concepts and ideas to others.

Labels:

Comments

Post a Comment

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr...
5 comments
Read more

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...
3 comments
Read more

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...
2 comments
Read more