Computer Engineer vs. Computer Scientist
Which one are you? I am an engineer. But maybe we should first define the differences between the two. Engineer cares about how the system is put together whereas CS cares about how it works. Do you care about the technology or the algorithm?
The Interview
Since I am on engineer, these are the kind of questions I ask in an interview:
- Imagine you are an evil developer, how do you make code hard to test?
- How would you store a math expression tree, such that you would have an evaluate() method and a toString() method which would print the tree in an infix notation placing the parenthesis only when necessary.
On the other hand a CS asks these “algorithmic” questions:
- Write a merge sort method which merges ‘n’ files into one.
- Write a method to reverse a string in place.
The solution to engineer’s question is a set of classes interacting to define a system. Whereas a solution to a CS question is a single method doing something complex. Now, I don’t know about you but when was the last time when your application consisted of a single method. When was the last time when your system broke down because someone did not know how to write one of these algorithmic methods? When was the last time when your system broke down because the interaction between classes has gone too complex? I believe that most people are asking the wrong questions in the interview.
Algorithms
Now there is a time and place when an algorithm is exactly what the doctor ordered. Video/voice codecs, image compression, revision control, database optimization, and so on. But notice that all of these are nothing without some “application” around it. Video codec is nothing without YouTube around it, and DB engine is nothing without countless utilities, and database drivers which go with it. Chances are, when you are building an application, you will fail because your class interaction will go out of hand, not because you did not know how to solve some algorithmic problem. Libraries have already been written for the most (80%) of the algorithmic problems out there. So why do you insist that an interview candidate knows how to sort integers. Is that what he/she will be doing all day long? While building your web application?
Engineer vs CS
The thing is you need both, and preferably in one person. It is also true that no one is 100% engineer or 100% CS, there is a blend in all of us. Algorithms require raw brain power, whereas engineering requires prior knowledge (best practices) which you cannot get by thinking about the problem harder. You can only get “engineering” knowledge by learning from others. I have seen too many people focusing too much on brain power alone. We hire young kids and we let them loose on a code-base, and than we wonder why we can’t change anything because everything is tightly coupled. Hint, it is not because they are stupid.
The Reality
The truth is in the ten years or so I have been out of school I have been fighting bad code every step of the way. I can’t remember when was the last time I had to solve an algorithmic problem. The most complex/algorithmic intensive code I have written was Testability Explorer, which is a byte code analysis engine which tries to determine how testable your code is. I have written it in my free time, and the thing which enabled me to write such a complex “algorithm” were unit tests, and lots of them! I had to rely on “best-engineering-practices” to build something which is “algorithm intensive”. In other words it is my engineering background not my CS which made it possible. I think CS, is required but insufficient.
Going Forward
I would love for the industry to reflect on itself and realize that its problems is not lack of CS majors, or a the lack of bright people, but a lack of good old fashion engineers, thetn maybe we may start asking a lot more questions, to which the answer is not a single method, but a collection of classes interacting together. It took a handful of scientist to come up with an atom bomb, but it took countless of engineers to work out everything else, and software is no different. You need a handful of CS, and an army of engineers.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Jakob Jenkov replied on Mon, 2009/07/13 - 4:10am
It depends a little on what kind of job you get, right?
To become a researcher you need a lot of CS.
To become an API developer, you may also need a good deal of CS, depending on what kind of API
you are developing.
To become an application developer, you probably need more engineering than CS.
Still, I'd like to see a bit more "science" in our industry. It's way too opiniated with people discussing what's the best solution, without ever setting up the formal parameters to judge it. Does Hibernate really perform as great as it claims? Who ever measured it? (hint, Hibernate has quite an overhead on simple CRUD-operations). Is Spring really the greatest solution to every problem out there? Is this or that pattern really something we MUST always use? Is authority A always right in discussions? etc. etc.
I experience too much speculation. Do an experiment instead, and see what it says.
I read and hear tons of unproved claims every day in our industry. I probably even make lots of them myself!!! Though I'd like not to :-)
More scientific attitudes, please!
Michal Huniewicz replied on Mon, 2009/07/13 - 6:53am
in response to:
Jakob Jenkov
Jakob, I would disagree with you regarding the API development. Sure, you may need CS people to do the guts (or more likely you may not), but API stands for Application Programming Interface - and I would like to emphasize the word Interface.
That means it should be a properly designed facade that is easy to use and to understand without having to dig the documentation all the time - a well organized set of classes and methods. That sounds more like an engineering (using this article's nomenclature) job to me.
Unfortunatelly, what I have been seeing in professional products is rather poorly designed API that practically needs another API on top of itself.
Therefore, more engineering attitutdes, please! :)
Arek Stryjski replied on Mon, 2009/07/13 - 7:54am
Andrew McVeigh replied on Mon, 2009/07/13 - 8:37am
i've worked in industry for about 20 yrs and am also finishing off a phd at a prominent university. i think the artificial division between programming/engineering and comp sci has led to many great evils. here's just a few of the obvious ones.
1. programmers not knowing the basics provided by a comp sci education
i.e. "oh, i didn't realise there was a better way to find a path between those nodes in the graph"
2. influential academics who design and critique languages without (literally) ever having done programming on any scale apart from toy problems. i can point to a number of language features in current use in very popular languages which fit into this category.
3. programmers avoiding reading academic literature which might give them a better perspective on what they do
4. academic papers focussing on toy problems and not fully testing their "novel" ideas
5. programming being not regarded as "not a profession" because the learning bar is set so low
--> contrast being a top programmer to being a top surgeon
it all adds up to a terrible gulf between programming/engineering and comp sci, from which our field suffers immeasurably.
Doug Barnum replied on Mon, 2009/07/13 - 1:40pm
A computer scientists' code doesn't need to compile while a computer engineers' will eventually when worked on by a computer programmer.
:-)
Dapeng Liu replied on Mon, 2009/07/13 - 10:05pm
this is a very interesting topic
imo engineering is the art of compromising, where CS is the pure art. Sometimes i juz know that the problem i was dealing with is very close to the one descriped in the books, but more than often there are some minor requirement that make the problem not the ideal one, in the end, to get it done, i wrote some 'ugly' code
CS always turns to simplify the requirement (good for easy understanding), while you don have the option to 'simplify' in engineering. Therefore i'd rather define "engineering" as "solving the real problem with least 'ugly' code before you start to hate yourself"