Could you list some things that are red/green flags when perusing someone's public code/projects?

I'm preparing to publicly release a project with the intent of building it up to demonstrate my own experience level. I'm asking as someone with next to no prior public code despite developping back-end almost full time since I dropped out 10ish years ago. I guess I'm asking for external criteria for whether I'm impostor-syndroming!

Just a few things I usually notice when going through a potential hire's GitHub:

1) All projects have a bad commit history. Just one commit and that's it. Usually it's something for school with really basic stuff inside. Most might be IDE provided "generate code" boilerplate.

Even a single commit beyond the GitHub provided initial commit example is enough. Multiple ones in a sane cycle is even better. Even if you just update some comments.

2) Does the project run? If I check out the project, is there a clear way to run it or does it rely on the compile & run commands being on the submitter's bash history?

Add a make/magefile or run.sh or anything.

3) README. Does it exist? GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.

4) Bonus task: does the repo have integrations or GH Actions enabled? If the project automatically runs some tests or builds on commit, it's a big green flag for me. If I'm going to be paying you over 100€/hour, I don't want you spending your time doing stuff manually if it can be automated with 15 minutes of boilerplate work.

> GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.

This is a strange one, I am not sure why the priorities of a third party hosting platform should take priority. Many people use it is more of a cloud repo backup than a social sharing site.

So why knock people for using it differently? It does not measure their understanding of how Github works.

That's a good point, but it does raise the question of how best to transmit notes or information with anyone who stumbles on the repo. I understand these platform-specific features to be a way to show you do your homework and can integrate third party tooling or workflows into your own things.

Adding a README.md isn't just GitHub specific, it's a good idea to add it to any project you do.

My memory sucks, that's why I write down what I'm planning to do with a project into the readme. It doesn't need to be super fancy with images and status badges and all that jazz.

This is perfectly enough:

  projectname
  ===========

  This fizzes

  TODO
  ----

  Add buzzing later
  Check if bazzing library is ready for production

This is true, README has a long history.

However, I strongly associate Readme.md, designed for a web based intro view with Github.

It would be interesting to get the real history, because it could be a fluke of timing.

I’d bet if we look back at old source forge projects created pre-github there would be a strong correlation with the markdown version added and the rise of github. (Of course this could be a timing fluke)

Markdown was invented around 2004, Github was founded in 2008.

Which means you may be able to see a correlated acceleration in usage.

> README. Does it exist? GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.

Yes GitHub pushes you really hard to add one. But I disagree that not having one on a personal project means you don't understand how GitHub works. I don't need (or really even want) a README for a personal project. It detracts from writing code. If I neglect the personal project for months or years and come back to it then I'm not going to give a flying crap about the README anyway: I will have come back to it specifically to look at the code. Whether that's because I had a new/better idea or wanted to reminisce or maybe to copy/paste some idea from it.

All of the rest of your points are good though.

I mostly interact with github via a standard git cli, which does NOT bug me about it.

Which is something I would think someone who assesses people based on how much they know Github.....should probably know

How ironic ;)

Your points make sense and they're on The Checklist, thanks! I probably won't sweat CI/CD integration for the demo yet but ship (as the other commenter mentionned, also thanks!) something readable, mostly testable and usable (but limited) on day 0 and go from there.

I do wonder what a recruiter looks for in a good README though. Technical chops or perspective on potential applications/intended project direction or ... ?

You don't have to go whole-hog on CI or anything, but GitHub Actions is pretty easy to just knock together a thing that runs `make test` or equivalent.

I've ended up building boilerplate workflows for various languages, environments, etc. to just drop in and tweak per-project.

Honest question: If someone uses, for example, sr.ht, will you scrutinize it as much as a Github project? Would you check out the project and look for its equivalent of GH actions?

To be honest I've never seen a single project on sr.ht :)

But I think it's a plus for using something off the beaten path, provided that the other conditions are met.

These are some very low bars for a project to pass.

It is the point though. My public github projects are either empty (i pushed nothing cause everything was bad) or are half-baked projects. They would still pass those bars, which i can feel gratefull for.

For me, there are no "red" flags when looking at someone's public code.

I consider them as conversation items. I don't think anyone is expecting to see multiple completed products with 1k+ stars.

The worst case is, you waste time agonising over the quality of your code and either: don't publish, or no one even looks at it (highly likely)

You're not about to get code-reviewed. At most, if anything, it would be:

"explain this class/function": I'd expect you to vaguely know the answer after reading it

or, "why did you do <something> this way?": answers like "I got it from SO", "I don't know of a better way" are perfectly fine.

As a programmer (with a busy professional and personal life), I don't really care for the fact that it's like this but I acknowledge that it is and I also understand that it can be a strong signal in the right hands.

I use my pinned repositories to showcase side projects that I've worked on that are either complicated/challenging problems or that solve a specific problem in a complete way. These 6 repositories are "the most serious" work that is available in my public GitHub profile.

Some time ago, when I put my mind to doing this, I made sure to put extra effort and attention to detail into about a dozen different projects that were in my public profile, so that I had options across languages, project types, etc., for what I'd pin. I put each project through its paces, made sure it ran on multiple platforms (or, that there were notes in the README about how to get there otherwise), cleaned up Makefiles, test suites, etc.

At least one of these projects is incomplete and/or a work in progress, but I've indicated as much in the README, but it's also obvious to see exactly where (and why) that project stalled, if you read through the code.

I can't say that it's helped get me a job (I haven't changed employers) but I do feel a little better about the other 100 or so projects in my public profile now that are in varying states of completeness.