Following along with this thread as I've never written a single line of PHP.

They're good for teaching you why people often refactor the code that's generated... The problem is most scaffolds don't reflect a particular chief architects preferred style-guide, or software portfolio policy that has been adopted by company A, B or C. They can't read your mind. So, most have a generic structure that allows for refactoring easily enough by individuals or teams even if it is initially working backwards. Better to have the option to use it than not I say... but if someone has a desired scaffold they want to use/reuse they should probably do the legwork then automate it so it's not wasted time each time.

Oh dear, accidentally upvoted my own response. Mortifying.....

Sadly webdev is a topic where even working in it all day will leave you feeling you're wildly behind... there's a million shoots out there, nobody is up to speed on them all.

This depends on the organisation, the team itself, the team-lead, the level of leadership vs direction that are in play. In an ideal world, it should function like the Beatles... "whoever had the best song idea is the one we used" but more often than not you will find a somewhat curtailed level of design autonomy when it comes to software development... Of course this leads to the gripes, disagreements, factions forming, enemy-of-my-enemy, work to rule, I'm outta here scenarios depending on the gravity of the situation. Professionally we all like to think we're right, yet sometimes we'll do things and implement choices we believe thoroughly wrong because the decision is out of our hands or budget, or you simply no longer care enough to put up a fight. Moral high-horsing about walkouts are fine in print, not so fine when you've houses, cars, kids to pay for etc... As a manager, I try not to stamp out all friction, some can be very good, productive, educational and motivating actually, it's a case by case scenario. Naturally, anything serious or detrimental must be handled and delicately, but difference of opinion and a little loose rope to see how it pans out needn't be a bad thing. I'd rather have a team 'burdened' by respectful disagreements than a group of sheep waiting to have orders barked at them. A handy 'fire-blanket' I've used before is to take a losing idea, explore the merit of it and see where else we could use it assuming it's not a useless idea.

There is significant enough differences, given that Angular2 is a rethink and rewrite, that support the idea that if you're just starting out you're not hindered by the "That's not how we did it before" thinking that coming from Angular1 will raise for many. An advantage as such... of course many developers are used to wiping the slate clean and ramping-up again with a new product version, in which case experience is an advantage. In short, I've not seen any compelling enough evidence to suggest that if you are starting out Angular1 should be chosen over Angular2. While it's still in RC it's a good time to get ahead of the crowd also.

The problem now is that we live in an app world where people trying to learn to code set that as the base example and from the kick-off they have a large, daunting codebase when they're still trying to get to grips with it. It doesn't work, it's another digital soul on the abandoned heap of github.... To learn to code you need to write loads of crap code, mountains of it... also, frantically searching stack-exchange, 3 million blogs and a half dozen pages of a book per day just renders loads of useful nuggets that don't add-up to anything coherent, solid and memorable. It's like a mental, self-inflicted, DDoS. That overreaching is what's going to take your enthusiasm and turn it into a giant ear getting into the boxing ring with Mike Tyson while screaming "look at me, I'm an ear". Write loads of garbage code, analyse your day... what did I do for breakfast, code it, yes it's ridiculous, but as you say it focuses on the 'problem' and makes the syntactical elegance an after thought. Do you take the bus? done so every day for ages, accidentally remembered all the streets the bus passes and doesnt go down, code it, learn the decision trees, map it out.... yes it's ridiculous but... at least you're not wasting time thinking if only I had an idea . Make the idea that you code one thing each day, small, tight, always growing, expanding. Take a spoken language you don't know, French, Chinese, whatever... you don't learn this by going to a cheif planner and quibbling about the dubious specifics of a submitted architectural plan, you learn it by freaking out shop assistants by accidentally asking for a broken monkey instead of a lovely fresh salad baguette. Programming is no different..... Go code that rubbish. Be ridiculous, be fabulous....

In my opinion, yes. You're forced to structure your learning as others might read it too, and by writing about what you learned, how you learned it, the twists and turns involved you're further committing those details to memory. A two way payback. What's not to love?

look for extendibility, nobody wants a set of API calls with breaking changes every 5 minutes. So, nail down the requirements and factor in that it will inevitably change or grow so the call set should be robust.