
Software Engineering ≠ Computer Science (2009) - nreece
http://www.drdobbs.com/architecture-and-design/software-engineering-computer-science/217701907
======
alkonaut
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.

~~~
trevyn
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.

~~~
AnimalMuppet
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.

~~~
trevyn
Problem solving is our area of strength.

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

~~~
jolux
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?

~~~
sillysaurus3
I think it's self-evident that there is no theoretical basis for software
development in the way that would satisfy your criteria. Software dev is
generally a scattershot haphazard endeavor that involves trying dozens of
angles until one of them works. That's an unsatisfying answer, but if we try
to hide from the implications just because we don't like it, we'll end up
creating companies that fail to startups without these constraints.

It's also self-evident that in most situations, correctness and reliability
aren't a concern. The counterexamples account for maybe 1% of the field. 99%
of the time, if your program breaks, you can pay someone to go fix it and no
serious harm was done. Even Github outages, which affect almost all of us,
hardly matter.

~~~
nautilus12
I havent thought of this before but i was a mathematician that does software
engineering, and Im starting to see some stark similarities between a
mathematical proof and a "test" as in a unit test. I imagine if you went down
this road you would end up with something very similar if not identical to
TDD. What i was hoping this thread would discuss is how to turn software
design patterns like the adaptor or factory patterns into a science in the
same way that differential topology turns differential equations from a
haphazard collection of methods into a rigorous science. I dont know why more
people havent focused on formulating this more practical side of software
engineering. Why is it that SOLID works so well, etc

~~~
rnprince
Dijkstra spent a lot of his research effort on ways to prove that programs are
correct.

"Today a usual technique is to make a program and then to test it. But:
program testing can be a very effective way to show the presence of bugs, but
it is hopelessly inadequate for showing their absence. The only effective way
to raise the confidence level of a program significantly is to give a
convincing proof of its correctness."

[https://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF](https://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF)

~~~
euske
"I don't need to waste my time with a computer just because I am a computer
scientist." \- Dijkstra

~~~
sjg007
This basically describes the dichotomy between CS and software engineering.

------
peterburkimsher
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.

~~~
deathanatos
> _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
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://www.youtube.com/watch?v=oyLBGkS5ICk)

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

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

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

~~~
zerr
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...

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

~~~
zerr
I don't think so, since the examples mention overworking towards the current
assignment. Anyway, 5PM stigma exist and there is no harm to reiterate this
topic.

------
halfnibble
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.

~~~
deelowe
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?

~~~
halfnibble
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.

~~~
deelowe
You're confusing systems engineering with knowledge and skills

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

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

~~~
DonaldFisk
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
> 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.

------
hestefisk
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.

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

------
tim333
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.

------
drawkbox
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.

------
Chiba-City
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.

------
autokad
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
> 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
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
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
Well, remember: don't start with performance in mind unless you have to or you
already know the right way.

Take a Python library like requests. Who the hell will read the source code
and run a profiler on that module if you see a consumer? I don't care until I
have to. Perhaps before shipping my production code I can run a profiler. If
you are going that deep at the beginning, you are wasting your time instead of
building MVP and iterate. Library's code out there is ever changing. One
version can br slower than another. You aren't doing meaningful work if you
start with performance.

OP didn't say he/she is picking a random library out of the blue. I don't
remember reading that "random" part.

~~~
saimiam
This entire discussion is about what an SE does vs what a CS does. Item #1 for
an SE is to pick a library to use instead to reinventing every wheel every
time. OP says they don't care about performance which is a naive, potentially
stupid, approach to software engineering. Beyond this, I'm out of crayons.

Just because some hotshot (PG?) said to not optimize prematurely doesn't
absolve you of your responsibility towards picking a library to use. Don't
optimize early by all means but at least know why the library you picked might
not be a great choice for problems you face in the real world.

Do you write your websites in C outputting raw HTML? I'm sure you don't.
Clearly you made some sort of reasoned deduction about the tools at hand and
went with one which got the job done. Why did you not pick C code spitting out
HTML? No point premature optimizing your productivity, right?

~~~
stan_rogers
The "hotshot" was Donald Knuth, and he was talking about getting clever before
you're sure your program does what it's meant to do. The keyword is
_premature_ ; analysis and optimization pretty much forms the bulk of his body
of work, although he doesn't believe in sacrificing readability until you're
out of other goats to kill.

~~~
saimiam
You're right! @ Knuth. I knew that but it got overwritten by PG's point about
scaling prematurely.

Like a good astrologer, I'm going read into your comment to assume support for
my larger point - know your tools.

------
k__
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
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
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.

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

------
KirinDave
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...](http://www.diku.dk/hjemmesider/ansatte/henglein/papers/henglein2011a.pdf)

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."

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

------
cpburns2009
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.

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

~~~
sytelus
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 :).

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

~~~
bigger_cheese
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
> 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.

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

------
whatnotests
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.

~~~
deathanatos
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.

~~~
walrus1066
Does your job actually require knowledge of BTrees?

~~~
deathanatos
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.

------
oneplane
Yeah, no shit...

Truck Driver ≠ Road Planner

