In defense of programmers and coders

Off Topic
1

warning - this is a bit of a rant and I welcome all appropriate discussion :slight_smile: And this is not directly related to any recent posts, but rather a nagging thought that I’ve had for years and really just needed to get it off my chest.

As a programmer by training…

In situations where we assume it’s just an illogical/bad design, or lazy programmers, or “why can’t it just…”, or “It seems stupid that I have to this thing to make it work the way I want to”… or any other number of slurs against products we own and use…

Two thing come to mind.

First - if we, as the technical subject matter experts of our companies, say these thing to our users, then we are part of the reason our users dislike/hate the product they are using - and ultimately complaining to us about every time they have a problem. It’s a circle, and we need to be the neutral party outside of the circle - for the good of the users and the good of the company. We cannot afford to gang up with the users against something we own but rather strive to find the information and the understanding to help us enlighten the users and create more harmony rather than discord. Even if the product can’t do exactly what you want, we all know that there is usually a way to change the process or the product to get around what ever issue everyone is having.

Second - I always find myself considering the limitations of the framework in which an application was written. Most users don’t know about or understand this part of the process - and we don’t expect them too. At some point we always find ourselves up against the ‘wall’ so to speak where what we want to do just isn’t possible at a code level. I’m sympathetic/empathetic and think the the developers should have a crack at it first in order to tell us it just can’t be done before we get too frustrated. And then it’s our job to try and bridge the gap of understanding between the product and the users.

I practice all of this myself, and honestly it works - 95% of the time. The rest of the time I get a reaction that is more like “who’s side are you on?” rather than “thanks for explaining it” - and I’ve been known to over-explain things to my users… But I can tell you that my users do not hate Epicor, but they still have a list of ‘frustrations’ - and I’m working on those.

Peace, not war - or something like that :slight_smile:

9 Likes
2

I am so guilty of this!

1 Like
3

What awesome food for thought. I’m not a programmer, but on the implementation side of things the exact same issues exist. When I’m training or developing processes and we run into one of the more common frustrations (for instance, when you push a quote to an order, you just get a message telling you the order number which you’d better write down instead of just opening Order Entry), I’ll often bring up a discussion of how this all started and has grown so tremendously that these are minor irritations in the Grand Scheme of Things… and as you say it works MOST of the time.

2 Likes
4

I get what you’re saying here, but I’ve personally run into the opposite problem far more often: vague, inconsistent, legacy business processes that would be vastly improved if it stuck to the Epicor model. Not that the ERP is the “best” model, just that it is a model.

Can’t say I’ve ever been accused of playing for the other side. Then again, I tell people that my relationship with Epicor is like an angry old couple that argues constantly but still stays together out of pragmatism, it’s a hatred born of deep intimacy.

for instance, when you push a quote to an order, you just get a message telling you the order number which you’d better write down instead of just opening Order Entry

Pretty sure this could be done in a fairly straightforward post-process BPM or two. Not that most people would know that since whole swaths of the system are effectively undocumented.

4 Likes