Programmers who go off script

theColonel26 said:

Well first of all you shouldn't use controller tags in any logic, They should be mapped to Program Parameters using Connections. Other wise you are creating a tightly coupled mess.

As for as "_CS" I think it is silly in this instance, but having structured and detail naming conventions for Tags is a good idea. Some of my Tags actually hit the tag character limit in Studio Designer, but no one will ever question what that tag is for, If I have tags that are of differnt Types I will often do something like

• ScaleA_LiveWeight_Int and ScaleA_LiveWeight_Float
• ScaleA_LiveWeight_Int_LB, ScaleA_LiveWeight_Float_LBS, ScaleA_LiveWeight_Int_KG, ScaleA_LiveWeight_Float_KG

I think the biggest issue you have is buy in from him on your standard practices. Standards are not intended to be unchangeable. Let him influence them. If you want him to stop deviating then include him and the decision making for your standards. Otherwise you can either live with it or fire him. I doubt you will get him to change otherwise. These things are a 2 way street, everybody needs to give a little, to form a consensus.




HOWEVER, If he did this with me He would have an unfortunate industrial accident.

Click to expand...

If you created six tags like that for scale weight components I would shoot you. Create one tag of a UDT with each element. I loathe opening up a controller tag db and seeing 1000s of tags like this. Organize them into components.

Now, not picking on you, but just demonstrating that one person's convention is another person's pet peeve. So to the OP, nothing that programmers doing is really an issue.

CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.

HMI - yeah if not using alignment tools, shoot the *******.

theColonel26 said:

Well first of all you shouldn't use controller tags in any logic, They should be mapped to Program Parameters using Connections. Other wise you are creating a tightly coupled mess.

Click to expand...

Sure... let me know when the cross reference takes parameters and connections in account and I'll consider it.

robertmee said:

NEQ move saves scan time

Click to expand...

Even if NEQ takes marginally less scan time than a MOV, I think most would agree that the penalty on program size and visual distraction far outweighs it.

Gotta side with OP on this one.

It’s been my experience that programmers in general are the most undisciplined, unreliable, & unorganized people I have ever been around. They generally mean well but tend to be very narcissistic.

It could be that their unique ability to create things is related to these traits but it has usually created problems on projects where teamwork is necessary.

If these comments of mine seem harsh, all I can say is this was my experience with programmers for close to 40 years.

I truly believe that programmers may be among the luckiest people to have been born at a time when their particular skills were needed, otherwise most would be homeless & be unable to maintain a job or relationship.

dogleg43 said:

It’s been my experience that programmers in general are the most undisciplined, unreliable, & unorganized people I have ever been around. They generally mean well but tend to be very narcissistic.

It could be that their unique ability to create things is related to these traits but it has usually created problems on projects where teamwork is necessary.

If these comments of mine seem harsh, all I can say is this was my experience with programmers for close to 40 years.

I truly believe that programmers may be among the luckiest people to have been born at a time when their particular skills were needed, otherwise most would be homeless & be unable to maintain a job or relationship.

Click to expand...

Yeah, that's not going to go over well. Have been a programmer for 35 years, successfully ran my own business for 21 years, happily married for 20 years.

I would suggest you're over compensating for some deficiency in your life to make such a terrible broad sweeping statement.

Well, programmers do tend to be prima-donnas, at least a little. Even the disciplined, the reliable and the organized ones.

Just ask mechanical designers or machine builders

robertmee said:

Yeah, that's not going to go over well. Have been a programmer for 35 years, successfully ran my own business for 21 years, happily married for 20 years.

I would suggest you're over compensating for some deficiency in your life to make such a terrible broad sweeping statement.

Click to expand...

I am so very happy for you & your successes. For me, programming was never my forte so I went more to the hardware, design, & project management side of things. If that’s a deficiency, then so be it.

I really don’t care if my comments “don’t go over well.” These have been my experience. Cannot change that at this point.

dogleg43 said:

I am so very happy for you & your successes. For me, programming was never my forte so I went more to the hardware, design, & project management side of things. If that’s a deficiency, then so be it.

I really don’t care if my comments “don’t go over well.” These have been my experience. Cannot change that at this point.

Click to expand...

How long have you been on the hardware side?

I'm a little surprised you don't program, it'd be easy to jump into the easy stuff and if you are with a company that knows what standards are... it would be even easier to get into the more complicated projects.

dogleg43
You are correct. The best creative types are different people.

@dogleg43
There is no progress if you obey all rules. Also there is no progress without good organization. I think that best programmers are well organized and have ability to think outside of box.

dogleg43 said:

I truly believe that programmers may be among the luckiest people to have been born at a time when their particular skills were needed, otherwise most would be homeless & be unable to maintain a job or relationship.

Click to expand...

Kind of a bizarre statement since probably every programmer who ever lived had a different job before doing that. And consider how most controls guys program as only one of many responsibilities.

Ah yes, the cowboy approach. I've spent 4 decades doing primarily service work, including repairs, mods, and upgrades to a surprising array of inustrial and commercial machines over the years.

Very little in the way of formal programming education, but I've seen pretty much every style of programming you can imagine. My most painful job was replacing a half dozen SLC150's with a SLC500 with RIO. No quote as it was an emergency rebuild after a fire. Ported most of the original code in from dot matrix copies of the original programs as per the in-house tech asssigned to help us. The senior tech for the company near to tore my head off as we were doing startup and debug when he saw what we had written.

The assigned tech (assigned by the senior tech) failed to mention the very rigid naming convention that had been instituted in the rest of the plants SLC500's. That turned into a long night.

The worst piece of programming I've run across was on a silk screen printing machine. Multiple nested loops, 5 shift registers(3 of them masked) and not a single bit was directly addressed. This controlled an up/down motor and a pair of sliding squeegees. My best guess was that this guy had experience writing boot programs for microprocessors, brilliantly compact, and utterly unreadable.

The moral of all this to the OP is, yes I feel your pain, but trust me when I say it could be so much worse.

rupej said:

Kind of a bizarre statement since probably every programmer who ever lived had a different job before doing that. And consider how most controls guys program as only one of many responsibilities.

Click to expand...

Nope, I stand by that statement. Seriously, MOST of them that I worked with rarely showed up at the designated time to meetings or whatever. This would not have been tolerated if others did it but supervision would just shrug and say “well, that’s just how Joe is.”

The above may not be your experience but it has been mine with MOST programmers. It’s just them being unreliable and uncontrollable for “normal” job functions.

It’s not unrealistic to establish a spec for certain things and then enforce it. The problem is that specs are usually developed by committee, and you know what happens there. Some of the best running jobs I’ve been on have been ones with rigid specs for programming and hardware, (mostly automotive). Have you ever seen a Tesla spec, the go I great detail for their software spec and how they want it done.

robertmee said:

yeah, that's not going to go over well. Have been a programmer for 35 years, successfully ran my own business for 21 years, happily married for 20 years.

I would suggest you're over compensating for some deficiency in your life to make such a terrible broad sweeping statement.

Click to expand...

+1