When I first starting working as a computer programmer, I constantly ran into the problem of bosses who wouldn’t appreciate the severity of the problem I was describing to them. After a number of years I improved on the situation by modifying the language I used when explaining a problem. This didn’t solve all of my employment issues (at the time I didn’t fully appreciate how dysfunctional the communication chain was in my employers hierarchy) but it helped substantially.
To understand what words mean when you are talking to programmer I recommend this article by Charles Miller. Here is an excellent example of a software engineering concept that non-programmers often fail to understand:
To a programmer, a problem is trivial if there is a clear solution, and the only thing that needs to be done is to implement it.
The only caveat is that triviality refers to how hard the problem is to solve, not how hard it is to implement the solution. So there is no necessary relation between a task being trivial, and how long it takes. To the programmer, once the plans for the bridge have been drawn up, the materials chosen properly and the model tested for how it would survive wind, traffic and earthquakes, actually building the bridge is trivial.