Last summer, I started working on x264, the only open source H.264 video encoder. I knew basically nothing and was experimenting with the simplest things and harassing the only other active developer for explanations.

Slowly but surely, I learned the codebase. Eventually, I got my first major patch in: a modification to the subpixel motion search that improved efficiency a bit. But I still found myself blackboxing most of the code due to lack of understanding. Bit by bit, I made more and more complex changes. I taught myself x86 assembly, and then SIMD assembly. I finally learned the subtleties of C pointers. I finally realized that the best way to learn how things work is to identify some way to improve them, and then go and do it--the process of doing it will eventually teach you how it works, even if solely by forcing you to ask an enormous number of questions.

By late winter 2007-8, I probably knew the codebase better than anyone else in the world except the main developer, Loren Merritt, who had been the sole maintainer for almost three years. I was still learning new things all the time, of course, and his knowledge vastly eclipsed mine. But this limited knowledge of mine got me a contract from Avail Media, who wanted an adaptive quantization algorithm implemented, primarily to stop the problem of flat textured areas being blurred out (such as grass in football games). Bit by bit I tried various ideas, and finally got a working algorithm in January that did the job tremendously well. This was committed into x264 in April.

I then got another contract from them to improve the VBV compliance (buffering for constant and limited max bitrate encoding), since they're interested in x264 for television broadcast purposes. I worked on this, which was eventually later improved upon by Gabriel (an employee of Joost, a company that uses x264) and turned into a complete overhaul to the buffering system, which resulted in much improved compliance.

Finally, I got hired for a summer internship there at a rather decent salary.

In the meantime, Adobe had released the latest version of Flash 9, which supported H.264 video. Suddenly, thousands upon thousands of websites were interested in switching--the old FLV1 video format was simply awful, and VP6 was only mildly better and, unlike FLV1 and H.264, very expensive to license. There was a massive flood of people looking for assistance integrating x264 into their toolchains--there simply was no practical proprietary alternative for the vast majority of these websites. Most of the low-cost proprietary H.264 encoding apps were non-commercial only (and much inferior to x264) and the higher-cost ones were simply way out of their price range (and arguably mostly inferior too...).

So, as a developer of x264, I was in demand. I knew the application better than almost anyone else. Everyone wanted me to help them. I got contract offers from Criterion Collection, Facebook, and others. There were also loads of smaller sites looking for more minor help, or even just quick guidance on IRC. x264 is now far beyond a tool for DVD backups, anime, and Scene releases; it was a standard tool used far and wide. And again, I am one of only two active developers. Furthermore, after over a year of being involved in development, I basically made myself an expert in both x264 and the H.264 standard, now knowing most of the code backwards and forwards and having read most of the spec at one point in time or another.

And what about the other developers I mentioned?

Well, the main developer was very difficult to motivate. He didn't seem to care much about money, and had a habit of blowing off past contracts. If you can convince him that some of his assembly code is suboptimal though, he'll be right on it ;)

There were many other minor developers--mostly people who submitted bugfixes or worked on one portion of the code. For example, Gabriel worked primarily on ratecontrol and buffering, which was the most important thing given his job.

And thus I was left as the single developer who was willing to take all sorts of contracts, available to do them, and with enough expertise to deal with almost any part of the application, code-wise, algorithm-wise, or simply usage-wise.

Just the URLs are pretty telling.

I like this picture better :)

http://danhau.posterous.com/our-fearless-investor-paul-gra

They're going to try to ram it through again on Thursday, so if you agree with this economist call your reps. (Sorry for the politics, but I've been on the phone all week about this. I probably deserve some mods down, so pile on!)

Bears are godless killing machines.

One of the more stupider suggestions I've seen in this whole mess. Of course, Mark Cuban doesn't care, he's got f*ck you money.

Hi, I'm the one writing the series, and I halfway agree with you.

I started learning to write compilers by getting Turbo Pascal and seeing the whole syntax expressed in BNF in a page or two of the manual, and the Pascal family (Modula, Oberon etc.) are all great starting points if you want to start writing a compiler top down.

Apart from Wirth's text, there's of course also the great series by Crenshaw.

The reason I chose to go in the opposite direction, though, was in large part because starting with the syntax tree etc. has been done to death, and a lot of people hit the wall long before getting something that generates a program that can run.

I also get the impression that code generation is seen like something of a dark art ("shores of hell"? It's not _that_ bad :) ), and that a lot of the time the choice of writing an interpreter instead of a compiler comes down to fear of the amount of work involved with generating code.

Witness how many interpreters don't even generate bytecode (Matz Ruby interpreter, I'm looking at you...) and suffer tremendously for it.

It's not that hard. Generating really fast code is hard, but generating code that beats the pants of an interpreter for the same language is usually fairly easy. Though some languages make it tricker than others to get something efficient, in particular due to the level of dynamic features (Ruby, I'm looking at you).

Another reason was that I want to play with something close to Ruby, and the Ruby syntax is an absolute nightmare to parse when you're the kind of person who appreciates clean, compact syntax descriptions... Who am I kidding? Ruby is a nightmare to parse unless you're the kind of mental masochist who enjoys doing his tax calculations on paper in binary just for the hell of it.

I decided to chicken out and do the "easy bits" first, particularly since a lot of my motivation was to get a platform to experiment with efficient ways of generating code for a language with the level of dynamism of Ruby.

It's as much an experiment for myself, since I've always built compilers top down myself as well. The reason I decided to start posting it was because I realized how quickly one can get to something that's actually semi-usable.

Anyway, a few more parts and I'll get to the parser. It will be based on a parser generator, though a more "Rubyish" one.

(And before anyone asks: No, don't expect a Ruby compiler from me, at least not in the next 5 years ;), I don't have the time, though I will explore topics related to it, such as a Ruby-like dynamic object model)

It seems every day someone or other discovers this, and the sheer magnitude of money there is to be made (and the bonus: having fun while doing it). I discovered it early this year, when I realized I was only one of two open-source developers in the entire world with my specific expertise... and the other apparently has been rather difficult to hire.

Yes, we hate politics here....except this is a fantastic summary that has nothing to do with technology aside from the author. Still, if he had included technology issues in the analysis, Obama "wins" hands down, especially in specifics:

http://www.barackobama.com/issues/technology/

http://www.johnmccain.com/Informing/Issues/CBCD3A48-4B0E-486...

Or we can not socialize either and let companies who make poor decisions fail.

Note to fellow HN readers: while this is a good post, the article is NOT WORTH READING. Just note that PG appears on Businessweek and move on. Do not read his profile or that of other people unless you want your brain to hurt.

"The Millionaire Mind" and "The Millionaire Next Door" have hard data on this. (Mediocre books, BTW.) The answer is that high net worth individuals are predominantly low B students.

A possible explanation for this is simply that lower scoring yet ambitious students are forced to take bigger risks. Johnny A student has a decision tree with more safe salaried gigs on it, but fewer big payoffs.

I saw once that one of the better income predictors was having had more than one sexual partner in high school. I don't know how applicable this is in the top quarter of the income scale. But for people in general I think it illustrates the criticality of social skills over other factors.