<story><title>Software Engineering ≠ Computer Science (2009)</title><url>http://www.drdobbs.com/architecture-and-design/software-engineering-computer-science/217701907</url></story><parent_chain><item><author>alkonaut</author><text>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 &lt;i&gt;recognizes&lt;/i&gt; the problem at hand, and recalls the algorithm to pick when presented with the problem.&lt;p&gt;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?&lt;p&gt;You rarely need to remember a pathfinding algorithm or trie implementation by heart. What&amp;#x27;s important is that you a) recognized the problem at hand as &amp;quot;path finding&amp;quot;, &amp;quot;bin packing&amp;quot; or whatever. Terminology is &lt;i&gt;important&lt;/i&gt; 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.&lt;p&gt;So CS is definitely very relevant for software engineering - but you need a broad understanding instead of a deep one.&lt;p&gt;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&amp;#x27;s true - but sooner or later even they bounce into a performance or reliability issue that&amp;#x27;s basically &lt;i&gt;always&lt;/i&gt; due to incorrect choice of data structure or algorithm. I&amp;#x27;m only half joking when I suggest that most of todays &amp;quot;scaling&amp;quot; is compensating for CS mistakes in software.</text></item></parent_chain><comment><author>TheAceOfHearts</author><text>Sometimes you&amp;#x27;re just forced to accept you need to take some shortcuts. There&amp;#x27;s a few fields for which my general approach is to just try and maintain a mental index of &amp;quot;when might I want to use this&amp;quot;.&lt;p&gt;I&amp;#x27;d have a hard time implementing my own crypto, but I&amp;#x27;ve learned enough to know how to use it to secure communications, hide or protect information, ensure no alterations have been made to some arbitrary asset, identify an asset&amp;#x27;s source, etc.&lt;p&gt;I love working with a well understood and boring RDBMS. It&amp;#x27;s predictable and it lets you quickly move on to other problems. But you still need to have a good understanding of how it&amp;#x27;s implemented in order to store and query your data efficiently. If you have a poor understanding of how indexing works, you&amp;#x27;ll probably have a hard time selecting the right data model.&lt;p&gt;There&amp;#x27;s actually lots of fun problems in the frontend world. Try to write a multi-touch gesture responder, it&amp;#x27;s very tricky to get things right. How about a natural animation system that allows interruptions? CSS animations tend to look unnatural because they&amp;#x27;re largely time-based, and they don&amp;#x27;t handle interruptions very well. (Spoiler alert: springs are the magic sauce.)&lt;p&gt;Learning about compilers unlocks lots of powerful skills too. You can implement your own syntax highlighting, linter, refactoring tools, autocomplete, etc.</text></comment>
<story><title>Software Engineering ≠ Computer Science (2009)</title><url>http://www.drdobbs.com/architecture-and-design/software-engineering-computer-science/217701907</url></story><parent_chain><item><author>alkonaut</author><text>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 &lt;i&gt;recognizes&lt;/i&gt; the problem at hand, and recalls the algorithm to pick when presented with the problem.&lt;p&gt;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?&lt;p&gt;You rarely need to remember a pathfinding algorithm or trie implementation by heart. What&amp;#x27;s important is that you a) recognized the problem at hand as &amp;quot;path finding&amp;quot;, &amp;quot;bin packing&amp;quot; or whatever. Terminology is &lt;i&gt;important&lt;/i&gt; 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.&lt;p&gt;So CS is definitely very relevant for software engineering - but you need a broad understanding instead of a deep one.&lt;p&gt;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&amp;#x27;s true - but sooner or later even they bounce into a performance or reliability issue that&amp;#x27;s basically &lt;i&gt;always&lt;/i&gt; due to incorrect choice of data structure or algorithm. I&amp;#x27;m only half joking when I suggest that most of todays &amp;quot;scaling&amp;quot; is compensating for CS mistakes in software.</text></item></parent_chain><comment><author>noir_lord</author><text>I don&amp;#x27;t have a formal CS background and have indeed run into the issues you&amp;#x27;ve described.&lt;p&gt;I generally resort to Google and then go find the best approach and implement it if necessary.&lt;p&gt;I taught myself the basics of the underlying stuff (and it helps that I&amp;#x27;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).&lt;p&gt;Those are rare cases though.</text></comment>