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