Hacker News Reader

Comment by jerf | Hacker News Reader

If you're bashing together some web scripts for your local HR department in a company of 100 people, yeah, OS and computer architecture isn't very useful.

If you're a professional web developer that is creating web sites that need to be reliable, need to interact with other computer systems, and need to be performant even under heavy load, you will if anything find that your operating systems and computer architecture courses were merely the beginning of what you really needed. You need everything you can get when you're trying to make a web page that doesn't take 4 seconds to load. Learning another language isn't really the hard part of the problem.

View on HN

And perhaps more importantly, a CS education is applied to programming. Computer Science is a theoretical discipline heavily rooted in mathematics. Computer Science should not be confused with software engineering.

At my university, Software Engineering is a more theoretical course than CS, with no compulsory programming, and indeed no option for programming in year two, except for a Java module in year one, you do have to build a piece of non-trivial software for your final project though.

I disbelieve.

I was debugging performance problems in high performance websites before I ever began to try to fill in some of my severe holes due to not having taken CS. Thus I can say from first hand experience that a little quantitative thinking is enough to debug many real life performance problems. Absolutely no knowledge of operating systems and computer architecture required.

What kind of "performance problems" are we talking about here? Taking 2 minutes to write to a database because of some poorly indexed tables? Or trying to serve millions of requests in under 100ms each by intelligently leveraging a caching layer?

Maybe these days anyone can just take memcache and use it off the shelf. But the class of solution that memcache represents (or Cassandra, Thrift, node.js or XYZ...) is one that will not typically occur to a non-CS person. There's no basis for even understanding it.

As someone involved in hiring, I look for people who possess the capability to engineer solutions to my problems from scratch, starting with nothing but a solid basis in CS (even if they won't be doing that every day). I don't want just another tube connector (someone whose experience is primarily in leveraging APIs to write trivial but tedious code).

Both, and more. If you have a math background (as I do), it is not hard to pick up enough practical knowledge to be usefully dangerous. Here are a few examples.

Let's turn on internal database tracing just for one web page so we can figure out why certain requests are slow.

What traffic can we move to read-only copies to reduce load on the main database?

We're going to do an Oracle 8 to Oracle 9 migration, let's track every single database request for a day, and then do them again later against a test database at full speed.

At the start of each web page our database driver pings the connection to verify that it is still good. This functionality is essential for failover to work correctly, but due to an internal locking issue it is causing Oracle severe trouble under load. Fix the load issue without compromising our ability to fail over properly.

"If you have a math background (as I do)"

Ah, there's the resolution then. I would never argue that a strong math background is not easily converted into a very effective computer programmer with little further experience. Please do not go around telling people that they "don't need experience" based on that result; they will not hear "I can get a math background" instead.

What you say sounds obvious, but please let me remind you that you've almost certainly seen people who could not leap directly to those conclusions correctly. I can name names of people where I work with years of experience who still engage in "flail at the problem blindly until it seems to go away". In fact just the other day we observer one programmer created a perfect loop; patched a bug, created a new one, patched that, created another new one, another programmer jumped in to fix that, and then the original programmer patched yet another fix resulting in the exact same source code we had at the beginning of this process, only with another new line. (I am not sure what the degree status of this person is but it doesn't seem to have taken.)

(And I would agree you can learn a lot without formal training, but at some point you're still going to have to learn what that formal training covers. You also have to learn more anyhow.)

I agree that a quantitative background is useful. But you can do a lot without a strong background in computer architecture or operating systems.

That said, I agree that the lack of a CS background leads to holes that need to be filled in the long run. But that is something that can be addressed down the road. It is not a prerequisite.

Reply on news.ycombinator.com