This answer is the closest to what I believe is happening. From our side, in an IBM and Websphere world, Java will continue to be the mainstay of especially (micro?) services that integrate with e.g. AS400 mainframe, DB2 RDBMS, leveraging IBM API and so on. Node.js definitely has a place as e.g. additional middleware (e.g. aggregation, specific microservices while there isn't one in Java, caching facility and more). You use the tool that best fits your requirements. Business (especially operations) still struggle slightly with Node as they can't "control" it as they can with JEE containers (performance tweaking, shared resources etc), All of this will start to fall away as we move towards microservices and things like Docker. By then it won't matter so much if a team decides on Node, Java, Scala or whatever, as they all fall within the rich toolset that we as developers have available these days.

So, here's how we do it (in the context of SCRUM with 2-week sprints, thereby keeping design/code/test/deploy cycles short). We write down acceptance criteria and expand on it with architectural requirements/goals. We do a high-level architectural design with the team so we can agree on an approach if needed. The UI design is also napkin-sketched with the UX people. Then, we literally evolve the code using TDD where possible: Write tests (up to a point) for a given scenario and edge cases; Write code to let these pass; Refactor the code (and add javadoc/code docs while you're there, if needed). The above cycle happens multiple times per day, so you can imagine that You code only what is actually needed; You do the DRY-ness etc etc incrementally, like growing a garden The test coverage is pretty good as there's very little excess code. This happens concurrently for the back-end and front-end, frequently checking that we match the criteria and sketches (design approach and so on) and doing all the good things like CI. Once we're ready for an internal review, we first run it through Sonar Qube to increase coverage where we feel it's needed and increase code quality. All the above happens in a continuous integration (and deployment when appropriate) pipeline using Go-CD (with maven, some plugins and special Websphere deployment toys).

The same goes for almost any course, even those as well-rounded and hands-on as codeschool. Codeschool has "soup-to-bits' videos that shows you how to apply it in a project. Also, you need to get yourself a pet project or a real (paid) one to practice what you've learnt.