This blog post mentions some of the most interesting articles that I have read recently, with a little bit of my commentary on each article.
I read "Implementing SQL Server solutions using Visual Studio 2010 Database Projects-a compendium of project experiences". If you are using "Data Dude" in VS, you should read it to. Even if you don't implement all of the suggestions that @jamiet, it will give you a better idea of what is possible. The downside is that you may have to put a fair amount of time into improving things like build output or creating data that can be loaded into a development database that might not match the size of the production database, yet provides enough coverage to provide realistic query plans and durations. PMs are not always sympathetic to spending time on "features" that users do not see.
Having spent a lot of time with Database Projects myself, you can burn a lot of energy trying to get the tool to do what you want before realizing (or without realizing) that you want the wrong thing. Earlier versions of the tool also seemed kind of haphazard and it always seemed that some things always had to be hand-managed anyway (object security, linked servers and SQL Agent jobs, for example), leaving a "this tool is unfinished" taste in my mouth. As with most things that Microsoft sticks with, the tool has improved over time.
I also read "Discipline Makes Strong Developers", which is from a while back. It applies to DBAs as well, or anyone who is trying to move from assembly-line levels of competance to craftsman leves of competance. I'm sure that I've read before but it is worth reading again. Particularly for the quote from Code Complete, and because "grabastic" is such a great word.
Lately, I seem to be watching more than reading. This lets the presenter get more deeply into their topic than they could in a blog posting, but requires a larger commitment in time. Some of these might be a little bit older, but they should still be relevant.
I watched "TechNet Webcast: How Microsoft IT Architected and Redeployed an Application to Windows Azure", which is a level 300 talk. I was surprised that they had to move away from SharePoint to get the scaling that they needed. Not that I am a SharePoint guy.
I watched SQL Server and Solid State Storage - SQL/SSD, presented by Jon Reade. Once again, I see that space is cheap and speed is expensive. Simply put, when comparing SSDs to traditional hard disks, SSDs are expensive when comparing GB of storage space and disks are expensive when comparing I/O per second.
I watched 28 Weeks later - How to scale-out your MS Business Intelligence environment, presented by Sascha Lorenz and Performance Tuning Large Analysis Services Cubes, presented by Duncan Sutcliffe. I still tend towards tuning rather than throwing hardware at things, so Sutcliffe's talk is more aligned with my thinking. If you are Google or eBay or any number of the larger web properties, even with perfectly-tuned custom code you will never get the performance you require. Most businesses aren't in this position an anyone who is using SQL Server on Windows Server (or IIS on Windows Server) might not have the financial ability to deploy unlimited copies of those products, due to licensing costs. Google, for example, can deploy as many copies of Linux as they care to and they work at a scale where custom-coding everything makes sense for them. Heck, Google builds their own customized server hardware. I've worked for places that bought HP DL580 servers by the truckload.
I watched Consolidation and Virtualization Strategies-Microsoft Technology Center, presented by Ross Mistry. This is a nice overview of the strategies available to consolidators or people to start moving to a hypervisor-based (HyperV or VMWare, though he doesn't mention VMWare) or Azure-based cloud. There is only so much you can do in an hour, and its' lack of depth means that this talk is not something that will help you actually build that 16 node failover cluster, but it will go over it and the alternatives. Mistry also goes over how to map out your SQL Server situation and collect usage and performance data on your current systems so that you can plan accordingly.
I listened to a RunAs Radio episode featuring Jeremiah Pescke that discussed use of ORMs. I've been categorically opposed to these sorts of things, since they always seem to add too much overhead. Jeremiah's attitude is that ORMs are tools and can be used for good or evil, which sounds like something I'd say so perhaps I should soften my stance. He does go on to say that a positive, two-way communication between the development and DBA team is critical. I say that it is a shame that every development team can't have their own captive DBA.