Am I the only code monkey on OT?
 

That "other" thread got me thinking...the one with the alphabet soup I didn't understand. ;)

Am I the only programmer (code monkey) on OT?

I was thinking today that most of my job is not writing code or even testing--it's going to endless meetings and explaining that yes, I can make a program do just about anything, but I can't always do it on time and under budget. People have no appreciation that decisions made years ago often make certain changes very easy while making others very, very difficult.

Think of it this way: someone asks me to design a car. They want it to be fast, carry 10 people, and get good fuel economy. I am told that it is for commuters so luggage and off-road capability are not concerns. I design and build the car. It works exactly as intended. A month before it is to be mass-produced, I am asked to make it perform off-road, haul luggage, ford rivers, and it can't cost more to produce or get worse fuel economy.

These concepts are very easy to understand when the product is physical, but when the product is more abstract, it seems very few people have the capacity to understand how changing the purpose of a design can add to cost and hamper performance.

I designed a very cool piece of technology a few years ago. Think of it like making a car out of life-sized legos. Changes are easy to accomplish by picking the right components from the inventory and snapping them together. Because some changes are very easy and quick to accomplish, some people wrongly assume that all changes are easy and quick to accomplish. Sometimes I have to design a new "brick" to meet a new need and people get upset when it takes longer and costs more than a change that was merely a different combination of existing components.

Oh, and one thing I've learned to do is speak in analogies to physical things people can understand. SmileWavy

I did a stint as a code-slinger back in the early days of DSP microprocessors. I understand your point completely.

Like Jim, I completely understand where you're coming from.

I'm a code monkey / software architect / lead developer. Most of the meetings I have to attend all deal with code or giving a demo of a new software product. When I first started doing demos and speaking with customers I thought they always asked for the stupidest things. Now, I just automatically put them into the demos. The biggest thing I've learned is: presentation matters. No one cares if it works. If it looks awesome and pretty and shiny they'll eat it up.

I write software for my employer. It never gets sold outside of my company. Demos are nice, but it's hard to make meaningful demos for back-end software that has no user interface. ;)

Nah.....
http://msdn.microsoft.com/en-us/magazine/cc301903.aspx

I've been a code monkey of one stripe or another for going on 12 years now. Most of the time (these days) I just tell the littler monkeys what to do but sometimes I actually get my hands dirty.

Generally speaking if the customer says "we won't/don't need that", in 2 months it'll become priority 1. So I learned the role of analyst as well--tell me what you want, and I'll try to figure out what you NEED.

While it sometimes makes for longer initial development times, maintenance and enhancement turn-around always benefits enormously.

Br 14

Dammit - Keeps changing the R to lower case

(Not really a code jockey but a systems programmer)

Used to do some scripting, maintenance programming in VB,C++, but I'm pretty much a packet plumber by trade.

I programmed in C++ on Windows for the first 8 years, and have programmed in Java and Perl on Linux for the last 9 years.

PACKET PLUMBER!!! I'm going to use that.

I used to write monitoring tools in Perl for my employer - does that count? They were more like scripts called by cron or web reports run by users...I dunno.

I enjoyed it and kind of miss it but I really sucked.

BAD.

But I was the best on the team and they appreciated the work. Had they hired a real programmer I would have been completely out of a job.

I am a .NET developer.

I used to work in a place where they regularly referred to users as "losers". That term really became a part of the lexicon of the team, to the point where no one laughed or batted an eye. "I'm going to meet with the losers. Be back in an hour." "The loser-requirements for this application have been modified." "Make sure to read the ELLA (end-loser license agreement)."

I was a developer until '07, was a comp sci undergrad and went out on top of my game as a lead developer/lead architect. Now I seldom touch actual code but still work daily with a team of 6 developers at the same company. Back in the day I was PERL/ASP/.NET etc., current team is exclusively .NET.

Our software is also used exclusively within the company, and I definitely feel your pain :)

I've done COBOL, RPG, C/C++, Java, and I currently do a bit of perl. And lots of shell scripting.

http://www.bradfitz.com/mirror/Code%20Monkey.mp3

Used to do enterprise-level custom app development. as a boutique shop, we worked through big NYC-based consultants that sold completely unrealistic apps to customers that we had to build. it didn't help that the consultants typically had no experience in the industry and often got the basic data mechanics completely wrong, so we'd build something on their specs only to find it wouldn't work for the customer whatsoever.

After the first failure, and quickly realizing that 20-something consultant kids would do and say anything to get a client, we started talking to the end-user clients directly after getting the project.

One thing I'll never forget, we were at a bar with Mitchell Madison Group consultants in Cincinnati (were working on a catalog printing calculator for Federated Department Stores) after a client dinner just unwinding. One of the FDS VPs comes in (he was at the dinner earlier) and monopolizes one of the smoking hot consultants, this girl couldn't have been older than 23, he was in his 50s, and he starts getting grabby, hands on her ass and a lot more. One of my compatriots artfully quips that about the inappropriateness of his actions and the consultant, who did have a few martinis in her, didn't miss a beat, looked him straight in the eye and said, "whatever the client wants, the client gets."

to this day, it was the most repulsive moment in my 25 years of working.

I'm not a code monkey... but I play one on TV :cool:

Same same here. Single client, financial application. I try to program defensively, respecting GAAP, SEC, common sense and business rules, anticipating future developments. Sometimes changes are a snap sometimes they aren't. Only you know and I know.

yep, the most code I sling is perl, though I've had formal c++ training. Mostly I use perl to connect various monitoring products together. not glamorous at all, and I'm a complete hack at it.