The computer is an automation tool. When you write code, it is serving the purpose of automating a specified and designed process. The things you write in the p

The computer is an automation tool. When you write code, it is serving the purpose of automating a specified and designed process. The things you write in the program to make the automation happen only have to be as complex as is actually necessary for that task. First, have a good problem to solve. This is your design - developing your sensibility for it is somewhat independent of your coding skill. For your own project designs you should always prioritize your own motivations first, because there is nobody you are directly obligated to finish for. If you don't do this finishing will become very hard. Find problems people have already solved and reinvent their wheels so that you learn more about the problem domain. (e.g. if you want to learn how Facebook works, clone parts of Facebook - if you want to learn how operating systems work, build a toy OS, etc.) Or, find clients who seem to know what they want(nobody really knows - the design will change) and build things for them, on their terms, in a way which will get you paid so that you have the obligation to finish. A good problem should be either obvious and a bit boring on the surface(an everyday thing made easier, more available, more accessible), or scary(a technical problem that you are not immediately sure how to solve, or are not sure how long it will take to solve). Usually projects start out looking like the former and then develop parts of the latter as you go along, forcing you to "plateau" on new features as you build out the infrastructure. You can also slice up a project into defined versions with incrementally larger sets of features so that your expectations for "done" are managed - if you don't get to some things, you still have a practically useful program. Then, start working on it in small steps. Maybe you aren't sure how to envision the whole problem. In that case, you can simplify it by reducing the problem into a bunch of facades that are intentionally incomplete. Maybe you want to render a page that shows tables of data, for example. You can start by building up a facade for the presentation layer and see what kinds of data will have to be passed in to make the presentation work. Then you can mirror this at the other end and only solve the problem of "how to store and process the data." Then you figure out a protocol for making the two parts communicate. If you design each part so that it is simple to rewrite, the code will be maintainable regardless of your techniques or technologies, because then you can rewrite your way out of any corner you get painted into.