why you should code, regardless the background.

First and foremost, I am not a programmer, have never been, and am highly unlikely to become one. I am a mechanical design engineer, and until some time ago I had not dealt with the coding too.
Although projects I partake in often vary, it is inevitable to repeat certain actions. And most of those repeatable actions can be optimized, if not automated. Hence each next time you execute an action that is similar or the same to the one you have already completed in the past; you are wasting your time. It is not my intention to say that programming is the solution for all burdens of daily engineering tasks, but I have two valid arguments that are backing up my thesis.

Programming helps to understand the problem, lots of them.

As the title stands, it helps understand, not solve. Here is why. As a design engineer, I often join the project in either the initial or early-stage where only the goal is defined. No deliverables, no milestones, no actions. In programming, when you build a project, you do it brick by brick. You are forced to break the problem down into pieces, which will be completed one after another. Regardless of the industry, if you want to build or design something complex you have to define steps. The computer is limited to running actions in sequence, one after another. Whereas in mechanical engineering there are no hard written limits, and we tend to leap forward with solutions or ideas. This may cause us problems that are difficult to overcome as we simply try to achieve too much at once.
Steve Jobs once said:

“Everyone in this country should learn how to program a computer
 because it teaches you to think.”

Most advanced systems in the world have fundaments simple as possible. It makes it easy to manufacture, maintain, upgrade and invent in the first place. And this is my message here, thinking like a programmer, or rather like a computer, will help you to understand the problem and hopefully solve it as well.

You do not need to be an expert to write a simple script.

You certainly have activities that you do over and over. If not on a daily basis, then at least every week. If you script them, they will take you less time which will increase your efficiency. The more you use it, the higher the profit, and the time you invested in writing the script will quickly pay off. Moreover, if the action you just scripted is realized by your colleagues as the ell, the whole team benefits.

I tend to work with Finite Element Analysis software and regardless of the project, certain actions are just the same. You always must define materials, loads, constraints and if you work with composite materials, you must define layups on top of that. Several plies differ between applications, but quite often there are more than 10 of them. Considering isotropic characteristics of the structure you have to define different angles or different weaves of fabrics. It sums up a significant number of variables you must apply to the model. Every time you build it. And that costs time, lots of it.

It is not difficult to automate that, even partially. Based on the Pareto principle you can achieve roughly 80% benefit from 20% of your process improvement. And as mentioned before, if you invest your time to achieve that 20%, your entire team might benefit from the latter 80%.

Sometimes it is worth investing.