My mental model is "this beats the almighty fuck out of road construction." :)
The first is requirement gathering. This is essential to know what you are doing, be it from an internal customer or your boss. Best analogy I can think of is ask a 3 year old to describe in detail the house they live in. Enough that you can draw a picture of it and provide a fairly accurate floor plan. Floor plan good enough to use to order furniture against.
Design and coding others have covered.
Testing - ok inspect a car you want to buy ... in extreme detail. Write down the results.
Documentation - write a diary, detailed that if someone who read it they could impersonate you.
https://en.wikipedia.org/wiki/Unix_philosophy
Make small, quality, interoperable things, and glue them together for as long as you need them.
Writing an algorithm <-> Making a recipe (clear, explicit directions, missing details means that things don't come out as expected except by chance). Any analogy based on writing clear directions can be appropriate here.
My preferred analogy here is more like: The computer is the dumbest employee you will ever have, can you write well enough to communicate to it precisely what you want? Ever worked with a very literal person? That's the computer. It'll do precisely what you tell it to do, even if it makes no sense with a moment's thought.
Larger scale programming (software engineering) has better parallels to the design, and somewhat to the construction of, buildings. There's a reason we call them software achitects. The connection is closer to design work rather than traditional labor (construction). Where there is an analogy with costruction it's in project management generally, which is a discipline that spans all design and development fields.
Really, there are many appropriate model to consider and it depends on what you want to do.
I work in distributed, critical avionics software. I have an agent-based view of software as a consequence of this. I model (even single threaded programs) as a collection of agents communicating with each other (a classical view of OO, also related to the Erlang model, and Hoare's Communicating Sequential Processes (which I don't apply formally, but I keep the concepts in mind)). I encourage my new people to play with golang and erlang for a reason (though we can't apply either for reasons, they're great at informing the mental model I want them to have). But that's just the software design/writing/modeling aspect. There's the larger environment in which the software gets developed that also has to be considered.
Other people have a database oriented views, data flow oriented views, etc. Sometimes appropriate to their domain and background, sometimes not. You should learn all of them so that you can communicate.
===============================
Mental models are one of the most useful and most dangerous things. They're useful, especially when shared, because they allow you to communicate more effectively with others. They become dangerous when they go unchallenged. My agent-oriented view? Can you imagine someone writing (for a single 4MHz microcontroller with maybe hundreds of kilobytes of memory) in that model? Designing, maybe. But writing the code may require a more explicitly imperative style just for the constraints placed on the program. On the other hand, that explicit imperative style doesn't scale well to dealing with hundreds or thousands of servers (or in my case dozens of nearby radios in a mesh network). It's appropriate within the radio, but not when conceiving of the network itself as a computer itself.