When you want to learn to program, taking classes and reading texts are useful exercises, but Chad Perrin says it's not enough. To really learn programming, you need to start writing programs.
Ancient Chinese philosopher Confucius is credited with saying a lot of things, from trite fortune cookie messages to patently ridiculous jokes like "Man who stand on toilet is high on pot." One statement attributed to Confucius that is relevant to people learning to program is:
I hear and I forget.
I see and I remember.
I do and I understand.
Sitting in a classroom is far from the ideal way to learn to program for most people. Reading about the programming concepts at the same time might help, but it does not compare for practical skill acquisition with the effectiveness of reading and thinking about others' source code until you understand it.
Nothing really cements programming skills in the mind like writing programs of your own, however. Read a little, get taught a little, and start programming a lot. Find things you wish were easier, and make them easier by writing some code to automate them.
Unfortunately, figuring out what to do can sometimes be the most difficult part of learning to program. The key, based on personal experience, seems to be to wish you could do something in one step instead of seven or eight, and to have a sudden epiphany where you realize you have an idea how to write a program to solve the problem.
Because starting programmers typically have very limited knowledge on which to draw when looking for that kind of epiphany, it helps to stack the deck in your favor. Doing so, at least at first, involves figuring out what parts of your daily computer use routine most lend themselves to easy scripting. Once you have that sorted out, focus your early learning on programming skills that are particularly useful in those circumstances. To the extent such opportunities are lacking, you may want to make changes to your computing environment that will provide such opportunities.
The most important thing to do is to find a way to motivate yourself to write code. Here are suggestions on how to learn programming by taking action.
Major, industrial strength DBMSes such as PostgreSQL, Oracle, Microsoft SQL Server, and Informix offer scripting capabilities via stored procedures or stored functions. Probably the most widely recognized language options are TransactSQL, used by Microsoft SQL Server and Sybase, and PL/SQL, which is used by Oracle. PostgreSQL offers a PL/SQL-like procedural extension to SQL called PL/pgSQL, but it also provides a range of other language options such as PL/Perl, PL/Python, PL/Ruby, and PL/Tcl.
Such opportunities for programming are limited to a particular set of problem domains, but could prove very useful if you are a DBA or if your job involves developing database reports.
Many other applications have plugin and extension systems that can provide ample opportunities to build your burgeoning coding skills, including even some terminal emulators (see TechRepublic contributing writer Sterling Camden's urlpicker for rxvt-unicode for an example) and console-based text editors like Vim. (In the interests of full disclosure: I have contributed a little bit of code to the urlpicker project.)
3. Practice problems
You can try to solve the problems offered by a generic list of coding tasks designed expressly for the purpose of providing programmer practice opportunities. One of the more popular, regardless of the programming language, is Project Euler, which is "a series of challenging mathematical/computer programming problems". The problems are generally arranged from easiest to most difficult, and there are literally hundreds of problems in the Project Euler collection, so this can keep you busy for a long time.
Other examples include RubyQuiz, which has been a popular attraction of the ruby-talk mailing list for years, and CodeKata, a somewhat smaller and shorter-lived project of Dave Thomas, one of the co-authors of The Pragmatic Programmer.
These options are not as conducive to self-motivated exploratory learning as tasks that actually scratch your own itches, but if you find them interesting, they can serve the purpose of educational programming practice as well as anything else.
The biggest new craze in application development is smartphone applications. Such devices typically require the developer to use a specific language to their full capabilities as application platforms, at least to do so in an officially sanctioned manner.
A burgeoning industry of smartphone development frameworks that allow developers to write their code in languages other than the "native" languages of smartphone platforms, that then translate the applications into those "native" languages, is on the rise. Web applications are also gaining traction as a means of writing smartphone applications that do not require learning the official application development language of any particular smartphone platform. Another option for using the language of your choice rather than of the platform's is to use a device like the Nokia N900, which runs a Linux distribution derived from Debian and can run a wide range of software — including a lot of software that was not originally designed for smartphones at all.
The downside is that writing new smartphone applications is hardly something you are likely to do every single day while learning how to program. If your smartphone's OS is a Unix-like system (like the N900), however, the same small tool development projects can be useful on workstations and servers.
If you use spreadsheet programs with a robust macro system, you have a quick way to read code someone (or something) else wrote and write your own code. First, record a macro for a task you perform a lot and that normally takes several tedious steps. Next, look at the macro source code, and edit it to make it better suited to general use. This is an extremely limited approach that will not take you very far, but it might help get you started on the road to feeling like simple scripting is second nature for you.
The most common spreadsheet program for this kind of scripting is probably Microsoft Excel. Excel uses VBA, which is a miserable language, but if your daily work involves heavy use of Excel, this is probably a skill you should have anyway. OpenOffice.org uses a similar macro system that can be used in much the same way, as does its non-Oracle fork LibreOffice, that provides the same opportunities for early learning-oriented coding as Microsoft Office.
In every case, there is a slightly greater barrier to entry for writing code than when writing simple command line shell scripts because of the menu options and buttons that need to be clicked to get started. The overhead for getting started is similar to that of starting a new project in one of the major IDEs on the market, but for significantly smaller "projects". It would be a good idea to ensure this is not the only kind of simple scripting opportunity in your daily development environment, even if making use of it can be helpful.
If you use some kind of Unix-like system regularly, you have a huge advantage in finding ways to exercise your nascent programming skills. Unix provides more opportunity for simple scripting automation than any other general purpose operating system family, thanks to the extreme flexibility of admin scripting on the platform. In the least sophisticated case, an admin script might be nothing more than a series of shell commands saved in a file. Opportunities can be extended from there with simple looping and conditional constructs, input and output handling, file reading and writing, and scheduled tasks.
After getting comfortable with simple shell scripting, it is worth any Unix sysadmin's while to learn how to write admin scripts in Perl, Python, and Ruby. Key skills for such languages in a Unix environment involve accepting text streams via Unix pipes and redirects, processing command line options, reading and writing files, and searching and operating on text with regular expressions. An admin will also want to know the common basics of programming like producing output, looping (or recursing in some cases), and using conditional constructs for programs that make decisions based on well-defined criteria.
Writing command line tools for Unix is fertile ground for opportunities to write programs that make use of a lot of the capabilities of a scripting language. Because of the flexibility and minimalistic requirements of admin script development, writing such utilities can range from the simplest examples of useful tools to robust server processes, and even massively parallel task automation, load balancing, heuristic filtering, and other interesting problem-solving jobs that intrigue some of the world's best programmers.
While some admin scripting capabilities are available in just about any general purpose OS, and quite a few that are more narrowly purposed, some OSes are more equal than others. Unix stands head and shoulders above the norm in terms of its suitability for admin scripting, and because Unix-like systems such as the major Linux distributions and BSD Unix systems share the same basic operating environment design, they all benefit from this richness of opportunity for admin scripting and portability of script between platforms — as long as you write them to be portable (such as by using sh or Perl instead of bash, and choosing standard
sysctl values instead of the
proc filesystem for data sources).
This works for languages other than very high level, dynamic, interpreted languages as well. C, C++, Haskell, Objective-C, Objective Caml, and a plethora of other options fit neatly into the task of writing various types of simple Unix utilities. For many of these languages, a more extensive set of skills must be learned to tackle projects even as simple as small admin tools than for languages like Perl, Ruby, and the Bourne shell, but such tasks are still much less daunting to a beginning programmer using these languages than GUI application development, systems programming, and other tasks for which they are often used, especially on other platforms.
In fact, given what the Unix philosophy has provided over the years in terms of a plethora of common utilities that each do exactly one thing (for the most part) and do it well, part of the value of Unix-like environments for the novice programmer is that leveraging the power of the Unix command line environment encourages the user to think more like a programmer than an audience.
7. Web pages
Be careful about the code you write before uploading it to a publicly accessible Web server; make sure it is good before you subject the public to what you have wrought. If you wish to start more locally with scripting that you find useful, browser extensions exist that allow you to apply arbitrary scripts to pages you view — and that apply only to your personal browsing experience. Greasemonkey for Firefox is one example.
Solicit feedback about your code
Another great way to improve your programming skills is to solicit feedback from people who know more about the subject than yourself, and to learn from the wisdom they share with you. They may not always agree with each other, but if they are worth your respect as good programmers, what they have to say should at least prompt you to think about new ideas and to think about old ideas in new ways.
There are many ways to solicit feedback. These are three possibilities:
- Start working in a language that has a strong, helpful community, such as the ruby-talk mailing list for the Ruby programming language or the PerlMonks website for the Perl programming language. Join one of these communities (or something like one of them), and learn the culture, the best practices for the language, and how to get the most out of asking for help.
- Pair with another programmer. Pair programming is a fashionable practice that has gained respectability through the rise of the agile software development methodology. Two people get together to work on a project, but often only one of them is actually writing code at any given time. The pair of programmers switches off who is sitting in front of the keyboard, ensuring that both of them get substantial coding time, while the other basically reads over the coder's shoulder. An ongoing dialog about the code can help ensure that the best way to approach a given problem comes to light and ends up being used. Anyone who has had an epiphany while trying to explain a problem to another person should recognize the potential value in pair programming.
- Get a mentor. Mentors can be found in language communities, among friends or co-workers, in open source software development projects, and at conferences and conventions with a heavy technological subject focus. School may be another good place to find mentors, in the form of tutors, instructors who take a shine to you, dorm roommates, and even study groups for a less traditional and more give-and-take mentoring relationship. Sometimes, a one-on-one relationship with a mentor can prove to be the single most valuable way to get feedback early in the process of learning to program. If you are lucky enough to get a good mentor, you should take advantage of that resource, and never take it for granted.
- Create a project on a code hosting site such as Bitbucket or GitHub. Tell your programmer friends, post about it to your Weblog or Twitter account, and generally encourage others to have a look at your code and offer feedback. Make sure that the issue tracker is turned on so that people can submit bugs or propose enhancements through the code hosting site's interface.
Between practicing your craft and getting feedback from people who have insights to offer, you should be able to get well on your way to learning the basics of programming and gaining practical, useful experience at it. Now go forth and code.