"How many times do we ever face situations where we sit down to do things that are totally new to us?"

The vast majority of my day, and the vast majority of my career. If you're not, it's most likely because you're not challenging yourself, and you've got nobody to blame for that but yourself.

When I first got out into the working world, I read all the posts that said "Really, the vast majority of programming is just plugging together pre-wired components and pulling stuff out of a database to stick on the screen, and all the interesting problems have been solved already." I thought that sounded terribly depressing, but I liked programming and it paid well, so I figured I'd deal with it later. And sure enough, after spending 3 years in college working on a PHP webapp and about a year at my first job wrestling with JSF/Hibernate, I was pretty bored.

So I quit. I founded a startup to let teenagers create their own casual games, basically trying to put Macromedia Flash on the web. On the way, I learned HTML, CSS, Python, JavaScript, and ActionScript; used MySQL, Postgres, MogileFS, Munin, Monit, Pylons, Django, and JQuery; wrestled with how to persistently store a "game" in editable form (eventually settled on an AST-based representation serialized to JSON and dumped into MogileFS, with metadata stored in the DB); wrote a compiler from that AST to JavaScript and ActionScript backends; learned some image processing so people could manipulate assets for their games; and implemented all these physics & collision-detection algorithms in the runtime library. The startup ended up failing, but I guess it was impressive enough to get me hired by Google.

When I entered Google, I thought I was a hot-shit frontend engineer because I'd been working intensively with JavaScript and Flash for a year and a half. It took me about 3 weeks to discover I knew basically nothing. Because Google Search really cares about latency, which means that all JavaScript libraries were banned, and we had to count bytes in our source code to make sure our new feature wasn't slowing things down too much for users. You design programs differently when every line of code you write is a cost not just to you but to your users; you actually think about what you write instead of tossing in a 100K library because you need a couple functions. Plus, when you don't have JQuery to hide all the browser details from you, you really need to know how each different browser performs and have a large catalog in your head of what works and what doesn't work.

I've moved off my home base in Search twice, once for a short stint working with Google+, and another for a recent project that'll remain unnamed. Both have their own array of challenges. Unlike Search, G+ is not latency-constrained; they expect you to stay on the site for significant periods of time. The whole site is a massive AJAX app, though, so you have the challenge of how to manage a million+ line JavaScript codebase. The new project is developer-constrained; it has a small headcount, and so once again I find myself working with the open-source Python/Django/AppEngine/JQuery/LESS stack, but each of those tools has evolved in the 5 years since I last used them, and we now have all these HTML5 goodies to play with.

That's not even counting backend stuff. After a year and a half as a FE SWE in Search, I was starting to get pretty bored, so I asked to do backend stuff. I ended up working on an LLVM-based JIT for a templating language; the spec for Google's Authorship markup; the implementation of said markup throughout the indexing & serving system; a bunch of unstructured data-extraction tasks; and most recently some machine-learning with libsvm. All of these were new, and all were challenging.

And that's not even including soft skills like code reviews, mentoring, interviewing, managing up, product & UX design, and project planning. Having 3000 lines of code dumped on you on Wednesday when they want to get it in by Friday, needing to quickly figure out how it all works, and knowing that if you screw up you'll break google.com is something entirely different from hitting autocomplete in your IDE.

I'm beginning to think that if you know exactly what to do, you probably have no clue what you're doing. Real engineering is all about trade-offs: it's knowing that if you implement this new feature, it'll cost you a millisecond in latency and 2 months of engineer time, it'll have some unspecified effect on future productivity, and it may result in X number of happy users. And then you have to weigh those unknowns and decide "Given what I know, is this how we should do it?" If you know the answer to that immediately, your product is probably lame, because it means you didn't even consider alternatives.