I still can't figure out how to program?

Question

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?

Answer 1

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)

Answer 2

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.

Example:

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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.

Answer 13

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

Answer 14

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

Answer 15

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!

Answer 16

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!

:)

Answer 17

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

Answer 18

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.

Answer 19

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.

Answer 20

Divide and conquer.

It's as simple, or hard as that.

Answer 21

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.

Answer 22

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!

Answer 23

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.

Answer 24

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.

Answer 25

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.

Answer 26

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.

Answer 27

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.

Answer 28

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.

Answer 29

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

Answer 30

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!