How do they offshore IT jobs and address security concerns at the same time?

I've seen a number of indoor hydroponic installations. They all seem to have gone to LEDs. And these are for food production (exotic herbs, vegetables, etc.). What with the big money in pots grows, the extra investment should be a no-brainer. So much for the heat signature giving the location away to thieves or the local constables.

Yeah, I've heard the arguments that LED lighting isn't 'natural'. But some of the food farmers using these are on the cutting edge of holistic organic naturaopathic bullshit. And they don't seem to have problems with it. Stuff grown for sale to the local highscholl stoners should be a no-brainer.

Cheap solution

Voyager 1 replies, "What do you mean 'we'?"

Pursuant to your request that I enter into arbitration in place of a civil suit, I kindly refer you to the response proposed in Arkell v Pressdram

... by Korean shipbuilder ...... Hmm. On second though .....

Everyone knows that life was started when inanimate matter was touched by His Noodly Appendage.

What is the end product of this work? Source code?

If you produce source against a particular 'stack' (API, library version, framework, whatever) how do you know that the people next to you are using the same ones? And that the various modules your group produces will even build or link together? What happens if the guy in the next cubicle says, "This Dynedain guy is using the wrong version or fork of {whatever}. I'm going out to download and install the latest or the best and build my components using these. And if his stuff won't link with mine, tough." Who would stop him?

So, you wait until the sh*t hits the fan and then DevOps comes looking for whoever used the wrong tools or build configuration. The guy in the next cubicle says his favorite framework is better and that Dynedain guy needs to suck it up and redo all his work using the 'correct' environment. Antics ensue.

Somehow, I don't think your organization is going to score a very high SEI-CMM level. Forget ISO 9000 certification.

I assume you have various individuals/groups who have an interest in the systems you administrate. Users, developers, etc. Also regulators. Don't forget the utility of a good documentation system when the auditors come around*. So you need a process to keep them informed of the upcomming system changes. So they can ensure that their product or process isn't going to be broken by a change.

If you have relatively few of thes interested parties, the communications could be mandles manually and by you. If that community is large, the procedures need to be formalized and possibly automated. Having a CAB to represent your user community can offload the communications task from you. At the expense of some paperwork.

On the other hand, I've worked in organizations where the CAB was a make-work task for a few layers of management. People whos only other job prospects are standing by an off-ramp with a cardboard sign*.

*At one of my previous jobs, this was the acid test of the utility of our CAB. I had to fill out stacks of paperwork and await their blessing to make a change. But strangely enough, whenever the FAA came around, they were nowhere to be found. I had to walk the auditors through our systems myself.

I thought this was something we could use to exterminate all those smug bastards yakking on phones while driving or in line at Starbucks.

The least they could have done was to pony up for some Google Glass.

At least the homeless could have pawned them for some spending money.

Thank goodness that never came to be, #37809.

As a developer, what do you think your job is?

We may be suffering from a terminology problem here. I think developers produce code as their work product. Which is turned over to a build environment for subsequent testing and finally installation.

If you have a different job description for a developer, I'd like to hear it. I wouldn't hire it, but I always get a chuckle out of projects that are so deeply layered that there are people which we don't really know what they do.

If you produce anything that affects the configuration of the final product, it had damned well better be under configuration control. And that means your administrative 'privilege' is restricted by some processes and procedures. If you have them at all. That's the way its done in avionics, medical, financial and a lot of other software houses. If you are just hacking out games, then who cares? Fiddle with your development environment all you want.

No. Not if they are working on production code.

There is a project phase for testing tools and libraries. But even then, the installation for this evaluation should be done under configuration control. Or each dev could end up with a custom environment that doesn't properly reproduce code across different machines. The installation/configuration of these tools needs to be done by people with admin skills that lead to reproducible results across the entire dev team should that product be selected.

Too many developers here are crying about not wanting to have administrative responsibility. But try taking the admin privilege away and listen to the screams.

I hate to break the bad news to them. The only people that will be making a million developing s/w will be making a million rupees.