College Programmers
 

I work in an IT shop, and over the years I have noticed that fresh-out-of-college programmers seem to fall into one of two camps:

The "efficiency freaks" and the "get it done" programmers.

Efficiency freaks are searching for the holy grail of efficiency: code that when it executes consumes 0 CPU seconds. They will constantly rework their code to wring out even the most minor gains in efficiency. They have no sense of deadlines (you can't rush perfection :rolleyes: ) and don't like to unit test because they "know what they are doing". Their code is generally unreadable, does not follow standards, and is unmaintainable. They often view standards as inneficient and do not follow them. They tend to be very possesive of their work and take any suggestions as personal insults. These are usually the stereotypical introverted programmer types.

"Get it done" programmers are the people who fell asleep in their lectures in college and didn't start their assignments until the night before. As soon as they got output, they stopped working. At the workplace, they can best be described as lazy. Being that they have no Playstations or fridges full of beer to distract them at work, they tend to finish assignments early, scan their unit test results, and declare themselves done. They will spend the time between when they (allegedly) finish their work and the deadline loudly complaining about how boring their job is. Their stuff generally doesn't work. Their code is also unreadable, but this time because they don't know or care about standards. They tend to agree with suggestions when made, then forget to make them.

Both groups don't understand how to really test, as their college assignments were short and simple. The also have no appreciation for how standards allow you to be able to jump into someone else's code and quickly make changes.

BTW, I was a "get it done" programmer out of college.

Hmmm.... I was a punch card programmer in my day. Fortran, Cobol on an old IBM 360.

The CPU was at 90% most of the time and so were we! :)

Legion really?

I went to Purdue and we were required to take programming as part of the IS cirriculum. Are colleges not teaching these kids structured programming anymore?. I know OOP oriented stuff/internet tends to err to the "looser" side of standards though.

It's a problem of motivation, all right? Now if they work their ass off and you ship a few extra units, they don't see another dime; so where's the motivation?

That makes two of us Joe. Occasionally would explain to our fresh out of college programmers how we programmed "back in the day" in the 60's and 70's and their general reaction was you've got to be joking. I got into programming because the USAF said you gonna be a programmer boy .. had never even seen a computer much less used one.

As to todays programmers being "efficiency freaks" or "get it done" I think it has always been that way to an extent but definitely got much worse with the advent of fast workstations and instant turn-around in the 70's.

As an exercise, give either of these types one of the other's work product that they've got to unf*ck, and make it an object lesson in the merit of following standards (even if they're not 'optimal'). One thing it's easy not to have sight of right out of school is that your work product is going to have to work with others' work product and going to have to work indefinitely... not just "once" when tested by the prof.

JP

JP, you hit the nail on the head.

Around here, it's about six month to two years before someone finally "gets it". There are a lot who leave in the first two years and never "get it", but they probably never will.

Chris,

Structured programming is taught, but not really enforced in assignments. We recruit heavily from Illinois State, UNI, BGSU and other midwest state schools. Like most things in college now days, students can whine or argue their way out of accountability for their work. We require a 3.5 or higher GPA to apply so we generally get the cream of the crop, but a general lack of accountability is still there among new graduates. (When I was in school from '96 - 2000, I noticed it then too.)

I have a student working for me now - hand picked him from one of my classes. The kid has good chops but needs direction in terms of user applicability. What makes this kid a good hire in my eyes is that he will consider any wild arse idea I have and look to see how to make it work. he is good at asking his old profs and call up various companies to get the info. He has a nothing is impossable atttitude and is not afraid of saying "I don't know but I will look into it until I find the answer."

I would hire on attitude over ability anyday!

haha perfect usage

There's your first problem. ;)

Joking aside, computer science != software engineering. I know of no university that actually teaches software engineering as it is applied in corporate America, where performance, reliability, timeliness, flexibility, etc are all critical...not just that "it works" or "it's fast".

I'm lucky, my best guy is an efficiency freak^2, and has developed a serious appreciation for standards (he inherited a few tens of thousands of lines of really ugly code written for us by a former employee in India). However my other guys (and gal) are still, um, working on it.

I'd say approximately 1/8 of all the kids who come out of school with any sort of CS background have a chance of really being effective.

Thom's got a serious point though. You have to find someone who codes for the love of it and is willing to sacrifice some of the "fun" part in order to do it right. Then you have to figure out how to keep him/her from being made into a manager because they do such good work.

You are absolutely correct, BlueSkyJaunte about computer science vs. software engineering. That's the skill that new employees need to "get". I don't know that anything could fix it other than making all computer science programs include graduate work (much like CPA programs now do) that addresses software engineering.

Its people like this who made American what is is now and a great country. Support him all you can and make sure that he knows that there is no task that is impossible.

The only limit is the limit you place on yourself. Learned that years ago and its very true in most cases.

Our code is tested, migrated, audited, tested, migrated, audited, tested, migrated and through the whole process a couple of more times and then hammer the SOx controls at it, it is amazing any code ever moves anywhere along with the huge documentation and audit trail.

Blockpoints are scheduled and timelines/requirements are defined and made.

Most college students have never held a "responsible" job where their income and job status (fired) were really in great jeopardy. At this position it should be.

It sounds as if the business rules/requirements at your company are either not in place or enforced...well, or both.

I assure you that is not an issue. If only you knew...

If they are enforced, why are they still there?

I've found that not a single one of you guys likes the other ones work and can always do better. Us engineers are never like that:rolleyes: .

I hand someone requirements, specs, and standards and say "go code". They come back with something that does not meet standards but does allegedly meet functional requirements. Where was this caught? During a peer review. The process is being followed and enforced. It's just I inevitably have to explain why standards are important or why maximum efficiency can make something unmaintainable.

I'm of the firm belief that software development should be an apprenticeship. Most people I've seen straight from uni write ureadable/unmaintainable code and are arrogant to boot (maybe that's a generational thing...). Uni teaches you nothing that's useful for the vast majority of development jobs out there. At best a degree is some proof that you have a brain and are vaguley interested in the subject matter.

You have to be proactive with new starters. Explain to them what you're doing and why you're doing it. Any monkey can write code that passes a unit test, being fully aware of what you're coding and it's context is another matter.

Yup, "slinging code" and building sellable and supportable systems are two entirely different things, and the latter does not seem to be taught in the schools. I agree with some of the above comments that it may not be something that can be taught in academia, vs. having to be learned in the real world. I don't have the time or patience for that anymore - paying a premium for experience is sometimes a smokin' deal in the end.

+1000

Too bad IT work is often treated as a commodity and often (usually) goes to the lowest bidder. I can't tell you how many times I've spent days-week-months reworking code from a low-cost vendor (and this applies equally to domestic and southern asian vendors). Often times the rework takes many times what it would have taken for me to do it right the first time. A fundamental problem is that vendors generally do not understand your business as well as you do, and work is often done quickly (over correctly) to maximize their profits.