I like the analogy of software engineering and gardening. I believe in the power of analogies in conceptualizing abstract problems and I think it's useful to be able to compare two fields (excuse the pun) and ask yourself, "How are these two different, and how are they similar?"
Comparing software to construction has been very useful in the past when I communicate technical work to non-technical people. In my experience, comparing a piece of software to a building -- either a building that's in the process of being erected or, say, a derelict building that's being repaired -- is a very tangible, visual and intuitive way to communicate progress.
It's also a good way to explain the intricacies of software development. I don't know much about how buildings are actually constructed, but I can compare framework code to the building's foundation, or inter-process communication to the pipes or electric wiring in a house, etc.
I tend to prefer the building analogy a bit more, because one of the big disconnects I've found among people who don't understand tech and people who do, is that the former group tends to assume that things are a lot more automatic than they really are. A plant may be able to grow on its own with little supervision, but a building needs to be consciously built and then consistently repaired and maintained if you want to keep it standing.
For instance, I have an app I develop on the side, when I have free time. Sometimes I don't touch it for months, and usually, when I return to my codebase after a few weeks of absence, the chances are good that I spend a bit of time updating dependencies, rebuilding a cache, fixing a permission problem that edible mushroom growing kit crept in when another piece of software was installed, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I like the analogy of software engineering and gardening. I believe in the power of analogies in conceptualizing abstract problems and I think it's useful to be able to compare two fields (excuse the pun) and ask yourself, "How are these two different, and how are they similar?"
Comparing software to construction has been very useful in the past when I communicate technical work to non-technical people. In my experience, comparing a piece of software to a building -- either a building that's in the process of being erected or, say, a derelict building that's being repaired -- is a very tangible, visual and intuitive way to communicate progress.
It's also a good way to explain the intricacies of software development. I don't know much about how buildings are actually constructed, but I can compare framework code to the building's foundation, or inter-process communication to the pipes or electric wiring in a house, etc.
I tend to prefer the building analogy a bit more, because one of the big disconnects I've found among people who don't understand tech and people who do, is that the former group tends to assume that things are a lot more automatic than they really are. A plant may be able to grow on its own with little supervision, but a building needs to be consciously built and then consistently repaired and maintained if you want to keep it standing.
For instance, I have an app I develop on the side, when I have free time. Sometimes I don't touch it for months, and usually, when I return to my codebase after a few weeks of absence, the chances are good that I spend a bit of time updating dependencies, rebuilding a cache, fixing a permission problem that edible mushroom growing kit crept in when another piece of software was installed, etc.