I am always looking for some nice ideas/projects to work on.
Sometimes I have to agree with my colleagues that it is a waste of time to program something that has been done dozens of times.
But some projects really helped me to understand the problems software is faced with.
How do you handle projects/ideas that have been done before, but you don't really get the point out of it (I mean understanding what is really going with it)?
I'd say that the scope of suitable projects for beginners depends a lot on the language, and if the beginning programmer already has some goals set. You wouldn't recommend the same projects for a beginning C programmer as you would for someone starting out with PHP or .NET for web services.
If it is interesting for you...do it. Best way to learn.
Many times I have sat down with a manual or reference book to pick up a language or framework and found it too dry to make it more than a few chapters. Ultimately I didn't really own the concepts until I implemented them in an application that really caused me to focus without "forcing myself to".
Additionally, I often find myself rewriting code not because it needs it but because it helps me understand it. I try not to do this but if I am going to own it sometimes it helps to reinvent the wheel.
I only re-program software which is fascinating and which offers some space for improvements.
That way I'm motivated and some day even a popular freeware/open source program can come out of it. (long term motivation)
I've never re-programmed something because I didn't understand how a particular software product works (You can't create something you don't understand)
But I frequently make small proof-of-concept applications, targeted at a specific area of interest. That way I gain experience (positive and negative). It also helps to remember certain things if you actually have hand-coded them yourself.
If you can plan the project easily on how it would be done, then probably it is not a good idea reinventing the wheel. But if you are not clear in your mind then for learning reasons you can implement it.
In the interest of learning, it is best to pick projects that you will fully understand once you've dug into it. If you code up some examples/projects but do not actually understand the point of doing any of what you did, then you really did not learn anything, did you?
I once picked up a book and worked through every example, hoping I'd have learned what I needed to when I was finished. It didn't help at all. It wasn't until I did my very own personal project from scratch that I truly began to understand what it was I was learning. I guarantee it is because I understand the inner workings and main goals of the project.
If you do choose to re-program something, make sure that you make it into your own project so that you can fully understand what it is you are trying to accomplish.
The main reason I indulge in reinventing the wheel sometimes is that not all wheels are perfect.
If you feel that a particular problem could have been solved differently in a better/more performant/more efficient manner with more intuitive code, go right ahead (and if you succeed, post it on the net or blog about it so others can learn or provide you with feedback).
So, it's not always a waste of time. However, it would require that you do considerable research on the problem to find out the less-obvious pitfalls and barriers that others encountered.
Compilers, operating system, databases etc have already been written and tested. One can understand them just by reading literature concerning these concepts. But you will get a thorough understanding only when you implement a decent compiler or small database.
In this case the intention is not to use what you have written in production code, but to satisfy your urge to know something deeply and appreciate it. Under such circumstances reinventing the wheel is a nice idea, because it helps you become a good programmer.
To answer the second part of your question, start with a small component in the system.Try debugging it, read design docs , play around with, see how it fits in the overall system. Gradually expand this to other key components.
This way you will understand the project/system better.
Hope this helps.
There's certainly nothing wrong with reinventing the wheel as a pure learning project.
Reinventing the wheel is great for giving you an inside perspective of why many wheels have spokes and give you new ideas on how exactly you can use wheels.
However, I'm not sure what you mean by this:
Projects/Ideas that had been done before, but you don't really get the point out of it (i mean understnading what is really going with it)?
(maybe it translates badly - what did you mean to say in German?)
If you don't understand the point of the project/idea, then you're unlikely to learn anything from recreating it - you'll likely end up writing something that completely misses the point as well.
I will say its better to use "good practices" for professional development.
meanwhile when teaching/mentoring, you can ask a learner to come-up with his own idea, and then show them the good practices. It will let them map a similar problem in future to best practice :)
I find I Learn best if I have specific objectives in mind. You can use it to brush up your skills in a number of areas. A common case would be to try to reimplement something you've done before in another language to help understand the differences between them. Or sometimes the existing project doesn't quite do what you want so it might be worthwhile patching it (if it's open source you can raise an issue and contribute the patch).
I'd start by defining one or two scenarios that I'm interested in exploring. I'd then write a brief specification for them, enough so you know what you're trying to achieve and can focus on those problems without getting overwhelmed. I'd then put together the high level design (again doesn't need to be exhaustive), and sketch out roughly how you want to implement your solution. You should be able to identify the tricky areas and those are the bits to focus on.
If you want to get to grips with development lifecycle techniques as well as the code I'd look at setting up some common development tools and get to grips with those tools and the disciplines involved. Doing this on "toy" projects can take some of the pressures off and avoid you screaming because the tool isn't working right.
These might include:
A real world case that relates to this question: For SO, the HTML sanitization part was completely reimplemented because, as Jeff says "deeply understanding HTML sanitization is a critical part of my business". Read the whole blog post to get a very nice perspective on when you should and shouldn't reimplement things that already exist.
For certain things, reimplementing would really help you understand the issues involved, and will help you write code that is better and synergises well with the rest of the application.
Once you know the basics of a language, reinventing a medium-sized wheel (in your spare time) can be a great way to learn more and to push yourself. Pick an area that you're interested in and at least reasonably comfortable with, and go to it. (You should be at least reasonably familiar with the topic because trying to do something more challenging and learn a whole new area is probably too much to do at once. For example, don't choose to create a webserver if you don't know much about HTTP. I suppose I am thinking of this primarily as a way to get better at programming rather than learn new areas of technology. You could approach it the other way around: you know [some language] very well, but nothing about HTTP. So you decide to use that language to write a webserver. Either way, you should know at least one part of the equation pretty well.)
However, you shouldn't expect to put what you write into production (or use it immediately at work) and you really should read the source code of some version of the wheel you're trying to reinvent. Assuming you pick a solid, well-tested original to read, its source is bound to reveal edge cases you never thought of and also to show you tricks about the language you're using that you didn't know.
If you are developing on a professional project for your job, do it the 'best practice' way. For personal development and growth, I'd say go ahead and re-invent the wheel.
At this day and age, there are libraries for most types of applications and utilities, but the only way to really learn how it works is to take a stab at it and learn from your mistakes. Then you can check your work against other libraries to see how they did it better.