[lazyseq]

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.

[themusicgod1]

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

Know how they got qualified to do this? By actually doing it, and by reading about others who were doing it. Modern language developers have so many shoulders of giants to sit on it's not even funny, but even so; it was only a generation ago that stuff like C didn't exist. Someone had to fill a need with a language.

Same goes for OS's/other stuff.

And sometimes, occasionally your stuff gets useful for other people -- and then they start correcting your mistakes. We are going to need one or two people who are that good at programming language design in 2039 and if it takes 24 years of putzing around and designing languages that don't work to get them there, all the power to them.

[lazyseq]

No, making more languages is not a solution. If your language solves a problem that others cannot do as easily, great. The point is that even if you succeed on one level, you can create messes. One of the largest problems we have today in computer science is all the mess of poorly constructed languages. Just because something is widely used does not make it good, rather there are other realities like popularity contests, luck, press, etc. at work.

If you read my comment, you'd see that I didn't write no one should do it, just that there are only a few people that should. You can create your own language or DSL like thing in your spare time. Just don't spend thousands of hours on it and push it into the public. Without naming names, there are quite a few languages that we would be better off in many ways if they did not exist. Some of the authors of these languages have admitted as much and I am pretty sure they know better than both of us.

There's a difference between academic messing around vs. putting out something there with the presumption of knowledge. Making languages is a very hard thing. If you don't understand why this is true, you are probably one of these people that should not make a language. Sorry, but it does more harm than good 99% of the time. At best, the language gets ignored, at worst, it becomes popular enough in a half-baked state.

[themusicgod1]

> Making languages is a very hard thing. If you don't understand why this is true, you are probably one of these people that should not make a language.

It is a very hard thing, which is precisely why we should be doing it. We do not do things because they are easy, but becuase they are hard, and because the practice makes us better at it. I have maintained a language for a living and I know what mess you're talking about. There are real systems out there that languages can be useful for, and even if you're right that the 99% of the time they cause more harm than good the 1% I would argue justifies the 99 failed attempts in practice.

[eatonphil]

There is so much wrong with this post. I'll follow your ordering.

1. Program WHATEVER you want. We can't make assumptions about what drives you. If popularity is your biggest drive, then use it. Don't ignore what drives you because you think one way is more honorable than the next. Do what you need to do. No one cares why you do something if you do a good job.

2. Fine.

3. Anyone who judges on stars is normal. They may also be an idiot. But in most cases, stars WILL impress your prospective employers. This may not be a GOOD thing, but it is true. It is just how humans think. Go with the tide not against it, but certainly, the popularity ratings are not all important. Use them to help you advertise yourself but don't rely on them solely.

4. If you are a beginner, there is NOTHING you have out there a prospective employer would not benefit from seeing. Most people I see starting out have so little. It doesn't matter if the project is unfinished. Most projects ARE unfinished. If you just came out of school your prospective employer should be understanding of your priorities.

5. Fine.

Now onto the next list, but a general note first. WRITE WHATEVER YOU WANT. Our entire economy is based around survival of the fittest (for the most part). Create the next best * (language, OS, api, db, etc) or don't, you still learned a hell of a lot (I hope). Jumping into things with which you are unfamiliar is AWESOME. You WILL be rewarded.

Anyway, the next list:

1. As with everything else, if you want to do this, do it. You will learn about lexing, parsing (because God knows most people can't tell the two apart), ASTs, the difference between a compiler and an interpreter. At the very least you will be the more intelligent voice at Your Generic Job when talking about Python's awkward scoping.

2. Write WHATEVER you want. Now, truthfully, you probably won't get far. But if you learn what a kernel is, what a boot sector is, etc, you will be far ahead of most other programmers out there. Will this be helpful in your career? Probably not. But WHO cares! You'll learn some good C skills at least.

3. Write WHATEVER you want! Honestly a simple database is probably the simplest of the three mentioned topics (language, OS). New databases are always being written.

Ultimately, the point is always that although you probably won't beat the existing implementations, you WILL learn a lot about how they work. There is nothing more helpful (IMHO) when learning a new topic/api/etc than writing it from scratch. Move on when you understand the concepts. Certainly, don't use your project in production probably, but it doesn't mean you didn't learn anything!

4. Fine.

5. Fine.

Point is, these lists come off as incredibly narrow-minded. A beginner should do what interests them. While their projects probably won't take off, these are the most important things to show to employers down the road. This will demonstrate your interest in CS, your ability to take on a challenging project, and for crying out loud it gives you code samples. Email me if you have questions.

/rant

[carapace]

I don't think you correct the parent so much as come at the question from a different viewpoint and context.

If you are trying to avoid B.S. as a newbie professional programmer then the parent advice is, in my opinion, very apt (and "narrow-minded" only to a degree that feels well-focused.)

On the other hand, if you are a beginner and hoping to really learn the art, as well as the trade, then your comments eatonphil are most apt as well.

For example, knowing what I know now, I would never try to design and implement my own language (except for fun), but I know what I know now in part because I've done so in the past. ;-)

[lazyseq]

3. No, judging on stars is ridiculous. A good library is a good library. Perhaps stars may catch people's attention, but honestly anyone professional I've ever known doesn't even remember to look at stars in the UI. Better to look at other things like the actual code and commit frequency and contributions to see if it's still alive.

4. This is not at all true. If you send me a link to code to look at and it sucks, I won't hire you. Perhaps my perspective is skewed since I rarely ever hire people who I have to teach computer science 101 to, rather I take only people who show promise, have the tools, and simply need to put in the time. Your work is completely reflective of you, so please just don't throw random bad code and call attention to it. This is terrible advice.

Anyway, I think you missed the point of my next list. The point is that you give these things long and hard thought. You do them one day if you get there, and you mess around for a few weekends. What you don't do is dedicate years on these projects unless you treat it like a video game in terms of fun level.

1. This is why you take a class in writing an OS and screw around for a few days. This is different from writing an actual OS.

2. Same as #1.

3. New databases are often being written and they are bad. A lot of the new databases are simply layers on others, not true databases. As for this issue, again, it's something that requires careful thought and experience. You better be solving a problem and be solving it well. The fact that things are written is not justification to write them. Notice how so many of these are written and not really used. Notice all the problems created, abandoned projects, and catastrophic design flaws that creep in later in the projects because of lack of planning, thinking, and ability. I've contributed code to some of the biggest databases out there and I don't feel qualified to write one myself. Sorry, but this is another skill beyond most people. If you've ever worked with someone who really gets this type of programming, you realize they were born to do this. You may be a better programmer than them in everything else, but DB, OS, programming language people who are good are super rare.

My lists are not narrow-minded. You can philosophize about how little Johnny can do anything. I speak more in terms of actual experience and reality. It is better to tell it like it is. You can write whatever code, whenever you want, just be reasonable. Build things you and other people want to use. Do not build hacky, half-baked things that waste time and repeat history. Following this advice would probably eliminate a good majority of the bad projects out there. If you can't see that, I am not sure where you've been working all these years. I've worked with some brilliant people, and especially the ones who did these things would tell you the same.