41 ms·

Software Engineering ≠ Computer Science (2009)

482 points by nreece 9y ago

whatnotests 9y 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 9y 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 9y ago
    Agreed, a good interview question is also a springboard to a discussion of engineering practices related to the problem.
    - LoSboccacc 9y ago
      The only work environment viable engineering answer is to get a library to solve whatever the problem at hand. At best a top candidate should be able to turn a whitepaper into working code. Knowing trivia rarely translate in solid, productive teams. Very, very few companies are pushing the what's known barrier.
  - sidlls 9y 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.
    - Pyxl101 9y ago
      I wouldn't ask this question but I don't think it's irrelevant. It shows you that the person understands concepts like recursion, is familiar with data structures like trees, and understands how to express and work with those concepts in code. Completing this problem should take only a few minutes and tells you whether a candidate has a basic degree of competence. When someone breezes through a problem like this, you learn something. If someone struggles with it, you also learn something. You can use that knowledge to calibrate subsequent questions and find the limits of their knowledge. I would be skeptical about the effectiveness of software engineer candidate who isn't comfortable with trees or recursion or algorithms like search. It's a weed-out question like FizzBuzz. I wouldn't ask this question because I think there are better questions available that allows candidates to demonstrate mastery of concepts like these and also have depth so you can go into substantially more detail when the candidate performs well. (And questions that permit multiple solutions, etc.)
      - scierama 9y ago
        Then you want to hire people are good at interviewing; not necessarily people who are good at their job.
      - maxxxxx 9y ago
        I have learned programming on the job, not in school. I think I have a pretty good handle on things like recursion or traversing or implementing structures. But I don't speak the lingo so I don't know what "Implement a recursive depth first traversal of a tree" means exactly. I have been doing this for 25 years now and I don't think I have ever heard anybody formulating a problem that way.
  - gravypod 9y 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
    - saghm 9y ago
      > 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 Really? You don't think there's any possibility of a middle ground here?
      - gravypod 9y ago
        I don't think there is anything representative of an employee's quality of work that can be done during a short interview that would have a strong correlate to productivity and quality. I think a real-world take-home problem followed by a meeting-style presentation of your work, your solution, and a Q&A about the implementation with a representative subset of your peers would be better as this would actually be representative of the work load at hand at the company.
  - rocky1138 9y 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.
- sidlls 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
- deathanatos 9y 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 9y 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 9y 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 9y ago
    Does your job actually require knowledge of BTrees?
    - arianvanp 9y ago
      Yes! Our database blew up in our face because we misused and had wrong performance assumptions some indexes. Colleague had knowledge of btrees (the underlying data structure of database, iirc) and database internals. Optimised the whole thing. Queries are now 500x faster
    - deathanatos 9y ago
      Yes. They're the typical data structure backing most relation database indexes. Knowing when they will perform well (and more often, when they won't) follows directly from knowing their structure. (The example of trying to do a range search on two dimensions in the post above is an example that doesn't perform as well as — again, I find — people naively expect it to.) Have I ever implemented one? Not yet. Do I ask for a BTree implementation or exact, low-level understanding on an interview? No.
hprotagonist 9y 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...
- scierama 9y 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 9y ago
  I quite like your analogy. If software engineer is like a mechanical engineer, what would a programmer be like, a mechanic?
- bigger_cheese 9y 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.
  - tedmiston 9y 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 9y 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.
- saimiam 9y 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.
  - sidlls 9y 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.
    - saimiam 9y ago
      The OP said they don't care/haven't had to care about performance. What you're saying is that they used a library which is known to be performant. If the OP knows it to be performant, they are misstating that they don't care/have never been asked to care about performance. If they truly don't know about the performance and picked a library at random, they are halfassing it and aren't doing their job as a software engineer.
      - yeukhon 9y ago
peterburkimsher 9y 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 9y ago
  How does copying the english words from the image to english words as text help non-English speakers?
  - sdrothrock 9y ago
    Makes it easier to look up (copy/paste) and/or use dictionary tools.
  - spullara 9y ago
    They can copy and paste them into google translate?
- fny 9y 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)`.
oneplane 9y ago
Yeah, no shit... Truck Driver ≠ Road Planner
amw-zero 9y 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.
- ajarmst 9y 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 9y 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 9y 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.
dimitar9909 9y ago
diversity != black and latino
jolux 9y 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.
- sillysaurus3 9y 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 9y 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.
    - sillysaurus3 9y ago
      Forcing it to grow up would harm it, though. The engineers would move to companies that don't force those kinds of constraints. It's important to keep in mind what "growing up" translates to: slowing down. This has both economic and competitive implications. Sometimes it might be a win, but the vast majority of the time your ability to move quickly (and yes, occasionally break things) is an advantage.
      - lilott8 9y ago
        Yes and no. It is a natural progression of the industry. Those who cannot do "formal engineering" probably don't belong in engineering roles. Engineering, in general, imho, can be distilled down to this: Clearly define the constraints in which your project will operate under and prove that they will hold under those constraints. If someone as an SE cannot do that, they really have no business being anywhere near any field of engineering.
ajarmst 9y 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 9y 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.
KirinDave 9y 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/henglein2011a.pdf 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 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."
ChuckMcM 9y 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.
- Clubber 9y 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/programmers-should-not-call-themselves-engineers/414271/ https://www.theatlantic.com/technology/archive/2015/11/progr...
partycoder 9y 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.
sytelus 9y ago
Computer science is neither about computers nor is a science :).
- goatlover 9y 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.
- sytelus 9y 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 :).
halfnibble 9y 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 9y 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.
- deelowe 9y 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?
j05huaNathaniel 9y ago
in·fe·ri·or·i·ty com·plex noun an unrealistic feeling of general inadequacy caused by actual or supposed inferiority in one sphere, sometimes marked by aggressive behavior in compensation. su·pe·ri·or·i·ty com·plex noun an attitude of superiority that conceals actual feelings of inferiority and failure. I can't decide which one you are.
- halfnibble 9y ago
  Ha! Which one of your syllable-splayed psych terms defines a person who is tired of being stereotyped by academia?
- tonyedgecombe 9y ago
  I don't think there was any need for that kind of response.
- cpburns2009 9y ago
  I'd say neither. The parent sounds like he knows his stuff without down playing his knowledge (inferiority complex), and isn't pretentious enough to call himself a software engineer (superiority complex).
- sctb 9y ago
  Personal attacks like this don't belong on Hacker News. We detached this subthread from https://news.ycombinator.com/item?id=14945322 https://news.ycombinator.com/item?id=14945322 and marked it off-topic.
alkonaut 9y 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_lord 9y 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 9y 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.
hestefisk 9y 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 9y ago
What is software Engineering !? Making an excel sheet ? Making a web site ? Writing SQL ? Using programming language X, Y, Z ?
thomasbachem 9y ago
We also wrote an article about this about a year ago: https://code.berlin/en/blog/computer-science-software-engineering/ https://code.berlin/en/blog/computer-science-software-engine...
tim333 9y 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 9y ago
Sure. Engineering is an applied science. So, these cannot be equal.
Chiba-City 9y 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 9y 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__ 9y 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 9y 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).
joedo3 9y 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.

482 points by nreece 9y 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 9y 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 9y ago
  Agreed, a good interview question is also a springboard to a discussion of engineering practices related to the problem.
  - LoSboccacc 9y ago
    The only work environment viable engineering answer is to get a library to solve whatever the problem at hand. At best a top candidate should be able to turn a whitepaper into working code. Knowing trivia rarely translate in solid, productive teams. Very, very few companies are pushing the what's known barrier.
- sidlls 9y 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.
  - Pyxl101 9y ago
    I wouldn't ask this question but I don't think it's irrelevant. It shows you that the person understands concepts like recursion, is familiar with data structures like trees, and understands how to express and work with those concepts in code. Completing this problem should take only a few minutes and tells you whether a candidate has a basic degree of competence. When someone breezes through a problem like this, you learn something. If someone struggles with it, you also learn something. You can use that knowledge to calibrate subsequent questions and find the limits of their knowledge. I would be skeptical about the effectiveness of software engineer candidate who isn't comfortable with trees or recursion or algorithms like search. It's a weed-out question like FizzBuzz. I wouldn't ask this question because I think there are better questions available that allows candidates to demonstrate mastery of concepts like these and also have depth so you can go into substantially more detail when the candidate performs well. (And questions that permit multiple solutions, etc.)
    - scierama 9y ago
      Then you want to hire people are good at interviewing; not necessarily people who are good at their job.
    - maxxxxx 9y ago
      I have learned programming on the job, not in school. I think I have a pretty good handle on things like recursion or traversing or implementing structures. But I don't speak the lingo so I don't know what "Implement a recursive depth first traversal of a tree" means exactly. I have been doing this for 25 years now and I don't think I have ever heard anybody formulating a problem that way.
- gravypod 9y 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
  - saghm 9y ago
    > 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 Really? You don't think there's any possibility of a middle ground here?
    - gravypod 9y ago
      I don't think there is anything representative of an employee's quality of work that can be done during a short interview that would have a strong correlate to productivity and quality. I think a real-world take-home problem followed by a meeting-style presentation of your work, your solution, and a Q&A about the implementation with a representative subset of your peers would be better as this would actually be representative of the work load at hand at the company.
- rocky1138 9y 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.
sidlls 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
deathanatos 9y 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 9y 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 9y 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 9y ago
  Does your job actually require knowledge of BTrees?
  - arianvanp 9y ago
    Yes! Our database blew up in our face because we misused and had wrong performance assumptions some indexes. Colleague had knowledge of btrees (the underlying data structure of database, iirc) and database internals. Optimised the whole thing. Queries are now 500x faster
  - deathanatos 9y ago
    Yes. They're the typical data structure backing most relation database indexes. Knowing when they will perform well (and more often, when they won't) follows directly from knowing their structure. (The example of trying to do a range search on two dimensions in the post above is an example that doesn't perform as well as — again, I find — people naively expect it to.) Have I ever implemented one? Not yet. Do I ask for a BTree implementation or exact, low-level understanding on an interview? No.

hprotagonist 9y 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...

scierama 9y 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 9y ago
I quite like your analogy. If software engineer is like a mechanical engineer, what would a programmer be like, a mechanic?
bigger_cheese 9y 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.
- tedmiston 9y 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 9y 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.

saimiam 9y 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.
- sidlls 9y 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.
  - saimiam 9y ago
    The OP said they don't care/haven't had to care about performance. What you're saying is that they used a library which is known to be performant. If the OP knows it to be performant, they are misstating that they don't care/have never been asked to care about performance. If they truly don't know about the performance and picked a library at random, they are halfassing it and aren't doing their job as a software engineer.
    - yeukhon 9y ago

peterburkimsher 9y 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 9y ago
How does copying the english words from the image to english words as text help non-English speakers?
- sdrothrock 9y ago
  Makes it easier to look up (copy/paste) and/or use dictionary tools.
- spullara 9y ago
  They can copy and paste them into google translate?
fny 9y 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)`.

oneplane 9y ago

Yeah, no shit... Truck Driver ≠ Road Planner

amw-zero 9y 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.

ajarmst 9y 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 9y 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 9y 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.

dimitar9909 9y ago

diversity != black and latino

jolux 9y 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.

sillysaurus3 9y 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 9y 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.
  - sillysaurus3 9y ago
    Forcing it to grow up would harm it, though. The engineers would move to companies that don't force those kinds of constraints. It's important to keep in mind what "growing up" translates to: slowing down. This has both economic and competitive implications. Sometimes it might be a win, but the vast majority of the time your ability to move quickly (and yes, occasionally break things) is an advantage.
    - lilott8 9y ago
      Yes and no. It is a natural progression of the industry. Those who cannot do "formal engineering" probably don't belong in engineering roles. Engineering, in general, imho, can be distilled down to this: Clearly define the constraints in which your project will operate under and prove that they will hold under those constraints. If someone as an SE cannot do that, they really have no business being anywhere near any field of engineering.

ajarmst 9y 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 9y 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.

KirinDave 9y 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/henglein2011a.pdf 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 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."

ChuckMcM 9y 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.

Clubber 9y 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/programmers-should-not-call-themselves-engineers/414271/ https://www.theatlantic.com/technology/archive/2015/11/progr...

partycoder 9y 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.

sytelus 9y ago

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

goatlover 9y 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.
sytelus 9y 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 :).

halfnibble 9y 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 9y 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.
deelowe 9y 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?

j05huaNathaniel 9y ago

in·fe·ri·or·i·ty com·plex noun an unrealistic feeling of general inadequacy caused by actual or supposed inferiority in one sphere, sometimes marked by aggressive behavior in compensation. su·pe·ri·or·i·ty com·plex noun an attitude of superiority that conceals actual feelings of inferiority and failure. I can't decide which one you are.

halfnibble 9y ago
Ha! Which one of your syllable-splayed psych terms defines a person who is tired of being stereotyped by academia?
tonyedgecombe 9y ago
I don't think there was any need for that kind of response.
cpburns2009 9y ago
I'd say neither. The parent sounds like he knows his stuff without down playing his knowledge (inferiority complex), and isn't pretentious enough to call himself a software engineer (superiority complex).
sctb 9y ago
Personal attacks like this don't belong on Hacker News. We detached this subthread from https://news.ycombinator.com/item?id=14945322 https://news.ycombinator.com/item?id=14945322 and marked it off-topic.

alkonaut 9y 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_lord 9y 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 9y 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.

hestefisk 9y 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 9y ago

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

thomasbachem 9y ago

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

tim333 9y 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 9y ago

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

Chiba-City 9y 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 9y 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__ 9y 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 9y 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).

joedo3 9y 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.