Time and time again I am stumped by the following problem: WHEN do I stop helping ? when is it enough, when do I get the feeling I`m taking over their code ?

...

Don't get me wrong here, I really try to explain the problem with their code, and the reason why I would do it differently. But these people aren`t coders, they`re application managers, writing little tools to make life a little easier on themselves.

As I see it, there are (at least) two ways of looking at your problem: the pedagogical ("How do I best teach these people?") and the business ("What's the best way to get the job done?"). (I'm an academic, basically, so I like the first one, but YMMV.) Which way you want to look at the problem is going to affect whether you step in and write someone else's code.

If you're trying to teach someone, it's probably best to get them to code as much as possible, and write code "for" them only to illustrate a new point, or to provide a framework for what they're doing. (For instance, in a machine learning course I took a couple of years ago, we were handed most of a neural networks package fait accompli. Our task for that assignment was to write the backpropagation code, not the framework.)

In a business context, things get more complicated. It might easily be worth your while to write a few little tools for these managers, especially if they're trivial (to you) scripts that you can toss off in ten minutes, but that take the managers hours to produce broken code. In that case, it's far better to take ten or fifteen minutes of your time than it is to take two or three hours of theirs, and get a better result.

On the other hand, teaching these managers the basics of good programming might be spectacularly worthwhile. One thing I've noticed about programmers (mostly myself) is that as we learn, we spend more time coming up with ways to get the computer to do our work for us. (Start with code to solve tedious problems, then code to write tedious code, and so on.) Getting consultants and managers to think in terms of automating tasks, and to push the boundaries on what they consider automatable, might be a huge win. In that case, you'd be better off taking a more pedagogical approach.

--
:wq