8 ms·

Your comment reflects a common meme that can often be summarized as: "Real World" work doesn't involve the academic nonsense you learn in school. Many of the p

• mdoms 6y ago
  Can you give some examples of where computer science academic theory helped in software engineering?
  • rubatuga 6y ago
    Dictionaries for O(1) lookups, b-tree indexes for fast SQL queries, interval trees in genomics analysis software.
    • mrits 6y ago
      If this was an interview I'd say dictionaries aren't O(1) but one popular implementation of this collection is.
  • aejnsn 6y ago
    Please go pick up any of the Martin Fowler books. All are rooted in computer science fundamentals. Let’s not pretend software engineering isn’t rooted in computer science. That’s a categorically false assertion.
  • Kalium 6y ago
    Knowing the properties of a data structure and how it works under the hood is incredibly valuable when deciding if it's a good answer to the problem at hand. If you don't know why hashing is important or what it gets you, you might not understand why a hashmap is a very powerful tool. You might choose some other structure or hand-roll something involving manually managing multiple arrays, and down the line run into what feel like intractable performance problems. That's just one example, pulled from people I've worked with. An understanding of fundamentals is required to do a real evaluation for yourself.
  • tmotwu 6y ago
    Boolean algebra, relational algebra, sets and graphs, reductions, runtime analysis, gossip and epidemic protocols, satisfiably, verification, turing machines, push down automata, etc.
    • leetcrew 6y ago
      it's a small thing, but I find it pretty useful to be comfortable with the basic boolean identities. makes it much easier to rearrange if conditions for readability without stressing that you might be changing behavior.
  • vbtemp 6y ago
    People can go on all day about this. The most major one for me is protocol engineering - there's a whole world out there on this. Others would be model based design and its formal verification. Also several problems in state synchronization in distributed systems. In many of these cases, the team I joined had a code base in place that "kind of" did the solution, but was not grounded in any conceptual model - despite phenomenal code quality, peer reviews, etc. Recasting it as an implementation of a well-studied formal model generally yielded a codebase that was one-tenth the size of the original, and with far fewer defects. As I said in the parent comment, if you aren't familiar with this kind of stuff, you don't know about it, so you don't use it, so you find other (suboptimal) ways to do it.
    • lliamander 6y ago
      What are resources you reference the most in this kind of work?
  • ipnon 6y ago
    1. Unix was cutting edge OS theory and gave birth to the microcomputer industry. 2. AWS was cutting edge distributed systems theory and gave birth to cloud computing. 3. Renaissance Technology was cutting edge algorithms theory and gave birth to quantitative hedge funds. Some people innovate for a living.
    • AnimalMuppet 6y ago
      Unix was cutting edge OS theory? I mean, it was Bell Labs, and they were probably the premiere research facility in the world at the time, but my impression is that the trick on Unix was how small they were able to squeeze it, not that it was pushing theoretical boundaries. Can you point me to any aspects of Unix that were theoretically new?
      • ipnon 6y ago
        What we take for granted today was once brand new and hard won.
        • AnimalMuppet 6y ago
          True. But what was new in Unix? What specifically?
          • mav3rick 6y ago
            Multitasking
            • AnimalMuppet 6y ago
              Didn't Multics have that? I mean, Multics never went anywhere, but the theory wasn't new to Unix, was it?
              • stevofolife 6y ago
                Back then, Multics was designed to run on expensive and specialized proprietary hardware where as Unix could run on a variety of cheap computers. One can say the philosophy behind Unix was new. I'm sure that's why modular and micro kernel designs caught on.
  • bcheung 6y ago
    I use category theory quite frequently when doing functional programming. Unfortunately it is not taught in CS programs AFAIK. I rarely implement any tree kind of algorithms other than a simple tree visitor. An understanding of time/space complexity (Big O Notation) is also relevant to evaluating approaches. A senior level developer will use this to make high level choices. I also use compiler theory when writing parsers and simple DSL languages. Honestly, never really had to deal much with red-black trees or linked list algorithms.
  • sweetsocks21 6y ago
    I tend to use it quite regularly. I've had to diagnose many performance issues with our large code base. Understanding compilers, data structures, networking, OS internals, etc, have all been quite helpful. Even if it's simply finding a starting point for tackling the problem. Sometimes it's trivial, replacing a for-each loop with something that's log(n) or O(1). Sometimes a little more complicated, like refactoring some code and realizing the original implementer was trying to do BFS but.. wrote something else. And the rarer cases are having to really dive in and trace some odd contention issues. All of these touch on what I learned in college at some level. Sometimes knowing something exists is helpful for looking up later and can save lots of time. I do wonder if it's less about "requiring" the education and more about someone seeking out the kind of work that uses the education. I know many people in my company are the opposite of me, and definitely do not care to go much deeper than implementing things until they work.
    • sokoloff 6y ago
      I wish the whole industry would at least get to that latter level. I see a fair amount of “jiggle it until it’s no longer obviously broken”.
  • helloitsian 6y ago
    Personally, I see it come up in more vague areas during my Web Development. It's more along the lines of, "based off my understanding of X, I can assume this bit of JavaScript code works like this under the hood". Understanding how memory works traditionally keeps me "memory-conscience", but this may be redundant when working with JavaScript. When writing complicated operations I can use things I've learned previously to improve efficiency. To put it nicely, I'm not balancing binary trees and sorting my arrays with JavaScript. However, it was helpful when learning how the VDom works. In other industries... I started my Software Development journey with C, then moved into Game Development in C++ as my first job. Game Development DEFINITELY requires a lot of CompSci info (that I lacked). Hash Maps, Pathfinding, Matrix math, physics calculations, Linked Lists; all the works. We were also using a proprietary Game Engine so maybe with other Engines CompSci isn't as needed, I haven't worked in different engines.
  • ptasker 6y ago
    Dealing with unicode bugs taught me a lot about computer science academic theory. It helped to understand memory addresses and how encoding works.
  • stevofolife 6y ago
    Tons: Cryptography, operating systems concepts including multi-threading, distributed systems, network communication, mobile and embedded systems which are basic backbones of all the things you use today. You know that's where majority of the tech companies are innovating on, right?
    • Kalium 6y ago
      I have definitely worked on systems that tried to do parallelism without any real understanding of underlying primitives or theory. They were not ideal.
  • Jtsummers 6y ago
    - For parsing, the difference between context free languages and regular languages. This has helped in a number of projects (usually at the clean up end). - Boolean algebra has helped me greatly simplify hard to understand nested conditionals. - Understanding data structures lets me pick the right ones for the problem. - Algorithm analysis has let me take program runtimes from minutes or hours on modest data sets down to seconds or minutes. - Discrete math topics helped me prove a problem that a coworker had spent a few weeks on was technically impossible. - Again for parsing, understanding the ideas of parsing let me make a number of parsers over the years using a variety of mechanisms. The critical part, though, was understanding what was being parsed and how to parse so the code was clear. I replaced convoluted code with hardcoded values and assumptions about what would be in each part (line, or binary blob) with something more flexible and less hacky. - Knowing how C stores data (stack versus heap) let me fix a lot of code from some engineer colleagues that would work, sometimes, but not reliably because they didn't understand how memory works.
  • varjag 6y ago
    A moderate complexity task such as writing a JPEG codec requires understanding of Huffman coding, discrete cosine transform and a number of other minor concepts. Right now am working on a physically distributed, synchornized system. It has some signal processing code: cross-correlation, FFT. The process planner builds spanning trees out of the layout graph to execute the tasks.
  • bfung 6y ago
    Relevant comment from a few days ago about Linus Torvald’s code handling of linked lists and the theory behind it: https://news.ycombinator.com/item?id=25327683 https://news.ycombinator.com/item?id=25327683
  • etimberg 6y ago
    Currently writing software for electrical engineers. One example that comes to mind is graph theory. I use it frequently to answer questions about the data I'm looking at. Imagine an electrical distribution network where there are 3 phases (A/B/C) and an overhead line can contain any combination of those phases. These networks can be modeled as a graph with nodes connected by links. The links do not have a direction, but they do have a phase. If you want to know what the phasing is at any point in the network, the way to figure that out is to use graph algorithms.
• cyberlurker 6y ago
  Agreed, but also some great moments are when you finally use something you learned and think “Oh, that’s why they taught me that.” Even if it’s many years later and I did NOT master the concepts, I’m just aware of them. It’s happened enough to me that I no longer have the opinion that stuff I learned was “useless” even if I don’t use it. I might one day or someone else might encounter a problem that requires that knowledge.
  • vbtemp 6y ago
    I'll also say you won't just come across a problem that requires it, but rather you will apply that knowledge to a problem that never seemed to have needed it in the first place, and then you'll come up with a very powerful, compact, and resilient solution.
• CraigJPerry 6y ago
  CompSci theory hasn't helped me with the complexity of the industry i work in. It hasn't helped me when i've misunderstood something in our domain. It hasn't helped me release / distribute a product easier or faster or cheaper. It hasn't helped me navigate team dynamics or how to work effectively with others. It hasn't helped me write better technical texts. So for some very specific cases, in my career (and i suspect for many business application developers) set theory has been the most useful thing i learned in CompSci. How much of a real world day do i spend using that knowledge? 0.0something% on average. In fairness, It has sometimes helped me get a product finished sooner but this is tenuous at best because i can point to far greater influences from learning how to use specific tools that have helped me get to "done" sooner. The difference between real world developer and CompSci isn't necessarily in more effective use of CompSci.
  • UncleMeat 6y ago
    All this is true, but when I look at undergrad curricula for other engineering disciplines I don't see this stuff either. And the software engineering courses I did have in undergrad were terrible.
    • vbtemp 6y ago
      Software engineering needs to be learned on the job. I see lots of new grads that take classes in "Agile" and I cringe just knowing how instead they could be taking difficult courses in graph theory, theory of computation, abstract algebra, advanced algorithms, distributed systems, or any other number of advanced topics. As we get older it's easier to pick up tricks of the trade (various Git workflows, "agile", etc)... but it gets harder to sit down to do 3 hours of homework 4 days a week doing your pushdown automata or linear algebra exercises.
      • Jtsummers 6y ago
        > but it gets harder to sit down to do 3 hours of homework 4 days a week doing your pushdown automata or linear algebra exercises. 38 year old studying astrodynamics for work. Can attest to the difficulty of this. No kids yet, that helps, but the wife and I are planning on starting a family soon so it'll get even harder with increased demands on my time.
• commandlinefan 6y ago
  > it's not useless, they just found success in a career that didn't need it. Or don't realize how often they actually do use the skills they learned in calculus class to solve problems that don't necessarily involve derivatives or integrals but do require a methodical, structured approach to solve that isn't something you're born being able to do but must instead be honed through practice on "toy" problems.
• kylestlb 6y ago
  "Many of the people who say this kind of stuff never really mastered the theory, and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless..." this is quite the assertion. do you have any evidence supporting this statement?
  • banachtarski 6y ago
    I think the claim is easily sustained with just empirical evidence. If you want to do a career in embedded, or graphics, or robotics, or maybe flight control, etc., you're going to need the math and the comp sci in droves. HN tends to have a crowd skewed towards certain disciplines, which is why every time the topic of a whiteboard interview shows up, most of the comments voice a strong opposition. In my line of work (graphics), the whiteboard is used all the time, both in and out of the interview.
    • vvanders 6y ago
      I've done both graphics and embedded systems. I don't think any of that is true. In fact I found most the formal education around graphics to be outdated or disconnected from the reality of how systems are built(mostly due to trade secrets and the industry moving much faster than coursework could keep up).
      • banachtarski 6y ago
        Oh yea, calculus and linear algebra is all washed up and the industry has moved way past it. /s "I don't think any of that is true" is a strong statement. Nobody is saying that a toy renderer in school resembles a AAA rendering engine, but the point is that the thought process needed is the same, and I'm still going to expect a certain degree of rigor from any candidate. Also, the parent post is speaking more about the theory and fundamentals in general, not the direct contents of any particular coursework. FWIW, I am not formally trained in graphics or CS (my training was math).
        • 6y ago
• bird_monster 6y ago
  > and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless... But isn't this statement too specific to apply to the generalization that you're disagreeing with? "Most 'real world' work doesn't require CompSci" is a generally true statement, because most "real world work" is incredibly mundane and repetitive. So, isn't your take kind of the inverse of what you're talking about? "I enjoyed ____, so I sought out industries that required ____". Almost as though computer science is a specialization within "real world" work? I guess I think that most industries are not the industries that you're seeking out. Most software developers are employed to combine already-solved problems with new inputs for money. What do you think?
• caymanjim 6y ago
  I agree with everything you're saying, but I didn't make the claims you're disputing. I don't think CS fundamentals are "useless" or "nonsense" by any stretch. There have been times in my career when I wished I had a stronger background. In particular, I've worked for NASA and in finance, and in both cases, I'd have benefitted from stronger statistics and math knowledge. My comment was that most (I would say the vast majority) of software engineer roles don't require a computer science background (emphasis on the science), and wouldn't leverage it even if you had it. If you do have a strong CS background, it opens a lot of doors, and in particular opens doors to--in my opinion--more interesting and challenging work. There's nothing bad about getting a CS degree. It's just not required for a software engineering job. I'm not being dismissive of the education. I'm skeptical of the idea that it's important for most roles.
• konjin 6y ago
  I enjoy CompSci as a distraction - my background is pure maths/mathematical physics so don't think I don't appreciate abstract nonsense - but using it daily is impossible without a lot of contortions. Contortions I can do easily mind you, but other than recursive functions and linked lists any more complex data structures are too fragile to survive the harsh world of constantly changing business requirements. As a younger developer I wrote a beautiful algebra that described the company hierarchy for giving permission levels to people from active directory. Within a week I needed to scrap that and redo it from scratch because people needed permissions in the specific app that had nothing to do with their job position.
• tejohnso 6y ago
  > Your comment reflects a common meme that can often be summarized as: "Real World" work doesn't involve the academic nonsense you learn in school. But isn't that generally true for most education and most jobs? For example, what percentage of Real World work that requires a high school degree, actually involves high school geography academic knowledge?
• JSavageOne 6y ago
  90% of jobs in software engineering require very little CS knowledge. Yet interviews for entry level software engineering jobs focus 100% on CS 101. It's not that CS knowledge is useless, in fact it's great to know the theory. It's just not the top priority in terms of doing everyday work. Recommending an aspiring engineer prioritize CS (outside of what you need to pass interviews) is like recommending an aspiring pianist to master music theory. Nice to have, sure, but not an efficient use of time. Also when people defend the importance of knowledge of CS theory in this industry, their seems to be this implication that CS theory somehow can't be learned on the job. As if it's super complicated and only "real" engineers have the intelligence to pick it up. A load of crap. For example, I once had to use graph algorithms on the job (probably the only time I've ever had to use CS on the job), and I didn't remember any of that stuff from school, so I took a day or two to read up on graph data structures & algorithms, and was able to get the job done. What's more important in this industry, or any field really (unless maybe you're doing something super special like nuclear physics), is knowing how to learn - especially at the junior level. That is way more important than any knowledge. Of course you need to have some base knowledge, but any junior engineer working their first job is going to have a hell of a lot to learn anyways, so for an entry level role I'd rather pick the smarter person who's dabbled in his own projects and is eager to learn than the CS major who's expecting to be tackling interesting CS problems all day at work - unless of course the job actually requires this which until now has never been the case for any of my software jobs.
  • 908B64B197 6y ago
    > What's more important in this industry, or any field really [...], is knowing how to learn - especially at the junior level. Here we completely agree. > so for an entry level role I'd rather pick the smarter person who's dabbled in his own projects and is eager to learn than the CS major who's expecting to be tackling interesting CS problems all day at work - unless of course the job actually requires this which until now has never been the case for any of my software jobs. I disagree. Using CS problems has two advantages. The first is that it establishes a common vocabulary. The second is that it's stack agnostic. Personal projects are great, but sometimes it's hard to tell how much help they got from the internet... Being able to learn CS fundamentals is, to me, a bigger predictor of later performance when they'll be tasked to learn Enterprise X Custom Stack that's not really covered online instead of Well Documented Framework With 1000 Examples.
• twelve40 6y ago
  haha no true Scotsman strikes again! If you are not using theoretical computer science in your daily work, you are either not a true programmer because you neglected to truly absorb the theory, OR not working on true problems, just some low grade commercial bs, right?
• geebee 6y ago
  I think you've refuted something other than what caymanjim said here. I personally agree that "the vast majority" of software engineering does not require deep knowledge of computer science, and I also believe there are plenty of "real world" problems that absolutely do require computer science. In no way does my agreement with the first statement commit me to disagreeing with the second statement. You say caymanjim's comment "reflects a common meme" that real world work "doesn't involve the academic nonsense you learn in school" Why? It seems like you swapped out his argument with something different, by claiming one "reflects" the other. Sounds like "We got trouble, with a capital T, and that rhymes with P, and that stands for Pool". Stating that most software engineering work doesn't require CS theory doesn't commit anyone to claiming that it never relates to real world work. Furthermore, I think you can claim that theory isn't used in the vast majority of real world work without dismissing that theory as "nonsense" - a word you supplied here that wasn't part of the OPs comment. Now - I will agree with you that many people say this stuff, and you may very well have diagnosed why. But you refuted something you recall other people saying, not what caymanjim said.
• vvanders 6y ago
  > But those who are not comfortable with the foundational theory stuff just don't see it and don't even think to approach the problem in that way. Or maybe all that "foundational theory" is oblivious to cache hierarchies(hello Big O notation) and generates worse performance on constrained devices. Or perhaps there's enough unknown, unknowns that throwing something at the wall is a legit way to get data if it's not a one-way decision. However the attitude on display above is a problem because you've just alienated those people who may have come from a different background or do know the theory but are approaching a problem in a different way.
  • josephg 6y ago
    All approaches aren't equal. Yes, big-O notation hides constant factors like cache coherence but the solution isn't to analyse things less. Its to analyse things more. And thats what a proper CS education should teach. And at least once a year I draw on my CS education to: - Model something using state machine semantics - Use heap-based priority queues, binary search, b-trees or skip lists. And of course I use hash tables and hash sets weekly. - Read and implement something that CS researchers invented (PAXOS, interval tree clocks, CRDT work like RGA & YATA, etc). A lot of self taught programmers also don't seem to have fluency with all the degrees of freedom you have as a software engineer. Off the top of my head: Do you know where the bottlenecks are in this program? Are there better algorithms you could use? Are there different dataflow architectures which would help? Can you trade off CPU for memory with caching or memoization? What are the memory allocation patterns? What do you expect the upper bound on performance to be for this process? What are the fundamental invariants your program / data model should always maintain? Can we use a fuzzer to ensure those variants are always maintained? If those invariants aren't being maintained, would we know about it? What are the single points of failure? (And how could we add redundancy?) How would reliability and performance change if we use a different database, or added or removed indexes or caches? If you wanted to steal our user data, what are all the ways you could you do it? A junior engineer (or an engineer at a feature factory) might never need to ask these questions. But becoming a good senior requires a deeper expertise in seeing a program. And that requires an integrated knowledge of fundamentals, program analysis, tooling, experience and creativity. People learn all that without a degree, but personally? There's no way I would have learned all that stuff as well on my own.
• runawaybottle 6y ago
  How is this not an ad hominem attack? Take your typical software job, can we not identify clearly what percentage requires formal computer science? You’re debasing his claim with a passive aggressive attack on ‘maybe you just didn’t learn shit in college’.