[r00nk]

Hey there, one of the young guys here, trying to weasel my way into a job, I have a few questions for you If you don't mind.

You said this:

More likely I am not impressed because your code is terrible and I am shocked that it took you so many weeks and commits to do what you would be expected to finish in 1 day at our office.

I have a github account, and I use it to host a few of my projects. Right now I'm working on writing a operating system. It's been somewhat successful so far, but as operating systems are a deep and complex field, and I'm definitely still learning, there's a lot of embarrassing mistakes and bad code throughout the git log. For example, I just recently learned how to properly write makefiles , and a day on my project was just on writing a somewhat simple in hindsight makefile (because I was reading the man page at the same time). Should I just not host said projects on my github?

Also, when you look at a github profile, what do you look at? Asking because I can probably get more followers if I make more node.js whatever, but I really like my C and I tend to go for more challenging projects then popular ones. Is that a bad idea?

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

[lazyseq]

Well honestly, that part about Github was a bit of a joke grounded in some real-world experiences. Mainly I was just referring to people who act mighty about something that is in essence, nothing. Further, I am referring to people who obviously are struggling over basics, but are not humble enough to recognize it. Amazingly, people love to brag about things they are actually not skilled in at all.

As for public facing programming-related artifacts and sites, I don't think it's a good idea in general to judge people on things like Stackoverflow, Github, etc. It's not that I don't at all and not that my colleagues don't, but rather we place appropriate weight. Mainly when we asks for things like this, we just want to see what your writing and code looks like to get an idea. If a candidate said to me, I don't have a Github account or I have better code I can send to you, then that's fine. There are so many arguments why judging people this way is bad that I would end up writing a book in reply.

This is why sometimes we'll do a coding test regardless because then we can at least have greater confidence that the person actually wrote the code we are looking at and that they are capable of executing the type work we are interested in doing. Even for coding tests, we mainly put weight on the explanation the candidate gives rather than the code. You learn a lot about how someone understands problem solving by asking them to explain their code and walk you through it. Moreover, it helps weed out the cheaters, pretenders, and liars, of which there are many.

Regarding your case, I would never really penalize someone that harshly based on their commit history, at least in isolation. As you explained, there are many factors at work. If a candidate explained why there were so many commits and 3 months ago, he did x and then now he's doing y, I wouldn't care. I would actually just look at the explanation itself, rather than the commits.

Be wary of any employer that cares too much about your Github. Although one should be humble in interviews, you also to a small degree are seeing if the company and people are a good fit for you. If the interviewer is placing too much stress on things you feel are irrelevant, it may or may not be indicative of other future problems with them. I have noticed for instance that people that I have co-interviewed someone with sometimes become very antagonistic when they feel threatened by the person they are interviewing. That is, their ego gets in the way of doing a constructive interview.

If I had to pick specific things I look at when viewing anyone's work including Github:

1. Clean code with a consistent style. This is rather subjective, but I think that most of us develop a feeling for the things we want to see. A good developer searching for other good developers should recognize that good is not simply coding very similar to yourself, but rather that the code has easily identifiable merits, even if you disagree on some choices. Simple things like namespaces and following the standards of the language are easily identifiable and hardly debatable.

2. Understands the material. In the case of Github and your commits, part of that might be understanding how to use git. Things like rebase vs. merge come to mind, cleaning commit history and branches, and so on. We all make mistakes and do stupid things like use git to move things between machines to get something done fast. It's fine, just keep things tidy and use the tool properly most of the time (preferably all the time obviously). If it's a programming language, don't write Lisp like C++, don't write JavaScript like Java, and so on.

3. Recognizable that it is actually the person's work and not plagiarism. Bigger problem than you may think.

4. Obvious that something of value has been created. I've seen a lot of node.js projects linked to me by candidates that are in essence doing nothing but wrapping something else, then outputting it to a pretty UI that came from someone else, i.e. Bootstrap. A lot of this can be fine, but there better be a point to the project and the description given by the candidate should match reality. If it doesn't, it just feels like bs or a lie. It's OK to use tools like Bootstrap, but just don't take credit for those parts as if you did it all yourself, from scratch in assembly or something.

5. Good behavior. This can mean a lot of things. For example, how does the candidate interact with issue submitters? Is the documentation broken? Do they seem to post a lot of crazy, false, ridiculous stuff everywhere (your language sucks type stuff, sweeping false generalizations, etc).