DEV Community: Tassia Accioly

You got your first job, and now what?

Tassia Accioly — Thu, 15 Jun 2023 16:36:00 +0000

5 tips to help you in your first month as a new developer

Photo by Andrew Umansky on Unsplash. Cropped for aspect ratio.

Everybody has been the newbie at the company before.

Everybody that calls themselves an engineer, developer or programmer has had a first job where they felt like they knew nothing, and everybody was better than them.

After being the newbie, talking to other people about their first experiences in new developer jobs, and later onboarding new engineers onto my own team, I compiled a list of things to make your first month (or two) be less stressful, and to help you turn all the scary unknown things into an advantage.

1. Get used to the uncomfortable newness

Everything is new at a new job. Every time.

It doesn't matter if you have zero days or 10 years of experience working as a developer: it will always feel like everything is new. Mostly because it is.

Every time you start a new job there will be a bajillion things you've never seen before: every company works differently, and has different cultures and work habits; you'll work with new people, new codebases, sometimes new technologies, and all of those (and much more) are bound to take some time to grasp; especially if it's your first job ever.

If no one ever told you this, let me tell you this right now: you're not required to be good at your first job right away. As a new developer we're not so used to the newness of it all, but as time goes by you'll probably get better at dealing with the new and quickly adapting to it. So you shouldn't stress too much about it.

But, if you want to get up to speed faster, you'll need to get used to the uncomfortable feeling of the new and use it as a resource rather than a hindrance. Take a deep breath and rely on your peers. They all know what it was like being new (although some may have forgotten).

Here is a list of things you can do:

Ask as many questions as you need, sometimes to the
point of being annoying. Being annoying for a few weeks is better than being completely lost for a few months. (But also, find out who you can annoy and who you can't.)
Ask a more senior colleague if they can walk you through the codebase or, alternatively, ask for some smaller bugs to solve if you prefer investigating on your own. This will help you get acquainted with the codebase faster and also will show initiative and ownership.
Ask if you can shadow a colleague for a day and watch how they work and interact with other people. Shadow more than one, if you can.
If they don't do this already, set up 1:1 meetings with people on your team and some other people your team might interact with on a regular basis. Ask about your team and their work, how they interact, and anything else you may want to know. This is especially useful to understand who and how people are and who to go to when you have questions.
Ask if they have any documentation that you could read to help you understand the work better and faster.

"Being annoying for a few weeks is better than being completely lost for a few months."

2. Document everything

If they don't have documentation, you might be the one writing it. And rather than seeing that as something bad, you can make it work in your favor.

Pause for a little personal story.

When I joined my team they didn't have an onboarding document, so my manager loosely suggested that I take notes of my onboarding process (everything I learned in my first month on the team), and make a document that could help the next people coming in.

At first, I didn't fully listen, and never took notes of my environment setup as I didn't think it was going to be needed - it was not a set environment, we were allowed to use whatever was the better fit for us, so I thought nobody else would need my environment setup details.

Oh boy, was I wrong… and I was the one who suffered the consequences as just two weeks later they needed to exchange my computer for a different model and I had to re-do the whole setup.

After those two days I spent re-learning how to set up my computer, I realized that even though some of the things I was learning might not be useful to other people, I could be the one benefitting from them in the future.

That helped me realize the importance of documentation: it's useful not only to speed processes (my second setup could've taken me a couple hours instead of two days), but also to make sure everybody's on the same page and understands the work that is being done.

Since those early days, I have gotten better and better at documenting processes, and even earned a documentation award. Only I know how many times I had to go back to my own onboarding document when I needed some information I had already forgotten.

Without a proper onboarding document, things might take more time to figure out - and this might not be a problem, but a blessing in disguise.

My advice to you is: take notes about everything you're learning, everything you think might be important to remember later, all your team's meetings and rituals; If you don't know a process, ask a colleague to go over the process with you and take notes of it.

You'll then get all these notes and format them into an onboarding document the way you prefer. On the other hand, if there's already an onboarding document, you can compare your experience with it to check if anything changed or if there's anything missing and you can help improve it with your new found knowledge. First project done. And you haven't even touched the codebase yet.

By the way, it's always good to document every time you get any compliments on your work or you've done a successful task. Keeping a "Brag Document" is a great way to help yourself through imposter syndrome and also helps your manager and colleagues through performance reviews.

"Get your work recognized: write a brag document", by Julia Evans

3. Take it one day at a time

These first days or weeks can feel daunting and the imposter syndrome might pay you a visit. Just remember: your colleagues have been there too. Everybody had their first job once and a lot of people feel imposter syndrome, even after many years of experience.

There will always be days where everything seems too overwhelming and you feel like you don't understand anything. This is very normal, everybody has been there and although this is an uncomfortable feeling, with time, you'll learn to recognize it and not give into it.

My way of mitigating imposter syndrome is going through my brag document.f that doesn't bolster me, I'll try to solve a problem. Everybody's different, you just need to find what makes you not feel that way. But this is a feeling that more likely than not will accompany you for the rest of your career, especially if you're a young woman. Like imposter syndrome, some things need time and experience for you to understand.

There's this one debugging technique that I thought I knew how to use but every time I needed to use it, I couldn't figure out for the life of me what I was doing wrong and it never worked out. Imposter syndrome screamed at me every time I tried to debug something.

It took me asking my manager over and over again for a year and a half how to do it every time I needed to debug anything until one day I didn't need to ask him anymore.

Some things might take you a day, while others might take you one and a half years and several attempts to grasp. And that is ok. In development, the more we fail at something, the more we see it and re-learn it, and when we finally grasp the concept, the easier it is to remember it later.

Every failure you have is just a way for you to cement that knowledge deeper into your head. So you might need a few days of being overwhelmed with something until you get it. Be easy on yourself.

"Some things might take you a day, while others might take you one and a half years and several attempts to grasp. And that is ok."

4. Don't be a deer in headlights

It's common for some people to freeze whenever they feel overwhelmed, and like I said before, this first experience in a new company is filled with opportunities to feel that way.
As a way to mitigate this feeling of overwhelm, you should do something you know and feel comfortable with to keep you in motion: figure out a bug, review a PR, talk to someone about something you like, write about your experiences or like I did, survey people about your team and product. What?! Yeah. I did that.

I came from a very - VERY - different background than computer science: I used to be an assistant director in movies and television. So, my first ever job as a developer was more than overwhelming; It was completely different than anything I ever knew. I had never worked in an office, or with technology, and in a different language than mine before. Everything from meetings' structure, to zoom, to having managers, to sharing a codebase to working in a design system, to working with people from another country, were new to me.

I had a month to spare between signing my offer letter and the day I started working, and my manager had bought me a book about design systems to bring me up to speed faster. In the book (Design Systems by Alla Kholmatova), they described in depth the process of creating a design system from scratch, and went into a lot of detail about how you need to understand the purpose of the design system before making decisions about it through surveying the team and stakeholders. This book, along with a lot of UX I was learning at the time, gave me the idea to create a survey that I could ask people when doing my 1:1s.

The survey consisted of a quick 5–10 minutes personal interview about how they viewed my team, our customer service, which were their favorite and least favorite components in the design system, how they would describe the design system in three words, and a few other questions. I also interviewed my teammates with slightly different questions than the rest.

I promised anonymity and assured them I had no stakes in this as I was just joining and was not responsible for anything. I did that in hopes they would be as truthful as possible and I could gather good insights. After a month of interviews and crunching numbers I created a presentation for my team.

This survey had nothing to do with the development work per se, but this helped me understand a lot about my team, the work they did, how other teams viewed them, and what I had to do to catch up with them (one of the top phrases in the surveys was "great customer service" and I felt I needed to match that from there on).

This helped me not to be stuck with feeling overwhelmed, and also helped my team find pain points in the design system that they had not known before.

This whole story is just to show you that if you feel overwhelmed, you might want to rely on something that feels more familiar to you at first. Try and find something that you're used to doing and can bring value to your team.

This doesn't even need to involve code or be something necessarily expected from a developer. Just doing something familiar to you will help with feeling overwhelmed and might actually help your team in ways they were not expecting. A lot of the time your fresh eyes will help see things your more senior teammates can't.

5. It will end one day so, enjoy while it lasts

The best part about being a new developer is, most of the time, people will cut you more slack as you're still learning and getting the grasp of things. This opens the door for you to make mistakes, try new things and learn a lot.

Don't waste this time by thinking you don't know anything or that you're less than your peers. Believe me, you're not. You were hired because they saw something in you. Ask your manager how many people you were competing with for the job. This might give you some of the assurance you need.

Also, embrace the fact that you have a lot of room to grow and each interaction you have with your team or a new part of the code is an opportunity to learn something new or solidify knowledge you already have.

If you have the opportunity, go ahead and create your own project, make something from scratch and allow yourself to learn and make mistakes in the process. Nothing teaches us how to fall and get back up again like falling and getting back up. And there's no feeling better than seeing something you idealized and built yourself come to life.

As time goes by, you won't be the new developer you once were, you might even get a promotion or two and you'll see the responsibilities grow and mistakes might become more costly - even though mistakes will always happen, and that's fine too. So allow yourself to experiment before that time comes.

Being a developer can be a roller coaster ride, where you have great and not-so-great days. There will be times when everything feels like a mess and you can't make sense of anything, but when you finally find the solution for a problem that has been bothering you for days, it's magical and will fill you with euphoria.

Remember that even experienced developers make mistakes and continue learning everyday. You're not alone in this journey, so reach out to your colleagues for support and guidance. Embrace the process of constantly learning and enjoy the ride.

Don't let anyone undermine your abilities or discourage you, and welcome to the team!

If you want to learn more about your first year as a developer, read my other article:

5 lessons I learned in my first year as a programmer

Tassia Accioly ・ Jan 25 '22 ・ 8 min read

#programming #career #beginners #codenewbie

Copy editing: Jessica Appelbaum

5 lessons I learned in my first year as a programmer

Tassia Accioly — Tue, 25 Jan 2022 14:24:10 +0000

Special tips for people looking to enter the tech industry

Recently I had the pleasure to talk at Ironhack about testing to their new cohort of Web Development students. Unfortunately due to work, I could not be present for their final project presentation but I thought a lot about them.

I went to talk about testing in web development — and we did — but we ended up talking a lot about the market, how it is to work as a developer, what fears and anxieties I overcame this past year and what they should not worry about.

It's been about a year since I graduated from the bootcamp at Ironhack and talking to them made me think a lot about how the experiences I had in the past year changed me. It made me think how far I've come on this journey to become a developer, the things I left behind, the dreams that changed (and the ones that didn't) and how I grew and matured as a person and as a professional. But probably the most important: how their fears were the same as my friends and I had when we graduated.

Thinking about that made me want to share some of the general knowledge I learned this past year, with some tips specially for those that did not follow the traditional CS path into tech.

1. Make yourself seen

Unfortunately making yourself seen is super important when you're a beginner. Before companies can come find you and offer you jobs (sometimes this happens to juniors and associates too) you'll need to make yourself present. "Present where?" you might ask, well, here are some of the most important places:

Take the time to build out your LinkedIn profile and maintain it, you'll still need it to find jobs and to send it to recruiters, and this is the best way to make sure people are finding you on there. Having key words about your areas of work and interest on your profile is what's going to bring you those job offers.

Create a Twitter account if you don't have one. There's a huge tech bubble there, greater than on any other social media. Find the people you learned from or that you watch videos on youtube from and follow them. Make posts introducing yourself to the bubble and to people individually, there are always job offers there and people are always willing to help.

Add a profile to your GitHub — you should already have a GitHub account by now — if you don't know how, I have another article explaining how to do it:

7 Tips on making your GitHub profile better

Tassia Accioly ・ Jan 4 '21

#github #portfolio #tutorial #career

If you're any good at writing or talking, write about what you're learning, teach someone something new here on dev.to or on medium, or maybe create a video, a post on LinkedIn or on Twitter. Teaching others is the best way to learn it yourself (and solidify that learning) and also a great way to make yourself seen.

2. You're also interviewing the company

The most important thing we forget when trying to find a job is that in any interview we're also interviewing the company. It's super important to find a company that aligns to your beliefs: it makes your job easier and more enjoyable, it helps with connections, with not having burnout syndrome and more than anything it helps with your mental health overall.

Sometimes we tend to overlook the importance of the company's culture on our mental health but it's one of the most important things for how your daily work life it's going to be.

When it's your time to ask anything in an interview (if they don't care to give you some time to ask questions, the company might not be worth it), you have the chance to get a glimpse of what working at that company will be like. Ask the difficult questions and see how they react and what they answer. Interpret what they mean when they say things like ownership or flexible hours; Do they expect you to work for the company as if it was your own but not pay you for that? Do they mean you'll be working way more hours than a normal 9 to 5?

What are your personal red flags for a company? You might not know them right away or even recognize the traps on interviews, you'll learn them eventually but the important part is that you know what you expect from the company and from your future job. What is important to you?

After some interviews you'll learn how to ask the hard questions and interpret the answers. You'll also learn your red flags and even refine what you expect from your new job. I learned a lot about what I wanted from the place I'd work on after I had been through some interviews. Sometimes you don't even know what you can ask for when you've never been in the tech industry.

3. Nobody knows anything

This is perhaps the most important thing I learned this past year because it made me a lot less anxious in general.

When I say "nobody knows anything" what I mean is: the development world is made of people that need to constantly adapt to new frameworks, technologies and languages, so people end up not getting too attached to what they know because sooner or later they'll need to "know" other things.

Don't get me wrong, you'll still need to know the fundamentals of programming deeply, but to be a good developer you need to learn to adapt and adapt yourself to learn. ALL THE TIME.

We are professional learners and as time goes by we get so good at learning that we don't care much about what we don't know. If we need to know something to do a job we can learn how to do that in a heartbeat.

From what I've seen this past year even my seniors are frequently having to learn something new, something they never needed before or a new technology, and this is not a problem. It's impossible for someone to know everything. There is infinite tech knowledge out there and if you need to learn it for a job or a task, you just go and learn it. Everybody does that.

4. Forget what you've learned

In order to learn new things this fast, we frequently need to open space, so we end up "forgetting" stuff we don't use frequently. This might seem like a problem in other areas, but in tech this couldn't be further from the truth. Whenever we need to use some specific information we forgot, we know we can do some quick googling (stack overflowing?) and it will be there.

In my conversation with the students, one of them asked me what makes me feel I'm not a senior engineer yet. My response was simple: the only difference between me and a senior engineer (aside from the mentoring aspect) is that they have learned and forgot a lot more things than I have, so when they are faced with a problem, they have a larger pool of things to pick from to solve said problem.

The thing is: although I'm saying "forgetting", I'm not talking about completely forgetting what you've learned. I'm talking about how generally we forget how to implement something or certain specificities of what we learned, but we still know those are ways to solve specific problems. The important part is just knowing those things exist for when you end up needing them in the future.

Google and Stack Overflow will be your best friends

People coming from bootcamps or from teaching themselves have more than learned how to learn things, so we shouldn't be worried about that in our jobs, we'll learn and forget a lot and sometimes make this better than people with CS degrees, the difference is in the size of your pool of forgotten things. The more you read/learn different things the larger your pool will become, the more exposed to different approaches you'll be and the better you'll be at solving complex problems.

5. You'll never get smarter alone

This comes from a phrase Emanuel de Souza said on LinkedIn that I immediately wrote on a sticky note and glued onto my computer screen:

We do not get smarter alone. We "borrow" other people's intelligence by understanding their point of view.

Although you are probably very proactive in your studies (if you're not, you might want to rethink the tech world) you won't get very far alone. Good code needs exposure to several ways of thinking and when you expose yourself to other people's intelligence and processes of thought you learn a lot and make your code better.

One of the first things that happened when I started learning to code — and I think is a part of everyone's journey when entering the code world — is that I slowly changed how my thought process worked. I started learning how to break big problems into smaller ones, how to think about each small step I needed to write to make the computer do simple tasks (and I quickly learned that the computer needs a lot more detailed instructions than I had thought), or how I could solve the same problem in several different ways.

When you do pair programming or just watch another programmer work — and this programmer can have any level of expertise in this case — you learn a lot about how to think differently not only for processes but also for things you already thought you knew in code; Sometimes people use code structures different than you're used to. All this exposure to new ideas improves your own code greatly. Observing other people work through some problem is also a good way to learn about how things are done in your team and/or the company you just entered.

The great thing in tech is that, most of the time, if you care enough about your work to make it good and keep looking, you'll find your way into what you deem a good company. Everything happens really fast in technology and the industry itself is changing at a fast pace all the time. For example, a few years ago the number of remote jobs wasn't even nearly close to what we have available today after the pandemic started. This helped a lot with people not being stuck with the companies in their area anymore, they can now look for better opportunities outside their comfort zone. You can also do that, you just need to overcome the fears we all have of "I'm not enough for tech" or "I'll never find a job" and it will eventually happen for you.

I hope these tips leave you feeling a bit less fearful of your future in tech and help you learn to embrace the chaos of knowing you don't and you can't know everything. You'll eventually find your way into learning from others, searching stuff on Google and creating your own pool of forgotten things.

If you'd like to ask anything or would like to talk about your experience and how you can improve your socials, reach out to me on my twitter! I'd love to hear about your journey in tech and the place you're in now!

7 Tips on making your GitHub profile better

Tassia Accioly — Mon, 04 Jan 2021 18:22:43 +0000

Last year GitHub launched the profile feature. This feature allows GitHub users to create a ReadMe and use it as their profile to display interests, projects, and anything they might deem interesting about them and what they do.

The profile is definitely a feature that you should be using to give your GitHub a boost and to let people know a bit more about yourself, and here is how to do it and a few tips on how to make it better!

First make the profile

Making a profile is pretty simple: create a repository with the same name of your GitHub account, in my case tassiaaccioly. When creating this repository add a README, this is what will be your official profile.

Once the repository is created (make sure this repository is public!), GitHub will create a green button to the right side of the repository page saying that this is a special repository and you can make it your profile. Just click on it:

^{from GitHub}

Once you click the button, this repository now is your profile, so all you have to do is edit the README file!

The first time you open it, GitHub will have some ideas for you on what to write:

^{from vibhorchaudhary}

But how can I do that?

Well, there are some ways. The readme files on GitHub accept both Markdown and pure HTML — when I say pure I mean with no inline styles — so to write you just have to use one or both of these languages.

GitHub has a nice section on their documentation explaining a bit about how to use Markdown:

https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/basic-writing-and-formatting-syntax

Or, if you want a deeper knowledge of markdown:

https://daringfireball.net/projects/markdown/syntax

GitHub also accepts emojis! To use them you can copy and paste the full emoji 👍 or the emoji code :thumbsup:, both work fine just choose one and go for it!

Here are two fonts for emojis, the first one is for codes and the second for the emojis themselves:

https://www.webfx.com/tools/emoji-cheat-sheet/

https://emojipedia.org/

Some more tips of what to add lie ahead! Proceed at your own risk (Tl;dr)!

1. Add information about yourself

The first thing you should do on your profile is to talk a bit about yourself: who you are, what you’ve been doing, if you have some accomplishments (flaunt them!), what are the areas of technology you focus on and what is your focus on GitHub, so, the basics about you as a tech person.

Here is your place to talk more freely, you can also add gifs and images. I’ll talk about it on tip #5!

Another thing I’ve seen people with different names make, that should be added in this section, is to add an audio file to your profile showing how to pronounce your name, this helps people say your name properly if you don’t want to keep correcting them!

2. Contact Information

This is very important:

Give ways for people to contact you outside of GitHub.

This can be email, Twitter, LinkedIn, Facebook, Instagram, Telegram, Whatsapp, you name it. Pick at least two ways to contact you and add them to your profile.

GitHub is a child of a social network with a public repository but it makes it difficult for people to communicate amongst themselves so if someone wants to talk to you they won’t be opening issues and waiting for you to respond (they might, but let’s agree, twitter or instagram is much easier). So give them a way to talk to you that is easier than GitHub.

These ways might be added as normal links using Markdown or HTML but they can also be added as image links, with icons attached to them, as it’s own section:

Or as just images links below your name/opening phrase:

A simple way to make these icons is using a link reference on Markdown:

^{this also allows the images to have some space between them}

Some good places to find icons are Simple Icons (brands, languages and app icons), Flaticon (miscelaneous icons), or any place you might find online! Just remember to give credit to the people who made the icons!

Also I’d suggest using svg icons because you can control their colors more easily making it easier to do a cohesive profile. I explain how to do it over on tip #5!

3. Badges

Badges are usefull to show people in a fast and organized way the languages, frameworks, libraries and technologies you know. I have a full article on how to make simple custom badges:

5 Steps to make custom language badges for your profile using shields.io

Tassia Accioly ・ Jan 4 '21

#github #career #productivity #tutorial

Some people section their badges to further organize their profiles. Depending on your area of work, some of your sections might be: Languages, Frameworks, Dev Ops, Application and Data, Bussiness Tools, Utilities, or anything you find works to showcase your habilities.

4. Status Cards

GitHub user Anurag Hazra made several status cards that you can easily add to your profile, they can show your top languages, your GitHub status, add specific repository cards to your profile and more. They also come in a lot of different styles and themes:

anuraghazra / github-readme-stats

⚡ Dynamically generated stats for your github readmes

It’s easy to use, just read the readme and chose the cards you’d like to use. You can add them to your profile and showcase your status to the world to see:

^{here I'm using the compact layout and the Great Gatsby theme}

You can find all the available themes here. You can also customize the cards to your liking adding or removing stats.

5. Add Images and Gifs

To add images and gifs to your profile you can use both markdown or HTML. But with HTML you can also define the image/gif size and position on the page, so most people tend to use HTML to display their images.

People can use images to illustrate some aspects of their profile but I’ve also seen many people do beautiful presentation banners of themselves and use that, for example:

WaylonWalker / WaylonWalker

Learning in public

Hey there 👋,

I create blog posts and open source packages mainly about python and data engineering. I have a passion for learning and sharing my knowledge with others in a way that's as public as possible. You can see a full list of what I am up to on waylonwalker.com. If you found value in something I have created, please feel free to send a tip, give me a shout out @_waylonwalker, give some ♥ on DEV.to/waylonwalker, or sign up for my newsletter at waylonwalker.com/newsletter I would love to see you join.

Boy Scout Rule

I love open source. I am not a heavy maintainer of any large libraries, but I really like the boyscout rule. I contribute to things as I come across issues that I think other people might struggle with. This may be things that are overlooked by someone who is deep…

View on GitHub

Waylon has a very impressive README if you want to check his! He also includes some parts that update in real time, which is really nice!

One last important tip for images!

Since the end of last year, GitHub implemented on the dark mode, so be mindful of your gifs, svgs and pngs when making your profile because if someone is using dark mode and you use a black icon it will desappear! Try to find colors that work well for both dark and light mode.

One of the advantages of using svgs is that you can change their color very easily, just add a “fill” attribute to the path tag and add the color you’d like to use in any formats accepted by CSS (rgb, hex, etc), for example:

As I said before, a great source for svg/png icons to use on your profile is Simple Icons, they also include the official color for that brand/company.

Just search for the Icon you want and download it or use their link!

6. Languages/Frameworks you’ve been studying

Alongside languages and frameworks you know, you can also show in your profile that you’re continuously working on your self-improvement by adding a section with the things you’ve been studying lately.

This section will also showcase what you’re interested in right now which makes it very interesting because you can stray from just tech to other areas too if you’d like.

Again this section can be a list, various images, badges or anything you might think of. Maybe gifs? Who knows? The sky is the limit!

7. Make it your own

The most important thing about this profile is to share with people who you are, what you’re doing and how to contact you, so make your profile unique and make sure it represents who you are!
If you are very into data, maybe adding a chart or a graph would be a good idea. If you’re a more laid back jokester type of person maybe adding some gifs or a fun theme might be interesting. I saw a profile once that was all Star Wars themed and all the text were jokes with the movie theme. If you are a writer and researcher of technology maybe showing off your articles and some social numbers is a good idea!

Well, I guess you get the gist of it: make your profile you! The more you it is, the more people will connect with you!

But again, none of what I say here is set in stone, I’m improving my profile all the time, adding and removing sections, changing colors, adding and removing images. As you grow and evolve as a tech person you might change what you want to showcase, or maybe new assets (like the status card one) appear and you want to incorporate them. Have at it!

And to end this long thread, a list of many profiles you can take a look and get some inspiration:

coderjojo / creative-profile-readme

A Collection of GitHub Profiles with awesome readme

Also this whole thread from Waylon Walker with several people sharing their profiles:

🤓 What's on your GitHub Profile README

Waylon Walker ・ Jul 9 '20

#discuss #github #watercooler

If you managed to get this far I hope you use these tips and make the most of your profile on GitHub. And if you want to contact me: my GitHub and Twitter are open!

You can also follow me over on medium: https://tassiaaccioly.medium.com

5 Steps to make custom language badges for your profile using shields.io

Tassia Accioly — Mon, 04 Jan 2021 17:46:44 +0000

A few months ago when I started my journey into being a developer I used to see those little languages badges on people’s profiles on Github and think they were very cool. But even though I looked the code behind the profiles, the shields.io URLs and the shields.io page I was completely dumbfounded by how people did those.

One day I found a few of those on a friends profile and I thought that I finally would discover how to do them. I contacted her and she gave me the sad news that she also didn’t know how to do them and had just copied from someone else, as I had done myself.
Well, it took me a few weeks and some research, since I was trying to graduate from Ironhack’s Web Dev Bootcamp at the same time, but I finally was able to kind of “reverse engineer” their URLs. So today I bring you how you can make your own badges and make your profiles more interesting.

First things first

The first thing you need to do to make your own badges is to find if the logo image you need is available for shields.io. This is quite simple, the available images are: bitcoin, dependabot, discord, gitlab, npm, paypal, serverfault, stackexchange, superuser, telegram, travis or any icons available on Simple Icons:

Simple Icons

On the Simple Icons site you just have to search for the language, framework, library, or brand you want to see if it’s available.

1. The URL

If the icon you want is available, you are ready to start building your badge, this is the first part of the url that will precede all your badges:

https://img.shields.io/badge/

Then, following the first part, you are going to add a dash and whatever you want to appear written on the badge the way you want it to be written (this part is case sensitive) so you can add a language, framework, library, brand, or whatever you may want to do a badge for. I’m going to do ReactJS for example:

https://img.shields.io/badge/-ReactJS

If you want to write more than one single word, you need to put %20 instead of a space:

https://img.shields.io/badge/-React%20Router

2. The Color

After the name, you’re going to need to add a color for the background of the badge. The shields.io url accepts named colors and also hex codes. Some of the named colors the url accepts are: brightgreen, green, yellowgreen, yellow, orange, red, blue, lightgrey, grey/gray, success, important, critical, informational, inactive, blueviolet, black, and any other color accepted in CSS.

these are some examples of named colors

You can find some more named colors (and hex codes) here:

https://htmlcolorcodes.com/color-names/

To add the named colors or the hex codes to the link you just need, again, to add a dash (-) and the color:

https://img.shields.io/badge/-ReactJS-lightblue

https://img.shields.io/badge/-ReactJs-61DAFB

A little tip! When looking for the logos on Simple icons, the site already tells you what is the oficial color (and hex code) for that icon/brand:

3. The Logo

After knowing the logo exists on Simple Icons it can be simple or a bit more complicated to add it to the url. If the icon has a single name as in the case of react, git or javascript it’s quite simple, just add ?logo=name_of_the_icon:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react

For icons with more than one word, like React Router, you have to add a dash (-) between words:

https://img.shields.io/badge/-React%20Router-CA4245?logo=react-router

Another tip! Some names might be more difficult, for example, NodeJs is written: node.js in the url. So some names you might need some experimenting. Feel free to contact me over on twitter @itsmetherogue if you have difficulties with this.

4. The Logo Color

You can also define a color for your logo, to do that just add &logoColor=color at the end of the url. This also accepts named colors as well as hex codes:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react&logoColor=white

Like the badge, the logos also accept any of the named colors accepted in HTML/CSS.

5. Other Stylings

Other than colors, shields.io also allows for some more stylings of the badges:

The flat style

This is the default style for these badges, but if for any reason the default style change from browser to browser or changes in the future, to get this style you just need to add &style=flat at the end of the url:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react&logoColor=white&style=flat

The plastic button style

This transforms your badge into a 3d button like badge. To use it just add &style=plastic to the end of your url:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react&logoColor=white&style=plastic

Squared Bold Style

This makes your badge into a rectangular flat badge with the writings all caps and bold. To use it just add &style=for-the-badge to the end of your url:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react&logoColor=white&style=for-the-badge

Squared Style

This makes your badge into a rectangular flat badge. To use it just add &style=flat-square to the end of your url:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react&logoColor=white&style=flat-square

Badge Width

You can define a bigger width for your logo just by adding &logoWidth=amount_of_pixels to the end of your url:

https://img.shields.io/badge/-ReactJs-61DAFB?logo=react&logoColor=white&logoWidth=30

There are a few other stylings but they don’t apply for this kind of badge. You can check other stylings and other types of badges over on shields.io and I’ll be doing another article on interactive/real time badges soon!

There’s also a npm package that allows you to make badges easier. I haven’t tried it yet, but it’s called {badgr} and you can find a bit more about it here.

I hope you liked this little tutorial and make good use of it to add some interest to your profiles!