3 ms·

I started a little blog about trying to learn to code from scratch: http://newbiehacker.wordpress.com/ http://newbiehacker.wordpress.com/ As that blog post says

I started a little blog about trying to learn to code from scratch: http://newbiehacker.wordpress.com/ http://newbiehacker.wordpress.com/ As that blog post says, it is really difficult finding resources for people who want to learn but really have no programming background whatsoever.

jrheard 17y ago
That's a great blog - it's really interesting to see what the code-o-sphere looks like to a newcomer! I saw that you were having a little trouble dealing with some of the proper-noun Concepts thrown at you in Beginning Ruby, and that you weren't entirely sure where to go next in terms of finding exercises not already in the book. As far as the Concepts go, it's probably best to approach them all as a bunch of different ways of solving the one main problem in programming: complexity[1]. When you're coding anything longer than ten lines, you're usually tackling a problem that's too big to fit into your head all at once. So, you need to break the problem into a bunch of little chunks. Coders do this by building abstractions. All an abstraction is is the act of deciding you've got a problem ("I need a way to print the contents of the screen!"), solving that problem (by writing code that grabs whatever's being output to the screen, translates it into something the printer can deal with, and prints it), and then hiding that solution from anyone who has that problem. The key here is that you're hiding the solution, but you do expose an interface - a "print_document" function, say - that allows them to benefit from your hard work without having to think about it[2]. That's really what nearly every programming technique is all about: minimizing complexity. So when you see big scary words like Encapsulation and Polymorphism and Mix-Ins, just remember: they're almost certainly just different ways of minimizing the amount of stuff you have to think about at any point in time, and if they're any good at letting you do that, they're probably worth learning about. Oh! And as far as finding fun exercises to work on goes: Try writing something that'll automate a chore in your daily life. Say, an automated grocery list, or a "books to read" list, or an apocalypse-detector that checks every five minutes to see if Google's down. You know what they say about the sky and the limit and all that :) - [1] “Managing complexity is the most important technical topic in software development. In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity" - Steve McConnell, Code Complete [2] "Civilization advances by extending the number of important operations which we can perform without thinking about them" - Alfred North Whitehead
malte 17y ago
I'm in the very exact situation like you. I also do not have a programming background and started to learn to program (Ruby) last fall. "Learn to Program" was also my starting point. Like you said in your blog, it is a decent book, but didn't get me very far. Being involved in a Rails project, the ultimate goal is to master Rails in a way that I can work on small features for our project. Right now, I'm kind of cross-reading "Heads First Rails" and "Beginning Ruby". "_why's poignant guide to Ruby" is also on my reading list, but more because of my fascination for _why. One advice (from beginner to beginner) is to find yourself a good mentor. I've got to know a Rails programmer and he is helping me to get into Rails and giving me advice on good ways to work (using the command line etc) and how to solve problems in Rails.

jrheard 17y ago

That's a great blog - it's really interesting to see what the code-o-sphere looks like to a newcomer! I saw that you were having a little trouble dealing with some of the proper-noun Concepts thrown at you in Beginning Ruby, and that you weren't entirely sure where to go next in terms of finding exercises not already in the book. As far as the Concepts go, it's probably best to approach them all as a bunch of different ways of solving the one main problem in programming: complexity[1]. When you're coding anything longer than ten lines, you're usually tackling a problem that's too big to fit into your head all at once. So, you need to break the problem into a bunch of little chunks. Coders do this by building abstractions. All an abstraction is is the act of deciding you've got a problem ("I need a way to print the contents of the screen!"), solving that problem (by writing code that grabs whatever's being output to the screen, translates it into something the printer can deal with, and prints it), and then hiding that solution from anyone who has that problem. The key here is that you're hiding the solution, but you do expose an interface - a "print_document" function, say - that allows them to benefit from your hard work without having to think about it[2]. That's really what nearly every programming technique is all about: minimizing complexity. So when you see big scary words like Encapsulation and Polymorphism and Mix-Ins, just remember: they're almost certainly just different ways of minimizing the amount of stuff you have to think about at any point in time, and if they're any good at letting you do that, they're probably worth learning about. Oh! And as far as finding fun exercises to work on goes: Try writing something that'll automate a chore in your daily life. Say, an automated grocery list, or a "books to read" list, or an apocalypse-detector that checks every five minutes to see if Google's down. You know what they say about the sky and the limit and all that :) - [1] “Managing complexity is the most important technical topic in software development. In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity" - Steve McConnell, Code Complete [2] "Civilization advances by extending the number of important operations which we can perform without thinking about them" - Alfred North Whitehead

malte 17y ago

I'm in the very exact situation like you. I also do not have a programming background and started to learn to program (Ruby) last fall. "Learn to Program" was also my starting point. Like you said in your blog, it is a decent book, but didn't get me very far. Being involved in a Rails project, the ultimate goal is to master Rails in a way that I can work on small features for our project. Right now, I'm kind of cross-reading "Heads First Rails" and "Beginning Ruby". "_why's poignant guide to Ruby" is also on my reading list, but more because of my fascination for _why. One advice (from beginner to beginner) is to find yourself a good mentor. I've got to know a Rails programmer and he is helping me to get into Rails and giving me advice on good ways to work (using the command line etc) and how to solve problems in Rails.