4 ms·

So you like the algorithms and data structures used to build a distributed collaboration system with event sourced data in Microsoft Orleans, but not the algori

So you like the algorithms and data structures used to build a distributed collaboration system with event sourced data in Microsoft Orleans, but not the algorithms and data structures used for string search.

lwansbrough 8y ago
Honestly I don't care about the algorithms and data structures used for string search, or event sourcing for that matter. I use that code to build stuff. There's a vanishingly small portion of the population devoted to these problems, and indeed most of those people are probably working on search at Google or something similar. Calling them "foundational" is a joke. They're important, absolutely -- we all use them daily. But expecting every developer to be able to implement a search algorithm? That's the kind of dumb interview question I'd walk out on. Programming is much more than algorithms. Algorithms are the tools we use to build problems. You don't expect a tradesman to build his tools himself, do you?
- MikeLui 8y ago
  What would you consider foundational?
  - lwansbrough 8y ago
    Algorithms aren't foundational, in my opinion. Once you understand the syntax of programming, you can start learning about the applications of that syntax, which for 99% of developers rarely ends up in the shape of an explicit algorithm. It's not all bad, debugging is foundational for sure. I'd place a person's debugging skills, their ability to predict bugs, system design, knowledge of common (applicable) libraries (more so knowing when to use them, not method signatures), and perhaps even ethics above algorithms. Probably many more but there's a couple to start. Having never needed to build my own sorting algorithm in 14 years of coding, I'm pretty confident I don't need an engineer who can do that, either.
    - gowld 8y ago
      You seem to have a nonstandard definition of "foundation". It doesn't mean "introductory" or "beginner"; it means "what everything else is built upon".
      - lwansbrough 8y ago
        I’m thinking of it more as foundational from the perspective of a programmer’s skill set, not the code itself. So in that sense, your ability to debug is foundational to your ability to code anything more than the most basic programs. Granted, they do provide both of those paths.
    - saulrh 8y ago
      > Having never needed to build my own sorting algorithm in 14 years of coding, Neither have I. What I have had to do is recognize when I could do what I needed to do without sorting the array, understand various requirements when I'm writing comparison functions, understand why std::list::sort exists when std::sort is right there, debug a stalling mapreduce job, recognize when a library I'm using has done a stupid and written an intrusive data structure that sorts in N^2, etc. Are you seriously claiming that you'd be able to do any of that if you didn't know how sorting algorithms worked? If those things aren't in the documentation, or if you run into the intersection of that thing and some other issue, you're hosed unless you know the math. For that matter, why are you so focused on sorting? You know what I have to write all the time? Tree and graph traversals. Why does it matter if I use a stack or a queue if my traversal will visit every node anyway? Why can I get away without maintaining a set of visited nodes in one case or the other? Hell, I have to implement something very much like a toplogical sort once a year or so. That's not something you'll ever learn by groveling over for loops in fifty languages. I agree that you rarely need an explicit "algorithm". What you do need, regularly and consistently and on a basic level to write correct code that is usable in the real world, is knowledge of algorithms. In a perfect world everyone would know from reading the docs and from staring at stack frames that their code gets slow when they use particular data structures and libraries. We do not live in a perfect world. The engineer that cannot write a single sorting algorithm is not the one that just uses library functions for everything and is fine in the end. The engineer that cannot write a sorting algorithm is the one that writes a jumble of for loops and you improve runtime from eight minutes to eight seconds by replacing it all with hashes. The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS. These are people that I have worked with. In every case the fundamental issue was that they had "started learning about the applications of the syntax" and never studied formal CS theory.

lwansbrough 8y ago

Honestly I don't care about the algorithms and data structures used for string search, or event sourcing for that matter. I use that code to build stuff. There's a vanishingly small portion of the population devoted to these problems, and indeed most of those people are probably working on search at Google or something similar. Calling them "foundational" is a joke. They're important, absolutely -- we all use them daily. But expecting every developer to be able to implement a search algorithm? That's the kind of dumb interview question I'd walk out on. Programming is much more than algorithms. Algorithms are the tools we use to build problems. You don't expect a tradesman to build his tools himself, do you?

MikeLui 8y ago
What would you consider foundational?
- lwansbrough 8y ago
  Algorithms aren't foundational, in my opinion. Once you understand the syntax of programming, you can start learning about the applications of that syntax, which for 99% of developers rarely ends up in the shape of an explicit algorithm. It's not all bad, debugging is foundational for sure. I'd place a person's debugging skills, their ability to predict bugs, system design, knowledge of common (applicable) libraries (more so knowing when to use them, not method signatures), and perhaps even ethics above algorithms. Probably many more but there's a couple to start. Having never needed to build my own sorting algorithm in 14 years of coding, I'm pretty confident I don't need an engineer who can do that, either.
  - gowld 8y ago
    You seem to have a nonstandard definition of "foundation". It doesn't mean "introductory" or "beginner"; it means "what everything else is built upon".
    - lwansbrough 8y ago
      I’m thinking of it more as foundational from the perspective of a programmer’s skill set, not the code itself. So in that sense, your ability to debug is foundational to your ability to code anything more than the most basic programs. Granted, they do provide both of those paths.
  - saulrh 8y ago
    > Having never needed to build my own sorting algorithm in 14 years of coding, Neither have I. What I have had to do is recognize when I could do what I needed to do without sorting the array, understand various requirements when I'm writing comparison functions, understand why std::list::sort exists when std::sort is right there, debug a stalling mapreduce job, recognize when a library I'm using has done a stupid and written an intrusive data structure that sorts in N^2, etc. Are you seriously claiming that you'd be able to do any of that if you didn't know how sorting algorithms worked? If those things aren't in the documentation, or if you run into the intersection of that thing and some other issue, you're hosed unless you know the math. For that matter, why are you so focused on sorting? You know what I have to write all the time? Tree and graph traversals. Why does it matter if I use a stack or a queue if my traversal will visit every node anyway? Why can I get away without maintaining a set of visited nodes in one case or the other? Hell, I have to implement something very much like a toplogical sort once a year or so. That's not something you'll ever learn by groveling over for loops in fifty languages. I agree that you rarely need an explicit "algorithm". What you do need, regularly and consistently and on a basic level to write correct code that is usable in the real world, is knowledge of algorithms. In a perfect world everyone would know from reading the docs and from staring at stack frames that their code gets slow when they use particular data structures and libraries. We do not live in a perfect world. The engineer that cannot write a single sorting algorithm is not the one that just uses library functions for everything and is fine in the end. The engineer that cannot write a sorting algorithm is the one that writes a jumble of for loops and you improve runtime from eight minutes to eight seconds by replacing it all with hashes. The engineer that cannot write a sorting algorithm is the one that designs an API that fundamentally requires server-side session state that grinds to a halt at ten QPS. These are people that I have worked with. In every case the fundamental issue was that they had "started learning about the applications of the syntax" and never studied formal CS theory.