Let me also add some more specifics for your case: 1. Program whatever you want. Don't go for popularity. If you don't do what you want, then you won't finish.

Let me also add some more specifics for your case: 1. Program whatever you want. Don't go for popularity. If you don't do what you want, then you won't finish. 2. Corollary to the first item, finish what you start. 3. Anyone who judges on stars as an idiot. I will use the sweeping brush. In the same way it's hard to make a hugely successful startup, being good and being popular are two different things. Without naming languages, frameworks, etc., I personally find a lot of the most popular stuff to be among the worst tech wise. 4. Consider making some of your projects private if you are really that worried. Github is for open source, public collaboration. Although it provides private accounts for pay, I am not sure it's always the best deal financially. If something needs to be private, then hosting on a public service may not be the best idea anyway. Either self host, or at least comparison shop. More generally, don't put things out there you don't want people to see. I'd even add people need to stop putting things out there that are not worth seeing as it just makes it harder and harder to find what is a toy vs. a real project. 5. For Github profiles, mainly I look at what I mentioned in my other post. Code quality over quantity, good behavior, and claims match reality. Finally, I will add that you should not take on things that are too ambitious. While it is good to challenge yourself and you learn, it is much better to take on projects you can finish. This is a hard thing because it requires motivation and the related skill of picking something that is challenging enough to keep it interesting, but still feasible. I say this as the author of multiple past game engines that I never fully finished and released for instance. I often tell colleagues the following rules about projects in general (again, challenge yourself within reason and for mental exercise, but consider below general statements about programmers): 1. Don't make a programming language. You probably aren't the guy to do it. There is most likely exactly two people in this world in every generation qualified to do this well and you probably are not one of them. Unfortunately, many people have made programming languages who should not have without naming names. 2. Don't make an operating system. This is hard. Really hard. Same points about #1 hold, only you probably also need an army of people helping you to do this right. Obviously this may not apply for some small scales and it's find to experiment, but your OS isn't going to change the world. No one will care about it and realize that the software usually makes the OS, rarely the other way around. There are a lot of abandoned/nearly abandoned OS code-bases that are much better than anything we use, but they didn't have developers, weren't cost effective, etc. Console wars have shown the same thing in the past. 3. Don't make a database. You probably will do it wrong. Your database will be fast and fix all kinds of problems the past ones had, but when you start adding in the real features, things change. Soon you will realize that your database now has similar problems to the ones you wanted to fix because as you had to do things like transactions, clustering, backup, logging, and so-on, your optimizations could not work anymore. A lot smarter people than you worked on these problems a lot longer. If they could have magically fixed many of these problems, they would have. While it's true legacy code and corporate politics get in the way here often, that doesn't mean that the same won't happen to you. If you do need to make a #1, 2, or 3, please sit on it for a few years first and talk to people smarter than you before you start. And don't neglect security either. 4. Pay attention to the past. Someone probably made what you made many times before. The first or second time was probably the best, but everything since has just been worse with the benefit of faster hardware. Instead, just simply dig up the past if you must and do what they did in a modern context, giving acknowledgement and credit where it is due. Learn from the mistakes of others as well. 5. Whatever you built is insecure. Ask a security expert or 50 to review it, and then get some coffee because you probably have twice as much work to do to fix it as when you first built it. Better you ask these people before you even write a line of code or at least very early in the process, or hell will descend about you quickly.