Love this article... my first computer was an Apple II back in the 80s which I taught myself to program in a very rudimentary fashion. How? Hong Kong knock off backstreet copies of Applesoft and BASIC manuals. That and those old home-computer magazines with program listings in that you could type in and make a lunar lander game etc.
Programming wasn't available at school so my next chance to get my feet wet was on my final year Physics degree project. With a few math projects in FORTRAN along the way :-/
So given that my skillset was pretty much BASIC only at this point I took one look at C in 1995 as I graduated and balked. Pointers? WTF? I am never doing that ever. Programming ain't for me. Just not that smart I guess.
In reality I did a lot of early web programming, I just never thought of HTML and very early javascript as being programming. I'd build the occasional page or two myself with HTML JS CSS in the intervening years.
But it wasn't till 2010 and I was having technical co-founder issues for the second time in back-to-back startups (not his fault, visa issues with a family member), when I realized I needed to be my own technical co-founder.
Ruby! WTF? Nothing like that old C that scared me away. I can do this! Thanks to Ruby-on-Rails, Stack Overflow, a ton of great web blogs and Hacker News here I am a few years later able to get paid for programming for other people while I build my own MVP and first iteration of product for my own startup. Am I as good as the folks I'll end up bringing on board if it takes off - hell no, a great programmer is light years ahead of me.
However, if a muppet like me can do it, you can to.
So it might not be the quick answer you want, but I get asked this a lot by friends so I have a package of recommendations put together in an email with links and setup instructions etc., I usually copy and paste - if you're asking for yourself I'd be happy to forward it to you if you put an email in your profile or something temporarily so I can find you.
In short though I used Hartl's Railstutorial, an old Sitepoint introduction to Ruby and Rails, everything Railscasts... then I started coming up with projects and building (or often half-building) them. Stackoverflow helped me with answers. Google was my friend because so often people had blogged answers I was looking for.
Learning to read other people's code was the biggest step forward. But after the basic tutorials, it was mostly building things. Finding problems. Reading answers. Experimenting.
Could you make your list publicly available on a blog or something similar so everybody can see it, please? (So those who'd like to see your package of recommendations won't spam this thread for requests.) If that's okay with you. Thanks!
From playing around with gorillas in QBasic to pretending to know C to learning HTML visually to getting CSS and DOM to trying to remake PacMan in C++ to finally learning Python and Django and Flask and the point of OOP to finally now realizing the modern day shift towards EDP thus how powerful JavaScript really is.
Ten years of sucking. To realize I'm not meant to be a programmer because my code is not as efficient, compact, or beautiful enough like the "pros" that keep pushing to GitHub.
And that internal chasm, that lack of confidence is what kills it for me. And if I were to do it all over again I would have definitely done all this on other people's time and money instead of my own.
But I just keep hacking away because programming is art and until the day I can bring about all the crazy things I know I see in my head that will change the world I will suffer for my art.
Would you've considered using the money you've generated to launch a local devbootcamp to teach yourself among 'pros'? In these 10 years you haven't stayed out of touch since you know EDP, some people are stuck in OOP. Putting up a MVP together and using those connections you would've gained in the bootcamp to find a partner sounds better than the loner route. That's what I'm assuming. I lurk here, but comments like these puts reality down in a summary I can comprehend.
I wish there was a shortcut to all of this. You know finally landing on a legit niche and outsourcing it. Outsourcing can be an art for people like us who aren't pros.
[Edit] One of you guys in here should launch an old school way of learning how to hack hub. For Generation Y.
A lot of bootcamps are popping up in the bay area. To me it's weird and speaks more about how broken our immigration laws are than that the bootcamps are fulfilling a market niche.
There are huge leaps between the introductory levels (covered by CodeAcademy or Udemy reinventing the ...for Dummies series of the 90's) to the intermediate levels to the expert Google/Apple/Facebook levels (trained by the traditional college systems or just talented enough to self-learn).
That intermediate level is a big opportunity and I can see the pitch of the bootcamps being able to launch candidates from intro levels to get as close to the intermediate level as possible. Yet, that's a big jump.
Things like knowing about message queues, tasks queues, server provisioning, or creating REST APIs are still a lot of information to learn. If I were a funded business organization my options are to:
- hire internationally and relocate them (thus far expensive)
- setup offshore (expensive but cheaper)
- hire a 12-weeker (cheap)
In my experience of working at big corps and startups, there's just not enough introductory work to go around to make hiring a 12-weeker worthwhile.
It's even worse on the startup scale since there's just not enough money to keep a newbie around long enough to make good use of them or provide technical training. Not to mention how often people jump from companies to companies these days and OTJ training just doesn't work anymore.
I don't know how to fix that. I keep hearing that DevBootcamps are pretty successful at placing people into work though I would love to have a deep dive with the employers to know what's going on because to me they just don't seem efficient enough.
In this case, I'm building out a Rails MVP for a client wherein I'm involved in the short term. I'm pairing with the DevBootcamp grad and teaching him my process as we go and assigning smaller tasks to him. In that sense he's a very junior developer, and I work as both a consultant hacking away on product and a trainer. It's still early, but it's working well so far.
I've worked as product lead or product manager in small and mid-sized companies and have had to hire developers in PHP, .NET, and Rails shops.
And yes, I've been trying to focus on Rails as of late.
An informal DevBootcamp-like fellowship like the one above is the solution for some Gen Y kids. They can properly contribute to https://www.hackerschool.com/ and cut formal education time.
Yeah, but that's a far cry from a full-on static type system. Don't get me wrong, though — JS is one of my favorite languages! (Most) Lisps don't have static type systems, either, and not many people call them underpowered. Same goes for Ruby, Python, etc.
Is popular because is the only language allowed in the browsers; any other assertion is purely speculation. Just be glad is not COBOL or C (imagine any amateur's code causing memory leaks in the browser...)
I'll sound cynical, but when I read testimonials like this, about people struggling with learning how to program, I can't help but make the comparison:
Learning how to program is like learning how to use a hammer. It's useful, but it doesn't teach you how to build a bridge.
Writing a program that does something useful isn't hard. The hard part of software development is reasoning about requirements, architecture, performance, maintenance, security, user interaction, data modeling, algorithms, relational algebra, graph theory, taxonomy, semiology, psychology...
Software is a fairly new endeavor and touches many areas of human knowledge. To apply it well, you should seek this fundamental knowledge, more than wrestling language syntax, memorizing APIs or groking pointers.
The biggest problem in computer programming education is the pervasiveness of object-oriented design patterns. There is a subset of humans on this planet who find this incredibly structured way of thinking exhilarating. A subset of that subset are great programmers. Others are just pedantic fetishists.
There is another subset of humans who find upfront, structured design boring as fuck. Yet some of these people could be great programmers. If they find Python or Ruby before they find C++ or Java, they might have a chance to be a great programmer. But if not, they will just end up thinking the programming world is full of insane super-intelligent aliens.
Learning how to write a set of instructions (however high-level) and reason about its functionality is a special skill. It probably comes natural to you, that's why you're here. But it does not for everyone. This is something we should foster in people, even if they aren't inherently interested in current software engineering dogma and all of the other areas you mention. They can find their place in that world later.
I think learning how to wrestle language syntax and the glorious, consistent, harsh, and utterly fair grumblings of a high level interpretor are the best first steps in being a great programmer.
> There is another subset of humans who find upfront, structured design boring as fuck.
That's orthogonal to OOP, isn't it?
> I think learning how to wrestle language syntax and the glorious, consistent, harsh, and utterly fair grumblings of a high level interpretor are the best first steps in being a great programmer.
If you like the computer to yell at you, then strong powerfully statically typed languages are even better for you. Try e.g. Haskell.
Sure, you can do upfront design in any language. But you need to have experience to do upfront design. If you're new to programming, you should just hack around.
The other option is to read a Design Patterns book and treat it like religion. This is what happens to many new programmers who start with C++ or Java. You learn the patterns and you apply them everywhere, because that's what you were told to do. Some people like this, but many are turned off right away. I understand the point of things like Java. They make it possible for dozens of programmers to collaborate on a large project without stepping on each other's toes. But all of that abstraction makes no sense to a new programmer (at least one who is not a super intelligent space alien).
I don't see that risk in other programming paradigms, mostly because they are not as popular. But I also think something like functional programming carries a lot less baggage than OOP. It's easier to get the main concept.
Dynamic typing is easier on a newbie. They're just trying to put the parenthesis in the right place. There's plenty of yelling going on already. That said, something like Haskell which is less verbose probably wouldn't be so bad.
Yes, just hacking around can be useful for beginners. Dynamic typing like Python does (and not like PHP or Javascript) might be ideal for novices.
About design patterns: Lots, if not all, of the common design patterns for Java are just workarounds for weaknesses of the language, like lack of proper closures. So more capacity for abstraction would make them less verbose or invisible.
That is true, but when you start it is certainly the part that seems the hardest.
It's one of those things that seems almost impossible until you get the "aha" moment and then everything seems to get a lot easier. Then you try and solve more difficult problems and it suddenly gets hard again.
I spent $600 on a COMMODORE P.E.T., friends of mine got tired of playing the 10 or so games that came on tape when I got the machine. So I decided to write a complete ripoff of Galatic Conquest from Broderbund.
31 years later I'm still making games for a living. Love it.
But it al started with a need to play a new game, and no money.
Too many to list really. I became a producer in 1990 so I could work on more projects. I have 23 titles in Apple's App Store, all as Producer. Look for them under "addictinggames.com", I did all but one of those.
There's a field known as "Instructional Technology" or "Learning Technology" that studies how to optimize instruction, training, and educational experiences. The difference that the author articulates is the difference between two major schools of thought in this field: Behaviorism and Constructivism.
The hand-holding, specifications approach taken by American College Board is an example of Behaviorism. While Project Euler's structured, incremental challenges are examples of Constructivism.
Within IT, there are certainly adamant followers of both schools of thought. But, as with many facets of life, the middle ground is normally better than either extreme.
For example, would you like your next pilot or ER doctor to have ONLY learned the Project Euler way? (If you say yes, you really need to stop what you're doing and read "The Checklist Manifesto: How to Get Things Right" by Atul Gawande.)
On the flip side, when you come down with some extremely rare condition, do you want your doctor to have ONLY learned the American College Board way?
Similarly, programming and computer science have facets that are best addressed through Project Euler challenges, and others that are better addressed through CodeAcademy hand-holding and lessons based on detailed American College Board objectives.
i initially started learning how to problem solve when i started dabbling with my first computer. living in saudi arabia created an isolated environment. access to information, especially game related was hard to come by. the only thing left was to hack away any way possible to achieve the desired results, which was mostly beating the game.
thank you sierra and lucas arts for all the adventure games. i literally played all the games and beat them all without cheating, must have spent literally 1000s of hours playing and teaching myself. i learned how to hack and problem solve because it peaked my curiosity, it was just all a game to me.
now coding and problem solving come quite naturally.
it really all comes down to constant and correct intervals of dopamine release. just like any sport, entering the dopamine "flow" is what keeps me programming. time disappears, its me and the problem, fencing back and forth, just enough challenge to prevent frustration to prevent boredom.
if you program and don't experience this... i don't know why anyone would want to program if they didn't truthfully.
This probably does not need to be announced 'round these parts, but Project Euler is an incredible website. When I wanted to start programming I went out and bought a few books to learn Java. I got the general idea and I could make things happen but I didn't really know how I'd solve problems that weren't in the book. Enter Project Euler. I picked up Python and started working through the problems. As I went, I learned what questions I needed to ask and I got a real sense about how to attack a difficult problem. Sure my solutions were mostly brute force messes that I'd be embarrassed to show off today, but I was solving problems with a keyboard. The feeling of mental potency was incredible and it's what got me hooked on CS. As a bonus, sometimes I'd come up with the elegant solution on my own and it's an incredible feeling. Working for 3 hours to eventually independently re-dicsover Pascal's Triangle and combinatorics was a really enlightening experience.
The bit about the triangle in the box is a really good example of thinking vs applying a formula...
A math prof of mine told me that in the US, a student typically does 90% drill and 10% concept, but that in Japan, it's the opposite. In other words, the Japanese student would spend 90% time figuring out how to find the area of a triangle (perhaps taking a few different angles toward deriving the formula), whereas the American student would get a brief review and then a lot of applying the formula.
Has anyone else heard about this? It's just something I heard once.
There might be more to it than just a myth. Eh, I'll have to read more about it later. Things can vary so much from teacher to teacher, classroom to classroom, that it's hard to get away from anecdote on something like this.
If you're progressing through Codecademy and feeling like you don't understand the material you've learned, I highly recommend working through Project Euler. The web-based curricula hold your hand through projects, which is great, but it's not a complete breakfast. Project Euler will exercise your general problem-solving skills, much like real-world programming.
If you're learning to code from Project Euler, you should be a student at my school, Hack Reactor. http://hackreactor.com
I learnt to code in exactly the way described, with a Sinclair ZX Spectrum and a manual, no teacher or other form of instruction. I still think it's the best way to learn. Looking around for something similar to teach my own kids programming. If worst comes to worst, I'll buy a ZX on EBay, plug it into the TV and let them learn the same way I did.
When I was 13, I was stumbling around in my mom's garage and found a copy of Ivor Horton's "Beginning Visual C++ 6". I still refer to this moment as the reason I became a programmer. Like the author, I tried to read the book for a month and got so confused that I knew that this is what I wanted to do for my life. So, of course, I put the book down, waited 5 years, and went to college.
I can't imagine what my life would have been like if I had been given an ORIC-1, or had any accessible way of getting into programming at that age.
Think of it as acquiring an addiction rather than "learning" something. Look for the most addictive component activity the subject involves, that can be repeated with minor variations and increasing complexity as rapidly as you can go.
In math for example, this is graded homework problems of increasing levels of difficulty. For programming, it might be little coding problems. For people management, it is running effective meetings.
No individual instance should take more than an hour on average, for a meaningful "hit."
Now do this activity repeatedly. "Learning" is merely a supporting activity required to keep the hits coming. You'll find that you are endlessly resourceful while pursuing the next hit, just like crack addicts can be quite clever in finding money to buy the next hit.
Some people are serial addicts and can learn one thing after another, learning many things very quickly. Others get addicted to just one thing. Others struggle with even one thing. For the last category, the problem is often patience until the first hit. Once you have your first hit, the addiction begins.
They were more like DC8s (the 10 was an MD model), and you still haven't cone anything about Incident I.
The main problems with the Scientology flap were that the advertorial was not sufficiently distinguishable from the regular editorial content, and that they tried to keep comments (which should have been disabled altogether for the ad—who the hell opens an ad up to equal-time commentary???) seeming favorable or at least neutral. Poor planning and execution in both cases, but that doesn't necessarily carry over into the editorial (which is still generally good).
I'm trying to collect computers from that era. I have my own Atari 800XL, C64 and I recently found a Sinclair QL (kinda super hard to find at a reasonable price).
I remember working my way through the GW-BASIC manual alphabetically and finally getting to the 'SCREEN' statement so that I could switch to graphics mode and do something interesting (using all the alphabetically-preceding graphics-mode-only commands I'd failed to get working).
Programming wasn't available at school so my next chance to get my feet wet was on my final year Physics degree project. With a few math projects in FORTRAN along the way :-/
So given that my skillset was pretty much BASIC only at this point I took one look at C in 1995 as I graduated and balked. Pointers? WTF? I am never doing that ever. Programming ain't for me. Just not that smart I guess.
In reality I did a lot of early web programming, I just never thought of HTML and very early javascript as being programming. I'd build the occasional page or two myself with HTML JS CSS in the intervening years.
But it wasn't till 2010 and I was having technical co-founder issues for the second time in back-to-back startups (not his fault, visa issues with a family member), when I realized I needed to be my own technical co-founder.
Ruby! WTF? Nothing like that old C that scared me away. I can do this! Thanks to Ruby-on-Rails, Stack Overflow, a ton of great web blogs and Hacker News here I am a few years later able to get paid for programming for other people while I build my own MVP and first iteration of product for my own startup. Am I as good as the folks I'll end up bringing on board if it takes off - hell no, a great programmer is light years ahead of me.
However, if a muppet like me can do it, you can to.
Great article!