5 ms·

Dan nearly solves his own riddle with possible explanation No. 2: "You don’t need a CS degree to be a developer." He just doesn't spend long enough probing this

• deathanatos 9y ago
  I have to disagree; I routinely need to educate co-workers on how things like B-Trees works, what a sum type is and why it is useful, what the SRP means (and why it is useful), why testing matters, why abstraction matters, or even things like how to secure production servers. To take the B-tree example: I've run across a number of people who I feel are more apt to blame "the database" for being slow; "it can't handle the load" being one of the excuses I've heard used as a "reason" to switch to an entirely newer database that "scales" better. The real reason that the DB isn't scaling is that the queries being run aren't properly indexed (i.e., there exists a B-Tree that has the column being queried, but that B-Tree nonetheless cannot effectively answer the query without reading millions of extraneous rows) and a fundamental understanding of how a B-Tree works is missing. (I find this most often arises on B-Tree indexes indexing multiple columns, e.g., for an index over (a, b), people mistakenly believe the index can effectively answer range queries on b without specifying a.) To take the abstraction example: in a project I currently maintain, the codebase is incapable of doing anything other than being an HTTP server: the incoming JSON is handled at the lowest levels interacting with the storage systems, and those same storage layers generate the response JSON. (Though each is filtered and mangled a myriad of ways in between, but it's all dicts and lists, from top to bottom.) > the opportunities for non-CS majors to pick up programming skills via electives or non-classroom projects are huge. You're not wrong that these opportunities exist, but in my experience, while they do indeed teach people how to code software, they do not teach people how to engineer software. A math/physics major may only need their simulation to run on their input, but building stable server-side systems that won't wake you up in the middle of the night is a different thing altogether.
  • closeparen 9y ago
    >even things like how to secure production servers You might find this, for old versions of Windows Server, in a trade-school IT degree program. You're certainly not going to find it for Linux in a regular Computer Science program.
  • randomdata 9y ago
    > I have to disagree; I routinely need to educate co-workers on how things like B-Trees works, what a sum type is and why it is useful, what the SRP means (and why it is useful), why testing matters, why abstraction matters, or even things like how to secure production servers. Given this, why would someone want to get a CS degree, usually at a significant cost, when their coworkers will happily cover the same content while getting paid to learn it? To put it more succinctly, given this, what is the business case to expect increasing enrolments in CS? You will always have some who are passionate about the study, but it seems unlikely that the segment of passionate people is growing over time at this point. CS is not a new field of study anymore.
    • deathanatos 9y ago
      That's an interesting — and mildly dystopian, to me — thought. I would argue that the cost of having not understood these things is taking quite a toll in the form of tech debt, however. While it is certainly true that I, and others passionate about the field, can potentially educate (though it's debatable how good I am at that), I find I'm usually doing that after-the-fact: I can't know that someone lacks knowledge until they've someone demonstrated that, typically in the form of tech debt, at which point it is much more expensive to course correct. (In the BTree example, I find people often think they understand how BTrees work, so they're not going to raise questions, since they don't know what they don't know.)
      • randomdata 9y ago
        Of what real concern is technical debt to someone who is debating studying CS though? Especially when you say that they don't know what they don't know, thus not even realizing what debt is potentially created. Worst case is that they create too much and leave for greener pastures when the weight becomes too burdensome, which is really not that big of a deal to the individual. But you seem to be looking at this from the owner/employer point of view, which I am not sure represents the type of person who would be studying CS in the typical case anyway. At least once you get past the early startup phase, if the business even started in software, these people tend to disengage from the day-to-day development to focus on the business. In that respect, if technical debt is a real concern to them, they would provide more formalized coverage of these topics to all employees to ensure that everyone understands B-trees, or what have you, at the level the business deems necessary. Since that is not common, it may not really be the operating concern you make it out to be either.