You Sir, have basically described what a lot of 'programmers' won't admit, and that is that a lot of them also don't know what is going on.
I've come to realize that in the world of real applications, the process is less about doing everything yourself and more about just Googling that shit until you find a solution.
Heck, look at all the questions on SO that keep cropping up. They all ask these simple problems that either they've faced or someone else has too. Some guy even wrote (about why he stopped using SO) that in order to answer the questions, he'd just google the question and find the answer in some blog post. Copy/Paste and make it pretty and you'll get 600 upvotes from the thousand other Rails noobs who need that answer.
That is why, if you want to build something real, just put all the pieces of the stuff together (like how people do in Rails) and launch the product.
Better yet, just do it with WordPress too, or some site builder. At the end of the day, if you're learning for the sake of learning, you'll give your 10 000 hours of duty, but who the heck wants to live behind a computer for 10 years?
Piecing shit together should be a philosophy that is encouraged, especially in elitist programmer world where if you mention anything of this sort (like this post) you immediately become an antagonist.
If that is all you got from my 'rant', then you've missed the point of my message.
FYI, houses do fall down and pipes do burst too. Heck, if you want to go that far, let's talk about a company thats been around for a 100+ years, that is worth a couple hundred billion US dollars, that hires the best chemical, mechanical and civil engineers to build (or outsource) building an underwater pipe that bursts and floods the ocean with a black liquid that kills everything within its spill area.
The guy obviously can't seem to get the mantra of going from bottom-up (because not everyone is like that), so putting the shit together and then plugging in where problems may exist is a simple alternate strategy to feel some sense of "completion".
So until the day where the super-talented PhD folk at the big software companies can stop storing their passwords in .txt files or losing 5 million passwords on their holy-grail 140 character-limit app, then piecing things and facing a data breach simply becomes a 'cost', unless your PR firm sucks.
The purpose of Stack Exchange is for people to ask questions so that other people may answer them. At a base level, this is the purpose of all education. To impart knowledge.
It is true that some may take what they learn and "Paint by numbers", but you should not fault a community for answering questions it was built to be asked. After all, some may take what they learn and build something amazing.
The author of this article learned languages, which I suppose is the equivalent of somebody learning the technical skill of putting paint on a canvas with a brush. What he and others like him might need is for somebody to teach them how to make art, or in real terms: how to read and architect programs.
It sounds like the author became a programmer many times over, but kept slamming into his own expectations about what the process would be like.
Learning any new language is a process of continuously diminishing returns- it feels like you're moving along in leaps and bounds at first, as everything you learn is applicable to almost every program someone might write in that language, and things that looked like gibberish before start to make sense. Eventually you move past the basics and get into more specialized, esoteric, and less generally-applicable bits, and it feels like it's taking a lot more effort to learn much smaller and less widely applicable chunks of information.
This isn't even taking into account the fact that the more you learn about something, the more aware you become of how much you don't know. Two months in, you might feel less confident in your knowledge base than you did after the first month. It's just the nature of the game.
I really got the sense reading this that the author assumed that the learning process would always be linear (the ratio of effort to returns wouldn't decay as he got deeper into it), and that eventually he would reach an endpoint where he just knew everything and could build whatever he could imagine without continuing to struggle and flounder. It's not like that though. You're never done learning, you never reach a point where you can whip up nontrivial projects without at least a little bit of floundering, and you never reach a point where most real-world projects you take on don't involve learning yet more new stuff or periods of floundering and frustration and false starts while you wrestle with how to design and implement it.
It sounds like he would get to this point of diminishing returns and assume that this must be happening because he wasn't cut out to be a programmer, but really the problem was that he was assuming that things would get easier, not harder.
It doesn't help that he was so focused on web development as opposed to other types of programming- more than any other programming specialty, web development involves grab bags of seemingly random and unrelated technologies, some vastly overengineered, some comically underengineered, and none of which were really designed to be used together in the ways that people want to use them.
> "It doesn't help that he was so focused on web development as opposed to other types of programming- more than any other programming specialty, web development involves grab bags of seemingly random and unrelated technologies, some vastly overengineered, some comically underengineered, and none of which were really designed to be used together in the ways that people want to use them."
Doesn't this lead to the simple fact that the way things are built in the browser is in 1 simple word: fucked?
A lot of the passion-based fanboys have justified the existence of at least 5 different mindsets needed to flesh out a single application (eg. some web app using: Ruby with Rails, JavaScript, HTML + CSS and lets throw in the need to write a couple of bash scripts just for petes sake).
I've long been contemplating having a single-language situation or at max 2 languages to flesh out web applications (why the fuck does CSS need to exist?).
If a browser itself could be built on a core of using just one language (like C++) then I don't see why stuff that works in a browser can't be done with that same philosophy.
So now I'll have to find myself a bomb shelter and spend the next 20 years writing a web-only language to solve the pain points of some dumb shit called JavaScript that is great because Node.js is great...
>So now I'll have to find myself a bomb shelter and spend the next 20 years writing a web-only language
Eliminate the entire browser and just start distributing x64 "apps" to raw hardware sandboxed virtual machines in Bochs or another emulator. That way people could have as much pixel level control for display purposes as they wanted. Ideally you'd also have some client side OCR so that we could copy and store text from these new websites. Some sites would want to have you download megabytes of "operating systems" before. But there'd be nothing stopping you from making a raw hardware Forth website 1000 times smaller than the next guy if you so desired
you might like opa; at the very least it's worth a look. it bills itself as a "framework for javascript" but it's actually a language that lets you write frontend and back end code that mixes seamlessly
>You're never done learning, you never reach a point where you can whip up nontrivial projects without at least a little bit of floundering
I agree that you're never done learning, but you shouldn't "flounder" forever. Somewhere between 4 and 10 years you should be done floundering. :)
Sure you may need to check your API reference for specific function names and parameters, but there are very few aspects of my main languages that I don't just know without having to look them up at this point.
And that experience translates even to languages you haven't spent a lot of time learning. With less than a dozen hours of JavaScript exposure, I understood the syntax of his "OMG!" examples. It does eventually get easier.
It seems like he's giving up too soon, but he's also (seemingly) refusing to just ask questions. There must be forums where he could ask about syntax like that.
I had the same reaction, especially when I got to his paragraph about Sinatra (vs. Ruby on Rails). If Sinatra is more fun for him, more easy for him to understand, and more productive for him, why not use it to build things? It's possible to build very nice things on top of simple tools like Sinatra.
To the author, I think you should give yourself a lot more credit.
My takeaway was that the OP could not grasp MVC which caused all the issues with learning the frameworks. Also I'm a firm believer that you can't really learn unless you want to make something. If you're not trying to build a game/website/app that you're excited about then you're not going to go far.
My advice on web frameworks: Try to make a project without one. If you're where the author is -- tolerably familiar with HTML, CSS, and JS -- look up WSGI or CGI. Write a program that outputs HTML by string manipulation.
Try to build something simple, like a web forum, or maybe one of those old-fashioned "guestbooks".
Then you will be able to see the pain points that a web framework solves. For example, you'll eventually decide you want to save your forum posts to disk to make them permanent. You make some format which you can just use read() and write().
If you've gone through the pain of doing this, when you go on to read about databases, you won't say "WTF this is overwhelming and irrelevant," you'll say "AHA this makes so much sense -- I know exactly what problem this is trying to solve -- because I've already spent dozens of hours solving that exact problem!"
MVC got you down? Well, if you started out with a basic web forum software that only allowed login, posting, and viewing, then updated it to include user profiles and avatars, my guess is that when writing the update you would have encountered frustrations due to poorly organized code. So when you later read about MVC, you say "AHA! I understand exactly what this is for -- because when I had to make major changes to a codebase that was already fairly large and complex, I had lots of pain, and came up with a laundry-list of ways new code should be better-organized to avoid similar pain in the future -- and MVC looks awfully similar to that list!"
I have been programming for over 40 years, have a PhD in computer science, and I'm comfortable in many languages and in picking up new ones. And yet I can relate to what he wrote. In the 90s, I decided to try and become productive with Microsoft's C++ environment for building GUIs, and it was just a long, long list of seemingly arbitrary steps. Couldn't get it. Or at least not without studying mountains of Microsoft literature to learn lower layers, (COM maybe?), which I wasn't willing to do.
I think this guy has two problems.
1) He doesn't know the fundamentals.
2) He doesn't have a project, and so is not directed. Lacking direction, he meanders. With direction, you learn just what you need to do your job. But you learn something and can expand from there.
Addressing at least one of those problems might have got him unstuck.
#2 is a bigger problem, in my opinion. it takes a very, very special kind of person to just do textbook exercises or silly pointless mini-projects until they have an expert knowledge of a language.
most smart people, on the other hand, can build a specific something if they are determined enough, fundamentals be damned.
> Rails isn’t just a brick wall, it’s a brick mountain... By the end of the first month, I had literally no idea what was going on.
This is not a brick wall. It's giving up as soon as something gets hard.
Rails is a great example. It has so much behind-the-scenes "magic" that it's really hard to wrap your mind around at first. Back when I was first learning it, my brain felt like it had been filled with cement at the end of every day. I didn't understand it for weeks; I felt like I was just pounding my head on a brick wall over and over. Then, all of a sudden, the fog suddenly parted and it was like being set free. After that, I never had another Rails problem that I couldn't handle.
Everyone that I've ever talked to that has learned Rails - or any other language - has struggled through this initial pain period. The difference is that the successful ones push through it after it stops being fun.
It doesn't only apply to programming either. Everything you ever learn starts with a "brick wall" that you think you'll never get past. Once you suck it up and break through it, you may find that the road is clear from there.
There is no programmer so intelligent and so experienced that there does not exist a framework which makes no damn sense to them.
I think I'm a decent programmer but the scope and complexity of Rails (especially with all the great concepts and practices Hartl introduces simultaneously) is daunting at first. But you just have to keep at it and it eventually clicks. I think I did his tutorial 3 times from scratch before I really started to understand what was going on, and it wasn't until I tried to make a large and complex app that all the features and beautiful organization of Rails began to feel natural. Rails (or Ruby, or any other insanely powerful tool) just takes a long time to really grok, and even longer to master. Smart people are used to getting things quicker than that and that is what makes all of these things so emotionally painful. Our projects don't work and our egos suffer as well.
Exactly. The smart people ego thing. Yikes, that's me. Programming is humbling the shit out of me. It really is a good process.
Just slow down, be patient, expect many failures and false starts. Hell, if I can do this, it seems like I'll be better prepared for all sorts of challenges in life.
What I'm mostly seeing here is a lot of 'small' projects, hobby things - what I think the OP needs is a project. Work with a team on a product or project, and stick with it for a couple years. Work with a single project / codebase for months on end, instead of the one-off things done so far. That kinda thing.
Convoluted comparison, but, you can teach a man to fish, but unless he goes to fish it won't lead to anything.
I came here to post this very thing. Unless you have something real to work on learning a language, framework, or tool is not going to be rewarding. A programming language is a means to an end; that should never be forgotten.
I love learning new platforms but I know from experience that I have to have a real meaningful project to work on. I have thrown in the towel a few times myself and I've been programming for decades.
I'm inclined to agree with both your sentiment and analogy.
I only really know Objective-C, but from my somewhat limited position, the turning point for me came when I stopped trying to learn Obj-C by reading, and instead fully committed myself to functional, shippable products.
However, I still run to SO at the sight of a slightly complex issue!
I bet trying some native development would help as well, especially inside a well-structured framework. I learned so much about architecture and design patterns when I was trying to figure out how to do iOS development a few years ago.
He doesn't mention why he was trying to learn any of these languages. Just to learn them? Yeah, I dabble in human languages that way, just out of curiosity. Nope, that hasn't made me fluent. I know a bit of conversational German because I lived in Germany and I have German relatives plus studied it on my own a smidgeon. I actually took classes in French, my second strongest foreign language. I know a few words of this, that and the other (Greek, Russian, Spanish...possibly others) but having not taken more than a couple of classes in anything else and having not lived any place else where I could consistently use those languages, nope, I have not become fluent. It has nothing to do with whether or not there are good materials available to learn them.
So, other than "learn to program," what was his goal? He does not appear to have had a real, tangible goal. This is likely the problem. What little (self taught) html and css I know is from working on my own websites and following some lessons in books and on CDs and looking stuff up online. I moved away from hand coding my sites but knowing some html still comes in handy at times. So while I am not very fluent, I do still get use out of it. Thus I don't have some sense of "failure" in this regard because it served the purpose that was intended and has remained useful in other ways that I wasn't specifically looking for.
So, the big common problem I saw there--and one I'm going to probably get flamed for here?
Author seems to be looking at just Web tech. As Uncle Bob said, the web is the worst thing to happen to our industry in 30 years.
Had the author started with C or (gasp) assembly, I wager they would be a little less lost, and would have more solid footing--oh, bytes go in here, we do things to them, that gets put into a hash map, that's a decoded HTTP header. No magic.
The problem with that though is that it takes a long time and it can be quite a while before you've built something with the same whiz-bang-golly-gee as even a stupid ten-liner in jQuery.
Also, despite their mention, the author didn't elaborate on either Java or Objective-C (or, for that matter, perl).
Before you throw in the towel on becoming a programmer, maybe you should make sure you're not just giving up on being a script kiddie.
^^ that. I just posted a similar thought. I'm a full-stack web dev, too. Web poo is easy when you already know a lot about programming. I would hate to have started here, however.
A sad story, but easily explained -- there are books meant to teach you how to read, and there are books meant to be read, for entertainment, education, or inspiration.
The author obviously didn't approach programming in the way people approach reading -- small steps first, letters, then words, then sentences, then ideas. And finally, after mastering reading, one can try writing one's own ideas.
It's not self-evident how to do this in the programming world, because unlike the world of books, programming is a relatively new discipline. But, just as with reading, there are small programming steps, and there's a distinction between reading and writing. One must be a skilled reader before presuming to write.
This will be easier in the future as programming matures, and when being able to program comes to be seen as print literacy is seen now -- a default ability in an educated person.
I also think he's overestimating the degree to which all programmers, even good ones, can understand someone else's code easily. In fact, most of the effort being put into understanding how to code properly is meant to make it easy for other programmers to be able to read someone else's code and know what's going on, simply because it's extremely hard to do as things currently stand.
Why is it a best practice to write functions that only do one thing? Because as soon as the function is doing multiple things, it can get very very confusing as to what exactly is going on, even for the best programmers.
> In fact, most of the effort being put into understanding how to code properly is meant to make it easy for other programmers to be able to read someone else's code and know what's going on, simply because it's extremely hard to do as things currently stand.
Yes, and in that connection I want to mention narcissism, which I personally think is a big obstacle standing in the way of collaborative programming, in the way of seeing one's code as community property that must be understood by everyone involved.
Narcissists, more numerous than most people realize, think their code is much better than code created by ordinary people, to the degree that they see no point in making it comprehensible to mere mortals. Also, consistent with the true nature of narcissists, they're secretly insecure about themselves and their abilities, which is the real motive for making their code incomprehensible -- to do otherwise might reveal how perfectly ordinary their code really is, and they really are.
> Why is it a best practice to write functions that only do one thing? Because as soon as the function is doing multiple things, it can get very very confusing as to what exactly is going on, even for the best programmers.
That's a good argument in favor of OO programming, where one writes a class instead of a mere function, thus avoiding the trap of trying to create multi-purpose functions.
> That's a good argument in favor of OO programming, where one writes a class instead of a mere function, thus avoiding the trap of trying to create multi-purpose functions.
I disagree there (that "That's a good argument in favor of OO programming"). What if one creates a multi-purpose class? How is that any better than a multi-purpose function?
IMHO the point -- do one thing -- is applicable to many paradigms.
> What if one creates a multi-purpose class? How is that any better than a multi-purpose function?
Easily answered -- look at a class meant to deal with String objects. It encapsulates a string object plus any number of functions that deal with strings. Compare this to a function that does to a string what a class does, but necessarily under the command of a passed flag that instructs it which action to take. The latter is much less satisfactory from a comprehensibility standpoint.
I say this because I was programming before there were classes, or anything resembling high-level structure (I wrote Apple Writer in assembly language, a language utterly lacking in structure: http://en.wikipedia.org/wiki/Apple_Writer), so I've watched a number of revolutions in programming over the decades. The idea of a class associating a data type and functions meant to deal with it seemed to me to solve any number of problems -- problems I had to deal with in various clunky ways before that development.
> I disagree there (that "That's a good argument in favor of OO programming").
But it is. The idea that all functions having any special meaning to (for example) strings would be enclosed within an object also containing the string to be operated on, greatly reduced the confusion that preceded it. One can make too much out of the OO paradigm, but the basic idea is sound and based on pragmatic thinking.
I'd like to clarify my point -- I'm not arguing against OOP or for another paradigm. What I'm saying is that "do one thing" transcends paradigm. And in fact, its OOP incarnation is known as the single responsibility principle (http://en.wikipedia.org/wiki/Single_responsibility_principle). So when I say that "I disagree that 'do one thing' is an argument in favor of OO programming", what I'm saying is that "do one thing" is important, no matter which paradigm you choose. Neither OOP's strengths and weaknesses nor how it compares to any other paradigm are relevant to my point.
I'm sorry, but saying things like but it is and the basic idea is sound and based on pragmatic thinking without a supporting argument is unconvincing.
Behind the scenes using a method of an object is just syntactic sugar for calling a function with the object as the first argument. The modularity aspect is good but I think OO often leads to code that is difficult to read when there are many levels of inheritance, esp. in languages where you are forced to put everything in classes such as Java. Instead of the old spaghetti code you then get ravioli code: http://en.wikipedia.org/wiki/Ravioli_code#Ravioli_code
To me, one of the advantages of objects is that I can tune the object's functions and data structures to get the behavior I want, then while working at a different level of abstraction, I only need to remember the object's interface, not its internals, which makes it easier to use its abilities in a consistent way.
I agree with this advantage, that's what I meant with "the modularity aspect"; a non-OO programming language with support for modules also offers this. However, as soon as you get to non-trivial and often gratuitous inheritance hierarchies, it gets in the way of at least readability and probably also maintainability. Example: instead of String, you get AbstractMutableStringOfWesternCharacters, all the way to ArrayBasedStringOfASCII and everything in between. Suddenly to understand one function, you have to read and understand n classes, because they are part of the inheritance chain.
Some programmers may be narcissists, sure. But I think the big obstacle standing in the way of collaborative programming is having to be aware of too much other code in the first place.
It's very hard to read code, because code isn't linear--it's more like de-serializing a graph in your head, and so it takes somewhere between O(n log n) and O(n^2) to fully grok a codebase of size N. So we should limit N as much as possible.
Now, as programmers, we theoretically know how to limit N just fine. We can still make programs as big as we like, but as long as there's low coupling between the components making up those programs, each component can be separated into its own codebase. Each component exports a documented API, each other component consumes those APIs, treating their dependent components as black boxes. This is well-known stuff.
But despite "decrease coupling!" being one of the first things pounded into most programmers in Introduction to Blub courses since the 70s, coupling is still way too high, and codebases far too large as a result. Low coupling, when dressed up in terms like "Service-oriented architecture" or "the Unix philosophy", is seen as mystifying and novel to most programming journeymen, like some sort of weird Eastern religion. This probably means that, despite learning what coupling is and being able to recite that definition in a sort of cargo-cult manner, they never really viscerally absorbed what coupling does, the pain it causes, or how to lower it[1].
You shouldn't have to dive into a codebase big enough to drown yourself in. Codebases shouldn't be that big. Each codebase should be more like a little puddle, maintained by a few people (or even just one narcissistic person!), which is small enough that, if someone gets hit by a bus (or gets annoyed with the narcissist), it's both able to be read in one sitting, or able to be re-written from scratch in one sprint.
Effectively, this creates a "bus factor" of infinity: if any component is small enough that it can be learned, or recreated, then the original programmer is unnecessary to that component's upkeep. Because, sort of like an EC2 instance, the component is just as likely to be created anew, as it is to be "closed" and then "opened" again.
---
[1] I imagine that you could imbue such knowledge with a single assignment to the effect of:
* We'll be working with three already-written programs, Foo, Bar, and Baz. They're each available in source-control on Github.
* Foo is componentized already, so it's split into five codebases. You can clone the main one, then run `git submodule update` to get the rest.
* Bar and Baz, meanwhile, are big monolithic codebases. Just clone the whole mess.
1. On each of the original projects, two open bugs is listed in the issues. Fix the first bug in your fork.
2. Now, refactor your fork of Bar into componentized form. Copy the submodule approach of Foo.
3. Now fix the second bug listed on each of the projects' issue-trackers.
Exactly, code should be read like you would a math theorem, one symbol at a time. It's not a sentence where you read character after character and at the end of the line you know what those words mean. Every symbol has a deep meaning and expresses more than you probably think. In the same way, when you read a mathematical demonstration if you don't really stop and think about every single symbol you won't get the reasoning behind the whole thing.
> small steps first, letters, then words, then sentences, then ideas. And finally, after mastering reading, one can try writing one's own ideas.
Just a nitpick. You say one should first master reading, then master writing. But I think both go together; I would just reverse the logical order of the two concepts (small steps and reading-then-writing):
- read letters
- write letters
- read words
- write words
- read sentences
- write sentences
- read ideas
- write ideas
Of course, it is not a fixed frame either, but it gives the main idea.
>One must be a skilled reader before presuming to write.
I disagree, somewhat. I think one cannot become a skilled code-reader without knowing how to write code. One cannot be a skilled code-writer without knowing how to read code, and having read a lot of code, but without having written any code, I don't think reading code provides any enlightenment.
My small-steps progression would be writing Hello World, writing a smallish program, learning how to read code, writing code that you have to maintain, becoming skillful at reading code, becoming skillful at writing code.
I agree with you on natural language, that one must be a skilled reader before writing. I think the reason I see a difference between code and natural language is that the baby-steps of writing code can be mapped onto speaking natural language. I don't think one could become a skilled reader before being a proficient speaker in one's native tongue.
> One cannot be a skilled code-writer without knowing how to read code, and having read a lot of code, but without having written any code, I don't think reading code provides any enlightenment.
You make some good points, but as just one counterexample, the famed distorting effect of BASIC on a beginning programmer is certainly made worse by allowing the student to write BASIC as well as read it. As to, say, Python, I guess this is less of an issue, and writing a bit of Python just to see what happens probably has a beneficial effect on comprehension.
But, granted that point, I think reading and understanding the code of skilled programmers, before trying to write any significant code, is a very good idea. Otherwise one risks becoming trapped in classic beginner errors like laboriously processing individual data elements instead of looping through a list of them with one processing function (an error I saw any number of times while teaching programming).
C or ASM? You do realise on this site those languages dont exist, only Ruby, Haskell, Bracket-o-lisp variants, Go, Rust, and any other brogrammer ready shiny shiny. I didnt forget to add JS to the list - i dont really consider it a language, just a bad artifact of the web wars that sadly lived on.
This is utterly counter to my experience, both in metaphor and reality. In terms of reading/writing, trying to write poetry and stories has given me huge insights into the work of others. My poems are dreadful, my stories silly, but I've learned what makes others so talented.
In programming, writing is first, reading second. Creating good code is something that is learned through work. Reading and judging other peoples code requires great insight and sympathy; criticising something is easy. Understanding that they could have done it differently but chose not to for some very good reason is harder by far.
Well, this is obviously a matter of opinion, not science, but I think one would do well to read (examples) Hemingway or Clemens (a.k.a. Twain) before presuming to write something meant to be read by others.
> My poems are dreadful, my stories silly, but I've learned what makes others so talented.
I think one could learn skilled writing more quickly by reading than by writing, and without the esteem-crushing experience of seeing how badly one's own early experiments fall short. I emphasize that I'm talking about having an unrealistic expectation that one's own early writing serves as anything but an exercise to be quickly discarded -- referring to both programming and prose.
It's easy for programmers to forget how hard some of the earlier concepts were, even if we are good teachers and communicators. My wife has gotten motivated to learn Ruby on Rails (having never been a programmer before), and it's been a really valuable experience witnessing someone trying to understand almost all of the concepts from scratch. Just trying to describe what git does is almost impossible without somehow comparing it to saving a word document. The other day I had to clarify that typing something "into Sublime" doesn't mean it's only in Sublime - that Sublime is actually a view ("but I thought you said a view was a template!") into the same files and folders that are in her terminal. And the thing about how you can push to both heroku and github, but not check out or clone from heroku, that's still confusing. But she was deliriously happy when she figured out how to add a scaffold and add a link to the "create" functionality from the header, all by herself.
When I look at the examples that the author pasted, it seems like the commonality is that they all go more than a couple layers deep. Sometimes asking "why" twice is enough, but sometimes you have to go a few layers deep (like understanding PDO's connection flags when all you want to do is get a user's first name out of a database). I don't think that's so much about ability or smartness, as it is patience, and what layer of thinking you'd rather hang out in. Although, like other commenters have said, some good refactoring can help a programmer from having to need to understand those lower levels if they're not relevant to what you're presently working on.
I strongly dislike those books. I think LPTHW is perhaps good if you already know programming. Otherwise, he's just trying to get you stuck. Not what you need when you're already barely hanging on.
I also HATE how arrogant he is on the web. I dislike him as a person and thus can't bother with his classes.
I'm sorry you strongly dislike those books. I think they're quite good. I can't imagine why you would say he is "trying to get you stuck". Do you have a specific example?
I have taught zero-experience, low-aptitude beginners for nearly two decades, and his approach is basically exactly what I do with my own students.
This demonstrates the problem if our education material focused so heavily on micro problems and so little on the next step of building a (non-trivial) app.
If you want to learn programming I recommend having a project in mind. Learn a little bit and get to hacking on the app. Don't worry if the code is good or not.
I broke through that barrier by just building my own framework.
By the time I stopped, it was still grossly under featured compared to real FW's, but I figured out how to write an MVC framework with some of the niceties like URL routing, helper functions, validation harnesses, etc. The other part was building a websocket server in PHP, because the concept of something depending on Guzzle and parts of Symfony2 just struck me an insane for something like a standalone daemon.
Those two projects dumped me face first into the internals of a framework, and then into the nastiness of protocol implementation (hybi-17) in PHP. After that came PHP daemons for the AWS SDK, learning how to make shared memory segments work with different processes, etc. Once the floodgates are open, there is no stopping.
Even if we rewrote a lot of the education material to an ideal, there's still a huge leap from hobbyist to employment that I don't think is well covered.
My problem is that I believed employment would be within reach after teaching myself for a year.
> My problem is that I believed employment would be within reach after teaching myself for a year.
I was doing paid work within a year of learning PHP. It wasn't good work, but it was work.
The problem is that people want to go from 'learning programming' to 'building Facebook from scratch' - that's why the OP is having problems, when you compare your work to Wordpress, of course your work is going to come up short when you're new.
An analogy to carpentry: nobody expects a novice carpenter to make an entire set of kitchen cabinets from scratch and have them all fit and function correctly, or build a timber-framed barn.
But you certainly would expect a novice to be able to build you a crate or knock together a stool, shim a squeaky table leg, or make you a cutting board.
The equivalent paid work I was doing was along those lines - tweak this so that the tax calculation is updated, change the pricing structure to add a 10% surcharge if the order is over X pounds, those kinds of things.
This comment makes me realize how extremely lucky I was when I started learning to Program:
I had a friend working for a local medical company; they wanted to robo-call patients and remind them of appointments. They couldn't afford the existing $300,000 + $50,000 solution they were considering, and he told me if I could come up with something they would pay me $10,000. I had done some simple C++ programming in high school and knew I was good enough at programming, so I quit my job at HomeDepot and became an aspiring programming with a goal -- in my moms basement.
I read about Asterisk (open source phone software), then about PHP (which didn't excite me), then about Python. I liked Python. I read the 1200 page "Learning Python" book, but I learned most from the Python chat room on freenode IRC. They were harsh but helpful: "you're code sucks" and "use twisted" and "read this".
I manged to piece something together in 6 months and got the $10,000. From there, I got a entry level job, then job hopped for a 250% pay increase, then job hopped once more for another small pay increase, and now I'm here.
I think most people don't get offer a free contract and a goal to work towards before they even start.
What is not clear to me is what the author has been doing for a living during these last few years. I can remember getting started doing web development way back in the Perl/CGI days, before JavaScript libraries and massive web frameworks were common, and I can remember getting overwhelmed even then. I can remember trying to learn OO first in Perl and quitting before coming back to it from another language a year later.
Point is, programming is hard, but to me "being a programmer" means being a programmer as a job, where a) you have to solve problems for a living and b) you don't get to quit.
Where I feel the author is screwing herself is the endless stream of tutorials, coupled with drinking from the firehose. The language and the frameworks are two different problems that must be tackled, I think, in two different ways. For example, when learning to code for iOS, it's not Objective-C that gets you, it's the new environment, frameworks and libraries. However, you don't get to quit and say, "I could have done this in Wordpress."
I'm rambling. Point? Get a job as a programmer, paint yourself into that corner and stay there. It has been said earlier, and I agree: commit to one language/framework. Learn it really well. THEN, and this is after 5 years or so, language hop all you want with a more robust understanding of programming in general.
It seems a little disappointing that the author had such a bad experience with Python.
The Django tutorial is a 10x faster and more useful introduction than Hartl's Rails tutorial if you want to spend a night or two learning the basics and then toss together a crude blog over the weekend. Even better you barely need to know any Python to do it, either.
(I'm not saying Hartl's Rails tutorial is bad, it's just going to take most people weeks and even then various pieces of it, like authentication/login, won't even be applicable to an actual app. Someone should make a rails tutorial that's all about making something quickly with commonly used components and less about the kitchen sink.)
(I'm also saying this as someone currently developing rails apps.)
I definitely didn't have a bad experience with Python. I didn't really spend much time with it. But by the time I got to Python, I'd used Ruby a fair bit, and it just didn't feel as comfortable. Maybe things would have worked out differently if I'd started with Python?
Hey man, where you are now is where I've been a million times before. I've spent almost a decade trying to properly learn programming, jumping from tutorial to book to language to online course. I'm trying it again, but this time with a different attitude because of a very important life lesson I've learned recently: Every thing, every single thing worth attaining will always require a degree of pain that you can't do anything about but push through. I'd see all these hackers launching startups, side projects, really neat tools, and I'd always think about how much fun they must be having. I never saw the hours and hours of frustration these guys had to endure in the past to develop their skill sets and now to get their products out the door. So I'd go through tutorials and have fun because they were easy and weren't pushing me hard enough. The second I'd hit a wall, and stopped enjoying myself, I'd quit. I had wrongly assumed that the learning process was just always supposed to be fun. That's not the case. So maybe try readjusting your expectations and try again.
I think a big problem is using web technologies to learn to code. They're used because they're "simple," but that's kind of relative. It's simple when you already have a good CS foundation. When I started in CS, I wouldn't have understood a lot of javascript framework code samples either.
There's something to be said for going through the boring stuff: data structures, algorithms, OO concepts, threads, etc. You know, the equivalent of a first-year in a CS program. Without that foundation it seems to easy to become a code monkey who just copies, pastes and types without really knowing what is happening.
Or just throwing in the towel because it never makes sense.
disclaimer, I've never actually taught programming so this is my own opinion
Start with BASIC, yes totally 30 years old and unsexy.
Learn the primitives. Baby steps
Variables, control flow, looping, conditions, functions, data structures (start with arrays, then go to 2d arrays and parallel arrays)
Then go to reading and writing files etc etc
Do NOT move on to the next thing until you have a complete understanding of the previous. DO NOT JUMP TO FUCKING RAILS UNTIL YOU HAVE A COMPLETE UNDERSTANDING OF 100% Of THE ABOVE AND CAN GET ALL THOSE PRIMITIVES WORKING TOGETHER TO SOLVE ANY PROBLEM.
So then take your .bsc files and rewrite them in a sexy language say ruby or python.
The problem is that, without an adequate foundation, he's jumping into frameworks and web development, where you have lots of interacting parts, all of which must be understood.
He's jumping directly from toy examples for someone learning a language to "industrial scale" development of e.g. full-blown web applications.
My suggestion would be to try to come up with a project which stays within the bounds of a single technology and doesn't require frameworks.
This will probably mean something that's not web-based.
Yes I'm agree, if you switch too often you are not only learning how to code, you also learning a new language, is like going to duolingo and try to learn french in english and you don't even know english.
I liked this. Programming is not easy and it's not always pleasurable, people should be open about it(maybe?).
As a more programmer-programmer, what sucks, to me, is that I can't play anymore. Since I code professionally I find it really tough to keep on programming like 100% of the time I'm awake. Really, after 8 hours stressing and trying to deliver it feels like my brain is dry and can't take more, then surely I get the feelings of "isn't there more to life?"
I guess if I worked 6 hrs/day I'd probably be a happier and better programmer. It is a strenuous activity, when I get to it after a day of work, lets say 1,5 hours to two hours of doing stuff in my spare time, generally it's not enough to finish anything, or learn something to "I'm satisfied with this" level(I also gave up on backbone)
For example, I've already gone through a book on Android programming besides plenty of articles and plus messing around .. But in trying to build some useless shit just to develop it, in two hours I'll barely have anything new ready that I'm proud of, mostly no progress at all(Java btw), if the useless shit doesn't get done, it puts me off of doing the really cool shit I'd really like to do, there's not enough time in life to play with code and work with it and it gets me bummed, I'm 26 and I'm no longer at the "no really, programming is the coolest thing possible!" phase, I have other interests like reading, music, women, beer, videogames(basically given up on this already), soccer(my legs are not strong enough anymore, so, halted), drawing(seeming like a better escape for creativity than programming nowadays), hanging out with friends... I don't honestly don't know to do about this, I guess I wish I could do whatever I want... ;/
I think OP should start to learn computer science and not just programming languages and frameworks to truly understand the major concepts that he's wrestling with. There are good books and online videos on object-oriented design that would probably be a good place to start.
There does seem to be a gap in programming education. Synthesis.
Are there any resources that take someone from knowing the syntax of a language and into gradually larger and more complex projects? Not step-by-step walk-throughs but actually evaluating the all-important steps of knowing what to do in the first place and putting the individual pieces in place as needed? Synthesis?
I've seem plenty of tutorials on putting together a large project, but they are all step by step. They cover 'what' and the 'how' but are universally missing the 'why'. And without the 'why' a student does not know what to do when confronted with a problem.
The first mistake is thinking that all existing code out there makes sense and is written by people who actually know what they are doing. It doesn't, it isn't, it's mostly shitty.
An app is constructed from various building blocks. As you gain experience, you learn to recognise what building blocks are required, and you can tackle an 'app', one block at a time.
A challenge for new programmers is being able to deconstruct a 'build "x" app' type problem into these building blocks, even just recognizing that they exist. The lure of web frameworks such as Rails is they roll a lot of these building blocks into one, making it harder to see the edges. Compare this to a basic PHP-based, database-backed app, where you can clearly see you'll need a web server, php code, a database server, and html/js.
It takes time and patience to work through all the different building blocks to create a basic application. It's a lot of domain-specific knowledge to learn. That there's no "one true path" makes it even harder for a new programmer to wade through all the web development approaches available to them. Rails, NodeJS, PHP?
Newbie programmers need to seek advice from experienced developers who can recommend a straightforward, pragmatic approach for web development. Choosing what to try based on what's posted on sites like HN will steer them down the wrong path. Newbies need simple, boring web development guidance that will let them build and learn at a small scale. Where they go next is up to them.
Something common among all of his experiences is that he never seemed to have done projects FOR HIMSELF. Reading books and completing tutorials and examples does gives an introduction, but if you don't have a goal, something that motivates you, it's like learning how to drive by making laps in a parking lot. Sure you'll know how to push the gas pedal and turn the steering wheel. You'll even learn how to brake, but it is utterly boring and shows very little on real life driving.
My first personal projects where about downloading... files from irc networks and finding words for online scrabble games and little things like that. It allows you to make mistakes and get into design troubles. You learn what is nice with a GUI and how it eventually sucks to have spaghetti code. It is a real problem, not just a a spooky thing you read about in programming books. Examples and tutorials do not allow for that. They automatically guide you to the right choices with or without reason, but you will not have experienced the failures of the wrong choices and their implications. But most of all, I kept hacking those projects because they interested me deeply. I wanted those "files" and I wanted to best everyone with a fast scrabble solver.
These days, the only reason I read tutorials like these is when I have chosen the language I need for a project to use but don't have enough knowledge on how to use it and never the other way around. Find a goal first, then worry about the journey, even if "it is about the journey", otherwise you'll be making laps in a parking lot and eventually give up.
You are right. To summarize he needed to: 1) solve a specific problem. 2) Use a specific language, and 3) be passionate about it. If you remove any of those 3 you end up with failure.
What he talks about is about learning languages. He says he has gone through seven languages in the past 5-10 years.
School lays a deep foundation for programming. I went back to school to get a CS Bachelors. I took a mathematics course that covered graph theory. In the next class I learned data structures like trees, graphs etc. Another class explained big O notation. Then we learned various algorithms that could tackle things like the eight queens problem, sorting, or using Dijkstra's algorithm on a graph. We saw how different sorting techniques and algorithms had different big O times. We saw how data structures and algorithms interact.
All of this is programming, but all of it could be done with a minimal knowledge of a language such as Java. Learning to program is about more then the learning the ins and outs of a language.
It seems a common misconception to people new to programming that knowing the syntax and keywords of a language is what programming is about. Good CS programs give you an underlying intellectual framework of what you are doing. Most people on their own do not have the discipline to study what is needed. I spent hours studying the theory of computation and the Ackermann function and the halting function and so forth. Most people on their own who have a choice between studying that hard theoretical stuff for months or working on their new game are going to work on their new game.
Also, you don't know you don't know. For example, I had to come up with a hash function recently and was at a loss of what to do. Then it struck me to use Gödel numbers, which I had learned about years before. It worked well (although I barely made it into 32 bits). I would have never thought of that without going to school. Solutions occur to you that never would have without the education.
The OP has "dabbled", he hasn't committed himself to a single language nor a good regimen/project to succeed. Let's look at this quote:
"On top of that, there’s a constant din of “Python’s not for you, it’s for them ({scientists, academics, hackers, statisticians, someone else})” out there if you look up stuff about Python."
Really? Sounds like a bad excuse to me. There's a fuck-ton of tutorials and books for Python beginners of all ages and backgrounds. It's one of the few languages I recommend to newbies for that reason, beside the fact it's easy to be productive in. We have a full spectrum of users at local meetups and I chat with the scientist and tutor the beginners. Python users are diverse as a crowd at a state fair.
And coding isn't programming. There's a lot more to know than the syntax of a few languages and APIs. It's a whole universe to explore and learn how to control and leverage. You can find a cool project, then drop down the rabbit hole the rest of your life, enjoying the beauty...
Webmachine has a tiny codebase and clean code that you can read completely and understand in a few sittings, gives you trivally simple output and routing, and lacks opinion. Also, the combination of it and Erlang eliminate the harsh separation of RAM and disk that is a fact of life with single threaded, instance-per-request architectures.
Nothing you couldn't do in Node.js, but less fragile - and message passing over callbacks any day.
Just making my pitch to anyone in the same situation:)
Learn to crawl before trying to walk. Build a website with just html first. Feel the pain of copy-pasting html, having to edit 20 files to change a menu item. Then try applying PHP or Ruby to fix this. How would you do it? Maybe just an include/require statement would do. Then try to add dynamic stuff and forms. Would you mix sql, php and html or would you try to separate them? How about making a simple query builder?
Do you want to define your data constraints in the sql database, add cascades and foreign keys, write procedures? Or, wouldn't touch sql with a 10-foot pole, so you wrap it in some nice code and call it "active record".
Stay away from wordpress, drupal and most other php stuff, you will learn only bad practices. Think about it, PHP people were still sucking on sql injections when Rails came out.
As a someone leaving the beginner stages I can greatly sympathize with feeling overwhelmed with so much to learn and people so far ahead. What I have found, as others as have said, is to get a project in mind and work with other people. Coding in isolation, especially as a beginner, is usually a losing strategy unless you are extremely determined and pick things up quickly.
I signed up for two courses on Thinkful.com and went to it in view of building the MVP for my startup. It has been a blast! And I feel I've really learned and at only 20, I know I can become a developer. I really encourage projects and mentors. They save.
Ok, towel not thrown yet, so perhaps there is still some interest. In this case I would advise to step up to the next level. Basically what you've learned so far, is the BASIC that is advised below.
Instead I would advise you to read sicp and watch the video lectures. This will teach you about abstractions, and how to think about programs at a higher level.
This won't remove the difficulties with the kind of code you've shown: a lot of programmers don't get it, and write horrible, unabstracted, code. But at least it will allow you to recognize the problem, and to avoid or solve it yourself.
I completely agree with the author and I would like to add my opinion to it as well.
As a computer science graduate, I had formal training (as in courses) at all essential levels of dealing with computer, from hardware to assembly language to high-level languages. and even the theory of computation.
After years of having formal training and hands on experience, I finally stopped doing any programming for fun and just stick to my day job and hate every minute of it. BTW, I have to work with worst programming language ever made by mankind: C++ (that is a statement, not a challenge dear professor Strostrup).
Why? because making anything useful takes toooooo much time even for an expert. For example, I had SQLite database full of text and wanted to format it as PDF. I was expecting to do it in like 10-20 lines of script, and it took me almost a week to do it. Every simple idea that I have ends up being hundreds of lines of code with complicated logic. It is just not worth the time. I ended up using Microsoft Word to generate my PDFs instead of writing a script, although I have to convert every document manually by clicking through MS Word.
One of the main issue is that programming is stuck in the 80s, especially for Mac and Open Source developers. Everything has to be done through the terminal. We have to look at walls of code for simple things. And every programmer have to start in terminal. When I started programming in 1997, I used QBASIC IDE in the terminal. One of the first things I learned was stepping through my code and examining variables.
The second main issue is that because the programming is stuck in the 80s and the times of POSIX standard, all systems have diverged to the point that very little functionality is provided by the system to the developer.
The third issue is the programming language itself. It does not have to be ASCII based. It can be visual. There are thousands of experiments with it and yet, still the mainstream programming is still ASCII based and the hot topic of debate in programming languages is whether to be indent-based or use curly braces.
Almost all of the main stream languages on top of the charts today are created before 2000. We need more languages suited to today's software patterns.
First of all, being a good programmer is helped by a good foundation of CS/Math/etc.
It's not necessary, but it helps, it gives you confidence to think that the code is just a means to an end, the logical problem you already solved in your head.
If you know algorithms and data structures, have a decent understanding about computer hardware, networks, databases and all that stuff, then programming is much easier.
As far as languages go, the JavaScript snippets just show that JavaScript can be utterly horrible at times.
I'm not a JS programmer, but doesn't that function do almost nothing? It just decides to use AMD, CommonJS, or "browser global" to do the same, trivial thing.
The most fun I ever had learning a language was learning Lua through developing addons for World of Warcraft. It's an interesting dynamic I haven't found outside game modding.
A lot of people get into desktop programming through modding. They learn C/C++, Java, etc. However web languages can't be trained through game modding.. most web games are closed source and not moddable, nor foster modding communities or open APIs.
Nice read. When I read the title, I definitely didn't expect his reason to be that everything is easier in Wordpress. The part with the Javascript code snippet had me laughing, too.
Ironically, he sounds to me like he'd make a good programmer, because he took the time to learn his chosen tech in detail.
Telling myself I wouldn't "be a programmer" helped me learn to program competently. Counter-intuitive, but it meant I wasn't focused on following so many darn tutorials and APIs and frameworks and could just look at the raw building blocks and come to grips with them.
I'm 36 and I have been programming since I was 8. I'm not a genius but I have above average intelligence and I am a decent programmer. My interpretation is that Terry Sutton actually is a good programmer who has more common sense than the average programmer.
Practically speaking, it _is_ easier to do most things in WordPress, because there are plugins with nice user interfaces for a large portion of ordinary web application requirements.
This is an interesting article because Terry's journey and conclusions, for me, are actually a good indication of the direction that software development is going and what the new definition of a good "programmer" will be.
And the article hints at a very significant problem in software development today: the fact that the definition of "programmer" or "software engineer" is very much tied in with producing and consuming cryptic and complex ASCII-based source code. In fact, for many, (although not all), the ability to identify as a programmer is based on how far removed the implementation is from ordinary language, interactions, or business requirements. Or simply how difficult the implementation is to produce.
As more and more interactive graphical tools, powerful and yet easier-to-use and understand programming languages, better adoption of componentization (for example in the web space), adoption of knowledge representation as a basis of language/systems frameworks/protocols as well as projection editing, coding-by-example and coding assisted by artificial general intelligence, become popular and mainstream (for example, with the vast catalog of WordPress plugins, widgets, and themes available, it should be possible to build an AI system (user-directed incremental interactive narrow AI, not strong AI) that can handle about 70% of web application requirements for many small-to-medium sized business), people will eventually start to pick on the fact that systems that are more difficult to use are not inherently superior or more sophisticated. And they will realize that the value of a good programmer is not in his ability to produce or consume the most cryptic source code, but in his ability to solve problems using tools.
However, since I do identify myself as a programmer, which is still unfortunately tied in with the whole source code thing, and I hope that Terry will also reconsider his own self-identification as a programmer, I have some thoughts for anyone who has feelings that are similar to Terry's in regards to the types of systems he evaluated.
First, its very true, there is no endpoint. You cannot possibly master even a tiny subset of the popular systems out there, and they never stop inventing new ones with more and more layers. I think there are quite a few people out there that misunderstand this whole thing though in relation to what programmers are supposed to be capable of or do. You are not supposed to be a master anymore. You are not supposed to remember how to do everything off the top of your head. You are not supposed to spend 3 months reading a Rails book and then remember everything important about Rails.
What a good programmer does with a new technology is take an hour, or a day, or a week, or _maybe_ a few weeks mostly reading about something, and then paste some code in from an example and start experimenting with the system until he understands some basics of how it works. And then when he needs to add new features, you don't go buy and read another book. You go to Google and type "how do I do XXX with system YYY" and you get example code on Stack Overflow from three different people, pick the one with the most upvotes, adapt it to your code, and try it out.
And a good programmer is always looking for tools, programming languages, or whatever that makes his job easier. Because these days there is so much open source software, its really wasteful to not be taking advantage of these things. But with that mindset, what I said in the above paragraph is just the only practical way to go about things.
And you have to pick your battles, and you have to be willing to drop a technology after trying it out and realizing that its more difficult to use than something else, even if that technology is very popular. Because popularity is not the same as merit. Its very far from it. Often, by the time something finally becomes popular, its already quite outdated. And that is doubly the case for high technology, which evolves as quickly as people can think and type it in. And it can mean that an entire paradigm, which is extremely popular and considered a best practice, is also out of date.
As far as PHP, you're right, its usually easier to use WordPress. But you can still write an occasional plugin, or adapt an existing one, using your PHP skills. Or just configure and integrate existing WP plugins to solve a problem. I believe we need to extend our definition of what a programmer is.
As far as JavaScript, first, I have done quite a lot of programming in JavaScript. And I can say quite conclusively that JavaScript is a pain in the ass. I have also done a fair amount of programming with Backbone. And I can say conclusively that Backbone is a pain in the ass.
However, people looked at the issues with JavaScript and made it better. And now we have CoffeeScript. And then a genius in China figured out how to make callbacks in CoffeeScript go away and we got ToffeeScript.
And people looked at how to make things more convenient than traditional MVC in JavaScript and came up with AngularJS. I have done a fair amount of coding in AngularJS. It is much better both in terms of sophistication, software engineering, ease-of-use, features, etc. than Backbone.js. Now, many people are confused about that because they think that since Backbone.js is seems more complicated at first glance, it must be better. That goes back to some fundamental problems with the definition of programming.
However, one thing that is a pain in the ass with AngularJS is components. I.E., defining your own custom elements. Now we have a new thing called Web Components, using the Polymer system, which makes it much more convenient to create custom elements. So that is what I am going to use. Note that even though I used Angular in a couple of projects extensively, I never bothered to become a master. And now I am going to use Web Components instead. Because its a better paradigm.
But the thing to notice is that the technologies I am recommending are easier-to-use and understand and require less code than the technologies they are replacing. The direction we are going is to less and less code, especially less and less being written custom to an application. The direction we are going is for more and more systems to resemble WordPress.
As far as Rails goes, no you don't have to learn Rails. So what if it is popular? It is complicated, and now even more complicated than it used to be. And remember, popular != good. Sinatra is an awesome way to approach many types of applications. Speaking of Sinatra, if you want a cool technology to play with, checkout Jester, written in the new programming language Nimrod: https://github.com/dom96/jester You can write code that looks just like Ruby/Sinatra, but runs maybe 10 or 100x faster, since it is compiled to C and then to native code.
As far as that ImagesLoaded plugin, I think that is RequireJS or something. And that is one that I have avoided, because the complexity of defining components just hasn't been worthwhile. Compare that to using Browserify with require and exports. Or just using a script tag. Much simpler. And that particular example of that plugin code is a good example of why you don't necessarily want to use that. Again, just because something is popular, doesn't mean its better, and doesn't mean you have to use it. That ImagesLoaded plugin is bad code, and its mostly boilerplatey plumbing. Its not good software engineering as far as I am concerned, because making things less difficult to understand is very important. A lot of times what becomes popular is just the most complicated thing, either because people confuse complicated with good, or they add on to a simple tool and eventually make it too complicated.
So Terry, you're a good programmer. And if something seems a bit more complicated than you are willing to get in for, maybe it _is_ too complicated. And if you know how to and are willing to use tools to solve your problems without writing code, that doesn't make you a non-programmer. That just makes you a sane programmer with good common sense.
Holy crap that was a detailed response! I pretty much agree with it all! In short Terry just tried to do too much, and should have just focused on something that interested him. No matter what however, JavaScript is currently THE language of the web so he really just needs to focus on that, and put off everything else until he masters JavaScript FIRST (that is, if he wants to have a marketable resume)
The jump from understanding JavaScript to understanding how to grock MVC and the way different libraries and frameworks implement it is definitely something that is waiting for a simplified tutorial online. It's a pain point.
It's difficult to love it, even when it things don't work--like spending an hour trying to figure out why something isn't working, only to find you wrote if(isVar = true) (yoda that bish...)
These comments ring with explanations of where the OP went wrong, but I want to add my thoughts. Doesn't it strike you that every "brick wall" the author ran into was a move from learning a language to using a massive framework? PDO, Backbone, and Rails were mentioned in the article.
I've seen this tendency from new programmers: to be a programmer, I must do what programmers do. And that means using "real" languages, "real" frameworks, work on "real" projects. I think that's wrong, and I think we experienced programmers encourage that line of thought.
The author describes enjoying Ruby. He or she had fun going through a book on it, fun solving Project Euler problems with it, he or she ran home from work to play more with Ruby. I can't imagine a better student. But after getting a basic familiarity with Ruby, the author tried learning Rails and was immediately overwhelmed: "In the tutorial, Hartl introduces Ruby, Rails, Git, Heroku, Test Driven Development and just about everything else you can think of, right from the start."
If I had a moment to talk to the author before he or she began this programming journey, I would say something like,
"To many people, programming is first and foremost fun. Yes, it's a tool to solve problems, yes it can be a job and a career, but you already have a job. You don't need programming to make you rich, or to have a stable career. So why don't you instead focus on having fun?
"As part of that, don't think you need to learn all the tools of 'real' programmers: you don't need to make a beeline to Rails, or PDO, or Backbone. These are tools other programmers invented to solve their problems. You might not have their problems, and you might not like their solutions. After all, your goal isn't to solve a problem for your boss by noon; your goal is to enjoy yourself and to learn something new. With time, you may find that you don't need those frameworks and libraries. Or you'll run into those same problems, and then you will truly appreciate those kind souls who made their solutions available to you, at no cost and with copious documentation. But don't worry about that now. Focus on learning, on having fun, on challenging yourself bit by bit and then overcoming those challenges."
I've met programmers whose attitude was, "If you're not using [framework], your code is worthless, and no progress can be made until you fix yourself." That might be helpful at a company where the goal often has a deadline, but to a beginner, especially one looking to learn for personal gratification, that's not really a good option. Maybe your student is confused by all the magic happening in the framework. Maybe your student is a bit afraid of the tightrope of abstraction that they're walking. Maybe you should slow down and figure out why your pet framework solves their problem.
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.
You're right that there's a big 'inferential gap' [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).
Even seasoned developers (I have 24 yrs experience), are overwhelmed by the huge number of different frameworks and languages. The guy that wrote this article simply needs to focus on JavaScript, and forget all other languages and frameworks, and sell himself as a front-end web developer doing ONLY JavaScript. You can get a decent paying job just from being a skilled JavaScript guru. This guy just got psyched out by setting out to conquer the world. You have to pick one thing, focus on it (make sure it's marketable, on your resume) and just learn THAT ONLY. At least that's my recommendation on how to "break into" the software industry. Bottom line unfortunately is if you don't LOVE IT, you truly will never be any good. I've seen it before. The only decent developers are always the ones that have a passion for it. If you aren't passionate about it, go do something else, you will definitely fail as a programmer.
You are missing what he is really saying. He saw the tools available, liked some aspects of them, was even able to use some of them reasonably compentently.
But, he realised early on that our tools are limited, they have problems, they can be hard work, and he decided they were not for him.
Honestly, I think the author just needs to be more patient. It takes time and determination to understand these things. He didn't even make an attempt to understand the code in question. Every programmer has had to pick code apart to figure out how it works, its how you learn. He just wasn't willing to / didn't see the value in putting in the time.
Nothing wrong with this, if you don't see the value don't put in the time, but I think its foolish for people to assume you can just "become a programmer" without investing a very substantial amount of time.
Within the first two seconds of looking at the article, I thought "Yuck! My monitor has really gotten dirty. Strange that I didn't notice this amount of filth until now...". Then I scrolled a bit and discovered that the filthy look is actually part of the page's background.
Honestly, who would choose such a hideous design on purpose? Randomly generated CSS would have a good shot of making the page look better than this.
ETA: Scrolling down a bit more (so that the title is above the viewing window), it now looks fine. Still, though...
I've come to realize that in the world of real applications, the process is less about doing everything yourself and more about just Googling that shit until you find a solution.
Heck, look at all the questions on SO that keep cropping up. They all ask these simple problems that either they've faced or someone else has too. Some guy even wrote (about why he stopped using SO) that in order to answer the questions, he'd just google the question and find the answer in some blog post. Copy/Paste and make it pretty and you'll get 600 upvotes from the thousand other Rails noobs who need that answer.
That is why, if you want to build something real, just put all the pieces of the stuff together (like how people do in Rails) and launch the product.
Better yet, just do it with WordPress too, or some site builder. At the end of the day, if you're learning for the sake of learning, you'll give your 10 000 hours of duty, but who the heck wants to live behind a computer for 10 years?
Piecing shit together should be a philosophy that is encouraged, especially in elitist programmer world where if you mention anything of this sort (like this post) you immediately become an antagonist.