Software Engineering ≠ Computer Science (2009)

http://www.drdobbs.com/architecture-and-design/software-engineering-computer-science/217701907

by nreece • 9 years ago

482 301 9 years ago

100% agree.

So unless you spend all day writing compilers from scratch or calculating Pascal's Triangle, please stop with the ridiculous CS questions in interviews.

Software Engineering is more of a trade, and requires vocational knowledge and experience. A mountain of theory may not always be required to Get Shit Done.

justicezyx• 9 years ago

So unless you spend all day writing compilers from scratch or calculating Pascal's Triangle, please stop with the ridiculous CS questions in interviews.
Software Engineering is more of a trade, and requires vocational knowledge and experience. A mountain of theory may not always be required to Get Shit Done.

First, interview questions are engineering problems that either applicable to real world systems, or were inspired from them.

Second, interview questions are used to weed away candidates. At certain point, there will be a few candidates that can answer the questions and articulate sound engineering process. And that's one got hired.

vvanders• 9 years ago

Agreed, a good interview question is also a springboard to a discussion of engineering practices related to the problem.

sidlls4• 9 years ago

"Implement a recursive depth first traversal of a tree" isn't an engineering problem. It's a CS textbook problem. A fairly basic one, surely, but about as useful to a software engineering project in most cases as the ability to smelt and construct a screw is to an automobile engineer. And the software interviews GP complained about these days don't even start with something that trivial. Usually it's more absurd, and involves what are essentially little math tricks.

gravypod2• 9 years ago

I would never hire someone who would rather spend 20 minutes thumbing together a solution that may work instead of someone who would rather read available documentation and literature to find either...

    1. A trusted library that implements a complex feature
    2. A way to abstract away the need for a complex solution
    3. Feel the need to rush an implementation of a mission critical piece of code

I'd say software engineering is more about organization, abstracting, and simplification of a problem than it is about writing complex data structure implementations or complex algorithms. When you do need to implement a complex data structure or algorithm I think it's much more wise to survey available (and current) literature and implement the algorithm after thinking about the problem for a day or two then it is to attempt to implement it yourself in front of 3 people in a stressful time.

I'd expect no one I've ever worked with to be able to correctly meet any business requirement (full battery of tests, an attempt to avoid the more complex solution, documentation for the need and edge cases of an algorithm, real error messages, abstraction or library-extraction of this algorithm into a documented sub-project in our company's git server, etc) I have with a big 5 styled interview question.

It boils down to this:

    1. Your question is so simple it is stupid to ask someone who is actually qualified
    2. Your question is so complicated that anyone who would feel semi-confident in having actually solved it in 40 minutes is someone too dangerous to keep around

rocky1138• 9 years ago

interview questions are engineering problems that either applicable to real world systems, or were inspired from them.

My experience has shown me that in all cases except for two, this is false.

sidlls4• 9 years ago

It's not as simple as being "more of a trade." It's quite similar to the distinction between physics and, say, aerospace engineering in that regard. I'd never describe the latter as being a vocation or trade.

kohanz• 9 years ago

Agreed. Engineering is a "profession". You wouldn't call medicine or law "trades". In some jurisdictions (Canada for example) calling yourself a "software engineer" without having a professional engineering license is unlawful (although lots of people still do it and it's difficult for the regulatory agencies to enforce it at scale).

Nokinside• 9 years ago

Computer engineer != programmer.

1. Computer engineer is someone who knows computer science. Acquires knowledge that survives when tools die. Hired by Google and other firms.

2. Programmer. Blue collar worker writing bean counting programs. Mainly writes customer software for order. Gets shit done. Becomes difficult to employ when he turns 40 if the shit he does is outdated.

DaiPlusPlus• 9 years ago

A "computer engineer" is someone who designs microprocessors and physical computational hardware - not software. (And for the laity, it is not someone who fixes your broken desktop PC either).

Even if you meant SE instead of CE, I feel your distinction is arbitrary and almost classist - while it's true that the top notch folks hired by Google and Microsoft could write "bean counting programs" its fallacious to assume the contrarywise - major accounting and business software firms are just as picky when it comes to hiring - similarly I know plenty of small startups writing exotic software that are able to ship without needing to hire everyone from MIT an Stanford - I also know plenty of very intelligent and capable minds going to waste at companies like Google, MSFT and Facebook working on projects they dislike or for low-impact internal systems - while their contemporaries who went to a coding boot camp got picked up by Snapitterbook and become hot stuff despite never having read the Mythical Man-Month.

SAI_Peregrinus• 9 years ago

Computer Engineer != computer scientist.

1. Computer engineer works at and around the boundary between electrical engineering and computer science. Hardware, firmware, drivers, and other low-level systems that interact closely with the physical world. Hired by Intel and other firms.

2. Computer scientist knows the study of computation. Computer science tends to abstract the hardware away and consider ideal systems.

There is of course some overlap. Computer engineering is all about the overlap between CS and EE, so some CS people will work in some of the same areas as CEs. Likewise with EEs. And the terms are fuzzy, and may have different definitions to different people, but the distinction I made seems to be present in most college degree programs I've seen.

tensor• 9 years ago

Google and the majority of silicon valley grossly abuse the term software engineer (which is what you describe). There are very few software engineers at google, mostly just developers, many of whom are actually PhDs, which is also not an engineer.

Engineering is about process and responsibility. A professional engineer is often a protected term, and comes with a certain legal authority to approve designs as sound and correct. The purpose of this is to give people a reasonably reliable way to ensure that the people they go to for engineering designs meet a minimum level of professional knowledge. AFAIK in some cases the engineer can be held liable if their design fails causing death.

Can you imagine if developers had to take on some liability by legally and officially "approving" that a software design meets some criteria of being "free from error"? It's almost crazy to consider it, though you can imagine that such a thing would actually be pretty important for say, medical equipment software, or aircraft control software. Unfortunately this is pretty far from the reality of software engineering.

Unlike other forms of engineering, there is no such thing as a "professional software engineer", though you can get a degree in the _topic_ of software engineering.

TLDR there are no "software engineers" in the same sense that you have electrical or mechanical engineers. The protection on the term engineer in software is commonly contested, though perhaps less so in the US then elsewhere.

stale20024• 9 years ago

No, programmers get paid 6 figure salaries to work at top tech companies in the bay area.

Also,the "computer science" stuff that is asked in Google-style interviews is vastly overstated in terms of difficulty.

The interview stuff can be learned by most any programmer, in a couple months of intensive self study, involving going through practice problems in Cracking the Code Interview. You don't have to be a genius to do that. It is mostly just repetition and pattern matching.

I went through Google's process recently, and every single algorithm question that I was asked, was a problem that I had studied/seen in advance, word for word.

It turns out that there are only a pool of a couple hundred (thats a high estimate actually) algorithms questions that most interviewers will ask you, and if you've studied all X hundred of them, then you are good to go. No PHD or CS degree required.

ChemicalWarfare• 9 years ago

Assuming you meant "Software Engineer" not "Computer Engineer".

> Acquires knowledge that survives when tools die

I would actually agree with this, the kicker is though this "acquired knowledge" is not CS knowledge - it's understanding of how to get shit done in the "real world" and is not something you can easily acquire by reading a CS book.

deathanatos4• 9 years ago

I disagree.

* I routinely find people using the wrong data structure, when there exists a better one, with better O() time/space.

* I find people tend to not understand BTrees, particularly when there are two attributes being indexed. Given an index on (a, b), I find it common misconception that the BTree can efficiently answer `$a_min < a < $a_max AND $b_min < b < $b_max`. (I.e., people do not understand that the tree cannot make use of the second < condition, and must scan potentially many more rows than they intend.)

* Graph theory. git uses it. Any sort of dependency tree uses it.

That said, I acknowledge that software engineering does require a lot of non-theoretical knowledge, which is why I ask both types of questions in an interview.

Shank• 9 years ago

Yeah, but data structures and binary trees are about as much as you really need to get. There's a big difference between selecting the right data structure and re-implementing dijkstra's work on a whiteboard.

a_t48• 9 years ago

Counterpoint - I routinely see people ignore the actual real life cost of pointer chasing because O(n) (you don't need a linked list if you only have 10 small elements).

walrus1066• 9 years ago

Does your job actually require knowledge of BTrees?

wink2• 9 years ago

That's where I disagree. For 90% of the code it wouldn't ever matter if you're using a list with O(n) or an array with O(1). And in the 10% it can usually be remedied afterwards. Usually the reviewer will point it out and it's a 10min fix.

On the other hand I've seen so much hand-optimized code that used the correct data structures to solve the wrong problem.

Yes, that is kind of unfair - you want people who grasp the problem and find a good solution. But I prefer the people who solve the problem at hand in a wrong way instead of solving the wrong problem in the best imaginable way.

pitay3• 9 years ago

I am assuming you are talking about database indexes. The documentation for the database that I have most used actually specified what the various supported types were good for. It made choosing the correct type of index much easier. The documentation may be sufficient for determining which index types will perform well for the expected queries, even if knowing detailed information about data structures is nice to know. Having documentation which describes the data structures well enough is really nice though, and should be encouraged a lot.

hprotagonist• 9 years ago

This is not a particularly new observation.

My half-assed analogy:

CS is to SE as Physics is to Mechanical Engineering.

In both cases, it's unwise to trust one category with screwdrivers...

scierama2• 9 years ago

I love your analogy! Then there's the Howard Wolowitz's of the world who try to throw a pitch at a ball game using the Mars Rover. Not quite an applied technical person and not quite a pure theorist like Sheldon.

droidist2• 9 years ago

I quite like your analogy. If software engineer is like a mechanical engineer, what would a programmer be like, a mechanic?

bigger_cheese• 9 years ago

I've often thought there should be a third position a 'software designer' someone whose job it is to translate customer requirements into a design which the engineer can build.

In Engineering you have architects/industrial designers etc. They work out the product specifications and then ask the engineers to deliver an efficient workable solution that fits those specifications.

Sometimes at least from my view it feels like software engineering reverses the two roles. i.e The Engineer supplies the api and customer works around design. Think about something classic like Unix it feels like in some cases engineering has constrained the design rather than design constraining the engineering. This is not necessarily a bad thing but it is different.

tedmiston2• 9 years ago

In Engineering you have architects/industrial designers etc. They work out the product specifications and then ask the engineers to deliver an efficient workable solution that fits those specifications.

I've always thought programming would eventually go the way of mechanical engineering with engineers doing design vs fabricators doing the manufacturing. The closest we've come so far in software I think is having one person doing architecture or write a spec and others implement the code. Not quite the same but I wonder if we'll get there eventually.

autokad• 9 years ago

rarely has asymptotic complexity mattered to my code. usually the most important factor is modularization and readability. i spend more of my time reading or re-using code, and my time is more expensive than a computer. plus, highly optimized code can sometimes be unreadable and lead to bugs, which are also more costly.

saimiam5• 9 years ago

asymptotic complexity

If it hasn't mattered to you, it's probably because you are using libraries or apis which have solved for optimal performance.

In short, performance mattered a lot to you code. Only, you didn't slog long hours to make it so.

Back to the topic at hand, if you didn't spend time to understand why a particular module or library is part of your code base - be it for performance or maintainability or any other -ities - you're halfassing your job as a software engineer. Would a structural engineer ever claim with a straight face that they have never worried about the integrity of their struts? That's basically what you said with your claim.

sidlls4• 9 years ago

Nah, that isn't what was claimed. What you describe is more like claiming an engineer is half assing it if he doesn't verify that a given strut (library) that has been analyzed to death (already verified to have characteristics meeting the requirement) in fact meets them.

maxxxxx2• 9 years ago

I have seen the impact of linear or exponential complexity quite a bit in real world code so I think it's good to be aware of it in case you are having performance problems.

peterburkimsher2• 9 years ago

Here's the graphic transcribed as text for non-English speakers.

Software Engineering: Requirements, Modifiability, Design Patterns, Usability, Safety, Scalability, Portability, Team Process, Maintainability, Estimation, Testability, Architecture Styles.

Computer Science: Computability, Formal Specification, Correctness Proofs, Network Analysis, OS Paging/Scheduling, Queueing Theory, Language Syntax/Semantics, Automatic Programming, Complexity, Algorithms, Cryptography, Compilers.

In my opinion, some of those could be on the other side of the line (estimation could be CS, language syntax/semantics and network analysis could be SE). But I agree with the general division.

I studied Electronic Systems Engineering, but somehow always found jobs in software companies. One problem I struggle with is the division between DRY (Don't Repeat Yourself) and WET (Write Everything Twice) coding styles.

Most programmers hate it when code is repeated. They prefer to spend days trying to integrate external libraries instead of just copying the necessary functions into the main branch. There are good reasons for this (benefiting from new features when the library gets updated), but there are also risks (the code breaking when the library gets updated).

Software Engineering priorities include Safety, Portability, Modifiability, and Testability. I interpret that as a WET programming style. "If you want it done well, do it yourself." There's no arguing about responsibility then - the code is mine, and I should fix it if it breaks.

lgas• 9 years ago

How does copying the english words from the image to english words as text help non-English speakers?

sdrothrock• 9 years ago

Makes it easier to look up (copy/paste) and/or use dictionary tools.

spullara• 9 years ago

They can copy and paste them into google translate?

fny• 9 years ago

I don't think you understand DRY. It's a concern within the code you write rather than without. Whether you choose to freeze your dependencies is an entirely different concern.

Say, for example, you have a complicated condition you test for frequently within your code. DRY is when you decide to extract that condition into a testable function you can rely on everywhere in your code (e.g. `isLastThursdayOfMonth(date)`) You can extend this same DRY thinking to all the other abstraction tools (e.g. types/classes) you have as an engineer too. I'm sure you'd agree that it would be an enormous liability and maintainability nightmare to rewrite the logic for that function everywhere. God forbid you're ever asked to change your littered logic to the equivalent of `isLastWeekendOfMonth(date)`.

kfriede2• 9 years ago

Software Engineering looks like Systems Engineering with code applied.

peterburkimsher2• 9 years ago

That's a wonderful description, thank you! Yes. Software Engineering is applying Systems Engineering principles to the field of programming. It's a pretty good field to work in, because the biggest risk I face is only data loss, unlike other engineering disciplines where the stakes are much higher.

deathanatos4• 9 years ago

but there are also risks (the code breaking when the library gets updated).

This is the entire point of Semantic Versioning: to communicate breaking changes through the version number, and to build tooling to programmatically avoid breaking dependent code.

(No, it isn't generally perfect: it does require that human realize what the API is that that a given change is breaking it. If we had some programmatic language for specifying the API… type systems start this, but tend to not capture everything¹)

¹I suspect there are some formal analysis folks who know more than I do here, screaming that there is a better way. I work in Python day-to-day, so generally, it's all on the human.

gavinpc• 9 years ago

See this talk [0] about this addition to Clojure called core.spec [1]. I read the paper first, and it isn't until the end of the presentation that I understood how it was related to the feature at all. Basically, core.spec is a kind of formal verification tool designed to deal with the growth of software. It is not a type system, though it resembles one in some ways. The objective is to support comparisons between the signatures of a function at two different points and say, are these compatible? Is this a breaking change? You have to design for growth: make no assumptions about unspecified keys and always assume that later versions may return more than they used to. And so on.

If you're a fan of semver, be warned.

[0] https://www.youtube.com/watch?v=oyLBGkS5ICk

    https://news.ycombinator.com/item?id=13085952

[1] https://clojure.org/about/spec

tedmiston2• 9 years ago

And freezing / pinning dependencies (and their dependencies...) to avoid deploying a version of a library you haven't already tested first.

continuational• 9 years ago

Elm has automatic semantic versioning based on the type system:

https://github.com/elm-lang/elm-package/blob/master/README.m...

knocte2• 9 years ago

Computer Science: Computability, Formal Specification, Correctness Proofs, Network Analysis, OS Paging/Scheduling, Queueing Theory, Language Syntax/Semantics, Automatic Programming, Complexity, Algorithms, Cryptography, Compilers.

It's interesting/funny that when talking about CS, or more academic point of views around software development, the terms "Formal Specification" and "Correctness" are often mentioned, yet most CS students/labs still use languages that are really badly suited for this job, such as dynamically typed languages like Python.

goatlover3• 9 years ago

Are languages like C & C++ that much better?

xfer2• 9 years ago

There are various fields in computer science, nobody claims formal specification and correctness in a NLP/ML library nor in a graphics library. Formal verification is orthogonal to other fields.

elchief• 9 years ago

WET is "we enjoy typing" where I'm from

nautilus124• 9 years ago

Its a naivety of early programming that DRY is the chief principle of software engineering. Try understanding the underlying patterns and applying the right design patterns for the job and you will realize that DRY without deeper thought is just shuffling the problem around like a kid throwing his mess in the closet.

dragonwriter• 9 years ago

Software Engineering priorities include Safety, Portability, Modifiability, and Testability. I interpret that as a WET programming style. "If you want it done well, do it yourself.

None of those demand “write everything yourself”, only setting the same criteria for external code you integrate as you would have for code you write yourself.

oneplane• 9 years ago

Yeah, no shit...

Truck Driver ≠ Road Planner

amw-zero• 9 years ago

all computer hardware is essentially equivalent.

This is quite inaccurate. Hardware directly influences software. "if" statements, functions, and threads didn't exist at one time, and all require explicit hardware support. I believe that as we come up with different abstract constructs at the hardware level, we'll influence the possible software that can be written.

ajarmst2• 9 years ago

There are many abstract concepts that need to be realized before we can usefully call a particular device a 'computer'. Many, but certainly not all, of these, are gathered up into things like Turing Completeness, Von Neumann Architecture, etc. On that (admittedly mostly theoretical) scale, it is meaningful to discuss computers as a broad class having certain characteristics. That's what allows us to reason effectively about things like efficiency and correctness in computer algorithms. They even allow us to meaningfully compare digital, analog, mechanical and quantum computers, despite radical differences in the physical hardware. If the object you're showing me doesn't support conditional behaviour ('if' statements), it's going to be pretty hard to convince me to discuss it as though it were a computer.

DonaldFisk• 9 years ago

Sometimes true (e.g. the PDP-11 instruction set did influence C), but software can also influence hardware.

Many early computers had very rudimentary subroutine call mechanisms (e.g. the B-line of the Elliott 803), but this didn't prevent programmers from using functions which returned values, sometimes recursively.

Burroughs mainframes were designed to run Algol 60 (with a few additional instructions for use by COBOL programs), and Lisp Machines were designed to run Lisp. In these cases, the influence of the languages extended to the entire instruction set. This is a better approach, as it's easier to experiment with language design than it is with hardware design.

vitus• 9 years ago

software can also influence hardware

This happens more often than you'd think. Intel (and later, AMD) added AES primitives to their instruction set to speed up encryption. VT-x (and the AMD equivalent) were both designed to improve the performance of virtualization. Outside of the realm of CPUs, the use of FPGAs -> ASICs for accelerating bitcoin hashing certainly wouldn't have existed if not for the software. Hardware support for CUDA / OpenCL accelerated existing parallel workloads.

This is a better approach, as it's easier to experiment with language design than it is with hardware design.

FPGAs certainly lower the barrier to experimenting with hardware design, although yes, it's probably still higher than language modifications.

goatlover3• 9 years ago

As an example of different hardware, there was a Russian engineer who built a couple of ternary computers in the 70s. And of course there have been analog computers.

Quantum computers would certainly not be considered "essentially equivalent".

jolux16• 9 years ago

I don't understand why the author is so suspicious of formal methods. Other engineering disciplines are based on the application of solid, well-understood principles from the natural sciences to practical problem domains. There are few solid, well-understood principles in computer science that are directly and obviously applicable to software engineering so far.

I vigorously contest the idea that software engineering cannot be rigorous and so shouldn't try.

sillysaurus34• 9 years ago

Because there are what, six types of bridges? (EDIT: 36 according to wikipedia.)

There are six thousand types of programs (as a wild guess), and they all interact with each other in an exponential explosion of complexity.

For a formal method to work, it has to be generally applicable across a wide range of situations. There are methods like that in software engineering, and you see them in situations where the program is potentially life-threatening. But most programs would be hindered by this rigor.

rubidium• 9 years ago

Six types of bridges... Were you serious? There are definitely ways to apply formal engineering methods to software that greatly help its development.

Computer programming is not a special snowflake. It's a field that (in many areas) refuses to grow up.

jolux16• 9 years ago

I'll put it this way. In mathematics, the atomic unit of progress is the proof. Proofs are constructed from axioms and other, smaller proofs. The Curry-Howard correspondence is the direct correspondence between computer programs and mathematical proofs.

When programming in a well-typed language, everything we do is a degenerate proof of something. I think it's entirely reasonable to try and make it easier to make less degenerate proofs, and encourage the re-centering of proofs as the atomic unit in programming, because they are for programming (as in math) a well-defined, solid formal system that solid systems can be built on in a way that nothing else can be in software, at least thus far.

In a world where software flows more freely than water, the correctness and reliability of software systems must be taken with utmost seriousness. This applies to basically any tool that contacts end users, and a lot of ones that don't as well.

What do you propose as the theoretical basis for the engineering science of software development?

KirinDave2• 9 years ago

So like, for example, Monads. Monads are applicable across every program ever written and with some rules laid out around them have remarkable properties. Comonads too.

Can we use those? By your criteria, I mean.

nautilus124• 9 years ago

There may be thousands of typs of programs but how many software design patterns are there? This is a much better analogy I think.

eksemplar• 9 years ago

Wouldn't it be more fair to compare the bridge types to for loops?

You need science to come up with it and engineering to apply it in practice.

bousaid• 9 years ago

You can't seriously be putting software engineering above civil or mechanical engineering... They're two completely different fields which both require years and years of training.

bluetwo2• 9 years ago

Because entropy. The natural state of the world is chaos.

andrepd• 9 years ago

That's about meaningless a statement as they come. How do you mean?

ScottBurson• 9 years ago

I agree with you about the potential value of formal methods, but I think you completely missed the point of the article. Formal methods can't supply specifications. They can perhaps tell you if your specification is consistent and therefore implementable, but they can't tell you whether the system you've specified will meet your needs.

I think those of us who promote formal methods need to remember this. At best only verification -- making sure the implementation matches the specification -- will ever be fully automated. Validation -- making sure that what we specified is actually what we wanted -- will always be a human activity.

jolux16• 9 years ago

Yes, you're entirely correct. But you also seem to be the only person in this thread who can pull that distinction out of this discussion, everyone else is ranting about how The Market is the only real spec or whatever.

peteretep• 9 years ago

    > why the author is so suspicious of
    > formal methods

I studied Z-Notation and CSP at what is perhaps the home of formal methods (cs.ox.ac.uk), and I've yet to come across a real-world situation where I've found either in the least bit useful.

auggierose• 9 years ago

It is right to be suspicious of formal proof. In most areas of software engineering, employing formal proof makes you about 10-1000 times slower. Knowing how to do a formal proof in principle though lets you often reap a lot of the benefit without actually getting slowed down much. This is similar to how mathematicians know how to prove something in principle without running it through Coq or Isabelle.

By the way, Curry Howard is just one way of doing formal proof (one I personally don't like). There are many foundational and practical problems that need to be solved before formal proof is ready to go mainstream (but I am convinced that it will one day).

ajarmst2• 9 years ago

I'm convinced that the only useful definition of a Software Engineer is "someone who has 'Software Engineer' in their job title". Most other Engineering disciplines are far more rigorously defined. That said, observing a disconnect between theory and application is hardly novel or unique to software disciplines.

drawkbox• 9 years ago

Most developer jobs contain parts of both, with more time spent in software engineering.

Software development, app development, game development, web development are all probably 90+% software engineering and 1-10% computer science depending on the project. Specific projects may differ such as writing standard libraries, engines, data, standards, teaching, etc. In the end most of it is production and maintenance as part of shipping.

ChuckMcM2• 9 years ago

I've seen similar articles to this one, both in print and on web sites. I used to explain it to people as the difference between 'coders' and 'engineers' but I think my own hubris at having a degree got in the way of my thinking on it.

Over the decades I've met a bunch of people who program computers for a living, and there is clearly a spectrum where on one end is a person who spends the weekend benchmarking different sort algorithms under different conditions for the fun of it, and the guy who left the office at 5PM once an integration test passed on a piece of code that he pasted in from stack overflow was deemed to have no regressions. There are many different disciplines that have such a wide dynamic, from chefs who spend their weekends trying different flavors to cooks who take frozen patties out, reheat them and serve. Painters who throw human emotion into a painting and painters who lay down a yellow line on a road according to a template for $20/hr.

It seems to me that most, of not all, of the 'theory' stuff in computer science is just math of one form or another. This is not unlike all the 'theory' stuff in electrical engineering is just physics. You can do the tasks without the theory, but you rarely invent new ways of doing things without that understanding.

But just like carpenters and architects there is a tremendous amount of depth in the crafting of things. That brilliance should be respected, college trained or not, so trying to 'split' the pool doesn't lead to any good insights about what being a good engineer is all about.

Clubber4• 9 years ago

I used to explain it to people as the difference between 'coders' and 'engineers'

This isn't going to be popular, but it's true.

Coders are what people called themselves before business started making the decisions about how to write software.

Engineers are what people called themselves after business started making the decisions about how to write software.

Guess what? People who write software aren't engineers, they are programmers. You have crap programmers and you have exceptional programmers, but you they are paid to write programs. "Software Engineer" is as valid as a "Sanitation Engineer."

Coder is a slang for programmer because they write "source code." it dates back to at least the 80s, probably earlier. It is also acceptable term for programmer.

If you have to make up a fancy term, call yourselves software developer or software designer. If you want to be called an engineer, go to engineering school.

https://www.theatlantic.com/technology/archive/2015/11/progr...

adjkant• 9 years ago

The terminology is shifting though, and has been for some time now. While I agree that CS/SE is not "engineering", it's the common term across the top companies, with words like "developer" now fading in use.

For me, I have the opposite reaction to coder vs engineer.

For a coder, I think code monkey, someone who writes boilerplate MVC apps and can't handle algorithmic complexities, write code that others can understand, or consider lower levels of a system they are interacting with. Also synonymous with hacker, which I would bet also has a reversed connotation for those who see coder as a good thing.

When I hear engineer, it's synonymous with the jobs at the big name companies and implies the person thinks their job is complex enough to warrant the title, even if not deserved by the standards of other engineers.

Of course, all of this is semantics, including the debate over what is an "engineer". In the end, it's pretty meaningless in terms of impact. CS vs SE I think should be the focus, as yes, the two can be quite different, even if most CS degrees end up working in SE.

hueving6• 9 years ago

It's sad to me when people try to trivialize the profession of the people responsible for the information age like this. Why does the term 'software engineer' hurt your feelings so much when these are the people responsible for taking mathematical concepts and turning them into working marvels like the Internet, wifi, cellular data, networks, etc?

zerr2• 9 years ago

You seem to be labeling overworking as "good" and in-time as "bad"... Here's an alternative perspective - I've seen underperformers who try to make it up by staying late and even allocating weekends for their employers, on the other hand, I've seen brilliant engineers who do the job and leave the office at 5PM, spending personal time on recreation, including learning other tech/stuff not relevant to their employers...

ChuckMcM2• 9 years ago

If I gave that impression I apologize it was not my intent. I don't attach any judgement to either hours invested or method of code construction. I was just sharing my observation that it is a multi-variable spectrum. That leads directly to your exact observation. Very little correlation between hours spent 'at work' and the quality of code produced.

When I started managing programmers I realized the best thing I could do was to manage people by agreed upon deliverables for their capabilities, quality, and maintainability. And if it took them 10 hrs to do it or 70hrs didn't matter. As long as I understood, and they understood, how long it would take them to do something we could manage to that schedule.

hueving6• 9 years ago

That's because you just fixated on the 5PM and not the rest of the words in each sentence.

partycoder• 9 years ago

Let's revisit the definition of "engineering", in a simplified form:

    Science -> Engineering -> Technology

Engineering borrows scientific[1] knowledge to create[2] technology[3]

[1]: or empirical knowledge

[2]: or maintain or implement

[3]: or processes

The relationship between science and engineering has been clear for a while now, even before the appearance of software engineering.

There's a lot of science at work in existing software, so it would be inaccurate to say that software is "unscientific". However not many people get to work on those projects.

A vast majority of people can make a decent living working on user facing technologies built with existing technology. At that level appealing to non-technical stakeholders has much more weight than applying engineering rigor.

But that's not the reality for everyone.

KirinDave2• 9 years ago

I neither agree nor disagree with the article. I think it conflates a lot of stuff.

But look, what the math and science sides of the room throw at us definitely informs the engineering. In every other engineering principle from architecture to ditch digging, there is a feeder system from a variety of mathematical and scientific disciplines. While many other engineering disciplines are well established, they are not immune to this and in general don't begrudge it.

Doctors are required to keep up on the state of treatment. Architects need to keep up on materials science AND new mathematical modeling techniques and tools. Car designers care about new discoveries in lighting, battery and materials technology.

Here's a good example of the kind of stuff we all should be on the hook for. I've tried to push this paper up to the front page a few times now because it's roughly the same as if someone walked up and calmly announced they'd worked out how to compress space to beat the speed of light:

http://www.diku.dk/hjemmesider/ansatte/henglein/papers/hengl...

Folks are generalizing linear sort algorithms to things we thought previously were only amenable to pair-wise comparison sorts without a custom programming model and tons of thought. No! And then a famous engineer-and-also-mathematician made an amazingly fast library to go with it (https://hackage.haskell.org/package/discrimination).

We're seeing multiple revolutions in our industry made of... well... OLD components! While deep learning is starting to break untrodden ground now, a lot of the techniques are about having big hardware budgets, lots of great training data, and a bunch of old techniques. The deep learning on mobile tricks? Why that's an old numerical technique for making linear algebra cheaper by reversing order we walk the chain rule. O(n) general sort is arguably bigger if we can get it into everyone's hands because of how it changes the game bulk data processing and search (suddenly EVERY step is a reduce step!)

We've similarly been sitting on functional programming techniques that absolutely blow anything the OO world has out of the water, but require an up-front investment of time and practice with a completely alternate style of programming. But unlike our fast-and-loose metaprogramming, reflection and monkey patching tricks in industry these techniques come with theorems and programmatic analysis techniques that make code faster for free, not slower.

Even if your day job is, like mine, full of a lot of humdrum plug-this-into-that work, we can benefit from modern techniques to build absolutely rock solid systems with good performance and high reliability. We could be directly incorporating simple concepts like CRDTs to make our systems less prone to error.

It's our job (and arguably it's the hardest job of the field) to dive into the world of pure research, understand it, and bring what's necessary out to the world of modern software. That means more than just tapping away at CSS files, or wailing about NPM security, or shrugging and saying, "Maybe Golang's model is the best we can hope from in modern programmers."

sytelus2• 9 years ago

Computer science is neither about computers nor is a science :).

goatlover3• 9 years ago

It's about the math of computation then, which can be carried out by any arbitrary system that we humans deem as carrying out symbol manipulation.

sytelus2• 9 years ago

People are obviously not getting this popular joke in academia. Open a book such as Introduction to Algorithms by CLRS and you will see its all about creating algorithms in pseudo-code, proving its correctness, evaluating runtimes etc. Authors not only pass on "systems engineering" but even producing algorithms in actual language that can be compiled on actual computer. Don't get me wrong, I love the book and have gone through every single page and vast majority of excerices twice and truly enjoyed it. It is then when it hits you what computer science is really about.

The folks in fields like mathematics or physics didn't used to consider "Computer Science" as "real science". As fun fact, there were no journals on computer science for quite long time. Researchers like Dijkstra would identify themselves as "Mathematician" and publish their now very well known algorithms in mathematical literature :).

halfnibble2• 9 years ago

I didn't study Computer Science in college. Not one single course. But I'm not stupid. I made straight A's in math through Calculus III. So a lot of these comments frustrate me. I've taught myself literally everything I know. I've read dozens of books. I practice coding obsessively--it's my passion. Do I "get shit done"? Yes, absolutely. Do I not care about the efficiency of my algorithms? No, I care deeply. I don't always know the "computer-sciency" term for things. But my goodness, get off your high horse and tell me what you want accomplished. Chances are I'll implement a solution that's just as efficient and arguably much better than most "engineers" can. And no, I'm not going to be obsolete at age 40. By the time I reach age 40, PhD's will be coming to be for advise. Because I didn't study computer science in college. I'm studying it for life.

ijidak• 9 years ago

I think your type is the exception rather than the rule. I have a background in computer science and I love the beauty of correctness. But at work, I constantly find myself struggling to get my fellow developers (even with CS degrees) to think in terms of mathematical correctness instead of just, "how can I get this program to work today?" For example, can we define our methods to use the most general base type that is appropriate, or an interface that is yet more strict, and guard clauses that, the combination of which, create a method that mathematically cannot fail except for upstream, downstream, or machine level (e.g. out of memory) issues. If we do so consistently, then we have rock solid methods that we can trust. But usually I find that my co-workers don't want to think in terms of these sort of rock solid contracts. And instead they just want to get the program to work today; To get their scrum story done. Inevitably they keep going back to these methods to fix a scenario they didn't anticipate. It's such a colossal, collective waste of time. I don't think everyone has to study computer science, but an appreciation that programming can be more mathematically precise than many programmers try to make it would benefit the industry. It would drastically reduce bug counts, improve the ability to reason on code, and increase developer productivity.

deelowe2• 9 years ago

That works great for you. What happens when my objective is to develop a solution that requires 100s of developers, spans multiple years, costs billions, and has major liability concerns?

oq-pmg• 9 years ago

...and by the time you finish, it most probably will be obsolete :)

Jokes aside, software engineering discipline of its own would not give you skills needed to accomplish that.

halfnibble2• 9 years ago

My recommendation would be to hire people who are smart, responsible, and passionate. The language or framework can be taught. That's what the FAA does. Their initial assessment exam determines cognitive aptitude--not textbook knowledge. And air traffic controllers from all backgrounds are responsible for billions of dollars worth of aircraft and the lives of hundreds of thousands of people every single day.

foepys• 9 years ago

Why do you consider asking for advice as a bad thing or being inferior? Every PhD knows that if you don't know something, you ask somebody that does. Collaborating is a huge part of academia. If you think you are better than a PhD just because they ask you stuff, you are definitely wrong.

You seem to have a completely wrong understanding about why people do a PhD. They (okay, most) don't do it to attach a title to their name but because they are passionate about a specific field and want to expand their and other's knowledge about it.

rpiguy• 9 years ago

Or because they are more interested in theoretical application rather than practical application. PhDs are where you explore questions that have unknown market value.

This is often interpreted as, "you can't hack it in the real world, so you hide in academia," and in some cases that is true. But really it has more to do with what problems you are interested in solving/exploring.

alkonaut7• 9 years ago

Software engineers need to know to recognize and classify problems in CS. You need to know what algorithms and data structures exist, what their properties are, and what they are called. The areas that come up will come from Math and Computer science (which are closely related). A solid computer scientist person knows how to derive some Dijksttra algorithm from first principles. A good software engineer recognizes the problem at hand, and recalls the algorithm to pick when presented with the problem.

What is that problem in front of you? Gradient descent? Tree traversal? Multiple dispatch? Path finding? What structure represents the data or algorithm? Ring buffer? Blocking queue? Bloom filter?

You rarely need to remember a pathfinding algorithm or trie implementation by heart. What's important is that you a) recognized the problem at hand as "path finding", "bin packing" or whatever. Terminology is important here. The good software engineer needs to know the proper names for a LOT of things. Recognizing and labeling problems means you can basically look up the solution in no time.

So CS is definitely very relevant for software engineering - but you need a broad understanding instead of a deep one.

There is always the argument that a lot of devs basically to monotone work with SQL and some web thing in node and rarely even reach for a structure beyond a list or map. That's true - but sooner or later even they bounce into a performance or reliability issue that's basically always due to incorrect choice of data structure or algorithm. I'm only half joking when I suggest that most of todays "scaling" is compensating for CS mistakes in software.

noir_lord4• 9 years ago

I don't have a formal CS background and have indeed run into the issues you've described.

I generally resort to Google and then go find the best approach and implement it if necessary.

I taught myself the basics of the underlying stuff (and it helps that I'm an older developer who grew up on Turbo Pascal and C since I do have a working knowledge of what the machine is doing underneath).

Those are rare cases though.

1_player• 9 years ago

Same here, I'm completely self taught, I know when the appropriate data structure for the problem at hand might be a binary tree, yet I never learned how to implement a tree data structure.

I've read plenty of implementations, but I never "studied" it thoroughly. And that's one of the reason I never went through an interview with a Big 5 company, where you're normally expected to implement i.e. a tree insertion algo on a whiteboard.

StreamBright• 9 years ago

> A good software engineer recognizes the problem at hand,
> and recalls the algorithm to pick when presented with the
> problem.

In my experience people able to pick the right algo straight away is extremely rare.

alkonaut7• 9 years ago

What's the right algo might not even be a clear answer, but even just identifying something as needing a tree-like structure (rather than say a linear brute force search) could be a huge leap in the right direction. Being able to do rudimentary complexity calculations in your head helps.

Broad knowledge could even identify several different approaches to the same problem, which can be compared on strengths and weaknesses even before trying one.

E.g for a nonlinear an optimization problem you might consider simulated annealing, genetic programming, gradient descent etc. and you need to know which is easy/hard to write, that gradient is good if you have (monotone) gradients etc.

TheAceOfHearts• 9 years ago

Sometimes you're just forced to accept you need to take some shortcuts. There's a few fields for which my general approach is to just try and maintain a mental index of "when might I want to use this".

I'd have a hard time implementing my own crypto, but I've learned enough to know how to use it to secure communications, hide or protect information, ensure no alterations have been made to some arbitrary asset, identify an asset's source, etc.

I love working with a well understood and boring RDBMS. It's predictable and it lets you quickly move on to other problems. But you still need to have a good understanding of how it's implemented in order to store and query your data efficiently. If you have a poor understanding of how indexing works, you'll probably have a hard time selecting the right data model.

There's actually lots of fun problems in the frontend world. Try to write a multi-touch gesture responder, it's very tricky to get things right. How about a natural animation system that allows interruptions? CSS animations tend to look unnatural because they're largely time-based, and they don't handle interruptions very well. (Spoiler alert: springs are the magic sauce.)

Learning about compilers unlocks lots of powerful skills too. You can implement your own syntax highlighting, linter, refactoring tools, autocomplete, etc.

alkonaut7• 9 years ago

I'd have a hard time implementing my own crypto,

Yes. Or, it's actually rather easy - but it's extremely hard to do well. That's why one shouldn't do it (or, you should, but perhaps for toying with and not for production). See, you obviously know enough about the topic to know this! This is exactly one of those nuggets of "broad knowledge" you need as a software developer. How much do you know about crypto:

- You need to know when to hash ansd when to encrypt.

- You need to know the properties perhaps of symmetric/asymmetric crypto and key exchange

- You must know that you never implement any of these algorithms yourself, you only choose from them.

That's about it. You need to know what you don't know (how to write reliable crypto) in this case.

If you have a poor understanding of how indexing works, you'll probably have a hard time selecting the right data model.

Right. Basically understanding a database is around the amount you need to implement a toy database. You know the difference between an index lookup and a scan and so on. Lacking that understanding means the database is some oracle (haha) you feed SQL and it spits out data. If you do know a bit more you might have a vague idea about how data sits on pages that are oriented into a btree. You might know that how the disk tree is magically updated in both ends to be consistent even if power is switched off mid-write and so on (I don't know, this really isn't my area - I have coded 13 years without a db). You didn't invent or even deeply understand any of these algorithms to the point where you could write them on a whiteboard. But it does help you if someone asks "what happens to users' bookings if I cut the power?" or "will it be faster to join in the DB or later in the language".

Another pet peeve of mine is people who can't identify NP /exponential problems. It happens several times per year that junior colleagues of mine develop solutions that are exponential in time/space, because that's what the problem is.

Them: "Look, I optimized the order in which we pick the X from the list"

Me: "That will take the remaining life of the universe already with 30 items!"

Them: "Dang :( that took me two days to write"

Me: "Do it the dumb way and get off my lawn"

trevyn2• 9 years ago

Eh, I'd much rather "software engineers" had good product and business sense, since most product managers and CEOs sure don't. No point in building the wrong thing well.

alkonaut7• 9 years ago

That's of course another factor that goes into software engineering skills. Collaboration, Domain knowledge, Design skill, Customer knowledge, some ops knowledge and so on.

19890309• 9 years ago

No point in building the wrong thing well

Very powerful statement there.

Jtsummers3• 9 years ago

No point in building the wrong thing well.

This is validation, and in systems engineering (which software engineering both came from and fed back into before we, in software, forgot about it). It's part of the V&V (verification and validation) portion of system development. Verification means ensuring the system is correct with respect to the specifications and requirements. Validation means ensuring that what's being made is actually the correct, desired thing.

We need our software engineers to study systems engineering, where you will find formal methods being applied to the task of developing complex systems, and rather effectively at that.

AnimalMuppet2• 9 years ago

If the product managers and CEOs don't have it, how do you expect the software engineers to do better? That isn't our area of strength.

vmware513• 9 years ago

Where could we find a kind of comprehensive list of CS problems, algorithms with association of the real problem what it can solve in practice?

You mentioned a few here, I suppose, there could be a full list already somewhere. :)

alkonaut7• 9 years ago

Excellent question. I'm sure this already exists, but if it doesn't it would be fantastic to have an archive with a toy example/challenge similar to Project Euler (https://projecteuler.net/archives) but with more "high level" algorithms with concrete and concise examples. For lack of a better place, this is a good starting point (with examples for each)

https://en.wikipedia.org/wiki/List_of_data_structures

https://en.wikipedia.org/wiki/List_of_algorithms

davidreiss• 9 years ago

So CS is definitely very relevant for software engineering - but you need a broad understanding instead of a deep one.

Absolutely. A general understanding of CS is necessary to be a competent software engineer. Just like a general understanding of physics is necessary to be a civil/mechanical engineer.

If there is a VENN diagram, there is definitely an overlap of "theory" and "engineering". But theory != engineering.

Illniyar• 9 years ago

Everything you suggested software engineers needs to know was covered in two courses in mt university- one called data structures, the other called algorithms.

And those didn't really need any requirements apart from basic math.

There is absolutely no reason for a software engineer to learn abstract algebra, infinitesimal math or any of the other dozen courses that you'll never ever use.

And even then, throughout my 10 years now, I can count on one hand the number of times I actually needed to use these things.

jawilson2• 9 years ago

It depends on your area. I am a software engineer and write software for biomedical signal analysis and finance/trading, and I promise you it is very math intensive. There is a pretty wide gap between a SE creating websites and a SE designing trading systems or medical devices.

fundabulousrIII3• 9 years ago

Well done! These are the two topic areas that are really interesting for the practically minded as well. It does help to like math rather than hate it for a software engineer but refined math is mostly out of scope for most programmers.

bnegreve• 9 years ago

To me the whole point of a university course is to learn part of the theoretical knowledge you would not learn spontaneously by practicing. That includes way more than just algorithms and datastructures.

For example, a good knowledge of language theory will prevent engineers from creating scripting languages that cannot be parsed. Probabilities are everywhere in machine learning. Many engineers work with by-products of operational research and need to understand the theory behind them to make them efficient. Complex numbers and trigonometry (quaternions etc.) are needed to build even basic 3D engines. Recent probabilistic data structures such as hyperloglog are being integrated into modern database systems. Good understanding of operating systems is useful for security and parallel programming...

alkonaut7• 9 years ago

As others have pointed out, some math is CS that is almost independent of the problem domain, and then there is obviously lots of math that is domain dependent. I use tons of linear algebra, trig etc. in my field (CAD).

hestefisk• 9 years ago

Software engineering is where the rubber hits the road in terms of requirements definition, creating a solid design, fitting stuff into an existing legacy environment (SAP anyone? Java EE?), iterating prototypes with stakeholders... and usually in large corporations. It was out of many years of budget overruns in defense procurement that software engineering cornerstones such as CMMI emerged.

To me, the essence of software engineering is that 20% is about building the 'good' solution itself, e.g. architecture, code, release / deployment, ... the remainder of the engineering is navigating / tolerating the inherent corporate messiness of politics, opinions, power, and everything else... engineering the solution is the easy part; engineering good requirements and quality is tough.

z3t4• 9 years ago

What is software Engineering !? Making an excel sheet ? Making a web site ? Writing SQL ? Using programming language X, Y, Z ?

thomasbachem• 9 years ago

We also wrote an article about this about a year ago: https://code.berlin/en/blog/computer-science-software-engine...

tim333• 9 years ago

The author has a slightly funny use of the word engineering. If you look at its use in a conventional field like making cars then the science bit is the basic physics and chemistry of how gasses expand etc, the engineering is designing the machinery so the brakes work, the engine produces enough power and doesn't break and the like and then human issues like whether the workers go on strike or the end users are idiots and crash are not engineering.

Similarly I'd say in software the engineering bit is making reliable systems that are fault tolerant and secure and so on and then the people bits like the user interface are something like design and psychology, not engineering.

lngnmn• 9 years ago

Sure. Engineering is an applied science. So, these cannot be equal.

Chiba-City• 9 years ago

These are complicated terms. Harvard's CS was part of their Applied Math department. There are Applied Maths of scheduling programmatic Engineering outcomes for sure. Fred Brooks taught us all that.

I studied Russell, Godel, Tarski and Quine and then compiler and runtime logic (as a Philosophy major). Back then CS was mostly a realm of 3-Page proofs on alpha renaming or newfangled Skip List speed/space utility.

As an old VAX/Sun or 512K/DOS C programmer working in DC for decades around lots of TC, datacenter and transaction processing folks, an SE MUST have basic speed/space, set theoretic, programming by contract, data integrity and MTBF abstractions in their heads while they plan and develop. Both accuracy and performance against test and measure just matter for the business cases 24/7.

Content software developers patching together framework components on 2 day schedules for consumer Web bloatware rarely understand something like data integrity needs of billing system logic embedding in redundant switches failing over on rough schedules. Typing commands is not even Software Engineering.

Software Engineering is not an individual identity phenomenon. SE is how groups show responsibility for stakeholder outcomes unrelated to paychecks. First rule of SE is everyone on the team passes the bus test. Nobody is essential. Unless we seek luck, we can't improve what we don't measure. Learning how and what to measure takes real training and group method application. So many out there never know what they are missing.

Business competition minus lucky windfalls is largely based on COST ACCOUNTING. Successful operations will discover heat dissipation costs challenges. Basic CS speed/space, contract covenant assertions, data integrity and MTBF logic in Software Engineers translates very easily into understanding business innovation problems.

cpburns2009• 9 years ago

Software Programming != Computer Science Software Programming and Science != Engineering

While we're drawing distinctions stop calling yourself an engineer unless you're legally licenced as one. Programming may share similarities with engineering but it lacks the professional accreditation and liability.

k__• 9 years ago

In Germany we have Informatik, which was treated as CS&SE long time.

Lately there are sprouting more and more SE degrees.

On the other hand we also have universities of applied science, where Informatik is often more like SE

flavio81• 9 years ago

In Peru we also have "Informatics Engineering", which is my degree. It is a mixture of CS courses (and a lot of math courses as well), plus SE and also EE courses (i.e. digital electronics' fundamentals / computer ALU/CPU design).

joedo34• 9 years ago

Scientists use the scientific method to make testable explanations and predictions about the world. A scientist asks a question and develops an experiment, or set of experiments, to answer that question. Engineers use the engineering design process to create solutions to problems.

Software Engineering ≠ Computer Science (2009)

Related Stories