Selfhosting is a hobby for me, and as such I am constantly experimenting in "production." It would be unwise to link to a page that can and will go down any moment.
this post was submitted on 22 Sep 2024
20 points (95.5% liked)
CSCareerQuestions
950 readers
1 users here now
A community to ask questions about the tech industry!
Rules/Guidelines
- Follow the programming.dev site rules
- Please only post questions here, not articles to avoid the discussion being about the article instead of the question
Related Communities
- !programming@programming.dev - a general programming community
- !no_stupid_questions@programming.dev - general question community
- !ask_experienced_devs@programming.dev - for questions targeted towards experienced developers
Credits
Icon base by Skoll under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
You can do what I do and just have a branch for the GitHub pages bit, and just point GitHub pages at that branch instead of main to have a consistent webpage that you can rebase/merge into as you test things to make sure they're safe
As a hiring manager of developers:
- If a candidate puts a link to public source code anywhere in their Resume, it's the first thing I read.
- I see a lot of GitHub, of course.
- I consider GitLab, Codeberg, or even BitBucket to be a mild bonus. Hosting code history somewhere unusual implies some awareness of Git's portability.
I'm personally still on GitHub, but planning to migrate my portfolio to somewhere with an open source back end over the next few years.
Would you take note of someone using git compatible version control tools like, Jujutsu, Sapling, Gitless or Breezy? Or an entirely different hosting and version control setup like Pijul, Fossil, or DARCS? (Sapling and Breezy can be setup and used without git-based infrastructure as well)
My hunch is this is generally a negative signal for hiring managers because it's too far from standard practice in their world and could indicate someone who is too contrarian.
Anyway, I've tried all of these at various times and there's a lot I like about each and some I think are overall improvements over git. But git has so much momentum that people are very reluctant to try something even if it can smooth out the rough edges of git and git workflows.
Those are all a signs of a curious mind, which is a big plus. There's also signs of not being a team player, and my job is to build a team.
So it all depends how the candidate communicates themselves.
The sweet spot is finding a new team member who is sure they'll convince my team to change tools, but is committed to embracing our current tools until they win over the rest of the team.
Resume building is the only reason I put anything on github.
My job is almost entirely public on GitHub. It is in my resume and the next time I use my resume I hope folks read it. Lots of folks won't but they probably don't value my particular set of skills.
I think the usual wisdom is most jobs won't care.