I am an electrical engineer with some programming background in JAVA, C++, VB and some scripting. I've been told that I write programs with the engineering mentality and not a programmer's mentality. The person can't seem to pin point the differences so I'm going to ask the ppl here. What goes through a programmer's mind when he has an assignment?
A Computer Programmer's Mentality
- Thread starter bacon333
- Start date
I think about how to get the job done easiest and with a minimum amount of work/time. Ideally the final result works, runs quickly and is efficient, and the end user approves of it. It also helps if I can understand the code 6 months down the line when someone asks me to tweak it or add "features"...
As for the engineer vs programmer mentality. I'm not sure what that means.
Another code writing engineer here.
And I get to read alot of code written by other engineers, and a bit by "programmers"
The primary difference I see is that most engineers are lousy programmers
Seriously ... their code tends to be a mess. Little or no abstraction, lots of stuff that should be broken out as seperate functions, poor use of control structures, etc. Very fragile and incomprehensible data I/O. Of course, most of the engineer code I see is written in Fortran, whether the language is fortran or not!
And I get to read alot of code written by other engineers, and a bit by "programmers"
The primary difference I see is that most engineers are lousy programmers
Seriously ... their code tends to be a mess. Little or no abstraction, lots of stuff that should be broken out as seperate functions, poor use of control structures, etc. Very fragile and incomprehensible data I/O. Of course, most of the engineer code I see is written in Fortran, whether the language is fortran or not!
Drakkon
Diamond Member
- Aug 14, 2001
- 8,401
- 1
- 0
A OOP programmer should be trying to break things up into objects and then into functions of those object
A engineer would be looking for a structure and ways to a mean sort of style not really necessarily breaking things apart, but more building up.
A business programmer would be more of a functional programmer lumping it all in a simple down the line manner
usually most people use a mix depending on what the assingment is...most of the time i try to be an OOP programmer but if have to meet a deadline i can go the business route
A engineer would be looking for a structure and ways to a mean sort of style not really necessarily breaking things apart, but more building up.
A business programmer would be more of a functional programmer lumping it all in a simple down the line manner
usually most people use a mix depending on what the assingment is...most of the time i try to be an OOP programmer but if have to meet a deadline i can go the business route
You should really distinguish between "programmers" and "software engineers." A programmer is someone who writes code, a software engineer is someone who plans, designs programs, tests, and maintains code.
A monkey can program. You just sit and type lines of code until you meet your specs. What goes through a programmers mind is fairly simple: find a way to meet the requirements. Usually this requires referencing some manual on the platform interfaces and arranging the correct function calls and objects into a way that works, and by works I means passes unit test.
A common task for most software engineers is to debug code already written. This is like detective work, except the culprit who wrote the code probably no long works at your company. This is very difficult as often times there is little to no documentation, so you have to be good at divining the programmer's intentions from the code. This requires much inductive and deductive reasoning to be able to find the cause of a bug, then fixing it is easy. When a softE changes existing code, they have to worry about teh change breaking another part that already worked (this is called regression), and they have to investigate a lot of avenues in order to boost their confidence that the fix worked.
So to answer your question, most programmers don't even know what they are thinking. They just try to get it to work, and if it looks like it does, great. Some poor software engineer down the road will have to ask the same question "what was this guy thinking?" and fix their mistakes.
A monkey can program. You just sit and type lines of code until you meet your specs. What goes through a programmers mind is fairly simple: find a way to meet the requirements. Usually this requires referencing some manual on the platform interfaces and arranging the correct function calls and objects into a way that works, and by works I means passes unit test.
A common task for most software engineers is to debug code already written. This is like detective work, except the culprit who wrote the code probably no long works at your company. This is very difficult as often times there is little to no documentation, so you have to be good at divining the programmer's intentions from the code. This requires much inductive and deductive reasoning to be able to find the cause of a bug, then fixing it is easy. When a softE changes existing code, they have to worry about teh change breaking another part that already worked (this is called regression), and they have to investigate a lot of avenues in order to boost their confidence that the fix worked.
So to answer your question, most programmers don't even know what they are thinking. They just try to get it to work, and if it looks like it does, great. Some poor software engineer down the road will have to ask the same question "what was this guy thinking?" and fix their mistakes.
clamum
Lifer
- Feb 13, 2003
- 26,252
- 403
- 126
I try to get a rough idea of what the final product should do and break that down into smaller pieces. For each piece, I translate what literally needs to be done into code, then test/debug, repeat. Sorry I can't go into more depth, I've only done some relatively simple Java programs and applets.
Sorry I can't go into more depth, I've only done some relatively simple Java programs and applets.Thanks for the replies. I think I'm pretty much along the lines of what armitage said. I think documentation is the major thing that most companies want. I am looking through a few pages on code documentation and code organization (breaking different tasks into functions rather than having a messy bulky function). Thanks guys!
I've seen some ugly sh|t. How about approx 10K lines of fortran without a single subroutine. Or a do...while loop that was 3pages from beginning to end. It worked ... but heaven help the poor bastard that has to go in and modify it. Unfortunately that was me.
I believe a software engineer will try to make their code maintainable, robust, and efficient. Note the efficiency is at the last of them.
maintainable means it will be easy to upgrade, to write code's on, and to fix bugs, that's basically done using modular codes, and information hiding.
robust is a little bit hard to understand, basically it means that if someone changes a part of your code, it should still work.
efficiency should be achieve on top of satisfying the above 2, or else the program wont be much worthy to upgrade and maintain etc.
and... i believe there's a 4th thing, in which i 4got...(very bad for a ms student in cs lol)
maintainable means it will be easy to upgrade, to write code's on, and to fix bugs, that's basically done using modular codes, and information hiding.
robust is a little bit hard to understand, basically it means that if someone changes a part of your code, it should still work.
efficiency should be achieve on top of satisfying the above 2, or else the program wont be much worthy to upgrade and maintain etc.
and... i believe there's a 4th thing, in which i 4got...(very bad for a ms student in cs lol)
The fortran exammple was really amazing. The kind of got the concept of a subroutine, but not really. There were blocks of code that were jumped to with a goto, and then a switch statement at the end to tell you where to jump back to depending on where you came from. Was fvcking amazing it worked at all.
ArmchairAthlete
Diamond Member
- Dec 3, 2002
- 3,763
- 0
- 0
I just started school... my uncle works here and tells me that Engineers, Computer Scientists, and other scientists (Chemist, Physicist, etc) are all taught to think differently.
He doesn't approve of my CS major though =(
He doesn't approve of my CS major though =(
- Oct 30, 2000
- 42,589
- 5
- 0
Then work with no comments.
Many programmers think that the lack of white space and sparse names are impressive.
Until you have to maintain code, you do not realize the value of documentation, readability and comments.
Stuff that you did 6 months ago can be hard to refigure out, let alone 3 years ago. And you wrote it. Now what about the poor slob that comes along after you and your schenagins.
Armitage - not an attack at you, just at the egotistical coder.
PowerEngineer
Diamond Member
- Oct 22, 2001
- 3,598
- 774
- 136
I have to ask if this was code for some sort of real-time application? I've had a similar experience myself many years ago. All the fortran code as similarly (un)structured. I found out that it had actually been written with subroutines, but these were then removed (in favor of the clumsy goto method you describe) to increase the speed of execution once the code was compiled. Yes, this does go back a few years! The computers we were using produced less than 1 MIP (roughly the computing power of a X286 if memory serves me) and only had 256k of wire-wound memory. We did a lot of things to minimize memory and maximize speed that now seem quite crazy given the power of today's computers. The good programmers of yesteryear wrote "fast" code; the good programmers of today write well documented and "easy to maintain" code.
As to the differences in coding styles, there's a lot of personal style involved. I often find myself disliking the code that others write (even if it works perfectly) because it's not the way I would have done it. It can be like reading a bad novel! And I am sure that others react to my coding the same way! On the other hand, I'm pretty quick to adopt conventions and ideas I see in the "beautiful" coding I encounter.
As far as professional tendancies go, I suspect that engineers like myself start coding before we have a complete understanding of what we're trying to accomplish. We use the code as a test bed for ideas, and this often takes it in unanticipated directions. The resulting code may reflect more of our thinking process that brought us to the finished product, and less of the good coding practices that a professional programmer (or software engineer) would use.
Interesting. I don't think it was ever real time, but it was old enough to have ben used on some very resource constrained systems. So maybe there was a method to that insanity. It was still an ugly SOB to work with!
I think this last paragraph is a good point. Often "engineering code" starts out as an experiment ... some crazy idea that starts life on the back of a bar napkin and the proof of concept gets written on borrowed time over lunch. Lots of various hypothesis are tested, code gets chunked in and out on the spot to try something out, etc. When it finally works, theres rarely time or money to rewrite it "the right way", And most engineers have a weak software background. It's just a tool to them, and a fairly blunt one. So it goes into production as a kludge that makes the software engineers curse when they have to look at it down the line.
On the other hand, when I've dealt with software engineers, they often want the requirements and algorithms laid out to the 9's. before they start writing code. They just want to write the code, not solve the problem. In fact, I interviewed for a job as strictly a coder. When asked to describe my coding & problem solving approach they were suprised that I was in it from the very beginning ... physics, problem definition, algothim development, code, integrate, etc. They were used to having the problem, solution, and test cases thrown over the fence, and their job was just to code it, and pass it on to the test group. I was "over qualified", although my computer science skills were probably lacking compared to many of the people there.. Not to say that all software engineering positions are like this. I'm sure this was an extreme example.
This one time I couldn't remember my logic 1 minute after I broke my concentration in creating it to ask a teacher a question. LOL. After that, I started to use comments on all most functions, but I noticed I still need to be more specific with them.
Note: This next paragraph, I started to write and just got into a rant, but I initially just wanted to say what I said above. I shows how much experience I have.
I'm still wet behind the ears when it comes to programming. Just 15 weeks with assmebly, with a DOS compiler - fun as hell. And I'm taking a class on C right now and I just finished for loops and going onto functions. But I love the entire problem solving aspect of programming. I spent 3 hours coding this one assignment to meet the minimum requirements and then another 3 hours trying develop an algorithm so that I can make the program better, in that time, I ended discovering that the original program was a bit faulty, I fixed that and I found out that making it better was impossible at this point because C rounds decimal numbers up and that's what was causing the error. I don't know how to get around it at this point so it was undoable.
BTW, my major is Electronics Engineering.
Programming procedure:
I can't program unless I'm looking at the screen, I consider it my drawing board. When I write a program, I try to find the most concise way of doing it. Such as using variables that were only used in another situation, but can now be used in this new situation instead of creating a new one. And I note that I will use it in two situations when I declare it and when it is used in the alternate situation. I also use as many performance saving things I can think of.
I think the whole argument about the subjectivity of code beauty is pretty important. I've seen a lot of other people's code which looks like crap, but to them, it's a finely crafted work of art. And I'm sure people would say the same of my code.
Commenting is one of those fine line issues: there's a fine line between good commenting and over-commenting, and over-commenting is REALLY REALLY annoying.
Also, in a lot of cases, instead of using comments, you can just make the code more obvious. Give that variable a more descriptive name, split that chunk of code into an appropriately-named function, etc. I try to only use comments to document "gotchas" that might not be obvious by looking at the code, and there's no way I can make them obvious other than just explaining them in english.
Stuff like this just pisses me off:
Commenting is one of those fine line issues: there's a fine line between good commenting and over-commenting, and over-commenting is REALLY REALLY annoying.
Also, in a lot of cases, instead of using comments, you can just make the code more obvious. Give that variable a more descriptive name, split that chunk of code into an appropriately-named function, etc. I try to only use comments to document "gotchas" that might not be obvious by looking at the code, and there's no way I can make them obvious other than just explaining them in english.
Stuff like this just pisses me off:
I should add that in general, programmers and software engineers alike are horrible cynics. I think this is due to the fact that they constantly run into ways of doing things that should be done better, but can't. Every coder i know is some kind of cynic.
When i write code for my job, (intern at an enginerring firm, working toward an IS degree), I find it frustrating at times. They do not give me clear directions on what they want to accomplish. I don't recieve written documentation or specifications. Most of the work i do are front end GUI work with VB.
Most of the directions i get are verbal, so i have to write down what i think they mean when they tell me certain things. I am a good notetaker so its not too bad.
When i code i tend to go down the line, I try to break it down to as many procedures and functions as possible. However, i find it alittle pointless and time consuming to create multiple classes for some of the projects that i am assigned.
Should a "coder" maximize the use of objects eventho the same can be accomplished for less amount of time? I know it might seems more "elegant" to use objects, but is it necessary?
Most of the directions i get are verbal, so i have to write down what i think they mean when they tell me certain things. I am a good notetaker so its not too bad.
When i code i tend to go down the line, I try to break it down to as many procedures and functions as possible. However, i find it alittle pointless and time consuming to create multiple classes for some of the projects that i am assigned.
Should a "coder" maximize the use of objects eventho the same can be accomplished for less amount of time? I know it might seems more "elegant" to use objects, but is it necessary?
Originally posted by: jman19
That's absolutely absurd. How did the author of that code learn to write fortran without learning to use subroutines
Well, my conclusion was that they were fvcking idiots, that had learned just enough to be dangerous, and left it at that. But PowerEngineer above may have an alternate expenation. I know these guys weren't stupid as far as physics, etc. But the code sure sucked to work with.
ArmchairAthlete
Diamond Member
- Dec 3, 2002
- 3,763
- 0
- 0
Originally posted by: Kwan1
Should a "coder" maximize the use of objects eventho the same can be accomplished for less amount of time? I know it might seems more "elegant" to use objects, but is it necessary?
I'm no guru, but more objects would make it easier for you to resuse your code on other projects. It'd probably make it easier to add features to the current project, or squash bugs.
Kaido
Elite Member & Kitchen Overlord
- Feb 14, 2004
- 50,477
- 6,587
- 136
Originally posted by: clamum
I try to get a rough idea of what the final product should do and break that down into smaller pieces. For each piece, I translate what literally needs to be done into code, then test/debug, repeat.
yeah, that's what I do sometimes, too - get the big picture then break it into small tasks.
I'm studying Computer Enginnering Technology in college right now and I've taken a few programming classes. I don't really care for being so organized on programming projects, which they encourage you to do at my school...I don't want to go into programming professionally. I don't like documenting all that much. I like it when I have a problem to solve or a program idea in my head, then sitting down and writing it and tweaking it until it works. Sure, I could probably be more efficient if I did a step-by-step process, but I have fun doing it my way.
My parents bought an IBM with DOS back in the day, and I started to use Qbasic like it was a game...it was fun just playing with it and seeing what I could do. I didn't really think of it as "programming" or anything, it was just another game on the computer with more commands. So I approach it as play, not work. Granted, I don't write anything heavy duty, mostly just simple applications and a lot of TI-83 stuff
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 20K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter