Many users new to ActionScript have often asked me, â€œHow do you learn to code?â€? They sulk when I tell them that I have a background in programming and have actually written programs in several languages.
They proceed to convince me that they have done their homework and tired to read the documentation but can rarely figure out how to do the things they need to. They have spent hard earned money on two or three programming books that take them a day or two to find the time to read and when they crack open the cover they quickly discover such material works really well as a sleeping pill. The same can be said for instructor lead classes and even some of the online tutorials.
Feed up with painstakingly searching the internet for canned solutions, and even expensive 3 rd party software they begrudgingly use on their projects with most results leading to the usual frustration of getting things to â€œalmost workâ€? they long for the day when the secrets of coding would be revealed to them.
If this sounds like you at all then don’t loose heart. I have a little practical advice.
There is no magic, and normally no secrets all the programmers are hiding from you. You don’t have to be some super geek or intellectual genius to learn to code. Also, programming is not just something â€œsomeâ€? people can do and some people can’t, anyone can learn to write code especially ActionScript.
That is not to say that there aren’t some people that would seem are born to code, scary smart people exist in about every profession, but most of us were where you are now at some point before, even if we tend to forget what it was like. What you need to get you on the right track is first, a change in your perspective.
I have made few simple rules/recommendations that may help you along your way:
First fundamental rule; programming languages, especially ActionScript, are designed for YOU to use. They are not just for the scary smart folks, and you don’t need a degree in computer science to become a good programmer. This seems a simple concept but I assure you that the assumption that you can never learn something or that it is not designed for â€œpeople like youâ€? can be more of a barrier to your success then anything else.
Second rule; most programming books are thick and not really designed for you to read them cover to cover. Think of them is instructions broken up in to sections. Like the manual you get for a new car. The car is designed for you to drive it. You only need the manual to learn about a particular feature or maintenance. You will use the book as a reference and jump around from section to section to learn about when you need as you need it. Taking a similar approach to your programming books can make them far less intimidating.
Third rule; start small. Give yourself the chance to learn to walk before you run! I can’t count the number of times a brand new Flash user boldly enters the user forum with a URL to a professional website built by a team of 5-12 experts and asks â€œcan someone tell me how they built that site. That is exactly what I want to do!â€? Sorry, but few things in life work that way. There is a reason most coding platforms and language manuals start with the â€œHello Worldâ€? program and it is not because programmers find it amusing.
Start with the basics, one line of code that does just one simple thing. Work you way up to several lines of code that perform a sequence of small tasks that lead to a single result. Then learn about loops, and conditionals. Finally learn about functions. These things are the basics of procedural programming. Procedures are a logical list of steps that accomplish one thing at a time resulting in the completion of a larger task. It is like giving the computer a cooking recipe only instead of cookies you get functionality when out of the oven, or in this case, the compiler.
Rule four; now this is the hard part. Most of us don’t have the luxury of writing dozens of little programs to teach ourselves one concept at a time. We have jobs to do and weekends to enjoy and unless you are sitting in a programming class, there is little that is going to encourage you along your journey of discovery. So don’t make it hard on yourself. Do as small project they way know how. Build your motion tweens on the timeline. Use what every tips and tricks work for you. Get the project finished and take the pressure off. But afterwards open up your project so you have a goal to aim for. Then create a new Flash document and do everything you can to build exactly the same thing, entirely in ActionScript.
Yes, it is has hard as it sounds, but since you know what the final outcome should be, and you don’t have to race for a deadline you can work on it just a little bit every day. Break down your final goal into the simplest of tasks that you can do in ActionScript one line at a time if necessary. Search through the documentation that lets you draw or attach your symbols on the stage and look for classes, loops, and events that can help you perform any animation. At some point you will finish recreating the project and you will have learned how to read the documentation and APIs. You will remember the basics of syntax, and most important you will have learned how to break down your final goal into a sequence of small tasks in your code.
Now this could take a while so again let me stress that you should start small. Try something like the animation of a bouncing ball or the creation of a web form. Choose something that has visual features that you can easily relate to what is going on in your scripts. For example the bouncing ball is a symbol wrapped in a movie clip that changes position over an interval of time. It is not hard to see that you have to draw the symbol in a movie clip and change the x and y value of the movie clip over time to end up with the same result as your motion tween of the bouncing ball. Knowing what you need to do and in what sequence is more then half of the challenge of coding. They rest comes down practice and experience which shows you how to do it in the most efficient ways.
Believe it or not, you do this a few times and suddenly the documentation will make a little more sense. Those big programming books will become a little easier to read, and soon you will be back engineering those tutorials and third party tools in order to make them work better for you!