Along those lines, the accompanying MIT class (MIT 6.001 Structure and Interpretation, 1986) is available on YouTube[0] and MIT OCW[1]. It's worth watching, if only for the following:
"I'd like to welcome you to this course on Computer Science. Actually that's a terrible way to start. Computer science is a terrible name for this business. First of all, it's not a science. It might be engineering or it might be art. We'll actually see that computer so-called science actually has a lot in common with magic. We will see that in this course. So it's not a science. It's also not really very much about computers. And it's not about computers in the same sense that physics is not really about particle accelerators. And biology is not really about microscopes and petri dishes. And it's not about computers in the same sense that geometry is not really about using a surveying instruments."
Yeah, it only teaches you about term rewriting, boolean logic, iteration vs. recursion, algorithm complexity, higher-order functions, data structure design, closures, generics, statefulness, environments, mutability, concurrency, stream processing, modularity, interpreter design and implementaion, lazy evaluation, nondeterminism, logic programming (i.e. search/constraint), low level computer architecture, memory models, and the design and implementation of virtual machines, garbage collectors, and compilers. Just a total waste of time unless you're doing Lisp.
I think the best way to learn architecture is to try (and initially fail) to do some projects which make demands on your architecture abilities. I'd recommend writing some frameworks or engines (without worrying about fully completing and releasing them!). Where I learned the most about designing reusable systems was building a game engine, then actually building a game or two on it and seeing what was painful and what worked and taking notes, then building another engine based on my experience, and repeating. I built three engines by the end, and made maybe four or five (little) games off of them.
I never released any of them and none are useful for anything any longer. None probably reached more than 75% completeness. But by trying to build games on them I saw with such clarity things that worked and didn't, and I got deep practicing in thinking about more 'general' forms/concepts/structures. I wrote a framework for writing 3D model loaders after, and the lessons carried over. I was utterly lost when starting the first game engine; with the model loading framework I had to think deeply, but I new where I was going.
Here's something to consider. If you try to just start writing 'a game engine,' (or whatever engine/framework) that could mean about anything (from 1 day of work, to 20 years of work). But, if you consider some concrete ideas for particular games you'd like to make, think about what they have in common, and then try writing a piece of software that takes care of the common parts, you'll have constrained the problem to something workable with definite goals, and a way of testing your success after.
This is at the heart of any sort of 'abstraction' you develop: you want to code several things which have a bunch of overlapping aspects, so you write something that captures the common parts, and then arrive at the several things you actually need by instantiating your abstraction with different parameters (I mean that in a very general sense, not with specific reference to OOP, though it provides means of instantiating abstractions with various parameters too, of course).
I'd say being able to do the above effectively is the cornerstone of being able to do architecture well. A bunch of other stuff comes after, like knowing when to not create abstractions, and all sorts of knowledge about doing things well for systems in particular domains (e.g. architecture for an interactive 3d simulation vs. web apps have very different patterns that have surfaced as effective).
The best introduction I’ve ever read is Michael Sipser’s Introduction to the Theory of Computation. It is eminently readable. It somehow manages to be logically rigorous while remaining approachable. I couldn’t recommend a book more strongly for someone such as yourself. As a bonus it’s not even particularly long.
Depends on what you mean by architecture. But if you mean what you'd learn in a Computer Architecture and a Computer Org class, this course/book is good.
I meant it in the context of the article, where the metaphor was made between a dogshed-builder--a person who can code--and an architect--a person who understands CS and uses it to build things using code.
Georgia Tech’s OMSCS program has been great so far, outside of the super rigid proctoring policies they have for testing that cost me 2 letter grades in my database class.
Some classes are better than others, but it’s extremely valuable to have a program that you’re following with deadlines and measures. If you have a desire to learn the stuff, you’ll get a lot out of it.
When I get busy personally or at work, I kinda phone it in and just do enough to make grades, but when I have the latitude to dive deep I’m learning a ton.
It’s also very affordable, fitting within most workplace education allowances, if you have one.
I'm sure this has been covered to death on HN already, but if anyone has a link bookmarked and feels like sharing?