| What I tell most people to do is to build a lot of toy projects. A lot. Ship a lot of code out onto the internet for the world to see. There are several purposes: 1) Building a lot of things will hopefully help you uncover different problems that you will have to struggle to solve. Hopefully after struggling to solve them, you will gain understanding. Just following hello worlds doesn't really help much. But when you're trying to figure out how to implement a "real-world" product problem, you'll have to figure out how to develop features that don't come for free with whatever framework you are using. 2) Also, don't write everything from scratch. Research what frameworks or libraries might help accelerate your development. Understand the pros and cons of using them. 3) Hopefully as you build more things, they will get better. And then you will have something to showcase to prospective employers. You'll have real code you can share with them. Be humble, get pointers on how you can improve. Bonus points if you have tests too. 4) It shows initiative and interest. I'd imagine these are important intangibles. I'd be very reluctant to hire an engineer who didn't tinker with things at night. (not necessarily all night, every night.) 5) Additionally, taking vague concepts and requirements and turning them into products does take some discipline. Which features will you keep, which features will you cut. How can you change your requirements and still get what you want. It shows that you can do things without being told exactly what to do, or how to do it. Hope this helps. |
That's the most often ignored advice I've encountered. Most frameworks and libraries are written by actually smart people, or at least by very experienced people. While it may not seem as the best solution for any given problem, they solve many basic things that are just hard to get right on the first try.
I started coding about 10 years ago by writing my own CMS. Then I've found it was built on wrong assumptions and wrote another one. Then another. My thinking was - my needs are very simple, I don't need the whole framework, I will be better on my own knowing every line of my code.
This time was almost completely wasted. I've learned what to avoid but not how to do things right. Also my resume was missing hot keywords recruiters are looking for, since I knew the language but not the frameworks. Usually it's ok for companies to train somebody as long as they have a point of reference ("he knows Backbone so he will learn Angular quickly" - not the best thinking, but that's what I've experienced so far).
My advice is do some initial research, see which framework or language suits you best and stick with it. It takes about a year to find all ups and downs of any given solution and many on the first glance look better/worse than they actually are. Good rule of the thumb is to choose something that is past the first iteration, so the initial problems are resolved but haven't had more than few, meaning that involved people are smart enough to not replace one error with another.