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...
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.
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.
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.
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.
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.
>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.
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.
> 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).
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
> "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...
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
>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'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 wouldn't say its a process of continuously diminishing returns. If you use the same process your entire life it will be, but you can constantly be learning new programming paradigms, algorithms, frameworks, architecture, etc. Also the diminishing return idea is a matter of perspective. When there has been something small I'm struggling with for a long time and I finally get it, it's a huge deal to me. Maybe to someone else it might not seem like a lot, but the satisfaction is still there. I think its more the difference between truly loving programming and romanticizing your love for it.
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.
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.
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.
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.
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?
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.
> 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.
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.
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.
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.
125 comments
[ 3.1 ms ] story [ 189 ms ] threadHonestly, 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...
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.
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.
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.
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.
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'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.
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.
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.
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.
> 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.
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.
I was actually tempted to comment about the language selection as well, but this post did mention that it was in the context of web development.
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).
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.
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.
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.
1. Think carefully about what behavior you want the project to have.
2. Prepare your development environment.
3. Hack on stuff until it seems to work.
1. Pick the simplest, most trivial concept at the core of your project and implement the minimal toy version of it in a REPL.
2. Now implement the next simplest thing that moves the needle of progress.
3. Repeat.
I started working on a Bitcoin implementation a few months ago to practice Clojure. It started with this:
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.
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.
You see, eventually you realize it's not the spoon that bends, but you yourself.
It is nice down here.
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.
What would the questions be like? Would there be people asking what a hammer looked like and which way to point a nail?
(I don't think this is particularly useful criticism of anything, it's just an interesting parallel)
That's not very Web 2.0. It would have to be something like Ushr.
Sorry, not very helpful, I just couldn't help myself.
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.
Paint by numbers, google by functions. Both result in a seemingly finished product, created without any understanding at all!
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.
Convoluted comparison, but, you can teach a man to fish, but unless he goes to fish it won't lead to anything.
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 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.
TL:DR Author is using wrong approach. Stick to one language till you master it, after that you can learn others.
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.
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.
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.
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.
Which is exactly why Zed's and my books sell relatively well.
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 have taught zero-experience, low-aptitude beginners for nearly two decades, and his approach is basically exactly what I do with my own students.
"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...
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.
To the author, I think you should give yourself a lot more credit.
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...
http://opalang.org
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
http://www.ultratechnology.com/forth.htm
You could bootstrap the whole thing by having bochs run in a asm.js setup, with the graphics frame buffer being spit out to a HTML5 canvas.
http://bellard.org/jslinux/
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.
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.
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.
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.)
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.
'On Data and Coding'?
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.
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.
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.
Pfftt, yeah sure. Everything is perfect in Rails land
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.
most smart people, on the other hand, can build a specific something if they are determined enough, fundamentals be damned.
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.