what its like to be programer or systems analyst in the work place?

This is my last year in computer science studies and i was just wondering what is it like to be a programer or a systems analyst / Designer in the work place ?

It's a lot like Office Space.

and how much money do you make?
[/quote]

Depends on where you live, your experience, your negotiating skills, and some luck. Bizdev programmers tend to make ~20% more than their gamedev brethren (for working fewer hours on average).

I'm just so worried that i would work in a company and get fired the first day because i couldn't do a specific task
[/quote]

Unless that task is something like not pooping yourself, you're probably safe. Firing a new hire on their first day reflects badly on the hiring manager.

My professor said anyone can be a programer but not anyone can be a systems analyst or a system designer. also he said that systems analyst make more money than programers and that programer are just like translators and they just translate the UML from the systems analyst to code. This made me very very worried and made me feel like being a programer is not important at all. I thought that being a programer is like being a surgeon in an operating room or a rock star for some reason !!
[/quote]

Maybe 30-40 years ago, or at certain companies. At my last gig, analysts made 75%-50% of what programmers made. They were people who were too stupid to be programmers, but somehow were smart enough to tell programmers what needs to be done based on business 'need'. I suspect that most would think UML was the type of connector your monitor uses.

That said, there's a nugget of wisdom here. The vast majority of programmers are bad. They're plumbers; code monkeys. They take libraries and snippets of code from the internet and plug them together to achieve something that has been achieved millions of times before. This is the sort of work that tends to be exported to 3rd parties and that people promise will be eliminated by the 'next big thing'.

You do not want to be a code monkey.

You do not want to be a code monkey.

ok so how not to be a code monkey ?

[quote name='Telastyn' timestamp='1322495974' post='4888467']
You do not want to be a code monkey.

ok so how not to be a code monkey ?
[/quote]

Have enough skill that you're not doing only boring plumbing work. The key skills needed here are program design and problem solving, which mostly comes through practice. Have a problem, make a program that deals with it. Learn what designs work and why, learn what designs cause problems down the road.

Every company is different as far as what the responsibilities of a programmer are. Some companies have the architects design down to the class level. You do not want to be a programmer for that kind of company. You are just a code monkey at that point. Other companies don't even have an architect position so the programmers design everything. You should ask your potential employer to describe a typical project life cycle and who is in charge of doing what. That way you know exactly where you would fit in the picture and what your responsibilities are. As far as getting fired on the job, it doesn't happen as often as you think. As long as you are a team player, are putting forth effort and you are making progress and they deem you are capable of doing the job then you will be fine. They do not expect a person straight out of college to know anything about how businesses actually work. They expect to have to teach you a lot on the job.

Also, the guys you mentioned are not legendary because they are programmers, but because they are innovators.

In the end, I would say don't be nervous. Nobody expects a college graduate to be able to just jump right in and add value.

[quote name='Ken Thompson']
"I am a programmer. On my 1040 form, that is what I put down as my occupation. As a programmer, I write programs." -- Ken Thompson.
[/quote]

If the label "programmer" is good enough for Ken Thompson, it's good enough for me.

Do "systems analysts" still exist? Haven't heard that term in like 20 years.

My professor said anyone can be a programer but not anyone can be a systems analyst or a system designer. also he said that systems analyst make more money than programers and that programer are just like translators and they just translate the UML from the systems analyst to code. This made me very very worried and made me feel like being a programer is not important at all. I thought that being a programer is like being a surgeon in an operating room or a rock star for some reason !!

At most of the places I've worked, there is no such thing as an "analyst" or a "system designer". Every programmer is a designer and an architect and an analyst.

When you hire someone who only "analyses" or designs (no programming responsibility) but is responsible for what the "translator/programmers" will build, then you end up with a pile of garbage as a result. Working at a place like this will not only be unfulfilling, but it will teach you bad practices and demonstrate to you what many failed projects look like.


Regarding your anxiety about not being able to perform the job -- don't worry, that's normal. Once you'll settle in, you'll realise that your co-workers (mostly) aren't rock-star programming gods either, and all of you will continue to learn together.

Another point of view - it's likely that 99% of a given developer's career will be spent modifying an existing codebase - whether that's adding new functionality or fixing issues. This is generally why the 'system analyst' role doesn't exist per se, because there's rarely giant new superstructures to design.

This is also reassuring for the new developer, because when you start out, you start out working on existing code.

So you learn coding and design practices as they apply to that product, and frankly it's pretty hard to stuff up one-liner new-guy tasks like "Change the form where it says 'Csutomer Sales' to 'Customer Sales'".

And most places I've worked they expect the new guy to take like days to complete that job while he figures out their specific IDE, location of the code, how to fill out the job sheets and so on.

I think your professor is spoofing a little. Maybe the college offers an extra year of SA that he wants to drum up enthusiasm for? Do not underestimate the power of ulterior motives...

In any event, his statement is based on a number of false presumptions.

One is that the design is always 100% complete and all-encompassing, which is utter nonsense. A design that goes into low-level implementation details is focussing priorities in the wrong place; a design says what is done, you as a programmer control how it is done.

Two is that the software lifecycle ends at initial implementation, and that's complete rubbish. All non-trivial software has bugs, no plan survives first contact with the enemy (users ;) ) and maintenance is where large amounts of subsequent work get done. You're not gonna find an SA putting that in his design!

Creating something new can be a buzz for sure, but for me I've found over the years that I get a real sense of personal fulfilment from bugfixing. It's an opportunity to learn from your own (and others') mistakes, to learn about how people actually use software in the real world, and to get your customers back on track with something that brings value to them. Amazing stuff!

Your professor's advice may have been true 10-15 years ago; however, the pay scale of programmers (naturally dependent upon location and experience of course) tends to be higher than that of analysts because as technology has advanced, there is a much broader burden on the programmer to make things work in a heterogeneous systems environment that often soars well above your analysts ability to truly comprehend. In most companies, the analysts are there to add buffer and a communication conduit between the more technical "programming" team and the "visual and creative" business and market teams. I stepped into that role over the years and it isn't one which I personally have enjoyed as it tends to be less technical in nature and more conceptual. It lacks the hands-on vibe I prefer to have when it comes to day to day work.

But when it comes to pay, naturally we all want to excel at our job and make lots of cash while doing it; however despite what cash can do for you now, it isn't the answer to happiness. Starting out, I'd advice you to reach for the stars while also trying to expand your mind in as many areas as you can. Do be afraid to experiment, don't be afraid to try atypical options even if it means sometimes doing it on your own time to prove or disprove any theories you or others may have. It's often a rewarding effort because you will likely learn several things along the way which you will be able to reuse in other projects or solutions down stream and already be familiar.

As for the hire/fire scenario, I wouldn't be too worried about that. As others have pointed out, if that were to ever happen, that's typically a reflection on the hiring manager and not the new hire themselves and that wouldn't be a company I'd want to work for anyway. Most companies are aware that newcomers from college have little real-world experience because we all know that college unfortunately doesn't teach you real world scenarios; college gives you tools for you to solve and apply at real world situations. So be brave and strong and don't fret about things like this. There is a lot of "on the job" training that happens with people who are new employees, even those who aren't right out of college.

My advice is simply if you enjoy programming, then that's where you should go. Don't do it because of the money. Do it because it is what you find passion and enjoyment from it!