Success in Silicon Valley, most would agree, is more merit driven than almost any other place in the world. It doesn’t matter how old you are, what sex you are, what politics you support or what color you are. If your idea rocks and you can execute, you can change the world and/or get really, stinking rich.
Wrong, wrong, wrong and wrong. It matters enormously how old you are -- either too young to be taken seriously as an entrepreneur, or too old to be taken seriously talking about new tech. Your color is ridiculously important, because the people with money, who are almost exclusively men and mostly white, are more comfortable talking to other white men, and your nationality even more so, because of visa restrictions. Even your politics are important, because Silicon Valley is hugely liberal, and those who aren't democrats are libertarians.
And above all your gender matters. Because the ugly truth is that the men of Silicon Valley do not take women in tech seriously by default. I see it every day. If a woman walks into the office, people ask if she's in HR or marketing or legal or product, or frankly anything other than engineering. And distressingly, most of the time they're right, because there aren't many women in tech. And as everyone knows and keeps saying, that's a vicious circle: the expectation that women don't get into tech is what keeps them out of it.
Here's how it happens: if a woman engineer starts talking, men will wait until she says something notably clever before they start taking her seriously. Men on the other hand are taken seriously by default, and only get dismissed if they say something notably dumb. That, multiplied by thousands of conversations every day, is all it takes to enforce huge cultural bias against women in Silicon Valley and tech at large. I know this is true because, even though I try very hard not to, I've done this myself.
So if you're a man in tech, and you want to fix this problem, it's simple. Start with yourself, and your expectations. The next time a woman walks into your office, make no assumptions about her job title. Don't ask if she's somebody's girlfriend. The next time a woman -- at the workplace, at a party, wherever -- make a point about technology, make sure you're not making any assumptions about her level of expertise that you wouldn't make if she were male. That's the change I'm trying to make in myself, and it's surprisingly hard to do, because snap judgements are so easy to make, especially when they are habitual. I even had to edit this post a little when I realized I'd written it with the assumption that my audience would be male. It's insidious.
Arrington's post concludes with some weasel language in which he does not explicitly state, but instead paraphrases somebody else saying, that women are fundamentally, culturally unsuited to starting companies because they are "nurturing" and "not risk-taking" enough. He even trots out that bullshit about Mars and Venus. And I'm sure there's a lot of people out there who, secretly, think he might have a point.
But he's wrong. The reason there are so few women in tech is because of the men. As a man, I'm trying to do my part to undo that, and if you're a man I suggest you do the same.]]>
SQL was invented in the 1970s at the same time that "large-scale" (read: millions of rows) data stores came into existence. It triumphed over other query languages not because it was particularly great (though it was easier to read), but because it was standard. Everybody building a data store could write to the SQL standard without having to re-train all their clients and customers. It reduced friction all round. It was a huge success.
There's no escaping that SQL, as we use it day to day, is not pretty.
Keep in mind that what SQL is really designed to express is relational algebra, a type of logic essentially invented by the ridiculously clever E.F. Codd (along with nearly all the other theoretical underpinnings of relational databases). If you're not familiar with it, I find it helps to think about relational algebra as Venn diagrams: it's about sets intersecting with, unioning with, subtracting from, joining with each other. Find all the fruits in set A, with prices in set B, farmed by the farmer in set C. That kind of thing.
What it's not really for is collating, aggregating, and most especially filtering of data sets. The reason count(*) is so awkward is because that's not really what the language was designed to do. GROUP BY and ORDER BY clauses look tacked-on because they are (HAVING is an even more grievous hack, UNIQUE is a disaster, and let's not get started on LIMIT). Of course, in regular use of a data set, you nearly always want to do these things, which is why SQL provides them. SQL, loyal workhorse that it is, is nothing if not willing. But it might not be terribly quick.
So you're right. SQL -- the kind you write every day -- is ugly and awkward. In fact, it looks like hell on legs. And it's often pretty slow. And that's all because you're asking it to do something it, the language, is not really designed to do (whether the engine is designed to do it is another question). But it works, and in forty years since its invention we have come up with very little in the way of improvements and nothing close to powerful enough to be a replacement.
I want to be very, very clear about this: ORM is a stupid idea.
The birth of ORM lies in the fact that SQL is ugly and intimidating (because relational algebra is pretty hard, and very different to most other types of programming). Our programs already have an object-oriented model, and we already know one programming language -- why learn a second language, and a second model? Let's just throw an abstraction layer on top of this baby and forget there's even an RDBMS down there.
This is obviously silly. You've stored your data in a way that doesn't match your primary use-case, accessible via a language that you are not willing to learn. Your solution is to keep the store and the language and just wrap them in abstraction? Maybe you'd do that if your data were in a legacy system and you needed to write a new front-end, but people slap ORM on new projects. Why the hell would you do that?
ORM is slower than just using SQL, because abstraction layers always are. But unlike other abstraction layers, which make up for their performance hit with faster development, ORM layers add almost nothing. In fact, often, if you need to do anything more complicated then a SELECT, you end up writing fragments of SQL or pseudo-SQL languages in order to tell the underlying RDBMS what you're trying to really do.
ORM is dumb, and people noticed. So clever programmers looked at this ridiculous edifice and realized the real problem: the data store and the use-case were mismatched. So they threw away ORM, SQL, and RDBMS, and wrote lovely new key-value stores, or object stores, or document stores, or searchable indexes, or any of a half-dozen other data structures that more closely matched what they were trying to do. And because these data stores all turned up at a time when nearly all data stores were SQL-interfaced RDBMS, they got the name "NoSQL", even though the actual problem was the Relational model, not SQL itself. And because "Obviously More Appropriate Data Stores", or OMADS, is not catchy enough I guess.*
So I love NoSQL stores. My startup would literally be unable to function without memcache. I think Cassandra is nifty even if Twitter found it not worth the trouble of switching from MySQL. I think Redis is cool if a little buggy. MongoDB is awesome, and I'm probably going to be building a production system based on it quite soon. HDFS I use in production every day, and it still blows my tiny little mind. Really, the only think I dislike about them is the label "NoSQL", which as many people have already pointed out doesn't really say anything about what they are, just what they are not. And also because it makes people unfamiliar with the details of the situation think there's something Wrong, Bad or Old Fashioned about SQL. And programmers hate using anything that is any of those things.
So if your data store should always match your application, what application is it that RDBMS are perfect for? The answer is: all, and none.
We take this for granted these days, but the relational model is pretty magical. Set up a model of your entities, pour data into it, and get answers. How many teachers at the university earn over $100k but teach less than 20 students? How many customers who bought our newest product had never bought anything before? What were sales like on Tuesdays over the last 30 months? You don't have to know in advance what your questions will be; you don't have to write any special code to examine all the rows, or work out the most efficient strategy for combining the results: you just need to know how the data relate each other, and then you can ask ad-hoc questions and the database knows the answer. I remember the first time I really grokked that concept, and it filled me with nerdy joy.
If you pick the wrong data structure for your store when you're first writing your application, you can end up -- as happened to a team at my last job -- running crazy, days-long depth-first searches across distributed document stores in order to perform elementary operations like getting a total count of objects. So if you don't know all the questions you might need to ask about your data, the safest thing to do is put them in an RDBMS. And when you first start a project, you almost never know all the questions you're going to need to ask. So my advice: always use an RDBMS. Just don't only use an RDBMS.
Is your data really just a giant hash lookup? Then a key-value store is what you want. Do you primarily access your related data via a single key? Then a document store is for you. Do you need full-text searching? Then, dear god, use a text-indexing engine, not an RDBMS. Do you need to answer questions about your data that you can't predict in advance? Then make sure your data also ends up in an RDBMS. Maybe not in real-time, maybe summarized rather than in raw form, but somehow. Then when your co-founder asks "how many Xs happened in Y?" your answer won't be "uh, let me spend half a day writing code to find that out". Just throw down some SQL, and it'll give you an answer -- it'll take 5 minutes to return a single number, but that's a lot faster than half a day.
Because that's what SQL is for.
If you scroll back to the top you'll see the description of the circumstances that gave birth to SQL: a whole bunch of new data stores came into existence at once, and the lack of a common language created friction and fragmentation. The same thing is happening again with the NoSQL crowd. If you decide to write your app using Cassandra, you better be sure it's what you want, because if you change stores you have to change all your code. It's the ultimate lock-in, and it's not the plan of an evil monopolist corporation, it's just an unfortunate side-effect.
Pretty soon, the same sort of clever people who noticed that ORM was a ridiculous hack will notice an opening for an actually useful abstraction layer: a single common API that can access all the NoSQL stores. Maybe it will be Thrift or Avro, but I'm not sure. I'd say the chance is about 50-50 that it will be SQL again.
And why not? Awkward it may be, but SQL is a lot more succint and readable than multiple lines of API calls or crazy, math-like relational algebra languages. And there's nothing intrinsically slow about the language itself. If you could run "SELECT * FROM table WHERE ..." on Cassandra, it would be no slower than specifying the same conditions via API calls. In fact, when trying to explain how to use its API, the MongoDB documentation lists the equivalent SQL queries. That's a pretty clear vote for the usability of SQL.
Computer programmers really like new, cool things. So when something like SQL hangs around for nearly 40 years, it either means nobody really cares about it -- I think we're clear that's not the case -- or that there's really nothing else that can do the job quite as well.
So go forth, use your OMADS, keep an RDBMS in your back pocket, and stop being so mean to poor old SQL.
* On the off-chance that anybody starts calling these things OMADS, remember: you heard it here first.
Updated 2010-07-13 to fix link to E.F. Codd; thank you Sordina!
]]>If you want to tout your own morality, you'd best come up with something more substantive than your heterosexuality. You did nothing to earn it; it was given to you.
I want this on a t-shirt. And a billboard. And written in the sky.]]>
There's a lot of public anger over the spill, mostly directed at BP itself, brilliantly captured by the BP Global PR Twitter feed. And there's a lot to blame them for. As the New York Times reports, BP officials knew weeks in advance that there were problems with the rig and had deliberately scaled back the rigorousness of the federally-mandated testing they were doing on the rig -- a very unusual practice; usually the tests get more and more strenuous. They knew something was up.
The Wall Street Journal (free article) has a lot more detail: they chose an inherently risky well design, skipped a lot of standard safety checks, ignored best practices, and were in an almighty hurry to get things finished. Furthermore, they might even have avoided loss of life: there's unsubstantiated rumours on the internet that a subcontractor on Deepwater Horizon ordered all their personnel off the rig 6 hours prior to the explosion because they believed it to be unsafe. If BP had listened to them, they could have evacuated. It's a scandal.
But as I started saying in this thread on Hacker News, it's not really BP we should be angry at. It's not their scandal. BP, Transocean, even Halliburton, were all just doing what was in their best interests. Relief wells such as the one they are hurriedly drilling are enormously expensive, and skipping them makes the cost of drilling the many unsuccessful wells necessary to get a profitable well going much less. Even the enormous costs of cleanup of this leak will probably not outweigh all the money they saved over years of risky practices.
The real problem here is political. The only way to get the oil companies to take the externalities of drilling into account is to force them to do so; economic self-interest is in favour of destroying the environment. The Minerals Management Service, the regulator in charge, was obviously corrupt and completely in the thrall of the oil companies.
So when the leak is plugged, and the decades-long task* of oil cleanup is underway, remember to direct your anger prudently and productively at the politicians in charge, the ones capable of pushing legislation forward that will create a stronger and more independent regulator. Yelling at BP and taking their money is emotionally satisfying, but will not fix the real problem. Destroying the environment must become more than merely expensive; it must be criminalized. Oil executives will think twice about approving risky drilling practices if they know they will personally go to jail if it fails.
* Cleanup of the Exxon Valdez spill, which happened in 1989, is still ongoing.]]>
The reason the web works is because it is independent, decentralized, and simple. There is no prescribed ideal for the way web pages should fit together. Indexing is independent of representation, and indexing is open to anyone. The web is a graph, a real graph, where no node is more important and any path is possible, and the protocol is a true protocol, defining only the most basic forms of interaction and leaving semantics to the application layer.
So at first glance, it seems a social graph protocol would need the same properties:
For the first part, I think a lot of people assume that a true social graph would unify identity. The WWW* is itself; it represents only itself and it contains all of its own information. But the social web isn't like that; the online representation of a person is a proxy. And I think for reasons of privacy, security, and practicality, a total representation of our social graph would be undesirable. Such a graph would consist of everyone you've ever met, and for completeness would have to indicate how strong your connection was to them. That in itself is information we keep socially very private. In addition, we keep our social and professional lives to some degree separated. Our friends are not interested in our business contacts and vice versa.
A true, complete, open social graph is socially undesirable; it's not what we want. So what do we want? The answer is already emerging: we like our social graphs partitioned by intention: professional networks (LinkedIn), personal networks (Facebook), "social" networks (in the sense of "socializing" -- people we like to talk to or hear from) like Twitter, romantic networks (an infinity of dating sites). Then there are less well-established, niche networks built around personal history (alumni networks, mailing lists) or interests (forums and online groups).
For individuals who exist in multiple of these circles, we already accept duplication readily. Many recent attempts have been made to find ways keep all your social networks in sync and related. This is not a particularly complex technical problem (though scaling it would be nontrivial), and yet no-one has succeeded. I think this is not because we've not worked out how to do it. It's because nobody wants it -- nobody except nerds who like graph data, and marketers who dream of the giant rewards to be reaped from owning that data.
This changes things for the designer of the proverbial Open Graph. The shape of the graph we are expecting changes, as do the nature of the nodes. The nodes become facets of personality rather than single true representations of people, and the vertices become somewhat simpler: type of connection, and probably directionality, but without the degree of strength that would be so tricky to judge relatively in a unified graph -- is your business partner closer to you than your girlfriend? It's an impossible -- and largely pointless -- question. The graph ceases to be a single unified graph and instead becomes hundreds of graphs, occasionally connected but in ad-hoc and inconsistent. This is already sounding much more like reality -- and much more like the web as we know it.
Furthermore, the openness is still a problem. Professional networks are closely-guarded secrets. Personal networks if open can be exploited for identity theft and social engineering. Privacy is paramount. We trusted Facebook with it and they pulled the rug out from under us, to monetize better. We trusted Google with it and they broke it by accident with Buzz. We never, ever trusted Microsoft with it. A central commercial repository for all our data is clearly the wrong way, and even a cental repository for each facet -- one for professional, one for personal, one for romantic -- seems flawed. What's the webby way to do this?
If we don't trust a single company with our data, if any single repository would be too much of an attraction, then we need instead dozens, hundreds of repositories: we need domains and servers, just as we have web sites and web servers, or email addresses and email servers. Each server will hold our social connections -- not a single true representation, but whatever facet of our personality we wish to represent via that identity. In fact, using an ID like name@domain.com -- similar to email addresses -- would not be a bad start.
To free us from the giant honeypots of isolated, centralized social networks, what we need is the protocol that would allow these systems to communicate -- in the same way that we each have an email address on a different server, but all email addresses can contact each other, we need distributed identity that can communicate via a protocol. In the early days of the Internet, services like AOL, Prodigy and Compuserve overcame the lack of a unified protocol by building rich walled gardens. In the evolution of the social web, it is time to make that same leap. Social Network A must be able to talk to Social Network B as a peer.
What are the actions this protocol must allow? The same things networks right now allow:
I learned a lot about ActivityStreams at their StreamCamp event last week, and it is an interesting solution to the second problem I listed: standardized, federated, and open, it doesn't care what network an update comes from, it just aggregates them and passes them along. It's the right direction. But we need something grander.
Imagine a set of servers. You can create an account on any server and invent an identity, or even several different identities. Duplication is expected and even encouraged. Now create connections between entities. They can be within the domain, or they can be between domains. For a unidirectional link, only the originating server knows the connection; for a bidirectional server, both do. If the originating and destination server are the same domain, it stores both. It doesn't matter; external and internal connections are equal citizens, wrapped around some central standardized metadata that is extensible at will: richer networks can share more, simple networks are not required to do so.
Each domain holds a single unique key: username@domain, possibly with a short, more human-readable label (very short, to avoid spam -- see later). Around that they can wrap as much metadata as they like. Secondary standards will emerge to define larger sets of metadata with suggested keys, which networks can adopt from each other in order to more richly represent entities on external networks. But the protocol itself says nothing.
The protocol should also make no assumptions about the nature of an entity. Some entities will be people, but others might be companies, or groups, or even events -- the difference lying merely in the metadata that might be attached to the entity rather than a fundamental protocol-level difference.
These can be handled via a pub/sub mechanism like PuSH. When an entity performs an action it distributes that action to any subscribers. They can further syndicate within their own network according to their domain-specific rules. ActivityStreams are the way forward here.
At the protocol level, the creation of a connection allows messaging to flow backwards from the subscribed party to the originating server; a pair of connections therefore allows bidirectional messaging. The connection is created simply by exchanging keys: when A connects with B it offers a key, signed with the identity of B and a timestamp. If B accepts the connection, it can thereafter use that key as authentication to send messages. A can revoke the key according to its own logic at any time, and re-issue a new key with a new stamp. B is expected but not required to cease communication attempts after its key is rejected. This solves a fundamental problem of email, which is that possession of an address is sufficient for communication; instead, possession of an address is merely sufficient to request communication.
Obviously the mechanism by which the connection is created is the weak link: there must be a very small, extremely proscribed set of allowed metadata in the connection request. There could also be an optional "connection password": if the request contains the password (which might be transmitted independently via IM, word of mouth, or attached to a business card) then the metadata accepted as part of the request might be expanded.
Spam is much easier to handle in this model. Communication attempts from entities with no connection would be ignored -- no more AI-level intelligence required to determine whether a message was solicited or not. There would still be connection spam, but the protocol would allow only one or two connection requests -- subsequent attempts would be ignored by default, and blacklisting an entire domain would be simple, possibly even automatic after a sufficient number of ignored requests. Some nets might even maintain a whitelist of trusted social networks, and only allow unlisted networks to send requests at all if they contained the "connection password". Simple heuristics would allow automatic blacklisting of a domain that generated hundreds of rejected or ignored requests.
A thornier problem, but an interesting solution presents itself: a search within your social network would become, by default, a distributed operation. A search request would be broadcast to all the domains to which you have connections, asynchronously, and they would be permitted a time window in which to respond. The search request would be in an open format related to the identity metadata: domains receiving a search request they do not understand or do not allow would be permitted to ignore the request, either silently or sending a specific HTTP response to allow the searching server to efficiently skip that request in future.
Thus indexing becomes a simpler problem. Instead of a single global index owned by any one company, each domain is its own index. Simply by being a smaller network, the problem becomes simpler -- the global social database is, in effect, sharded across hundreds of domains; the searching is distributed ("mapped") to hundreds of domains, and the originating server needs only to perform an aggregation operation (a "reduction").
Depending on the rules of the domains, some searches might be forwarded, to allow for 2nd and 3rd-degree searches. This would allow for an even more powerful distributed search; a multi-stage map/reduce as each network rolls up its own results for the next. The network latency issues here are considerable; some degree of caching should probably be permitted on the originating server side. The degree to which searching is effective is entirely dependent on both the user and the domain. Professional networks might allow two degrees of search; dating networks** might allow four or five; strictly personal ones might ignore searches entirely.
Another pub/sub mechanism. A group would be just another entity: one user would create group.identity@example.com, and other users would provide that entity with a key to join the group, and revoke it when they left.
An extension to the metadata of either a private or personal message, containing the identity of a new entity. An RSVP simply becomes a connection request; you subscribe to the event just like you subscribe to a group, and leave it by revoking the key.
This is the seed of this idea, dreamed up while flying back from Chicago. Clearly there are holes, edge-cases, and more. But this is the right shape of the idea, and it's pretty exciting, I think. Do let me know what you think.
Some areas that need work:
* I'm using WWW here not to be old-fashioned, but to distinguish between the web of pages (the true WWW) and the secondary web of entities, people and objects that some of those pages represent.
** Note that the protocol doesn't know if a network is social, professional, or romantic -- that's defined ad-hoc by the entities that make up the graph. By using professional.identity@example1.com and making connections to professional.identity@example2.com, you are creating a de-facto professional network. If you start making connections to your romantic identity at the same time, that's up to you -- or possibly to the rules defined by your domain.]]>
There's a big fuss right now because as part of the iPhone OS 4.0 release, Apple has explicitly banned the use of intermediate platforms to create iPhone apps (and hence presumably iPad apps, since they run the same operating system).
Their motivations for doing so are the subject of debate. The supremely well-informed Jon Gruber of Daring Fireball thinks Apple is doing it to lock in iPhone as the de facto standard for mobile development, in the same way that Microsoft managed to get a lock on the PC market despite the many flaws of Windows -- by attracting critical mass of developers, and hence apps, and hence users, and hence developers, in a virtuous, monopoly-creating feedback loop.
This interpretation has been tacitly acknowledged by Steve Jobs himself. However, Jobs placed the emphasis on another aspect of the post, saying
intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
This spins it as a user-friendly decision rather than a ruthless business one, but there's no reason it can't be both, and one imagines it being both would be just fine with Mr. Jobs.
Whether or not Apple is correctly positioned to dominate mobile apps a la Microsoft is a subject for another post. But right now, I think the idea that intermediate platforms are unwelcome on the iPhone raises an important question for web-native developers, such as myself.
When iPhone first launched, Apple announced that apps will be web apps. They were supposed to be first-class citizens and in fact were the only way of producing apps for the phone. There is even still a web apps directory, a neglected, poor man's App Store for web apps.
Since then the real SDK was introduced. It's unclear whether it was planned all along, or if it was a strategy adopted after Apple saw the enthusiasm and creativity going into jailbreaking, which allowed developers to run custom apps on iPhone before that was officially allowed. Meanwhile, the APIs web developers were promised for iPhone never materialized: location is now available, but a hundred others are not, and with the release of iPhone OS 4.0 that list has grown.
And now the official word is that intermediate platforms are not welcome to make apps for iPhone. I can't think of a more obvious and widespread intermediate platform than the browser environment, and whether you believe the motivation is a better user experience or a hard-nosed attempt to monopolize mobile development, web apps lose.
Because there's no denying it: web apps provide worse user experiences than native apps on the iPhone right now. They don't have to -- Apple could expose all the APIs via the web, and add extensions and libraries to Safari that would allow the beautiful, fine-grained UI controls currently available to native apps. In fact, they already built one, called PastryKit. Its non-release, despite being high quality and inclusion-ready, is another indicator that Apple is deliberately ignoring web apps as a platform for the iPhone.
Our one hope as web developers for developing on iPhone with full APIs was being able to build web apps that would get compiled down to native code (or, on clever platforms like Appcelerator Titanium, run as WebKit instances inside a customized, lightweight native app). With this change of the rules, the future of platforms like these looks very uncertain, and the door has been slammed in our faces.
The illustrious ppk thinks all iPhone apps should be web apps. I think the chances are slim, and getting slimmer all the time.
Everyone knows the largest development platform in the world isn't Windows, or Mac, or desktop or mobile: it's the web, the only platform that runs on all of those, plus nearly everywhere else. Ignoring the giant and ever-growing contingent of web-native developers -- people who grew up writing apps for the web, have never written apps for anything else, and see little reason to start -- is to ignore the tide of history.
The unstoppable march of technology has taught me that what ten years ago seemed like a ludicrously inefficient idea soon becomes standard practice. Running an entire IDE as a Java app, for instance, or installing each major component of my development environment in its own separate virtual machine. Computational efficiency is repeatedly sacrificed for speed of development, because computers are cheap and getting faster all the time, while developers remain expensive and oh-so-slow.
So it doesn't matter if, right now, native mobile apps are faster. That advantage is momentary. It does matter that the experience is better, but that just means there's an opening in the market for a platform that really does treat web apps like first-class citizens. Android or, perhaps, Palm, if they get acquired by somebody more capable of building out a platform.
At no point will web apps be faster than native apps. And the experience might never be quite as good. But one day it will be "good enough". The desktop hit that tipping point more than five years ago -- what's the last really exciting new desktop app you installed? In my case it was Chrome, and that was because it was a better browser. To pretend that won't ever happen on mobile devices is silly.
Once it happens, the web will win again. Attempts to lock web apps to your platform with useful but proprietary extensions will fail, as Microsoft failed with ActiveX. Developers will put up with building simpler apps because they run everywhere, really everywhere. Developers go where the users are, and the users, no matter who made their hardware or wrote their software, are always on the web.
The web will win, eventually. But in the meantime, find somebody who knows Objective-C.]]>
So now, after a few weeks of tweaking, I give you Re-Expressed: the Trinidad Express, made readable. I hope you find it useful.]]>
Above all, it was a message of optimism: yes, the system is broken, but it can be fixed, by us, right now. And this funny, sincere, incredibly, hypnotically charismatic man seems like just the right guy to do it
Today, the trust he inspired has been validated, and the promise he made has been -- as far as I am concerned -- kept. Sure, the coverage is not quite universal. And lots of things won't kick in until 2014, after the end of his first term. But that's politics. It's a business of compromise, and incremental advance. But he promised the biggest change to healthcare in a generation, and here it is.
Good going, Barry.]]>
The 10th anniversary of this blog is a little further away -- the site was mostly static until March 2001. This morning I grabbed a quick set of screenshots of some of the oldest designs of the site; they are pretty funky.]]>
I remember very clearly, when I was fifteen and had had Internet access for only a few weeks, building my first web page and thinking "wow! This is fun! I wish I could get a job doing this!" Then I tried to think of big, web companies I'd really want to work for, and the first one was Yahoo!. "But they've already built their website", I thought to myself, "They don't need another web developer. Plus, I don't know Perl."
So nine years later, when Yahoo! contacted me and offered me a job in the London office, it was a dream come true. I sent excited emails to friends and family, I printed out a huge "I WORK FOR YAHOO" banner above my desk at home (in a stolen copy of the Yahoo! font). I know it sounds terribly cheesy, but I really did.
Joining Yahoo! was amazing. We're so *big*! We have our own fork of Apache, our own version of PHP, dozens and dozens of our own specialized products and plugins (I love yinst!). In my very first week, I was already making changes to websites seen by millions of people (the FIFA world cup site). And the resources we can draw on! The devel-frontend list taught me volumes about CSS and Javascript, as did internal training for YUI.
For a young web developer, there is absolutely no better place to work than here. I got to build not just big sites but great sites, working with people who are absolutely at the top of their game in every department -- design, engineering, ops, and QA. Plus there are hack days -- I love hack days! You get to build the coolest thing you can think of, as fast as you can, and show it off to hundreds of appreciative engineers. There's very few places in the world where you can do that.
Yahoo! has made me a better web developer, a better engineer, and a better teammate. I have learned so much from this company, and for that I am deeply, truly grateful. Being a Yahoo has been a big part of my life -- and I know, from seeing it in others, that you never really stop being a Yahoo, even when you're working somewhere else.
So then, why am I leaving? Because I have grown as much as I can. In my first year I grew as a web developer, in JS and CSS. In my second I grew as an engineer, architecting a whole website from scratch. In my third I grew as a database developer -- I became "the database guy" to some of you, which I still think is funny. I'm a web guy! But in this last year I have mostly grown frustrated. I'm not saying I have nothing more to learn, but I need to go somewhere else to learn it.]]>