Good advice on the learning schedule. That could apply to many parts of the SDLC. It's amazing how many times you seem a development shop building an app, where they do a little digging on the web, and determine they need this or that web framework (Spring, for example), this or that persistence framework (Hibernate, for example), etc etc, they've tried to overwhelm the problem with technology and find themselves mired in complexity, when they could've knocked this out in a minimal sort of way, using .NET or PHP and be done with it.
I remember long back working on a large Ariba system at one of the big retailers. They were using Net.Commerce (now WebSphere Commerce Suite), which had originally been written for L.L. Bean by a very clever team. Back in the day before XML configuration and IoCs like Pico Container and Spring, it was all table-driven. So when this company, which had built it's commerce engine from scratch, realized it would be nice if they could have it more customizable (oops!), purchased Net.Commerce.
It had it's own macro language, Net.Data, sort of JSP-like perhaps, and then the controller code was written in C++. Anyway, this being a retailer, we were working on a tight deadline, trying to get all our code working, your typical integration test scenario with the Ariba code, webMethods scripts, Net.Commerce C++, even some Java, then the back end system - you name it. But it didn't work. Time for some laborious troubleshooting.
Finally we traced it to the C++ "command" code. I confronted the developer - it was a basic, trivial coding error, that would've been caught if he had unit tested. His code simply did not work! This was not even some strange data or unexpected condition, it friggin' simply was broken! Unbelievable.
"But it compiled!! It's too hard to setup a unit test in C++!"