Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 Dec 29 '10 at 22:48

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

locked by Yannis 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

Have you played the game of Chess ??. One can teach you the moves, but making them useful is your own concern. You can't learn from a watching a chess game played b/w two individuals instead of playing yourself; Similarly learning from a single USEFUL project as you said, won't help. You need to delve into your own requirements and make a project out of it.

Every project has his own requirements. Seldom, you will find a project using all the features of the language. Therefore, the books focus on the basic features, rather than taking a project and reading out.

To be honest with you, I too searched for a working sample of WPF application when i had to make one few months ago. Found nothing and then read from the books and internet and got things rolling.

And the last thing is that these already made applications or projects make you more confused than ever, because they are made by professionals who have their own styling and tweaks. To get to that level, you need to forget about everything else and just start coding and later on StackOverflow is always there to help you out.


Enlisting the help of Adderall.

It is used to treat ADHD which is apparently very common in the programming community. I'd say drugs are not the be all end all but he does have a point. – Terrance Jan 6 '11 at 15:51

Have you read Code Complete 2, and The Pragmatic Programmer?

These two books taught me a lot more than any course, tutorial, book or video.

Programming is about learning how to build something from scratch with a specific set of tools. But, if you do not know the fundamentals, you can't do anything.


"Out of Box thinking"

Hey, I asked myself the same questions five years back (at that time I hadn't heard about Stack Exchange). Studying programming every time won't make sense, you need to develop something.

Determine what to develop

1) Small goals make small and successful first projects

2) Plan so that you have little parts that clearly work and show you progress

3) Find something you're passionate about but is still small enough to be achievable

  • I build personal albums - which I have gained some Flash knowledge, Photoshop
  • I build my own personal blogs - gained some PHP knowledge
  • Bought Internet domains - gained some server knowledge

  • I find many freelance projects - I read their requirements and tried to build my own applications, I gained a lot of knowledge of programming, documentation, etc.


Another problem is that, you need a different programming language depending on what you are trying to program.

If you want to program a Windows application that extends a Microsoft product, you have to use .NET C# or VB.NET or VBScript. If you want to program an iPhone you have to use Objective-C, Java for Android, Silverlight for Windows Mobile, maybe Java for financial applications, etc.

It's not like you can learn one language and then be able to program anything you want...


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....


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?


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.


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).


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!


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 :-)


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.


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

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.


Yeah it's amazing how many "moving parts" are involved in making our software/hardware run. Partly it's because problems are incredibly complex, and need to be subdivided into managable parts. Partly it's because problems are incredibly complex, and no-one knows what they are doing. :) We have tens of programming languages, and hundreds of programming frameworks and libraries. Everything is blackboxed and layered. You can't do anything useful within just one layer of this mess. Need to learn and master the limitations and quirks of multiple layers. And writing everything yourself is close to impossible. Simple things grow unimaginably difficult as the code base increases.


First, you are already doing the prerequisites by taking classes, reading reference material, looking at open source projects, and staying curious with questions. I stress this because I've personally encountered similar questions before the person has done any leg work on their part (specifically, individuals circumventing classes and hoping to take short-cuts). Now, I think back to when we had labs about Turing machines and how at the time I felt it wasn't real programming. These are the experiences you will keep that anyone taking short-cuts is skipping.

  • Sign-up for student projects. I got involved with (CSUA) a group of like-minded students to build a game for the carnival booth my senior year. If you continue to enjoy it and think you want to expand your involvement, really take advantage of resources. Find out about projects, talk to your class mates, your professors, and land an internship.

  • Sit with an experienced programmer. There has been about three times in my history when I watched another person program that was truly inspirational. To them, they were just writing code and thinking out loud. No exaggeration, I felt like I absorbed more from listening to them than I would years on my own. If you encounter more, you are that much richer. We are lucky to be in an age where we can watch videos, inspect complete source repositories, and search a huge online store of knowledge instantaneously. It's no substitute to the in-person experience, but in the absence of a mentor it's a dramatic improvement over traditional material. Looking at raw code by others by itself may not lead to anything, though. You will want to have something in mind and a good debugger to step into logic. One of my fondest moments was making a Quake mod and it wasn't the mod itself that had anything memorable. It was seeing Carmack's in-game logic. The mod was just a reason for me to dive in.

  • Practice explaining and answering questions posed by your lab partner. Volunteer to help teach. Maybe form a study group and require each member become an expert on a class topic. Then grill that person and have them grill you. When you are forced to answer questions, you will be obligated to learn the answers yourself. When you can explain concepts clearly to others, you have enriched your own understanding to the point where you are able to convey it outside of a book and your thoughts.

  • Last, don't be afraid of learning the hard way, get your hands dirty, make mistakes. This can also be called experience. As a more practical example with regards to your question about projects with unwieldy code base and large file number counts, do this exercise: use a single file for your work. Really I'm not joking. This very same question actually came up at my current and previous company. Here another developer observed that I prefer to keep one file for each class. This seemed foreign to him and, in a related matter, he also did not like partial classes. So one way for you to get a sense of when or where it's appropriate to split up logic into separate files would be to begin with just a single file. After you have practiced the one file rule on multiple projects hopefully of increasing complexity, you may run into a project where you have so many classes in the one file that you find it difficult to read or due to version control becomes difficult to collaborate. At this point, you want to create separate files to group different classes. Given your preference, you may decide early that you like all data classes in one file. Then again perhaps later, you may decide that you like separate files even between data classes as a group.


You need real world experience!!. No book can teach you that!

You have to learn how to read others code, how to maintain it, how to hate them ( both the code and the coder ) how to improve it, how to think you can do it better and a few months later shout out loud I'll kill who ever wrote this pieces of code!!! Only to find out in the source version control it was you!

You have to understand books are very specific and some times for people who already know how to develop software.

So I would suggest you to find some programming job. If needed, apply for the most basic entry level. Probably you won't earn as much as you think you deserve, but use a few months to learn how software is developed in the real-world ( and it is not always as perfect and with all those beautiful best practices we read in the web, many times, code quality is very low, depending on where do you work, but that's part of the experience )

Keep reading your books, you'll find out, every year you understand a little bit more ( or differently ) the same topic, because you can see it know with the glass of experience.

If you manage to get a job with talented developers, much better. Learn from them, don't be afraid to make mistakes.

Until you have to fix your first live-production urgent bug, you won't know what software bug is!



I guess your problem comes from: 1. the confict there is between theory and practice, and also that... 2. ... you must realize that your code will be run by other's code. 3. you can't code something if you have no idea about what you could make. 4. You know half of the difficulty

  1. Knowing a language by theory doesn't mean you "speak" it: that's difference between reading english and speaking it. Also the great number of different tools available to compile, link, edit a source code will make your head spin.

  2. when learning how to program, most if the time a terminal is used to input/output text, because this is most simple way of dealing with programming. In fact, programmers use libraries (like Qt), frameworks (django I guess) and other shortcut code to be productive. Of course if you feel you can write your own wheel, don't reinvent it and read books about compiler design and kernel design: there's a lot to learn in these: maybe you feel it's stupid to de apps that doesn't require a lot of technicity.

  3. Invent something ! Of course you could do a text editor, a game, etc. The thing is, you won't do those if you don't see any reason to: these program will be useless for you if everything you think about has already been made. Personnaly I still dreams to be able to code a facebook-like decentralized p2p protocol with chat, offline messages, etc all in one so it can be used with wireless embedded devices. Internet gives a lot of possibilities, don't forget to think about it.

  4. In fact the theory is necessary to practice, but that's not all: algorithms and technics aren't part of the theory of programming, there are a lot of paradigms and other "standard" way to do your code: design patterns, linked lists, etc etc.


"The secret is there are no secrets" - Kung Fu Panda . First don't panic, choose a language and start writing something like tic tac toe game and keep adding new features. You have mentioned that you have read too many books but have you implemented what you learn? Try to look around you and find what manual system you can convert to automation, or what existing program can you re-engineer. Patience and Imagination is key to success in programming though i am not a great programmer but i am trying what i shared and its working. :)


In college, there was a class called programming practicum that basically taught this ramp. Early on you were given a UI for a basic shopping application, and had to code the backend, the last month was Tetris from scratch. I think around 50% of new students (not retaking the class) failed, because ramping from small to large is incredibly difficult.

I'd suggest one or more of the following:

  • Download an open source project, and add something. It doesn't have to be useful or good, but you'll have to look at the structure, which will give you a feel of how large project is built.

  • Just design your end project on paper, with arrows for dependencies. If you're making snake, you might have Snake head, snake tail, food, empty space, wall, board, current direction, etc. Might help you realize if your project is a lot bigger than you think.

  • Take a basic project, and make it bigger and bigger. You'll probably do a lot of refactoring, and hopefully you'll learn how to make smaller projects that can easily be added to.

  • If you know somebody experienced, tell them your idea for a project, and have them write your classes + some important methods, probably would take an hour or so. That way you can just fill the methods out, and always know what you need to do next.

Finally, whatever you do, you should probably use a basic MVC (Model, View, Controller) design pattern. Without going into much detail, put your view (UI) into 1+ classes, your controller (Input, output, etc) into 1+ classes, and your Model (Logic, Data, basically everything else) into several classes. It is an easy way to get basic organization.

Remember, this step is hard. It's true that some people simply cannot program, but you're probably just stuck at this stage. Good luck!


You're looking at the whole huge program and it seems impossible. But the whole thing is made up of little stupid programs like the ones that you're saying "don't do anything useful."

What you need is experience breaking down huge complex tasks into tiny simple tasks. That is the root of all programming. The rest is just semantics.


When I started programming, I loved computer games. So I started writing my own games, as soon as I had any tools at hand to do so.

Quite naturally, my very first game was a text adventure. Similarly, you could start with a quiz or something, or some sort of guessing games.

Also, you could start with something, like a slot machine (you don't really need the animations, or even pictures. Just use A = apple, L = lemon, S = start, P = Plum etc.).

This will teach you the basics of handling some user input, maintaining game state and generating output accordingly.

I headed down this road quite far. I progressively learned, how to read out the keyboard state, or the mouse, how to use graphics code. I learned more about the language itself (I started with PASCAL) and used this to enhance my existing games or just started something new.

I think games are really great to learn programming. Even with little experience, you can create small things, that give you small moments of pride. Because you create something, that's fun. Building actual applications is quite pointless, because it takes a lot of work to create something, that is actually useful, whereas it is surprisingly simple, to create a small game, that turns out addictive.

You may want to actually use an educational language (in my case, this was PASCAL and in retrospective, I think it proved to be quite a good choice). A lot of them are specifically aimed at creating games and such.

Creating applications is more than just creating algorithms. You have to design features, you need to organize and structure your code in different layers and modules. Unlike the rather "atomic" problems you're given at university, applications are sometimes best developed in an incremental way. You start with something and you add things on top of it. Thus already having something to start with (as you would in some of the languages listed in the wikipedia article), you save yourself a lot of frustration and start creating something right away. (A colleague of mine started programming by writing quake 2 mods). At some point, you will come to find the limitations of these easy-to-use tools, but until then, you will have a lot more insight and understanding. Probably enough, to reimplement the functionality they gave you to start with yourself.


I have found that something which benefited me greatly in this area was looking at code that other people have written. I mean code they wrote outside of school since school assignments typically are not applicable to the real world.


Simple, try to do better than written in your book.


The only way you're going to learn to program is by... writing programs.


I think part of the problem is that when you read programming books, they just teach you the language. They fail to mention that in order to program almost anything, you need access to programming LIBRARIES and SDKS, etc. Just knowing the language unfortunately isn't enough.


Think of something that you would would find useful and try making it. I mean something sensible, not Photoshop :-)


Divide and conquer.

It's as simple, or hard as that.


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.


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.