5 ms·

It also requires the right kinds of insights. I know plenty of people who somehow manage to make it all the way through an undergrad degree without ever really

It also requires the right kinds of insights. I know plenty of people who somehow manage to make it all the way through an undergrad degree without ever really getting programming. They then managed to get a low-skill job at a low-caliber employer, where they produce bad code, poorly. But because even bad employers need code these days, they manage to maintain a job in programming despite never really understanding it on a fundamental level. Unfortunately, in such an environment it can be hard to ever improve since you rarely have competent coworkers (and the ones you do have quickly leave). It might just be a matter of time, but only if you frame it that some people get it really quickly and others take forever. Ultimately, I think programming performance correlates very highly with IQ. Otherwise I really don't see any coherent explanation for why I should be able to out-program someone who started programming before I was born.

alistproducer2 10y ago
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.
- bpyne 10y ago
  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.
  - alistproducer2 10y ago
    Your accessment is spot on.
  - citizenkeen 10y ago
    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).
    - bpyne 10y ago
      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]
  - dredmorbius 10y ago
    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.
s_kilk 10y ago
> ... (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."
Terr_ 10y ago
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-conception-of.html http://blog.mathed.net/2011/07/rysk-erlwangers-bennys-concep...
projektir 10y ago
You provided neither evidence nor argumentation for your claims, though...?

alistproducer2 10y ago

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.

bpyne 10y ago
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.
- alistproducer2 10y ago
  Your accessment is spot on.
- citizenkeen 10y ago
  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).
  - bpyne 10y ago
    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]
- dredmorbius 10y ago
  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.

s_kilk 10y ago

> ... (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."

Terr_ 10y ago

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-conception-of.html http://blog.mathed.net/2011/07/rysk-erlwangers-bennys-concep...

projektir 10y ago

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