52

I'm fairly new to programming, and I've been working on many personal projects, which I'm concerned can come across as silly and unprofessional. The kind of projects I have are a Reddit Image Downloader and a tool for GMs to use in roleplaying games.

I want to start building up a GitHub account for projects in my chosen field of data analytics, but I'm not sure how to organize projects on my GitHub account. Should I create a "professional" GitHub, mainly containing different analytical scripts and have a separate "personal" account for fun little projects of mine? Or am I just overthinking this, and should I just maintain one account?

Steve Jackson
  • 3,595
Almost Surely
  • 637
  • 4
    Personally, I just have one account for both professional and personal projects. As long as there's nothing offensive in your account, I see no reason to use the same one for both purposes. If anything it just shows that you like doing the work and you're not limiting yourself to a specific kind of application. – Dylan R May 30 '14 at 20:47
  • 3
    This doesn't really belong here as it's asking for career advice, but I can say that when I've interviewed, personal projects are assets for candidates, no matter how "silly". (Assuming we're not talking a fart app or something.) The projects you mention would definitely be something I'd consider worth mentioning. – Gort the Robot May 30 '14 at 20:53
  • removed the career advice sections and made it more about github (including switching out the tags). – Michael Durrant May 30 '14 at 21:07
  • Are the "work" projects ones you did for an employer, or are they merely related to your career? – Alan Shutko May 30 '14 at 21:24
  • @MichaelDurrant Thanks, I wasn't sure what to tag this as. – Almost Surely May 30 '14 at 21:37
  • @AlanShutko I do have, and was planning on adding, actual "work" gits on there. Those that I've done for my company. I was about to begin construction on a Data Warehouse and host the SQL and Python files on my github. My organization doesn't have a development team, nor a work repository, however I would like to and need to share some of these scripts out with others in the global foundation of my company. I hope I explained that well. – Almost Surely May 30 '14 at 21:39
  • 1
    @AlmostSurely: do you have permission to put actual work on github? Your employer may not be too happy about this even if you do make those projects private. – Marjan Venema May 31 '14 at 09:53
  • 1
    Putting any code from your employer on GitHub without their consent - even in a private project - could be considered stealing. I know that if I put my employers code on GitHub without their express consent, I would be in serious trouble. And I haven't signed an NDA. Same if you are self-employed and put code you created for a client on GitHub. The code isn't yours to put there. – Marjan Venema May 31 '14 at 09:59
  • 1
    @MarjanVenema Sorry to be so late getting back to you, but yes I do have permission to post work on Github. Like I mentioned elsewhere, my organization is part of a larger Foundation, and it is how we share things together, and to the general public at large. I don't work for a type of company that cares about software patents and such. – Almost Surely Jun 05 '14 at 15:33
  • @AlmostSurely: Good on you! My concern isn't so much software patents (they seem mostly being (ab)used to prevent competitors from developing similar user interfaces) as it is the research and effort that went into developing a software application. Protecting the knowledge gained and the effort expended from companies wanting to take a shortcut towards developing a competitive product is best served by keeping the source well away from their inquisitive eyes... – Marjan Venema Jun 05 '14 at 18:26

3 Answers3

36

I say you can eat the cake in have it too! Introducing GitHub Organizations.

Use your GitHub account for your personal projects, and create an organization for your professional projects. The organization's homepage will show the professional projects you want to introduce, and it'll have a link to your personal account that shows all the things you have done in GitHub.

Benefits:

  • You'll have the clean separation you wanted while keeping a relation between your personal and professional GitHub activity.
  • You'll be able to control everything from a single account. No need to relogin just to open a repository in the professional account - all you have to do is to select the organization when you open a new repository.
  • No need to manage two different SSH keys on the same computer!
  • You can add other GitHub users to your organization, and even transfer the organization's ownership to them if you even need to. Each user will have their own account, so you don't need to share a professional account's password with other people. As a bonus, different accounts can have different permissions based on their actual role in the team - something you couldn't do with a shared GitHub account for professional projects.

Basically, this approach gives you the benefits of both approaches. The only downside is if you have some personal projects that you don't anyone to ever relate them with your professional public face. However, these criteria usually involves illegal stuff you wouldn't want to put on GitHub in the first place, so it shouldn't be a problem.

Idan Arye
  • 12,077
  • 3
    So if your personal laptop or account is compromised, it can lead to the compromise of your work account, since you conveniently use the same SSH key for personal and work projects. If your organization has a policy about carefully managing secrets, this might not fly. – Mark Stosberg Dec 21 '19 at 17:09
  • 3
    @MarkStosberg According to the question, it does not seem OP has is using his personal laptop for personal projects and his CIA laptop for professional projects. It looks like both personal and professional projects are created from the same machine, and the difference is that the personal ones are "silly and unprofessional" "fun little projects" while the professional ones are things they want associated with their professional personal brand as a data analyst. – Idan Arye Dec 22 '19 at 16:57
  • Old question, but there's one huge disadvantage to doing this. The notifications view in GitHub really doesn't work well when you use a single account for everything, especially when you interact with some FOSS projects in a "work context" and others in a "sparetime context". Considering switching to separate accounts for this reason. – Per Lundberg May 03 '22 at 12:28
  • @IdanArye So you are saying one github account for private and work projects is fine if you are using your own machine both for private and work. – Roland Sep 26 '22 at 15:48
  • 1
    @Roland Yes - just use organizations for separating work repositories from personal ones. I'd say that even if you never access both from the same machine, it should still be fine to use the same GitHub account. This is what we do at my current workplace - those of us who already had our own personal GitHub accounts just connected them to the company's organization. Just remember to go to Notifications -> Custom Routing in the GitHub settings and direct the notifications from the work organization to your work email. – Idan Arye Sep 29 '22 at 12:06
23

I recommend you keep them together.

  • showing suitable personal projects is often a big plus as it shows your passion and initiative
  • simpler to manage what goes where over time.
  • only 1 set of ssh keys to manage
  • no need to log in/out from one to another.
  • allows you to have 1 github to 1 main personal email, also simpler.

I think one answer to what you want (and what I do) is to have a paid account (I think its $7 a month for 5 privates) that allows more private repositories. So keep the work/play ones that you want to be public as public and keep other ones as private.

Michael Durrant
  • 13,199
  • 2
    showing personal projects is often a big plus - perhaps just as often a big minus, when someone else steals your idea... you can talk about other things you're doing with co-workers and superiors (without taking a lot of time to do so), even though they're not in github - that shows passion and initiative without giving others the "keys to the castle". That's what I've always done and it has helped me in my job - more than once I have been given interesting assignments : "Hey I heard you were fooling around a lot with JSON... maybe you can tackle this new project we're planning..." etc... – Vector May 31 '14 at 00:53
  • 3
    and many employers won't want the risk of cross contamination between their corporate property and some hobby projects... – jwenting May 31 '14 at 01:09
  • 1
    If you can't keep projects separate it doesn't matter whether they are private or public. I've never seen this "cross-contamination" in practice. In my work right now I have to use 20 repositories and not mix them up. – Michael Durrant May 31 '14 at 09:28
  • Vector - that's why I say use private repos for such projects. – Michael Durrant May 31 '14 at 09:30
  • 2
    Even if you put work in private projects, one's employer may not exactly be happy with having what it considers its code "out in the open" (not controlled by their own security policies) and showing it to other companies during interviews. Even putting it up on GitHub in a private project could be considered stealing. I know that if I put my employers code on GitHub without their express consent, I would be in serious trouble. And I haven't signed an NDA. – Marjan Venema May 31 '14 at 09:55
  • 1
    I mean put the silly projects as private. – Michael Durrant May 31 '14 at 10:52
  • @MichaelDurrant - that's why I say use private repos for such project - if you're keeping others locked out, IMO you should not be using a company account for that at all. That's an abuse. – Vector May 31 '14 at 12:22
  • 1
    i think we are driving different points. Moving on. – Michael Durrant May 31 '14 at 13:54
15

I think you should keep the accounts separate.

In almost all cases, work you create as a matter of your employment with a company is owned by the company. It is not your property. When you leave the company, the company keeps all that work and you no longer have any rights to it.

If you keep your personal and work accounts separate, it makes this much easier. When you leave, you just hand over the work account and they take ownership. You would not need to separate your projects from the company projects, and would not need to try to delete the projects from your account. Employment with any given company is fleeting, and the more you entangle your personal stuff with company stuff makes it harder when you separate.

This is my rule of thumb, and certainly individual organizations will have their own opinion on this. I could see some companies deciding that they have no problem with you keeping a copy of this stuff once you leave the company as long as they have a copy too. On the other hand, the company I work at keeps very tight control over things and they would likely fire me if I put company work product on github.

Alan Shutko
  • 1,400
  • I work for a separate nonprofit that is a part of a larger Foundation. I've talked with my higher ups, and they were fine with me hosting the files Open Source on my github, so that I can share out our progress with the rest of the Foundation, and this seems to be the method for other organizations in the Foundation. I understand what you are saying about what's the company's is the company's, but to be honest I would like credit for this work on my resume. That being said, maybe I should keep a separate work account and just have the projects on my resume without linking to the github. – Almost Surely May 30 '14 at 22:49
  • 1
    @AlmostSurely - +1 on this answer - I think tit's the right one. Keeping your private matters, whether technical or otherwise, is always the best policy, for the reasons stated here and many others as well. You can put your private projects on your resume regardless, and even link to your private github repository to show what you've been up to. If you do need to move on to another job, doing stuff on your own outside of work to broaden your horizons and learn new skills can (but not always...) be a plus: it shows you love your work, you're ambitious and energetic, etc. – Vector May 31 '14 at 00:50
  • 3
    also avoids/reduces the very real threat of them thinking similar looking code in your personal projects is stolen from work you did for them. Many employers demand ownership of all code you write during your employment, even code you write in your spare time that's not work related. Whether such a claim will hold up in court I can't tell (and would depend on local laws anyway) but it's a common thing and you want to avoid complications like that if you end up in a labour dispute of any kind. – jwenting May 31 '14 at 01:12
  • even code you write in your spare time that's not work related - Yup. I've signed NDA's that essentially gave them ownership over my programming grey matter. Whether such a claim will hold up in court I can't tell - I don't think they will hold up in a US court, so I never worried about it too much - but they put it in there so that you don't "get cute" - intimidation factor. – Vector May 31 '14 at 12:27
  • 1
    company projects should be kept under a separate organization. then it is easy to see which projects are yours and which are the company's. when you leave you don't need to hand over your account as you can just give access to the organization to someone else in the company. – eMBee May 16 '17 at 04:53