Hacker News Reader

Comment by ookdatnog | Hacker News Reader

I empathise with people who go to college to study computer science, mainly with the intent of eventually landing a well-paid programming job, who are then frustrated when they have to learn actual computer science topics instead of just learning to program.

But their anger is usually directed at the wrong institution. The problem doesn't lie with academia teaching the wrong things, it lies with companies requiring CS degrees for simple programming jobs. They treat the theoretical computer science material as nothing more than a raw intelligence/perseverance filter.

View on HN

We spent entirely too much time on O(this) and O(that)

But that's the stuff that sort of stood up to the test of time.

Also really helpful was symbolic logic, which actually was not a computer science course.

The most interesting computer science topics to me in school were the different computer languages -- but very few of them survived the test of time.

In my bachelor's degree, I spent two weeks of one course, tops on O(this) and O(that).

I suppose I spent two courses studying computational complexity, but reducing it to O(this) and O(that) does not quite do it justice.

I use CS theory all the time in my professional career. Automata, was the most useful class I took (the 2nd most useful was Programming Language Concepts).

What do you do professionally? How do you use automata there?

Web development, embedded systems, and game dev. I use FSMs, pushdown automata, and hierarchical state machines all the time.

For embedded systems and game development I definitely understand automata applications (from experience) but web development has me curious. Are you writing transpilers or perhaps something else (I also try to avoid web dev, so there's that).

Not OP but there are more than a few domains that can be modeled with automata, a shipping pipeline with approval steps is an example.

Ecommerce order/payment/shipping status is a good example. Anything that has a well defined state that can be changed by events is well-modeled as a state machine of some kind. Also anything that has to progress through certain steps and might be interrupted or have exception cases, and you want to proceed/retry idempotently.

Personally I have also found basic graph theory to be immensely useful for representing and reasoning about things.

>Personally I have also found basic graph theory to be immensely useful for representing and reasoning about things.

I agree! The graph theory portion of my algorithms class (more than half of the class) was the third most useful thing I learned in my degree.

Mostly for user interfaces and modeling business processes. But I’ve also done some work on a super simple language for some of our non technical people to use for data transformation, and a templating system for form generation.

What's amazing to me is how uncommon state machines are in software, comparatively. In ASIC and FPGA design, it's so fundamental and ubiquitous. At least with synchronous designs.

I pushed for using state machines and more formal methods in the rewrite of a system that I and a number of other devs were hired for. The idea was turned down in favor of lots of ad hoc state and string constants, even though the system has a limited and distinct set of states on the main domain objects. People don't do it because people don't do it, and they're afraid others aren't going to understand it.

The vast majority of companies essentially code and design to the lowest common denominator so that their devs are fungible cogs.

The problem is that it's extremely easy to violate the boundaries of state machines. For example there's some small edge case, that would normally require you to completely re-create the state machine, but people bypass that by just escaping the state machine. In ASIC/FPGA, it's actually relatively hard to escape the state machine because escaping the state machine causes explosions in timing required and causes race conditions.

Code doesn't have fixed timing requirements, most of the time.

I don't dispute at all that theoretical CS is practically useful, I love it myself and think it offers amazing tools for thought. But my hunch is (and I'm emphasizing that I'm speculating here) that only people who like the material end up retaining enough to see the applications. I feel like some of my fellow students, including ones that I felt were smart (but who were application-oriented learners who have trouble focusing if they didn't see applications right away), had to drag themselves through the theoretical material to barely pass and then promptly forget about it. I imagine their perspective is:

1. They have to work through material that does not particularly interest them and is quite hard, but employers insist that they must master this stuff if they want a good position.

2. In their work environment, no one ever asks them to actually use theoretical CS concepts, and they don't spontaneously see applications themselves.

3. Therefore, they feel academia is out of touch and teaching irrelevant material that has no practical application. With my earlier comment I wanted to point out that I don't believe academia is to blame for their suffering.

That's the thing, it is useful, so I don't blame companies for wanting people who know CS theory.

And when I hire people, even though I hate doing adversarial whiteboard coding, I will probe to find out if people understand a bit of theory.

You can get a lot of work done without theoretical knowledge, (but the end result is often not as good, and it usually takes longer). Combine that with the fact that CS theory is hard, and you get a lot of people complaining about how theoretical CS is useless outside of academia.

It's basically an extension of "no one needs to know math beyond arithmetic in the real world".

You can say that about many fields. Employers outsource their testing to universities. It saves them a ton of effort and it has the side benefit of shielding them from some potential discrimination claims.

Without university, how is an employer to know you would've spent 4 years working on something reasonably challenging that took a moderate to large amount of effort over long periods of time? They can't discover any of this in an interview. The fact that high school is mandatory robs it of much of its signalling value.

The fact that high school is mandatory robs it of much of its signalling value.

This will very clearly result in the same loss of signaling value for higher education.

There's a bunch of commercial prep courses and coding bootcamps that focus on applied programming.

I wonder how long-term those skills are, reminds me of companies teaching MCSE certification a few decades ago.

The way I've seen it distinguished in colleges is as a separate "Software Engineering" track within the compsci department.

Think it depends entirely on the person. I know someone who went through one of those 6 years ago. He worked a grunt job for a while for experience, and has traded up to a very nice gig today. He also worked pretty hard on the side, teaching himself.

I can't speak for the longevity of the training, but he's doing fine.

For that matter, other than a terrible 101 class, I have no formal programming training and have been doing this professionally for over 20 years so far. But I'm a bit of a broken record when it comes to degrees-as-gatekeepers - the vast majority of programming jobs do not require a college diploma to competently perform. Very, very few people are writing blank-page Paxos implementations or researching "ai" - they're gluing APIs together and writing business logic. Moderate competence, the ability to do basic research and the patience to get past the WTF stage with a compiler are what you need, not a four year degree.

There is a lack of a university (or above) level software engineering education that isn't aimed at computer science.

Reply on news.ycombinator.com