31–40 of 50 posts
Always build something. Nothing teaches you about a technologies limitations and benefits like building something with it. I don't think you really know a technology until you've build something with it.
Agreed for the most part, but might not work in all cases. For eg. Learning to use vim ....
1. Hear about cool new technology for the 3rd time, this time seeing a clear application for how it could be used 2. Get really excited and go to technology's homepage.io 3. Get 40% through homepage.io's tutorial before I get frustrated and confused 4. Shelve new technology away in my brain as a list of potential things I could build something with 5. Months later, get a really Cool Idea for something I could build w…
I have limited brain space and learning something really well often forgoes learning new things unless they are evidently superior.
That being said, I don't often spend time learning new technologies. Instead I invest in learning fundamentals.
Before I build something using a new technology/framework/language/whatever, I look at popular open source projects that use it. Not only is it useful to pick up idioms, but browsing through the project's closed issues is a great way to find and avoid common pitfalls of the new technology.
1. Hear about cool new technology for the 3rd time, this time seeing a clear application for how it could be used 2. Get really excited and go to technology's homepage.io 3. Get 40% through homepage.io's tutorial before I get frustrated and confused 4. Shelve new technology away in my brain as a list of potential things I could build something with 5. Months later, get a really Cool Idea for something I could build w…
1. Hear about cool new technology for the 3rd time, this time seeing a clear application for how it could be used 2. Get really excited and go to technology's homepage.io 3. Get 40% through homepage.io's tutorial before I get frustrated and confused 4. Shelve new technology away in my brain as a list of potential things I could build something with 5. Months later, get a really Cool Idea for something I could build w…
Javascript callback functions don't count as "one line". :)
1. Read tutorials if available, then books in that order. Not to be exhaustive but just to get more stuff into my head.
2. Do a small project that uses it.
3. Repeat from step 1 but with more info to digest and a slightly bigger project to work with.
After some 4-5 iterations I would have a nice grip on the technology and a handful of small projects to show with.
There's a lesson here for people whose aspirations include writing technical books.
It doesn't help that this is a generic poll about generic books. Of course imaginary books poll worse than imaginary websites: They're more expensive (because imaginary books have an imaginary label saying "$9.99", and imaginary websites are free and subsist purely on popular goodwill and flamewar-powered Carnot engines) and neither of them has any real content so it's impossible to evaluate the amount of imaginary value one is getting for one's imaginary money.
Whereas in the real world people judge their materials in the context of specific authors, subjects, goals, and budgets. People compare (e.g.) a copy of established-Github-wizard Scott Chacon's Pro Git (a try-before-you-buy CC-licensed free book) to the thrill of trying to learn Git's canonical workflow by reading its man pages and browsing flamewars about rebase v. merge. Or a ten-minute Railscast Pro about Devise, paid for by your boss, to the option of having to admit to that selfsame boss that your project's hand-rolled authorization code got hacked.