Is moonlighting allowed for contractors?

[daniel1211]

I am currently contracting as a Instrumentation Engineer for a very large engineering company, like with any other company this job has it's pro's and con's. Since I am doing the exact same job as an actual employed engineer my contract is only for 1 year and once the year is up I must take a 3 month "vacation" before being able to renew the contract for another year, also I know I shouldn't be surprised but I am amazed by how some of the common responses I get from the engineers and scientists that I work with are "I don't know", "I don't know how it works, it's a black box", "Why do you want to collect data, it should be plug and play".

That being said I really enjoy the work I am doing and I am really grateful for the opportunity that I have, but I struggle with whether I should work for a company or at least this section of the company with individuals that do not promote knowledge and at times it seems as though they actively try to hinder it.

 

[FactChecker]

Being a temporary employee puts you in an awkward situation. They may not know if explaining things to you will help them or just take up their time till you leave. Try to make your questions be something that will benefit them immediately. There may also be restrictions on what they are allowed to tell you. Or they might just be jerks.

 

[daniel1211]

I agree with that, and I always make sure that if I am asking questions I do my research first so that I'm not wasting anyone's time. But the responses seem more of actual lack of knowledge, after noticing this I started to research more and study more so that I could take advantage of the lack of knowledge to establish myself as the SME. The more I learned the more I realize how certain things that are being done are actually hindering progress and in some cases causing the contractors to not be able to do there job correctly. Another contractor and I even took it upon ourselves to write methodology books so that they could help with training, but as you said though I am a temporary employee so there is not much I can do... we were thanked for our initiative but unfortunately nothing was changed.

This is not everyone of course but most of the engineers are so focused on there own projects that they either ignore it or if they do try to help they are soon distracted by their own workload.

 

[JakeBrodskyPE]

I am currently contracting as a Instrumentation Engineer for a very large engineering company, like with any other company this job has it's pro's and con's. Since I am doing the exact same job as an actual employed engineer my contract is only for 1 year and once the year is up I must take a 3 month "vacation" before being able to renew the contract for another year, also I know I shouldn't be surprised but I am amazed by how some of the common responses I get from the engineers and scientists that I work with are "I don't know", "I don't know how it works, it's a black box", "Why do you want to collect data, it should be plug and play".

That being said I really enjoy the work I am doing and I am really grateful for the opportunity that I have, but I struggle with whether I should work for a company or at least this section of the company with individuals that do not promote knowledge and at times it seems as though they actively try to hinder it.

I&C Engineering is a broad and a surprisingly deep field of study. These engineers deal with everything from actuator response dead times to instrument lag, network security, real time systems, Cv profiles of various valves, cavitation of pumps, packing materials for valves, steam flashing, and a whole host of many many topics related to instrumentation physics and limitations.

I am thankful when these people tell me "I don't know." I see it as being honest about what they're doing.

As for data collection, this is one of my recurring rants. I deal with a constant stream of nitwits who see all industrial control systems as a fountain of high fructose data that they want to suck on. They want all the data, all the time, to millisecond accuracy and performance. Why? Well that's when I get talk of synergies, sharing of information, and the ability of the boardroom to drill down to the specific faulty sensor (as if they really cared). The truth is that these idiots don't know what's going on; they don't want to look stupid in front of the people who actually do the work; so they gather all the data and hope that they can learn about this stuff without actually talking to anyone. This makes them feel smart. Yet, no matter how much data they get, they still won't understand what they're seeing. But don't try to tell them that.

The other rant about data collection is that it must be actionable. Otherwise it is a waste of everyone's money and time. Major events happen and then you get this flood of data that you have to sort through. This is especially the case with object oriented devices. Usually what happens is that some consultant specifies that it should generate alarms for every little thing because "someone might want to know that." And then a storm hits. The operations center is lit up with so many alarms that people seriously suggest using artificial intelligence to keep up and sort through what all these alarms mean.

I have a better solution: Create summary alarms and then send just those system alarms. Those systems should tell the operators who to send to where and with what resources. Any further data on the subject can be stored on site for forensic or diagnostic purposes. There is no good reason to collect and store it with the rest of the process data.

That response about data collection is from a voice of experience and understanding. Do Not Collect Data You Do Not Have An Immediate Operational Need For! It just confuses everyone. Been there, Done that, Got the T-Shirt, Wore it out, and threw it away.

Note: I am a control systems engineer with nearly 30 years of experience as a technician and as an engineer. I live with my creations. It keeps me honest. If our work fails in the middle of the night (and it has), I get called back to work. It has happened on Christmas Day at 5 AM. It has happened at many inconvenient times. We do everything we can to avoid such problems.

(Welcome to the real world of process engineering)

 

[analogdesign]

Also, you shouldn't expect the other employees of your organization to know the details about how the equipment works. I'm an engineer as well and if you asked me technical details about how a specific oscilloscope in our lab should be configured or how to use our curve tracer I would tell you "I don't know". Experienced engineers know a lot about their specific domains and also they know how to learn. So, I needed to know the details about a piece of lab equipment I would crack open the manual and start playing with it, just as you should do.

You really shouldn't expect full-time engineers or scientists to have God-like powers of prescience. They are people just like you, with a bit more experience.

 

[daniel1211]

Thanks for the reply's and these are very good points

You really shouldn't expect full-time engineers or scientists to have God-like powers of prescience. They are people just like you, with a bit more experience.

I suppose it's not so much the answer "I don't know" by no means do I expect people to know everything about everything.

I just find it disconcerting when I request more information about a task or information so that I can troubleshoot a piece of hardware from my supervisor and his responses are "I don't know, when it comes to things like that I stick my head in the sand and ignore it" or "It's a black box to me, I just turn it on and it should work".

 

[JakeBrodskyPE]

I just find it disconcerting when I request more information about a task or information so that I can troubleshoot a piece of hardware from my supervisor and his responses are "I don't know, when it comes to things like that I stick my head in the sand and ignore it" or "It's a black box to me, I just turn it on and it should work".

I'm not fond of that answer either, but at some point, you have to stop asking questions and just rely on the fact that it is like that. For example, we don't ask questions about how the bricks of a building were manufactured. We presume they have certain characteristics, wear expectations, density, and chemical behavior.

Likewise, a network has some characteristics of how it communicates from one place to another. We simply presume they work within certain parameters. Yes, I've seen devices with fundamental problems that prevented them from working properly (it didn't have proper gratuitous ARP capability). Those fundamental problems do exist, but they should be rare.

The attitude is no fun and it's not all that nice. But you do need to realize that it is essentially a coping mechanism for focusing on what one is being employed to design for.

Not everyone has a desire to poke around in what makes for a black box. Do you really care how a variable frequency drive does what it does? No. What you care about is that it operates within the design parameters you were given. You can reverse engineer it some day when you have to select from half a dozen vendors. Until then, focus on what matters.

 

[CWatters]

Isn't one of the advantages of being a contractor that you can work for more than one company at once?

 

[analogdesign]

Isn't one of the advantages of being a contractor that you can work for more than one company at once?

I've never met a contractor who didn't have a stipulation against moonlighting in the contract.

You might be thinking about consultants who typically are called on as a last resort when things get hairy. They are usually super experienced experts in their fields and command a ludicrously high hourly rate, so we try to minimize the number of hours they spend on the clock.