DEV Community

Cover image for Tips for your GitHub Portfolio
Maxence Poutord
Maxence Poutord

Posted on • Originally published at maxpou.fr

Tips for your GitHub Portfolio

A few week ago 2 people asked me the same question on Twitter: "how do I make a better portfolio?"
Since, it's not the first time I have this question, I decided to answer in public™️.

Before I start, just want to highlight something. Having a GitHub profile is not and should never be mandatory. It's "a nice to have".

Quality over quantity

It's common to see GitHub profiles like this:

pinned GitHub repositories with no description
(repositories names were anonymised)

The person picked 6 repositories and pinned them. All the repo have 3 commits, no readme. This developper seems to experiment a lot of things but, nothing really stands out. If a recruiter asks you "what problem did you encounter and how did you solve it", the answer will be limited.

Don't get me wrong, there's nothing bad about experimenting new things! I also have a lot of hello world projects on my GitHub profile. However, those are not pinned on my profile. I only pin what I think it's relevant. I know recruiters don't have time to go through all my projects. That's why I have 5 when I'm writing those lines.

Instead of having 6 small projects, pick one. And polish it!

Learn in public

"I don't put it on GitHub unless it's perfect"

This quote comes from a senior dev I used to work with. I think it's a pity to think like that. In general, people who are afraid of making mistakes end up doing nothing. If you look at popular repositories on GitHub, most of them are far from perfect. And it's fine!

And also, if one day someone checks your project's git log and finds out that you forgot a bracket/semicolon, I don't think he will blame you for that. And if he does, it's good for you. Nobody wants to work with toxic people.

There's alway something to do!

I did a mentoring session once with a girl who wanted to retrain in IT. She showed me the small game she developed. But, she wanted to find a new project because she thought this project was "done".

A project is never done. There's always something to do... Remember the 1st advice: "Quality over quantity"!

Here are a few things you can do...

Add a README.md

The readme is the entry point of your project. The first thing people will see!
I think every code repository should have one. If you don't want people to get interest in your project you can add one and write "nothing to see here".

Your readme should answer those questions:

  • What is this project about? (1-2 sentences should be enough).
  • How to install it?
  • How to use it?
  • What does it look like? you can add a screenshot or a gif animation.

💡 Tip: You can take some inspiration in the Awesome README repository.

Do marketing

If you're building an app, advertise about it! I've an ex-colleague who's building a minimalist text editor. Every now and then, he publishes links on social media (Twitter, LinkedIn...) about his product and the new features he added. He also added his product on ProductHunt/Reddit. These platforms are great to gather feedback!

💡 Tip: There is also smaller communities in WhatsApp, Telegram or Discord (i.e. Party Corgi).

Add more features

On a green field project, finding more features should not be the hardest thing to find. If you did a bit of marketing on it or if you asked for feedback to your friends/family, you should have a list of ideas to add.

At some point, you might face the situation where you have to rethink the way you wrote your app. It's a good point for you because it means you overcome the "Hello world" stage. Interesting problems usually arrive when your app is growing.

And also...

  • Manage your todo list with tickets/issues. If you have a few tickets, you can group them into different categories: "bug", "enhancement"... If people spot a bug or have a feature request, they will probably open an "issue" on your repository! Also, one small tip: fix all bugs before starting any new feature!
  • Write tests! Lot of dev recruiters like to see tests when they review code. The project you're working on can be a good opportunity to write some!
  • Add continuous integration (CI). Every time you add code a robot will check if tests are passing and if you don't have dead code/oversights/... You can use tools like TravisCI, GitHub Actions...
  • Automate the deployment. Many tools allow you to deploy your app on the web once you git push to the master branch. You can check Netlify, GitHub/GitLab Pages, Vercel...
  • Make your app accessible (a11y), so people with disabilities can use your app.
  • Make it mobile friendly (responsive web design) and if you feel comfortable, why not creating a Progressive Web App (PWA)?
  • Monetize it? If you think you're solving a problem that other people have and if you, you should think about monetization. This project might pay you your coffee... or more!

Now it's your turn. Show me your kick-ass GitHub Profile!


Feel free to reach out to me on Twitter (@_maxpou) or in the comment below! 😎

Originally published on maxpou.fr.

Top comments (11)

Collapse
 
nicolasomar profile image
Nicolás Omar González Passerino • Edited

This is mine:
github.com/NicolasOmar

I worked my "readme" to have a more elaborated explanation of my tech stack and what i am learning over time. I think using icons makes more attracive and easy to understand to any visitor.

Also I am focusing on learn a single stack (Angular/React > Node > Mongo) and expand it little by little with techs like you mentioned before.

My best advice at this point is try to create a tool that you can analyze by yourself and create an ecosystem with open projects to keep tracking of your progress. In my case i made:

  • An angular and a react app for the front
  • A node api for the back
  • A docs project for the documentation
  • A trello link for the project tracking

Making this way (I know it could be a complex way) can be worked by small but constant steps and so create a good tool which has a clear background to anyown who wants to know more.

Collapse
 
maxpou profile image
Maxence Poutord

Hey Nicolas,
if you have 2 frameworks, I'd not call it a single stack 😛
Simple question: why do you use angular and react for the same app? One should be enough? You can reduce the number of pinned repo to keep focus in your fav repos. The most polished ones.

also, the link to the app seems to be empty ? mybudget-api.herokuapp.com

About the main readme, I feel overwhelmed by icons :D
I'd remove the most obvious ones. If you use React, I guess you also know/use HTML, CSS, JS...

Collapse
 
nicolasomar profile image
Nicolás Omar González Passerino

Hey Maxence! Thanks for the comments.
You have a point about the "single stack", i used that term because i was trying to simplify it, but I think I was wrong hahaha.
About your question, i am currently working in angular at work, so I can have a better version while I am building the API, but I worked with React before and I want to make a version using the same API to have both examples working. I know my react version doesn't have much work so far, but i will go for it after i get done my first 0.x version on the API.
About the empty app, it is because that version it is in a very early stage. I wanted to have a "stable" pipeline working and then mantain it in that way until I reach the first 0.x version.
At last, I understand that you can be overwhelmed with the icons, I wanted to make a more visible approach using the icons in that way. But i will keep in mind to remove the obvious ones.

I appreciate a lot your reply, any other idea you have is welcome. There is always room for improvement.

Thread Thread
 
maxpou profile image
Maxence Poutord

it was just some thoughts as if I was thinking loudly.
but it's your page, your projects. So keep doing what you think it's the best ;)

Collapse
 
denvermullets profile image
denvermullets

i follow most of these ideas and really like the idea of using issues / tickets for your TODO's. i tried it with one project and am comparing with another project using a TODO plugin so it's in the codebase. unsure which i prefer yet!

here's my github: github.com/denvermullets

Collapse
 
musaatlihan profile image
Musa Atlıhan • Edited
And also, if one day someone checks your project's git log and finds out that you forgot a bracket/semicolon, I don't think he will blame you for that. And if he does, it's good for you. Nobody wants to work with toxic people.

Awesome! 👏

Collapse
 
maxpou profile image
Maxence Poutord

Thanks Musa :)

Collapse
 
jozefchmelar profile image
Jozef Chmelar

Mine here github.com/jozefchmelar -- feedback appreciated 😊

Collapse
 
maxpou profile image
Maxence Poutord

In a nutshell: "quality over quantity".
You have 6 pinned repos. Why you don't only have one or two? Most of them have less than 10 commits. Take one and polish it, like you did in the "Tornado" repo have a great Readme 👍

Btw, you said this:

  • I once said "no" to my boss just kidding.

You should. Saying "no" is not necessarily a bad thing. If it's reasoned, it's a good thing.

Same for "That I'm ashamed of". I don't think you should add it. Mostly the last point. Don't undervalue yourself :)

Collapse
 
jozefchmelar profile image
Jozef Chmelar

Thank you Maxence!

I want to say that amble to say no even though it's an authority, like a boss.

This "shaming" is there to point out that everyone, including me has its flaws and I'm not perfect, i'm just a human :)

You're right about the last one though. I'll remove it

Thread Thread
 
maxpou profile image
Maxence Poutord

oh I get your point. Self-mockery shows you don't have a big ego... which is good :)