Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've read lots of books for various programming languages, Java, Python, C, etc. I understand and know all of the basics of the languages and I understand algorithms and data structures. (Equivalent of say two years of computer science classes)

BUT, I still can't figure how to write a program that does anything useful.

All of the programming books show you how to write the language, but NOT how to use it! The programming examples are all very basic, like build a card catalog for a library or a simple game or use algorithms, etc. They dont't show you how to develop complex programs that actually do anything useful!

I've looked at open-source programs on SourceForge, but they don't make much sense to me. There are hundreds of files in each program and thousands of lines of code. But how do I learn how to do this? There's nothing in any book I can buy on Amazon that will give me the tools to write any of these programs.

How do you go from reading Introduction to Java or Programming Python, or C Programming Language, etc.. to actually being able to say, I have an idea for X program? Is this how I go about developing it?

It seems like there is so much more involved in writing a program than you can learn in a book or from a class. I feel like there is something.

How can I be put on the right track?


migrated from stackoverflow.com Dec 29 '10 at 22:48

This question came from our site for professional and enthusiast programmers.

locked by Yannis Rizos Mar 13 '12 at 20:41

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Some people just aren't meant to program. Only you can answer whether an alternative path would sort you out or if it's time to try something else. You're unlikely to get an answer that will be useful here. –  duffymo Dec 29 '10 at 21:10
What would you consider to be "useful"? –  user1249 Dec 29 '10 at 21:17
@Michael - I, for one, voted as Off-Topic, move to P.SE. I thought that would be a more appropriate place for a discussion on programming as a career and a craft. –  mtrw Dec 29 '10 at 21:17
@duffymo: And some people aren't meant to comment on questions. –  davidk01 Dec 30 '10 at 3:06
I think you're just taking too long leaps. Going from the book examples to full-fledged Sourceforge projects is vast and daunting. Instead, try extending what you've already built. Add features, add GUIs, add network capabilities; and pretty soon, I imagine you'll have your own project on Sourceforge. –  gablin Dec 30 '10 at 21:07

48 Answers 48

Try an open source project, see if you can fit in. Start by downloading the source, and see if you can pick up some tickets

Novice programmers should not try to join an open source project; you will simply get in the way. Open source projects aren't there to tutor beginners. –  Glenn Maynard Dec 29 '10 at 21:37
@jellyfishtree, if you cannot program that might be a bit overambitious. –  user1249 Dec 30 '10 at 0:00

Building more complex programs comes with experience. When I first programmed I thought I was doing well if it was over 25 lines long (and I had to use the scroll bar) Now I write hundreds of lines a day for years on the same project application.

You might find this page interesting "Teach Yourself Programming in Ten Years" http://norvig.com/21-days.html

BTW: It is very hard to start a program. A writer might call it "writers block". Instead I suggest you start writing code and improve it. Don't be afraid to delete large sections which don't do what you need. Start again, this time you will write with a better idea of what you are doing. Start again and you will find you didn't need half the stuff you wrote last time. When an author writes a story, it takes a long time, a lot of writing and rewriting etc. lots of reviews and feedback and its only finished when it has to be published (released)

+1 For the link. –  Bill Dec 29 '10 at 21:46
+1 For what Bill said and for discussing "writer's block." –  David Dec 29 '10 at 21:51
+1 for the analogy to writing a story. My programs are still at the "Once upon a time..." stage. –  Andy Dec 30 '10 at 10:46
One of the scariest things about programming is an empty document. Once you've crossed that hurdle, you've made good progress. –  gablin Dec 30 '10 at 20:53
writer's block. you nailed it there! –  abel May 23 '11 at 18:09

Even the biggest program starts with an idea and is written one line at a time.

The best (perhaps the only) way to learn how to write real-world programs is to start doing it. When you run into problems, you search the web or ask here for solutions to those problems. Eventually, you'll gain experience and have to ask less often.

However, there are some things that you should be aware of right from the start:

  • Hardly any big application is written completely from scratch these days. You can get much more done in a much shorter time if you use existing high-quality libraries and frameworks. Getting started with these often feels quite frustrating and more work than doing it yourself, but that's almost never really true.
  • Thinking carefully about how you structure your program (how to design it) is very important once your programs get bigger. Spend some time on that, and read some books about design (I'd especially recommend "Clean Code") and software engineering as well as about technical basics.
"The best (perhaps the only) way to learn how to write real-world programs is to start doing it." More or less what I as going to say. You can only read and "understand the basics" so much... rubber has to hit the road somewhere. –  WernerCD Dec 30 '10 at 16:27
+1 for the line "Start doing it." You can't learn experience from a book. –  Stargazer712 Dec 30 '10 at 18:29

You don't need to have a great idea to start programming something. I'd start from the easy part. Like, a program that you already use it. Try to make something that you already know how it works. Faces your problems, so you'll learn it faster. Once you have more experience, you'll start to have some good ideas of programs to make your life easier while programming, or just a good program to do something you never thought about it before. I've been programming Java for almost a year, and other languages for a couple of years. It took time to start doing what I really wanted to do. I just started doing my own stuff. Thanks to StackOverflow. I didn't know about it before.


I was always overwhelmed by very large projects also, like the ones you find on SourceForge or GitHub. I wondered how anyone, or even a team, could understand what was happening across 10's or 100's of files, with thousands and thousands of lines of code.

No one does. At least initially.

Projects are organic things. What starts off as a really simple idea, can quickly expand into a massive piece of work. This is, I think, the main reason for iterative development instead of the classic waterfall approach.

Think of building a car. While it looks fairly simple from the outside, delving even a small way in you discover that there are a huge number of considerations, trade-offs, and innocent cases that need to be handled.


In the case of a semi-large project, it often starts out small. "I want to build a cache server". So you spend a few days hacking away, and arrive at something that works, but could be improved dramatically. So you add the concept of threading.

Then you run into concurrency issues due to that threading. So you fix by changing to concurrent data structures.

Now the the process has slowed down. So you change the concurrent data structures to regular ones, but provide locking mechanisms for synchronization.

Everything seems to be running fine, except users start to complain that operations are not atomic, and data is being corrupted.

So you add in some classic atomic operations, like increment and save. This works, and your users are happy. But someone opens a ticket asking if it's possible to do list operations.

So you spend a week or two building that feature in. At about this time, a friend decides to help you. You work on it together, complete, and release it.

Two tickets open. There's a bug in the list processing, and there are some rare cases that are deadlocking.

Your friend works on the list processing bug, while you tackle deadlocking. You realize that a fairly significant re-write to atomic operations needs to occur.

... and so it goes.

This seems fairly typical of how a project grows. 10 or so files have just grown to 20 in a couple of weeks. New features are added that weren't apart of the original plan. Convoluted bug-fixes are added that grow the code unnaturally large.

My advice:

Don't become overwhelmed. If you have an idea, implement pieces of functionality. If it's worth pursuing after that, add bit by bit. Let your project grow naturally.

+1, I really like your example. –  Scorchio Dec 30 '10 at 0:07
Excellent example, but if it could have started a little bit smaller it would have been even better. For instance, starting with building a few data structures, then a some code which provides an API for these data structures, then some code which uses this API to implement the cache function, and then finally a GUI on top of this. Voilá, you've written a cache server! –  gablin Dec 30 '10 at 20:51

Write a 200 line script. Then start improving it.

Featuritis will have you out to 100 source files and several hundred KLOC in no time :)


Ok let's start with your idea for program X that does something useful and let's break it down:

  • Use paper, mind-mapping, or diagramming software to layout the logical flow / flow(s) of the program.

  • Since you are just starting out pick ONE of those items (preferably near the beginning) and break it down even further.

  • Write your code for that first and use it to build upon

Does Program X need to open a file, manipulate it, and create an output file? See if you can open and echo the file as your first step. Do you want a nice user interface? Build one that can run your file echo program, etc. You'll not only be building code you can use in your complex program step by step, but you'll also be building your language knowledge as you have to search and lookup information.

As the saying goes - Gnome wasn't built in a day :-)


Just like driving or cooking, programming is something you learn to do by doing. Practice is irreplaceable.

If the textbook examples are already too basic for you, that's great! Time to move for something more complex - and you already can figure out some challenging exercises for yourself.

Or, if you have a specific idea in mind, break it to bits. Solve a small subset of the problem first. Then expand. When integrating the new code to your existing code becomes hard, then you redesign everything.


"They dont't show you how to develop complex programs that actually do anything useful!"

Without a definition of "useful" there's really not much we can do to get you on the "right" track.

We don't know how you're failing, or what's going wrong. We can't tell what track you're on.

Somehow, you have a notion in your head that you're not communicating.

Software -- programming -- is all about getting a notion out of your head into some language (Python, Java, English, whatever).

One important step in programming (and asking questions) is to define your terms. What do you mean by "do anything useful"? Be very clear, very complete and very precise.


What you're talking about is more software engineering than programming. It's a little bit architecture, a little bit "best practices" and "design patterns," a little bit working with others. While there are books that can help, most of it comes from experience. Nobody starts out writing, say, Microsoft Word.

Think about a large, "real" program that you would like to write. Now think about the various pieces you need to build to make it work the way you want. For example, in a modern first-person game you will need a 3D graphics engine, non-player-character AI, a music/sound module, a physics engine, and a top-level module that enforces the rules of the game (knows the "map", how the various characters interact, etc.). And then there is the artwork and character design and the music, none of which are code but which are necessary for the game to be complete.

Now: Which of these will you build yourself and which will you get elsewhere? Most large software projects are not programmed from scratch. Perhaps you will use an off-the-shelf 3D engine and music/sound module and program only the things that make your game unique. OK, so you have to figure out what third-party modules you're going to use, which will involve factors like cost, what languages they work with, what features they have, how their API is designed (that is, how complete it is, how well it fits with your personal programming style, etc.). Maybe you will write "proofs of concept" or test programs using one or two candidates for the various third-party modules to make sure they will do all the things you need and are easy for you to use.

Also, even the code you want to write yourself may be too big a job for you alone to complete in the time frame you have in mind. How many other programmers do you need working on the project? How will you split up the job? How will the various modules be designed so they all fit together even though they were written by different people? How will you all work on the same source code without wiping out each others' changes (answer: version control, which is extremely useful when you are working solo but indispensable when working with others).

Once you have figured out what modules you want to write in-house, you perform the same process. Figure out the pieces of each module, how they should fit together, and which you will write yourself and which you will get elsewhere. Continue breaking things down until each piece is small enough for you to hold in your mind, for you to say, "yeah, I could write that!" And then do so. As you do, you will encounter unforeseen obstacles in how the various pieces of your program fit together. These will be frustrating, but they are opportunities for you to learn more about your craft, and should be viewed that way.

Initially, you will only be able to hold very small pieces of your program -- say, individual functions -- in your mind, and so you will have to break things down a lot before you start coding. As you gain experience, you will think in functions rather than needing to think about functions and start thinking about objects. And then you'll be thinking in objects and thinking about larger modules. Finally, you will be thinking in modules and thinking about whole, large, real programs.

And then you will discover that you still have a lot to learn... but so it goes. If, as a programmer, you ever stop learning, you are obsolete and will be replaced with a newer model.

Anyway, don't be afraid, and don't worry if this sounds... awful or impossible and you don't really want to be a programmer after all. It's not for everyone. I love music and desserts, and I can play keys a little and cook some dishes, but I am not willing to put in the time it takes to become a great musician or a master chef.

If it turns out you don't want to be a programmer writing large, real, desktop applications, there are other types of programming jobs. You could become an embedded programmer, for example. There are definite, interesting challenges involved in writing embedded programs, and you are doing useful work, but typically the programs are rather smaller than desktop applications. Or you could write web applications. On the Web, it's easy to glue little bits of functionality together, so you could write (e.g.) a Web comment system and it would be useful even if it's not a whole Web application. It is easy to incrementally improve stuff on the Web, too, so you can start with (say) a basic Web mail client and, over time, evolve it into something like Gmail. (But don't do that, because then you'll be competing with Gmail.)

If you don't want to be a programmer at all, but still want to work with computers, possibly you could go into IT or some other technical field. In these cases, knowing as much programming as you already do is very useful, because your peers may not even have that much. Or, you know, become a musician if that appeals, because (like most fields) it involves computers today. Write little programs that manipulate audio or MIDI files in various clever ways, thus making you a better musician. You will find that whatever programming skills you have can be applied in a lot of fields to make you better at your job.

I guess it would depend on what you mean by "embedded." If you mean something like smartphones or integrated automotive systems, I can believe your 100 man-years. There are still plenty of smaller systems to work on in that space, though. –  kindall Dec 30 '10 at 17:02
What's the harm in competing with GMail? If something you've written single-handily actually can compete with something that Google released, you can consider yourself a pretty damn good programmer. –  gablin Dec 30 '10 at 21:00

(answered above in the comments already. It was suggested to submit this as an answer after the question was re-opened.)

You start with a problem - something you want to solve - no matter how complex you think it is. Then you take this problem and you write it down and start to break it into smaller problems. You then break down those smaller problems, etc. until you have something primitive that you already know how to solve or can do so with some effort. You start coding each of these pieces and organize them into different functions or different classes, etc.

Then you work on the next sub-problem. As you are working on each problem you can write small test cases and actually see you progress coming into fruition. There will always be challenges along the way, but at no point will see it as something too colossal to even approach (what are seem to be dealing with now). This is true for programming and many of life's challenges. They key is to break it up.

As for what to do - the idea. You can try to invent something new, but you can also take something that you might have a passion for and already exists, but just make it better or even just different. I'm currently writing a guitar tuner app for Android in my spare time. I know there already exist many other guitar tuner apps, but I thought this would be a fun and challenging project so I took it on. At first it seemed almost impossible, but after I broke the problem into smaller steps it's actually coming together nicely. Divide and conquer and be persistent with your goals.


Start with computer games, like everyone else did. A good game is both a programming and design challenge, needs careful thinking about internal structure, and it uses system libraries in ways that teach a lot, but don't tend break stuff and don't require a "good reason with good result" like actual "useful" software does.

General rule is that after writing enough stuff, some kind of enlightenment will unavoidably happen.

A nice point to start (if you feel like C) is http://gamedev.net/, especially http://nehe.gamedev.net/ . There are also many other good points to start :D

(Oh and I just realized why everyone starts with games. Shiny and pretty stuff is motivating.) –  Mirek Kratochvil Dec 29 '10 at 22:21
everyone? Bold claim. –  Clifford Dec 29 '10 at 22:24
I didn't start with a game. I'd find that beyond complex =P –  Josh Smeaton Dec 29 '10 at 22:26
Most people these days start with a webapp, much lower barrier to entry (it's just text). –  slebetman Dec 29 '10 at 23:33
Your first comment was probably better than your answer - shiny and pretty stuff is motivating. That's what matters. –  Scorchio Dec 30 '10 at 0:05

The primary difference between sucessful large applications and academic exercises is typically that the former are designed against a set of requirements. If you simply start with a vague idea in your head and start writing code, you are unlikley to get far.

So programming ability is probably not the issue here; what you really need to get you further is software engineering skills; i.e. the ability to capture and specifiy project requirements, and then to design a software architecture and detailed design to meet those requirements - this is the road map that will keep you on the right track throughout development. That is not to say the the requirements and design need be complete before you start to code (the waterfall method), incremental developmennt is a more flexible approach; but you should have some sort of framework and idea of how the application elements will interact and communicate.

Furthermore, a requirements specification and design is more-or-less essential if the project development is to be implemented by more than a single developer (another common feature of large projects).

Another feature of sucessful large scale applications is a strong motivation to complete. What would motivate you to do that I cannot say but in my case I am paid for it, I seldom write software for mere fun any more, but getting paid to do what you might otherwise do for free in any case is a great way to make a living.


When I want to learn a new language, I usually try to implement some fractal graph. That way you'll have immediate feedback on if it works and it's very rewarding. And there's lots of ways you can improve a fractal. The naive implementation of mandelbrot is slow as hell.

It's no very useful, but you learn a lot and it's beautiful to look at.


I get asked this question all the time, e.g. how to get started. It's simple really. Here is a step by step.

  1. Come up with an idea. Sounds like you already have that.
  2. Simplify your idea to its basic core - something you think you might be able to tackle
  3. Layout the UI on a piece of paper or napkin, whatever.
  4. Try and layout the UI in your development environment.
  5. If you encounter difficulties, google, google, google, ask questions on stackoverflow, use the living crap out of internet resources to get help. Ask friends and co-workers who are programmers to help you with specific situations. Go back to step 4.
  6. Start writing the logic of your application. If you run into difficulties, go to previous step and try again.
  7. Soon enough, you'll have something working soon.
@Chad I disagree with you. For noobs, the logic is abstract, but the UI is easy to grasp. The reverse comes with experience. –  AngryHacker Dec 30 '10 at 17:02

Create something small stuff. Don't mind, that your program will be the 1000th doing that.

Some ideas:

  • a clock (digital first, then analogue-look),
  • automatic labirynth creator,
  • directory structure displayer,
  • mp3 album lister,
  • etc.

Choosing platform, tools are the part of the task.


You won't figure out how to program unless you'll face a real task. No theory would ever replace a simple real-world task. Before starting working on r-w scenarios, I was naively reading lot's of books, with all examples, but when I faced a real problem, I just couldn't gather all my theoretical knowledge to complete the task. If you are starter, I'd recommend you to get the tasks from anywhere you can. Do not think they're useless unless you've solved them. As a first step try solving data structure problems, such as sorting a linked list, performing DFS, BFS on trees, graphs, etc. Not only will it improve your coding skills, but what's more important, it will improve your analytical and algo skills, which trust me is a valuable knowledge. Then, when you will know that you can rock with pointers, recursion, references, etc, try implementing a simple linear equation solver or something like that.

Bottom line. It's all about practice. Just keep digging and code, code, code.


You can find plenty of good answers here, but still, let's add this.

First of all, don't panic. A lot of people learned programming to different degrees, you will find the level that suits you, that's for sure. Work hard on reaching a quite high level, one step at a time.

Start in small. I remember one of my first applications, it was basically a frontend for an MP3 encoder. Nothing fancy, it just started a command line app with different parameters. But I enjoyed it!

PS: One of the most useful skills is that you should practice all the time: how to ask better. If you can ask in a really good way, you will find the answer in no time.


One of the hardest things to do when you are a beginner is setting realistic goals for what a "how can I improve"-exercise should contain at your current level.

Hence I would suggest you choose to practice solving small, given exercises, because the ability to finish a program according to a given specification is a very valuable thing for everybody who programs for a living.

I would suggest you have a closer look at http://projecteuler.net/ which has a lot of exercises and an automated "check answer" system, allowing you to work at your own pace. The exercises are well worded, but may require you to think. Some may even require you to think a lot, but even failing to solve those, will teach you something useful.

The full wording of problem 1 is:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

Do you think you could solve this? Then do it!


Programming is about problem solving and communication, not writing lots of code. Code is just a necessity, you should usually try to write less code, not more.

If you don't know where to start, maybe you just don't have any problems!

Look at Linux and other Unix-like systems: they all consist of many small applications that do only one thing, but do it well.

When I needed a script to find 10 largest files in a folder on my computer, I wasn't reading books. I just googled and used one of the existing solutions. Did I write any code? - No. Is problem solved? - Yes. Is this one-line program useful? - Heck yes.

Programs with thousands of lines of code are usually written by more than one programmer. You won't be able to write whole operating systems alone and you don't need to. They also often use cheats like version control and unit testing.


Maybe you could choice a scripting language to start. I started programming with the C language. In my opinion the C language is easy to getting started with, but much more time is needed to know the algorithm and something about operating system. And everytime I exercise is simply with a DOS GUI, that makes me depressed.

And later I chose a scripting language named ActionScript to start. The scripting language is an object-oriented language, and it can control the behavior of a Flash movie. The scripting language is easy for doing some work that is close to the problem domain, just like trace("HelloWorld") in ActionScript to output a string. And it has a powerful IDE to let you to checkout if your program is going well.

In a word, if you want to start programming in a quick way, a scripting language may be a good choice :-)


So there are a ton of answers so forgive me if I repeat much of what has already been said, but here is my 2 cents.

First pick an idea. Any idea will be fine, something simple would probably be better then large. Projects have a tendency to grow in their scope very quickly (some call it feature creep).

Next make a skeleton for the project. This will require a little bit of architecture and design knowledge and you'll probably get it wrong the first ten times you try it - I did. Simply lay out a decent file structure and maybe a small skeleton of code that shows the important parts of the system.

Save the skeleton in your VCS (pick your poison with this one and hold on when it leads to a holy war). Once you've started using VCS, constantly using it for small changes becomes second nature, but make sure to start.

Now pick a small, but important feature for the system and make it. Don't worry about making sure you have everything encapsulated perfectly and that it has the "best" design (that will evolve with the system). Just get something that will work. Also getting some unit tests will help ensure you know what happened when something breaks, if you run the tests regularly.

Build your system. This would also be a good time to get an automated build system and continuous integration. If you don't know what they are then either learn it and try, or just continue at your own risk; either way keep working.

Now pick another feature and repeat and repeat and repeat.

Once you think it works well, show it to a friend. The friend doesn't have to know how to program or even know what the program does. One you'll feel good about showing to someone and two it will help you know exactly what the system does.

If you get to the point where you are very confident with what you made, release it online and try and get feedback. A repository hub or the programmers sub-reditt might provide you with some constructive criticism. Try and find a CS/SE professor and have him/her look at it. Maybe ask a professional programmer. Just get another programmers opinion.

Once you finish (or probably before) you'll realize that the code you initially wrote is a lot worse than what you made recently. That is perfectly natural and happens to all of us. You now need to find a new project and learn something new - maybe a new testing strategy or how to use Service Oriented Architecture.


Something that may help is think of a simple problem you have day to day where something you might do by pencil and paper could be replaced by a program.

This gives you a relatively simple problem with a fairly known solution that just needs a level of automation. Keep in mind this doesn't need to be the next MS Word/WordPad/NotePad; just something that solves your (simple) problem.

For example a problem that I keep reimplementing when working with a new language is a simple timekeeper app. The app is used to track billable hours to different projects during a day. A fairly simple program with lots of little gotchas, like how do you handle reboots in the middle of the day or how do you add/remove items from your list.


Write a specification. What do you want your program to do? The screens (if it's a UI based program) the logic, the input/output, etc. Keep the scope limited to what you can do in a reasonable amount of time (one week? one month?).

Then build it. Stick to the specification, make it work according to what the specification needs. Sure you will come across distractions, sure you will have to do some research because you have never faced a particular issue before, but you will build something you wanted to build. This is different from building something that you just 'can' build.

Once you finish, refactor your code, try to make it more efficient. Then if you think your program is still not done, start over, improve the specification, improve the code and keep doing this.

Remember, most commercial software solve a need.. It is very important to define the need, and the solution to filling that need before actually solving the problem. And as the need grows bigger and bigger, your software will grow too, over time!


I learned programming because I know what I want to program.

Programming requires problem-solving skills, which it's hard to learn. Try to reproduce something "everyday", like a vending machine program that calculates changes in coins, and also an elevator simulation.


Try thinking up the smallest program you want and code it. Just the other day I wrote up code that automatically downloaded every file from a list of files. That was actually the easy part. The hour was mostly spent on creating the GUI, having it load and save settings and small simple things like that. The GUI is a time vacuum.

Also I suggest using a language with a massive library (it doesn't matter if it's portable or not). And a statically compiled language if your starting out (which means no Ruby, Python or JavaScript). I like .NET using the C# language. You can try Boo with SharpDevelop or use C# or VB.NET using Visual Studio Express. I like Visual Studio because I am a power user and use things like Ctrl + -, Ctrl + [, Ctrl + ','. But anything with breakpoints and the callstack is good. The only reason I can stand to debugging JavaScript code is because Firebug has these (along with immediate window and a watch).


The biggest challenge to learning how to program is to come up with something someone finds useful.

My biggest issue in programming for myself has always been inventing problems that needs solving.

I started programming in the mid 1980s by doing a course and then working for a company that told me what to solve. Your alternative is to do what I did in the 1990s when I wanted to learn JavaScript - I joined communities (one was the site Stack Overflow calls the hyphened site - start the downvoting...) where people asked questions, and commented with my suggestions on how to solve the problem. Having a specific task with a known input and output, really helped me focussing on finding the answer or similar answers and applying this to the problem at hand. After a few years of answering questions, I was fluent.

I am now doing the same with jQuery. I would have a hard time learning the jQuery syntax without specific problems that can be solved using that framework.


I died too much in some ZX Spectrum game, so the only way was to add more lives. I had a book, that described what code and where I need to change, so it was pretty easy. Then I found how to add ammunition (unfortunately the game become pointless after that).

So from my point of view, the best way to learn - is to achieve minor and easy goals. For me it was modifying existing code. If you are satisfied with every program you meet, maybe programming is not for you?


Divide and conquer.

It's as simple, or hard as that.


BUT, I still can't figure how to write a program that does anything useful.

Really?? Well, I suppose if you just read the books and didn't do any example programs and so forth then that's possible, but seems a bit overstated.

Anyway, the best advice is to just start working on some idea that you are interested in. If you have a real interest then it can start small and grow and grow. That's usually what happens with me. I might start a project just for the fun of it, thinking it will just be a small test project. Then I add and add....