As an Agile Coach, Miško is responsible for teaching his co-workers to maintain the highest level of automated testing culture, allowing frequent releases of applications with high quality. He is very involved in Open Source community and an author of several open source projects. Recently his interest in Test Driven Developement turned into http://TestabilityExplorer.org with which he hopes will change the testing culture of the open source community. Misko is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

Computer Engineer vs. Computer Scientist

07.13.2009
| 8306 views |
  • submit to reddit

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.

From http://misko.hevery.com

Published at DZone with permission of Misko Hevery, author and DZone MVB.

(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

I agree with Jakob. There is a lot of believes, ideology and blindly following "gurus" in programming. We should start thinking more critical and start to recognize difference between facts and theories from just opinions and believes. I also agree with Misko. We need a lot more of engineering. But I don't think you get engineering knowledge by learning from others. Sorry but this sound like craftsmanship. If you learn craft you need master. I will say more science and engineering less craftsmanship.

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"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.