I've always had a fear of writing spaghetti code that it had prevented me from actually coding. I think that has been a big hurdle for me starting out. Reading articles like this though definitely helps me out.
I always expect to mercilessly refactor what I write, though it's good to remember users don't care if your code is top notch, it's just something you do to make your own life easier, to simplify adding features. The ego aspects just gets in the way, especially if you're the only person working on it. In my experience, I'm always more productive with some code and building blocks to arrange than a blank canvas, and as you gain more experience it's easier to see corners before you code yourself into them.
Start writing. Commit often to a good source control system(git or mercurial but I prefer git). Refactor your code when you see an abstraction. The hardest thing about any task is just starting it.
For me learning to "Refactor your code when you see an abstraction" came only when I had to work in an environment where failing to do this caused pain (writing Win16 OLE/COM code in C)
I don't advocate masochistic practices as a means of self improvement per se, but the same habits can be built using intentional practice wherein you choose (for the purpose of the exercise) to take strong constraints on the style of your code.
I'm a professional software product developer who writes messy code all the time (true spagetti code isn't really possible today, it's a thing done only in assembler).
After awhile you realize the pain of doing messy everywhere, and do it only where it makes sense (Prototypes, quick fixes, first implementations, etc).
But you know what runs worse than messy code? No code at all.
From time to time it's good to have a reminder as to why many of us got into programming in the first place.
It wasn't to sit on HN for hours on end discussing the merits of various language paradigms & frameworks or implications of polynomial growth algorithms, but to actually build shit.
Not much beats the satisfaction of having working software in front of you that does something cool and knowing that it's all yours.
The actual story is linked in the nav (for those wondering).
This matches my experience with programming too. It's just beautiful how pieces fall into place when you first start programming.
I remember first taking a look into Rails when it was first released, as I'm a designer and I was into 37signals work back when they were a design shop. My reaction was "what the fuck is this"?
Some months later I had to collaborate front-end code with git, and ssh into a couple of servers. I started to feel comfortable at the console, so I took a look at Rails again, but it was still too difficult.
Wanting do add some interactivity to my front-end code, so I started using jQuery. Of course it was the naive selector spagetti code, but it got me started with programming. Took a look at Rails again, too hard.
I then dabble into really simple MySQL databases driven by PHP. What a nightmare, wasn't this supposed to be solved by ActiveRecord? I take a look at Rails again, and it starts making sense.
Then the pre-parse craze came out, so I learned CoffeeScript and Sass. CoffeeScript happens to greatly simplify js OOP code, and has some bits of Ruby's syntactic sugar, so this time I another look at Rails and suddenly it all starts making sense.
All those bits and pieces you collect from real project experience come together and suddenly the you have crossed the gap to create a full web application.
Personally, this is one of the biggest hurdle in making myself to learn/understand coding – how everything fits together.
HTML/CSS is easy enough, but I still don't understand how Ruby/Rails fit with HTML/CSS in web development/application. I read Rails is a framework coded in Ruby, and they're used for web development/apps – so I look at Ruby and that's where I get lost. Starting from the bottom (learning about arrays and what not, it's hard to stay focused when you don't know what exactly is the benefit and outcome of all this learning and how it fits in web development).
I came across a path, or tree skill, that recommends how one should approach web development:
HTML > CSS > JS/PHP > JQuery, then once you get that down, it's Ruby > Rails.
Hopefully when I look at Ruby/Rails, I won't feel so lost again.
I was on the same path, and did some Ruby by way of Sinatra for a class I was taking, and now I'm in a course learning Node.js + Express and I'm totally happy.
>you don't know what exactly is the benefit and outcome of all this learning and how it fits in web development
This is not your fault; most tutorials and intros are horrifically coded and introduced.
You'll often find obscenely arbitrary examples that have literally no place in actual coding. Take for example Backbone.js' introductions. It's an incredibly powerful tool for front end MVC work, but it took me a long time to "get it", because there are literally no examples on their site that pertain to any realistic or practical usage of the framework.
They themselves admit that this is a useless example, but choose to use it anyway. It confuses the Model and View purposes, and if it appeared in any actual implementation of Backbone, would break just about every convention in existence. Why even use it?
I know they want to avoid telling people how to use it, because it's so open-ended, but it doesn't hurt to establish some common practices or mechanisms. It took me a long time to figure out a good way to link models and views agnostically, simply because they don't address that whatsoever in the docs.
You could improve your icon. The game has such interesting shapes but the icon is just one plain shape. Making the icon one or more of the more interesting shapes would catch attention. Also, to me those diagonal lines somehow make it feel unfinished or like a placeholder. I'm not sure what they remind me of.
The app name in iTunes could include some of the description: "Polymer - slide to create never-before-seen shapes". That would catch more eyes on a list of apps.
21 comments
[ 3.1 ms ] story [ 60.9 ms ] threadI go build some tiny and completely unrelated to get me to enjoy programming again. Usually works.
For me learning to "Refactor your code when you see an abstraction" came only when I had to work in an environment where failing to do this caused pain (writing Win16 OLE/COM code in C)
I don't advocate masochistic practices as a means of self improvement per se, but the same habits can be built using intentional practice wherein you choose (for the purpose of the exercise) to take strong constraints on the style of your code.
After awhile you realize the pain of doing messy everywhere, and do it only where it makes sense (Prototypes, quick fixes, first implementations, etc).
But you know what runs worse than messy code? No code at all.
It wasn't to sit on HN for hours on end discussing the merits of various language paradigms & frameworks or implications of polynomial growth algorithms, but to actually build shit.
Not much beats the satisfaction of having working software in front of you that does something cool and knowing that it's all yours.
This matches my experience with programming too. It's just beautiful how pieces fall into place when you first start programming.
I remember first taking a look into Rails when it was first released, as I'm a designer and I was into 37signals work back when they were a design shop. My reaction was "what the fuck is this"?
Some months later I had to collaborate front-end code with git, and ssh into a couple of servers. I started to feel comfortable at the console, so I took a look at Rails again, but it was still too difficult.
Wanting do add some interactivity to my front-end code, so I started using jQuery. Of course it was the naive selector spagetti code, but it got me started with programming. Took a look at Rails again, too hard.
I then dabble into really simple MySQL databases driven by PHP. What a nightmare, wasn't this supposed to be solved by ActiveRecord? I take a look at Rails again, and it starts making sense.
Then the pre-parse craze came out, so I learned CoffeeScript and Sass. CoffeeScript happens to greatly simplify js OOP code, and has some bits of Ruby's syntactic sugar, so this time I another look at Rails and suddenly it all starts making sense.
All those bits and pieces you collect from real project experience come together and suddenly the you have crossed the gap to create a full web application.
HTML/CSS is easy enough, but I still don't understand how Ruby/Rails fit with HTML/CSS in web development/application. I read Rails is a framework coded in Ruby, and they're used for web development/apps – so I look at Ruby and that's where I get lost. Starting from the bottom (learning about arrays and what not, it's hard to stay focused when you don't know what exactly is the benefit and outcome of all this learning and how it fits in web development).
I came across a path, or tree skill, that recommends how one should approach web development:
HTML > CSS > JS/PHP > JQuery, then once you get that down, it's Ruby > Rails.
Hopefully when I look at Ruby/Rails, I won't feel so lost again.
This is not your fault; most tutorials and intros are horrifically coded and introduced.
You'll often find obscenely arbitrary examples that have literally no place in actual coding. Take for example Backbone.js' introductions. It's an incredibly powerful tool for front end MVC work, but it took me a long time to "get it", because there are literally no examples on their site that pertain to any realistic or practical usage of the framework.
To wit: http://documentcloud.github.com/backbone/#Model
They themselves admit that this is a useless example, but choose to use it anyway. It confuses the Model and View purposes, and if it appeared in any actual implementation of Backbone, would break just about every convention in existence. Why even use it?
I know they want to avoid telling people how to use it, because it's so open-ended, but it doesn't hurt to establish some common practices or mechanisms. It took me a long time to figure out a good way to link models and views agnostically, simply because they don't address that whatsoever in the docs.
I feel that this is very good advice. I give this same advice to friends who want to get into programming.
I'm glad to have read about your great progression in your programming; going from no experience to creating a pretty sweet game.
Congratulations on the release! I already got a copy :)
The app name in iTunes could include some of the description: "Polymer - slide to create never-before-seen shapes". That would catch more eyes on a list of apps.