I work at a large corp that has recently insourced all its IT. To support this they have been vacuuming up as much mediocre IT talent as they possibly could. Every once in a while they hire a person who is curious about the field and competent. For the most part, though, the majority MIS/CIS folks who couldn't hack CS or were business until a professor told them they could make a lot more money in MIS or "experienced hires" who just want a paycheck and health insurance. Its depressing to be surrounded by such people.

What I find in in-house IT is that CS curiosity and ability to develop good software aren't the critical traits. In those environments, a "developer" spends the majority of his/her time integrating vendor solutions and writing connector code. Often they are task switching rapidly between projects, operations, and support. The critical skills belong to executive function: time planning, task switching, communications, etc. The stronger your executive function, the better work experience you have in those environments.

Of course, some companies see IT in a more strategic light so software development is robust and they do look for talented developers. A mid-sized financial company, I was employed at 12 years ago, wanted custom finance packages. At one time, Fidelity had a separate business unit that was IT R&D: I'm not sure if it still exists. Nowadays I believe they are the minority.

That vendor-integration (and vendor-relationship-management), rapid task-switching, ops / support description sounds exceptionally familiar. It's what I view as more a dev/ops role, though it's also somewhat the old-school Unix-class sysadmin model. Someone who's familiar with compiler and scripting tools, and writes a fair bit of glue, but who is mostly building systems out of component parts, rather than coding them up from scratch.

It's the task-switching and firefighting elements of that position which tend to dominate, and which I've found increasingly untenable (at least to my own personality) with time. I need the long, clear timeblocks in which I can actually think.

Thank you for writing this. This feels like this vindicates a lot of the things I like and dislike about my current job (my first developer position, in an IT department of a very large company).

Currently I'm enrolled in a grad CS program after 25 years in the field. Most students in my classes have never been in the field before. My caution to them is to understand their own likes and dislikes. If a person loves writing software and delving into a problem for many hours without interruption, then the person needs to be careful with in-house IT.

(I also caution them that some likes and dislikes won't be known until they've been in the field a few years.)

I spent too many years being frustrated by this lack of understanding and outright denial. After all, we're in IT, don't we all want to produce really great software to help people?

Recently I had to admit to myself that the answer to the above question is "No". Often a timely good solution beats out a future great solution in the minds of people who thrive in in-house IT. They accept good enough and have no qualms about a vendor providing it.

[EDIT: spelling correction]

Your accessment is spot on.

Reminds me of "Benny's Rules", regarding the complicated (and incorrect) math rules a child inferred through trial and error.

http://blog.mathed.net/2011/07/rysk-erlwangers-bennys-concep...

> ... (and the ones you do have quickly leave)

"The problem with this place? Everyone with get-up-and-go has already got up and gone."

You provided neither evidence nor argumentation for your claims, though...?