Writing code is the real key- think of writing at least 50 lines of code a day.
This process takes about a year.
41–50 of 58 posts
Writing code is the real key- think of writing at least 50 lines of code a day.
This process takes about a year.
Learning to code is the same as learning a second language. You must recognize the amount of energy it takes to learn french, and apply it to learning ruby. Your final goal - which for the HN crowd would be something like building a SaaS web app, is equivalent to writing a novel. But before you get to your novel you must learn how to speak and think in the language. You need to know the vocabulary and how to write se…
From there I changed the paths so the style.css pointed to its location in the folder. I'd do the same thing for any .js scripts. After getting it running locally I would deconstruct the site (remove and add back various pieces of code) to witness how one thing relates to another.
I myself, need to jump on frameworks. I'm too stuck in my comfort zone of design and front-end skills.
Before that, I tried every book I could find, religiously watched the latest Railscasts, Peepcode screencasts, etc. and watched every free tutorial out there. Until I started working on something that I needed and just plowed through it until it was built, nothing truly clicked. It also helped that I locked myself in my attic for three weekends straight to get my first "real" project done - setting aside that kind of time to focus is huge...
Just pick a small-ish project that is personally relevant and hack your way through it until it's reasonably functional. Also pick a language that is fairly simple and readable (I chose Ruby, but there are lots of good options) and a problem that isn't too difficult at first (e.g., a straightforward CRUD app will build confidence before moving on to bigger and better).
Also, you'll see a ton of recommendations for the "next big thing" (e.g., Node.js) on sites like HN and you'll be tempted to run from one new language or framework to the next. Try to avoid that if possible. I think the key is just picking anything that can get you as close as possible to solving the problem you're trying to solve. Later on you can worry about finding the ideal tool for the job.
I should note that I'm not a pro developer by any means, but I can hack together prototypes and simple apps fairly quickly coming from a similar background to you, and this is the way I went about it...
As zedshaw says, do every exercise, type every bit of code, etc.
After learning javascript, I went on to learn something more immediately useful. It took me about a month before I had built and completed my own local file search engine with jscript (windows scripting) and ms access. I altered my sleep schedule to 34/14 (awake 34 hours, sleep 14). If your mind is actively engaged in the learning, you won't need to sleep regularly. Sleep was the only limiting factor.
3 months after first learning javascript, I had rewritten my file search engine in perl and C, and upgraded my database from ms access to mysql. I didn't know much about perl and C, but I was happy to now "know" 3 languages and 2 databases.
I started programming when I was 24 (11 years ago) and working at my first job. A coworker was my mentor early on, and we pair programmed frequently for a couple of months. I read a couple of Wrox Java books and just learned by writing a lot of code and reading as much as I could. Luckily, I was tasked with developing a whole bunch of forms for a client-server application, which the IDE helped me out with a lot with…
Can you define #3? Meaning going from easy to difficult? Or starting with a difficult task and trying to solve it (at the beginning everything seems difficult, but yeah :).
* moving averages
* linear regression
* matrix operations
* matrix lu factorization
* polynomial interpolation.
* multiple linear regression
* cubic spline interpolation
* variance, covariance, correlation
* gamma function
* t-test, t-value calculations
One limitation of the above is that it doesn't explore all of a language's features. The above are mostly interested in array processing. There aren't any classes or generic types or what-have-you.My first "programming" projects were a Processing app that fills your screen with randomly colored dots that increase in size, a website that will send an email after a one-year delay, and a pair of headphones that play back everything that happened 20 minutes ago.
These were perfect projects because they were "correct" and presentable when they were done, they have small enough scope that you can spend days perfecting the details, and they were done when they were done.
Lower the bar. Incorporate things you already know about. Build it for yourself. Make the objective a thing rather than a skillset.
First, I'm about as technical as they come (8 years old sounds about right), so take my advice with that in mind. But I think becoming "technical" is critical to learning how to code. I don't mean you should start solving equations in your spare time. I just mean find a concrete problem that you're motivated to solve (i.e. something fun), and then solve it. Maybe you think AI is cool, so try to figure out what it tak…
Interesting approach. So how should I become technical? Let's say I'm interested in AI, I can't just think about a problem without a certain base knowledge right?