Throwing in the towel on becomming a programmer

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.

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.

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.

> 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.

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.

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.

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.

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.

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.

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.)

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.

YOUR DOING IT WRONG

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.

Pick one language and stick with it. Only way to master it. Switching between languages trying to find one that fits you not is going to work.

TL:DR Author is using wrong approach. Stick to one language till you master it, after that you can learn others.

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.

There are different ways people learn.

For me, I couldn't just pick up and use an MVC Framework to build a webapp.

I had to first (a long while ago), write a web app using a bunch of shittily written javascript.

After a while, I started to understand the problems an MVC framework like backbone would help me solve.

My first HTML, written by hand. Now, I use templates.

I got my ass handed to me by Manual Reference Counting, but once I got the gist of it, I could use it very well, and could pick up and start with ARC.

Same thing with C++ and heap allocation.

(Also mixing IEEE and VAX Floating Points... :D)

Part of being a programmer, is getting scrapes and bumps, and learning.

Maybe not. Most the people on HN are Godlike devs.

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.

"I’ve been coding for years and have actually gotten pretty good at it. WordPress is my main tool of choice and I’ve gotten quite handy with it"

I kind of stopped reading there.

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...

Those languages are all very similar except for javascript, and that's been built to look similar to the others.

Try something completely different to shake yourself into another level of understanding. I enjoy Erlang/Webmachine.

http://learnyousomeerlang.com/

https://github.com/basho/webmachine/wiki

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.

And read Code Complete 2, still relevant.

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.

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.

Also, most people can learn to code.

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...)

>Despite hours and hours and hours of work, getting to that “next level” with Javascript feels literally impossible.

Heh... Oh dear... Hours? Um... Not sure how to break it to him but that's orders of magnitudes off...

Try a kaggle competition.

You can get a real problem (the same one the PhD student is doing) but you get to use whatever tools/framework you want.

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.

Perhaps I'm simply not cut out for it!

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...

People have different skills. We don't actually need that many programmers as web 3.0 winds down.