Usually? Based on what evidence? Writing actual code as a member of a team is the best way to learn a new language and set of tools. What some may call “bad habits” are more accurately called different habits. We can’t, as a profession, even agree on indentation, so no habits are objectively good or bad.
Based on experience. I don't mean things like indentation. I mean things like on http://thedailywtf.com/
One company I joined put all their database types as strings because it was most flexible. A lot of architecture types are bad - they're slower, inflexible, harder to read, harder to test. It works, but changing the color of an icon then takes 4 hours, and may possibly crash one of the screens.
There's also a lot of spaghetti code, god classes, people who hack things together until they work, instead of spending an hour reading the manual to find what the proper use is. For example, I've seen someone who wants to get location permissions install a whole map plugin and hide the map in the background, instead of just writing the code that requests location permissions.
I've got years of experience, and these days I'm spending an hour/day watching beginner programmer tutorials to unlearn a lot of the bad habits of the past.
Based on experience (40 years programming) were just as likely to learn good habits and practices as bad ones. Of course daily WTF things happen and we all make fun of them, but there’s no site like that to post when something goes right.
Programming is an ongoing learning process, and that means making mistakes and getting exposed to less than ideal solutions and habits along with the good ideas and practices. You can’t get either from tutorials or working on personal projects, because feedback and mentoring play a big part in making forward progress.
None of the problems you speak of are language specific habits, they're just generally bad programming habits. And those bad habits aren't proof that writing code isn't the best way to learn. Of course, you can't just write bad code forever and expect to get better, you have to analyze your results or get feedback somehow and improve your programming. It's basically like every other skill.
I work in the public sector in a role where part of what I do is project manage/code review/consult the suppliers that build various solutions for our different areas of business.
And you really hit the head on the nail with this one. Almost no company that we’ve worked with do things even remotely similar. Which is all right, if what they are doing works for them and produces stable products at a reasonable price and timeframe, then who really cares how they do it?
It does make for some interesting codebase transfers with modern public sector enterprise architecture though. Like when a major system goes from one IBM sized operator to another, because the winning bidder changed hands. But that’s another story, and it really just underlines what you say, because even huge international tech companies don’t remotely agree on practices.
I think our failure, as a profession, to recognize and accept different ways to solve problems holds us back. Programmers almost always dismiss legacy code and anything they didn't write as crap, even if it works and adds business value. There's always a better language, toolkit, paradigm that the original developers should have used. We're good at pointing at mistakes and speculating on how we could have done it so much better, but not very good at honestly studying and learning from someone else's code.
Programmers who carry around the idea that they alone know how to write the first ever perfect piece of software, if only everyone would listen to them, cause more damage than the people cranking out working but imperfect code. The perfect is the enemy of the good, but we never seem to learn that.
I see this play out in my own work -- I specialize in legacy and abandoned applications. I'm often told by my customer that several developers looked at the code before me and declared it crap, unmaintainable, have to start over with (fad of the month) language. Yet the code works and has been maintained and enhanced for years or even decades (the opposite of unmaintainable). Ugly, yes. Requiring some commitment and study, yes. But not so terrible that starting over from scratch (which almost never works out as predicted) is a good business proposition. Call it hubris, call it fleecing unsophisticated customers, but this attitude just keeps software development reinventing the flat tire in different languages, to paraphrase Alan Kay.
