Programmer Analyst vs. Software Engineer

[statik213]

^^

 

[Drakkon]

engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

 

[Rayden]

I am not familiar with the term programmer analyst and I am a computer science student. It could be more of an industry term though.

Computer Science vs Software Engineer I do know.

Computer science = creating algorithms (in practice writing code).

Software engineer = managing a software project, writing requirements, perhaps some design, doing managerial things.

 

[Descartes]

Originally posted by: Rayden
I am not familiar with the term programmer analyst and I am a computer science student. It could be more of an industry term though.

Computer Science vs Software Engineer I do know.

Computer science = creating algorithms (in practice writing code).

Software engineer = managing a software project, writing requirements, perhaps some design, doing managerial things.

Uhh, no.

What is "computer science" in practice, anyway? I didn't know that was an actual position of any kind.

A software engineer is just a title, and depending on the company for which you work you might have many other titles as well, including programmer/analyst. A software engineer typically does not manage a project... project managers do, and they typically do not have computer science backgrounds. Software engineers also typically do not write requirements... analysts do. Design they will do, but only for their functional elements, and they almost never do managerial things.

A "programmer analyst" means different things to different people, but typically anyone with an analyst in their title does more with process and business interaction than actual development. An analyst will often serve as a laison between the business expressing the need for a solution and the developers/"software engineers" actually implementing the solution.

 

[Gunslinger08]

Each of these terms is going to mean something different at each company. I'm a developer and my work ranges from system administration to database administration to coding to installation to client meetings.

 

[EagleKeeper]

Syntax only.

 

[Rayden]

Originally posted by: Descartes

Originally posted by: Rayden
I am not familiar with the term programmer analyst and I am a computer science student. It could be more of an industry term though.

Computer Science vs Software Engineer I do know.

Computer science = creating algorithms (in practice writing code).

Software engineer = managing a software project, writing requirements, perhaps some design, doing managerial things.

Uhh, no.

What is "computer science" in practice, anyway? I didn't know that was an actual position of any kind.

A software engineer is just a title, and depending on the company for which you work you might have many other titles as well, including programmer/analyst. A software engineer typically does not manage a project... project managers do, and they typically do not have computer science backgrounds. Software engineers also typically do not write requirements... analysts do. Design they will do, but only for their functional elements, and they almost never do managerial things.

A "programmer analyst" means different things to different people, but typically anyone with an analyst in their title does more with process and business interaction than actual development. An analyst will often serve as a laison between the business expressing the need for a solution and the developers/"software engineers" actually implementing the solution.

Softwar engineer is such a new term, I believe academia is attempting to move them into more managerial roles in industry. People with a background in managing have no idea how to manage software as it is unlike other industries. Ever wonder why a few years ago 80% of projects were not succesfully completed on time?

At least at my school, the software engineers take quite a few "management" type classes as well as software design, specifications and requirements, and maintenance. When I say management type things, I speak from having no experience in the area. I am speaking of managing a software project and this may not include standard management things.


I can't tell you what industry does, all I can comment on is what academia's current position is.

 

[talyn00]

it depends entirely on the company and what each job does. The title of analyst is thrown around far too often.

 

[talyn00]

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

that just sounds completely wrong. An engineering position most likley would encompass whatever an analyst does.

 

[Drakkon]

Originally posted by: talyn00

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

that just sounds completely wrong. An engineering position most likley would encompass whatever an analyst does.

all i was saying is that an engineer sounds like they would be working on more technical items while analyst works on more business level applications. and good job highlighting the one part and not the second "thats how it should be" and then the other part where you kinda repeated exactly what i said....

 

[Rayden]

Originally posted by: Drakkon

Originally posted by: talyn00

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

that just sounds completely wrong. An engineering position most likley would encompass whatever an analyst does.

all i was saying is that an engineer sounds like they would be working on more technical items while analyst works on more business level applications. and good job highlighting the one part and not the second "thats how it should be" and then the other part where you kinda repeated exactly what i said....

Writing code however is not at all engineering. No engineering practices are applied to writing code. Engineering practices are applied to software projects as a whole.

 

[DaShen]

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

Analyst usually talk to the end user and find out specifications for a program. They analyze what needs to be done and work out the overall scheme of the project and present it to the engineer. Sometimes this encompasses just figuring out what parts are crucial and telling the engineer what needs to be done (deciphering what the end user wants), other times it mean flowcharting and psuedo-code (not as often).

Software Engineers tends to do the actual coding. Many times they will work in project groups on big software project headed up by their superior who does nothing but "oversee" work, but if it is a small company, they tend to do double duty as an analyst and engineer (this is something you must ask and decipher through your interviews). Companies will sometimes encorporate debugging and testing into the Software Engineering job. In which case you could be doing less development and more maintainence (which is punk work). Hope that helps.

 

[boggsie]

Originally posted by: DaShen

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

Analyst usually talk to the end user and find out specifications for a program. They analyze what needs to be done and work out the overall scheme of the project and present it to the engineer. Sometimes this encompasses just figuring out what parts are crucial and telling the engineer what needs to be done (deciphering what the end user wants), other times it mean flowcharting and psuedo-code (not as often).

Software Engineers tends to do the actual coding. Many times they will work in project groups on big software project headed up by their superior who does nothing but "oversee" work, but if it is a small company, they tend to do double duty as an analyst and engineer (this is something you must ask and decipher through your interviews). Companies will sometimes encorporate debugging and testing into the Software Engineering job. In which case you could be doing less development and more maintainence (which is punk work). Hope that helps.

This attitude is precisely what is wrong with the popular view of Software Engineering.

If a person, who is a Software Engineer, does not do a significant amount of debugging and testing to prove that the code works, then that person is not a Software Engineer, but a code jockey.

That's not to say that a code jockey can't make a ton of money.

 

[boggsie]

 

[statik213]

thanks a lot for the reply guys, kinda cleared things up for me!

 

[DaShen]

Originally posted by: boggsie

Originally posted by: DaShen

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

Analyst usually talk to the end user and find out specifications for a program. They analyze what needs to be done and work out the overall scheme of the project and present it to the engineer. Sometimes this encompasses just figuring out what parts are crucial and telling the engineer what needs to be done (deciphering what the end user wants), other times it mean flowcharting and psuedo-code (not as often).

Software Engineers tends to do the actual coding. Many times they will work in project groups on big software project headed up by their superior who does nothing but "oversee" work, but if it is a small company, they tend to do double duty as an analyst and engineer (this is something you must ask and decipher through your interviews). Companies will sometimes encorporate debugging and testing into the Software Engineering job. In which case you could be doing less development and more maintainence (which is punk work). Hope that helps.

This attitude is precisely what is wrong with the popular view of Software Engineering.

If a person, who is a Software Engineer, does not do a significant amount of debugging and testing to prove that the code works, then that person is not a Software Engineer, but a code jockey.

That's not to say that a code jockey can't make a ton of money.

Ummmm, I test, debug, and maintain my own code, but many companies will throw new programmers into old outdated code, and have them specialize in debugging the code and maintaining the old code. This is bad for any new programmer who is looking for growth in his programming profession because he will only be specialized in projects that have outdated code and methods when he leaves or is fired from that entry level job.

I stress that this is quite important to find out if you are looking for a job because some companies will use you and throw you to the curb, and then where will you be in skills.

"I see you worked for so-and-so for 2 years. What did you learn there?"
"Oh, ... I was instrumental in maintaining there mainframe code and working on COBOL."
"Oh I see, well nice talking to you. Don't call us, we'll call you."

 

[boggsie]

Originally posted by: DaShen

Originally posted by: boggsie

Originally posted by: DaShen

Originally posted by: Drakkon
engineer works in more low level languages
analyst most likely working in high level languages

at least thats how it should be look at the job descriptions though...most people label things like that and have COMPLETELY different expectations

Analyst usually talk to the end user and find out specifications for a program. They analyze what needs to be done and work out the overall scheme of the project and present it to the engineer. Sometimes this encompasses just figuring out what parts are crucial and telling the engineer what needs to be done (deciphering what the end user wants), other times it mean flowcharting and psuedo-code (not as often).

Software Engineers tends to do the actual coding. Many times they will work in project groups on big software project headed up by their superior who does nothing but "oversee" work, but if it is a small company, they tend to do double duty as an analyst and engineer (this is something you must ask and decipher through your interviews). Companies will sometimes encorporate debugging and testing into the Software Engineering job. In which case you could be doing less development and more maintainence (which is punk work). Hope that helps.

This attitude is precisely what is wrong with the popular view of Software Engineering.

If a person, who is a Software Engineer, does not do a significant amount of debugging and testing to prove that the code works, then that person is not a Software Engineer, but a code jockey.

That's not to say that a code jockey can't make a ton of money.

Ummmm, I test, debug, and maintain my own code, but many companies will throw new programmers into old outdated code, and have them specialize in debugging the code and maintaining the old code. This is bad for any new programmer who is looking for growth in his programming profession because he will only be specialized in projects that have outdated code and methods when he leaves or is fired from that entry level job.

I stress that this is quite important to find out if you are looking for a job because some companies will use you and throw you to the curb, and then where will you be in skills.

"I see you worked for so-and-so for 2 years. What did you learn there?"
"Oh, ... I was instrumental in maintaining there mainframe code and working on COBOL."
"Oh I see, well nice talking to you. Don't call us, we'll call you."

Ah, I see. Apologies offered if I came across as harsh and judgemental.

I am a bit sensitive to this topic as I work with so many code jockeys who go by the mantra ICSM - It Compiles Ship It. I have to sift through so much un-tested un-debugged code and it often impacts my productivity. I often use stubs and drivers to ensure/prove that my code works, but overall overall results are often dismal, because of other untested code that surronds me.

Thanks for clarification ...

 

[Rayden]

It is interesting to see you guys describe software engineers (the major) as the hardcore low level programmers. This is not at all what I am learning in my SE classes. The SE classes at my school focus on requirements, project plans, lifecycle, function points, estimation, scheduling, metrics, configuration management, retrospectives. Stuff that is closely related to code, but is not actually writing code. It is managing complex software, not management in terms of managing people.

They know enough programming to write code, but any really low level algorithm intensive stuff is better left to the computer science majors (code monkeys).

As a basis for what I am being taught: the SE class I am currently in is being taught by the first Professional Engineer in Software Engineering in the country. He is a senior member of IEEE and is on several boards making nationwide decisions about Software Engineering.

The term "engineer" is a legal term in many states and you may not be allowed to legally call yourself a "software engineer."

Here is a good link describing software engineering.

 

[Descartes]

Originally posted by: Rayden
It is interesting to see you guys describe software engineers (the major) as the hardcore low level programmers. This is not at all what I am learning in my SE classes. The SE classes at my school focus on requirements, project plans, lifecycle, function points, estimation, scheduling, metrics, configuration management, retrospectives. Stuff that is closely related to code, but is not actually writing code. It is managing complex software, not management in terms of managing people.

They know enough programming to write code, but any really low level algorithm intensive stuff is better left to the computer science majors (code monkeys).[/quote]

Wow, you're really using the wrong terminology here. Calling a CS major writing "intensive stuff" a code monkey shows a lack of practical experience in the industry, imo.

As a basis for what I am being taught: the SE class I am currently in is being taught by the first Professional Engineer in Software Engineering in the country. He is a senior member of IEEE and is on several boards making nationwide decisions about Software Engineering.

Good for him, but he is just one man, and it's thus just one man's opinion of what constitutes SE. When you actually find work you'll quickly find that most of what you know is useless, and the only chance you have at surviving in the industry is to assume a great deal of mental agility; you have to adapt. Who does what, who has what title, and what should be happening according to academia has no place in the functioning world of software.

The term "engineer" is a legal term in many states and you may not be allowed to legally call yourself a "software engineer."

This has been discussed a lot in previous threads. It's just a title, some people like to call themselves an engineer, and I couldn't care less.

Here is a good link describing software engineering.

Just one man's opinion. His suggestion that the term developer is "lower" than an SE is patently false in my experience, because most professional developers I know call themselves just that... developers. I know of very few professional developers that call themselves software engineers. It seems the SE title gets handed down more from corporate than anything else.

I call myself a developer, and while the pointy-hairs like to add the SE title to me in conversation I still won't call myself that.

 

[Rayden]

Originally posted by: Descartes
(refutes most of what Rayden wrote...)

In case it was not clear from my previous posts, I am a computer science student and have little experience in industry. My input is only what I know from academia. There was a severe lack of that perspective in this thread so I think I contributed some worthwhile information.

 

[boggsie]

Rayden:
As a basis for what I am being taught: the SE class I am currently in is being taught by the first Professional Engineer in Software Engineering in the country. He is a senior member of IEEE and is on several boards making nationwide decisions about Software Engineering.

IEEE is a very distinguished organization and you are fortunate to have this particular gentleman instructing your class. Just be aware, the IEEE mantra, while very very thorough and scientific, is predominantly ignored by the "We know better" code monkeys writing 80% of the software in existance.

Descartes:
Good for him, but he is just one man, and it's thus just one man's opinion of what constitutes SE.

Don't be so quick to relegate the instructors opinions to that of "a single man". Presuming he is a fellow with IEEE, it is also safe to presume that whatever he is teaching is in line with IEEE process and technique guidelines.

Descartes:
When you actually find work you'll quickly find that most of what you know is useless, and the only chance you have at surviving in the industry is to assume a great deal of mental agility; you have to adapt. Who does what, who has what title, and what should be happening according to academia has no place in the functioning world of software.

I don't know about useless, but it is fair to say that 95% of what you may pick up in a Software Engineering class taught by an IEEE fellow, will have very impact to your day to day responsibilities as a developer, at 90% of the organizations producing code.

Descartes:
I call myself a developer, and while the pointy-hairs like to add the SE title to me in conversation I still won't call myself that.

I think the not so subtle differences between the two roles and skillsets (obviously depending on how a particular organization applies the terms) might be a little bit lost on the current software development culture. 36 month development cycles for applications that are expected to run on IBM big iron for the next six or seven years, just don't happen (much) anymore. Microsoft is obviously the biggest name and their flagship product appears to be developed with a great deal of agility - given the lines of source and time to market.

Oh and with regards to Software Engineer being a new term ... I can trace the term back to the IEEE Software Engineering Standards Collection, which I have had a copy since the 80's.

 

[Rage187]

Software Engineering is far from a new term, and management has nothing to do with it.

The guy who writes the specs is usually a Systems Engineer

The guy managing a project is exactly that, a Project Manager.

I bet you can't guess what they call the person who manages a product, thats right a Product Engineer.