Learning to Code
Here are a whole bunch of links: - youtube channels: sentdex (basic syntax learning), DevTips (for web applications), thenewboston (basic syntax learning) - Rosalind - A bioinformatics-specific learning platform with exercises and examples. This is an invaluable resource! - Code Academy - for very basic syntax learning, though I'm opposed to learning programming that has too much hand holding.
For Python, you'll need: - Python 3. The current version is Python 3.6. - The Anaconda distribution. Python has thousands of libraries - these are code and functions written by people for various purposes, e.g. scipy ("scientific Python", I think) is a collection of frequently used scientific and statistical functions, like linear regression, etc. - Installers and library managers: pip, conda - Jupyter as an IDE.
The Learning Process
As you may have picked up from some other tutorials in this repo, I'm a fierce proponent of independent learning, for many practical reasons. In general, the steps you should be attempting are: - Have you googled for the answer, or answers to similar problems? (If it turns out that the answer to your question is just the top hit on a simple Google search, I might just send you a snarky let me Google that for you link. Yes, it's easier to just ask someone, simply out of convenience. But all parents know that if a child asks a question, the best way to teach them isn't to just give them the answer, but to look it up with them. - Have you read the manual? Again, programming culture has a somewhat mean admonishment to this. In spite of how people generally ignore manuals for their cars, toasters or fridges, this doesn't apply in programming. An exception can (and frequently does) occur where the documentation is poor, but this isn't likely the case for well-established open source projects like Python or R. - Have you tried something? What have you tried? The problems that aren't easily Googled are usually more complex, and require some trial and error to home in on a solution, if only out of a process of elimination to cross off all the potential solutions that don't work.
Whatever the case, it's generally frowned upon to just ask for the answer. Ultimately, this depends on how far you want to develop your own programming skills.
At a broader level, you don't actually learn to code per se. The best analogy I can think of is: nobody actually learns to play the piano. They learn to play music, using the piano. This is why project-based learning, or learning-by-doing, works best (again, Rosalind highly recommended). A real project gives you a starting point, practical considerations about what you need to know or don't yet need to know, and a frame of reference of what's useful versus what isn't.
About Learning How To Code
Learning to code, generally, is rarely like other disciplines, where you advance along a linear progression of digestible chunks and clearly defined topics and modules. Code camps and the like tend to give you very sterile assignments ("Write a function that does X, Y and Z") which are nothing like the real-life problems a programmer faces ("Make a website.") You're more likely to learn to program by solving a real-life problem, and looking for the tools which will best accomplish what you're trying to achieve (my first python script consisted of extracting stock-price data from the yahoo finance website to save to a spreadsheet).
Ultimately, perseverance in the face of frustration is part of learning to become a programmer. Given the rate at which new technologies are being developed, being sufficiently independent to continuously learn is a basic survival trait. Anything learnt today will become pedestrian, or outdated in five years or less.
(Back in 2010, I did an internship at SAS Institute, where I got to know a machine learning phD. His thesis was building a program that could differentiate between pictures of bicycles and cars. Five years later, my Master's thesis would be about differentiating microscopy images of twelve classes of breast cancer cells. What was cutting-edge phD research in computer vision in 2010 would be a ho-hum Master's project just five years later.)
Admittedly, programming culture has got itself stuck in a bit of a quagmire, because: - Yes, all the information you need is out there on Google. But it's severely cluttered, disorganized, and no single source contains sufficient information to get you going, so you'll have to take charge of your own learning process instead of depending on someone else to give you a syllabus. - There are people who are willing to teach coding and all that, but these generally can't go very far because the equivalent content is entirely available on Youtube for free. It's hard to sell something when your competitor is offering a free product. - As a result, a proper "syllabus" or learning process never gets developed, and everybody just learns by themselves. Don't knock it - it works, and technology one of the fastest-developing disciplines that humanity has. This is in no small part because programmers are used to a rapid process of experimentation, prototyping, iteration and improvement.
This blog post from Viking Code School is especially insightful about the difficulties that beginners face. In particular:
"So, you're in Phase I -- the "Hand-Holding Honeymoon" -- checking off badges and completing coding challenges while your confidence and capabilities grow...Be careful! You’re about to overstep a precipice that’s broken many strong aspiring learners and relegated them to the “coding is too hard” camp. The precise moment this leap occurs is the first time you sit down at your keyboard, open up your text editor, and try to build a project from scratch without any of the fancy in-browser editors, scaffolded code or helpful hints.
You might stretch this out a bit by following tutorials, but no one has ever reached the skies without leaving the ground, and, at some point, you're going to have to create magic from a blank text file. You've just entered the second phase of learning, where confidence comes crashing down to earth -- the "Cliff of Confusion"."
So's this thread on reddit:
This isn't enough. It's not much more than teaching people how to bowl by telling them, "throw the ball down the aisle as hard as you can, right down the middle and hit all 10 pins." Simply saying, "Write little text-based programs to learn all the features of your chosen programming language, before moving on to bigger, complicated projects," is not enough and is not guidance.
I do vaguely remember what it was like while learning to code, and there was a struggle between "what is a for-loop" and "when do I use a for-loop", the same way there's a struggle between learning the basic phrases of a new language, and writing an essay in that language. My personal take is: that's just part of learning anything at all, and there's nothing anyone can do about that. Duolingo can only teach me, say, basic Swedish phrases and words. To actually learn Swedish, I'll have to practice speaking with a Swedish person.
Overall, you will be guided, and some people may be nice enough to guide you, but the guidance has to end at some point. If I teach you programming by sitting you down and explaining things line-by-line, I'm actually doing you a disservice by not letting you make mistakes, so we ultimately wish to mimimize that. At some point, guidance is impossible because the learning task becomes deliberate practice and iterative improvement, rather than answering pre-set questions which have clear correct or wrong answers. Duolingo can't teach me extended grammar, language nuances like how words are gendered, culturally-specific metaphors, or how to write Swedish poetry. So, to avoid avoiding the difficulty of having to wean oneself off guidance, my personal strategy is to not even get it in the first place (or at least accept only minimal amounts of it). So far, this makes the beginning phase of learning much bumpier than it has to be, but pays off in the long run.