As an employer that does the same thing as the person who wrote the article; I do, of course, look at the seriousness of whatever is on that Github profile.
I am usually easily able to tell if it is a half-baked project for some hobby-thing or active participation in e.g. a well known piece of open source software.
Someone who does this, is likely also skilled enough to separate those things. I don't only look at the user's own repos but also at contributions/comments etc. to others.
And just as the author, I too experience more often than not that people have NO idea how to set the level for own experience.
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
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)
> 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.
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?
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.
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.
I am usually easily able to tell if it is a half-baked project for some hobby-thing or active participation in e.g. a well known piece of open source software.
Someone who does this, is likely also skilled enough to separate those things. I don't only look at the user's own repos but also at contributions/comments etc. to others.
And just as the author, I too experience more often than not that people have NO idea how to set the level for own experience.