Part 1 of this series contains a link to an article called "How browsers work" (http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://www.htm

Part 1 of this series contains a link to an article called "How browsers work" (http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://www.html5rocks.com/en/tutorials/internals/howbrowsers...), which I read a while back. The epiphany for me was how browsers combine the DOM with style information into a render tree which can be traversed to do the actual drawing. While I won't be writing a commercial browser any time soon, that was the concept that was missing in mind, and once it was there I felt that I truly did understand the fundamental workings of a web browser and would be able to sit down and write one. This reminds me of the famous Torvalds quote: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." As I have advanced in skill as a programmer, I'm continuously reminded of how true that is. The canonical example at this point is obviously git - which has a mind-blowingly simple albeit clever structure - but I've found it to be the case in almost everything. I'm currently working on a compact DSL for performing a certain type of aggregations across streams of JSON objects. To me, the workings of programming languages used to be a black box with a lot of magic going on. Once I understood the concepts of lexing, parsing, using a visitor to traverse the AST and stack machines, it was went from being out of my reach to a simple but slightly time consuming excercise. There are many other examples -- raytracers, databases, rendering html and css as per the article and so on - but the point is that once you've found a convenient abstraction and a good way to represent the data, tasks that seem complex can become rather easy. A good chunk of what defines a good programmer seems to be the ability/intuition to find those magic abstractions which obliterates the problem.