4 ms·

Hey all. Terry here — the OP. Too bad I never got to chime in at all over the weekend. A 3 month old really takes up a lot of your free time! I've definitely g

by saltcod 13y ago

Hey all. Terry here — the OP. Too bad I never got to chime in at all over the weekend. A 3 month old really takes up a lot of your free time! I've definitely got enough to justify a followup post, but in the meantime, I'll address a few quick things here: 1. You need a mentor. Couldn't agree more, and I've not been able to find one. I've tried and tried locally, but really haven't found anyone interested in this stuff (and that I've also clicked with). But I agree completely. A mentor definitely would have gotten me farther than I've gotten on my own. 2. You need a project. Also agreed. Truth is, I've never had that one thing that I was burning to get built. I don't have a cool app or startup idea in mind, and so I never set to work building something specific. The other issue was that I'm not a full-time developer. I do client work (with WordPress) in my spare time, and I'd always try to fit in some programming stuff in the middle of that. So I only ever devoted 1/2 of my free time to learning to program. This definitely isn't enough, but I can't see a way around it. There's only so many hours in the day, and I needed the client work to help pay the bills. 3. The brick wall I'm talking about is probably that one. After spending a solid month or two or three working on Ruby or Javascript projects, a client project would come along and I'd need to spend a month at that. By the time I got back to Ruby or JS, I was always starting from almost-scratch every time. 4. Learn to crawl before you walk. I definitely did this. In every language, I went through all the basics quite well. I knew all the primitives, I could write functions, I could do things with arrays, etc. ESP with Ruby and JS — by the end of my month or two, I'd actually be pretty handy with the basics. I just always felt like the next step was always waaaaaay beyond where I was. I still feel this way. Every "front-end developer" job ad now will mention Ember or Backbone or similar, and these still feel like absolute gibberish to me, despite having a good handle on the basics of JS. 5. You should work on stuff that's not for web development. I'm sure that's good, solid advice, but I don't see it fitting where I want to go. If I want to get that "front-end developer" position, it seems like I need to know Javascript inside out, but the issue I'm having is that I really am getting the "basics" but the advanced stuff (MVC stuff) feels completely bizarre to me. A few months ago, I was feeling pretty good about my JS basics, and started to go through a Backbone course. I was lost in the first 10 minutes. I went through the whole thing, but by the end I still didn't really even know _why you would want to use Backbone in the first place_. 6. Why not just learn to program for the fun of it? That's where I am now actually. I still find it fun, but really, I'm going to devote much less time to it knowing that I'll likely be unemployable as a programmer. The motivation given to you by thinking "Hey, I can get a job at this, if I get really good at it" is strong. Take that hopeful feeling away, and the motivation definitely subsides a bit. Before everyone starts saying, "You don't LOVE it then" or "You're not willing to put in the hard work", that's not true. I've put in all kinds of time and hard work already. I did it without a personal project or a mentor, so I'm not going about it the right way, but I absolutely have put in the hard work over the years. Perhaps I'm simply not cut out for it!

aeorgnoieang 13y ago
You're right that there's a big 'inferential gap' [http://wiki.lesswrong.com/wiki/Inferential_distance http://wiki.lesswrong.com/wiki/Inferential_distance] between the basics and everything else. And that's probably at least partly because everything everyone does after learning the basics and grokking everything else is embarrassing. To really understand the 'everything else', you have to face the same problems that led to those things being created. Once you've spent hours writing, and then maintaining, a bunch of boilerplate code for interfacing a database with your application's set of objects you'll understand and really appreciate what an ORM does (and also how they're necessarily limited). Once you've tried writing and maintaining an app with a large number of JavaScript files, you'll appreciate what AMD and CommonJS provide in terms of managing dependencies among those files. I also found Rails particularly difficult in fully understanding. Part of the problem is that it's intended to solve so many different problems; problems that you, and other just-beyond-basics programmers would be well served running into on your own (and trying to solve on your own too). Another part of the problem with Rails is that it is comparatively opinionated, i.e. where other tools and frameworks are relatively agnostic about a lot of somewhat-but-not-directly-related issues, Rails picks sides and you just have to live with it. And there's no way (?) to know why those sides were picked other than finding references to the historical design decisions. The other significant problem with Rails, and really every other not-dead-simple tool or framework, in any language and on any platform, is 'magic', i.e. the programming black boxes for which you don't understand how they work at all, even in principal. Luckily, this issue can be solved by you, relatively easily – just read the source! I'm serious. I remember being mystified about ActiveRecord in Rails (which, by the way, covers the 'M' in 'MVC' for Rails apps); I understood that it was acting as an ORM but I didn't get why I didn't need to tell it (via configuration files, or 'fluent' configuration code, etc.) what the columns were in each table. Then I looked under the covers and saw that it was basically just parsing the name of the attributes being accessed, and using some 'magic' in the form of code that ran when code attempted to access a not-previously-defined attribute. As for mentors, find an IRC channel with friendly programmers; then you can ask questions and get immediate feedback. I'd offer to help, but I've got a newish baby too and I don't even know if we share a timezone (or similar work schedules).

by saltcod 13y ago

aeorgnoieang 13y ago

You're right that there's a big 'inferential gap' [http://wiki.lesswrong.com/wiki/Inferential_distance http://wiki.lesswrong.com/wiki/Inferential_distance] between the basics and everything else. And that's probably at least partly because everything everyone does after learning the basics and grokking everything else is embarrassing. To really understand the 'everything else', you have to face the same problems that led to those things being created. Once you've spent hours writing, and then maintaining, a bunch of boilerplate code for interfacing a database with your application's set of objects you'll understand and really appreciate what an ORM does (and also how they're necessarily limited). Once you've tried writing and maintaining an app with a large number of JavaScript files, you'll appreciate what AMD and CommonJS provide in terms of managing dependencies among those files. I also found Rails particularly difficult in fully understanding. Part of the problem is that it's intended to solve so many different problems; problems that you, and other just-beyond-basics programmers would be well served running into on your own (and trying to solve on your own too). Another part of the problem with Rails is that it is comparatively opinionated, i.e. where other tools and frameworks are relatively agnostic about a lot of somewhat-but-not-directly-related issues, Rails picks sides and you just have to live with it. And there's no way (?) to know why those sides were picked other than finding references to the historical design decisions. The other significant problem with Rails, and really every other not-dead-simple tool or framework, in any language and on any platform, is 'magic', i.e. the programming black boxes for which you don't understand how they work at all, even in principal. Luckily, this issue can be solved by you, relatively easily – just read the source! I'm serious. I remember being mystified about ActiveRecord in Rails (which, by the way, covers the 'M' in 'MVC' for Rails apps); I understood that it was acting as an ORM but I didn't get why I didn't need to tell it (via configuration files, or 'fluent' configuration code, etc.) what the columns were in each table. Then I looked under the covers and saw that it was basically just parsing the name of the attributes being accessed, and using some 'magic' in the form of code that ran when code attempted to access a not-previously-defined attribute. As for mentors, find an IRC channel with friendly programmers; then you can ask questions and get immediate feedback. I'd offer to help, but I've got a newish baby too and I don't even know if we share a timezone (or similar work schedules).