To All of My Talented Sisters

Negar — Sun, 07 Mar 2021 23:00:55 +0000

"Why shouldn't I give it a try?" I wonder, sitting in the living room four years ago.

Growing up, I always had huge dreams about my future, from being a superhero to becoming an astronaut. Hopefully, my parents never stopped me from dreaming big and never question any of my goals.

But around age 22, in the middle of my plan for becoming an astrophysicist at the physics faculty, I realized that this is not a job that makes me want to wake up every day and go back to work. I was feeling like that I had a plan for my life for years and now I am lost. I have always been the girl with the plan since I was 6 and now the same person didn't even know what should she do after graduation.

It was almost 4 years ago when my friend sent me a photo of a girl who was working as a developer and said "Look how successful she is!", that one picture made me wonder "Why shouldn't I give it a try?".

I have always been into technology. Ever since I've got my very first computer I couldn't get my hands off it. Even when I should study for my exams I rather read the book from the PDF instead of the physical book, just because then I didn't have to leave my computer. But programming was never something for me to think of.

The summer after my graduation I registered for a short frontend Bootcamp. Compared to the others in the same class I was one of the people with the least related background knowledge. I was scared and fragile. Compared to a person with a programming degree, I was lacking 4 years of studying. With all of that fears and doubts, I kept my mind open and gave all of my attention to the courses. Sometimes, I found myself opening the 20th browser tab to search for the meaning of another new concept just to be able to read an article to the end.

Nine months later I found my very first job as a Frontend developer with HTML, CSS, Javascript, JQuery, and Bootstrap on my skillset in my resume. I remember promising my employer in the interview that I won't be the same person in two months due to all the new things that would learn. I stood by my words and in two years of working in that team, I never let them down with anything that was assigned to me.

Meanwhile, I start writing articles and making videos in my free time to share my knowledge as little as it was with the new fellow developers to help them have fewer struggles at the beginning of the road. With all the supports and encouragement that I've got from people online, there were always a few destructive comments, making fun of the simplicity of the topics or accusing me to get attention just because I am a girl, not that I am doing anything valuable. I have to confess that some of these comments dissipate my motivation for showing up and providing more content for a while. But then I've learned no matter how experienced and professional you are, there are always some people feeling insecure about your growth and try to feel better by making you feel insecure on some levels. The best reaction to these destructive behaviors is to keep moving on.

In the past four years, I've learned that you never know everything and you never have all the answers, even if you have all the degrees and experiences. I've learned that tools and frameworks can be learned in two months but what you need years of experience are the fundamentals that happen to seem less important and useful. I've learned that sometimes your soft skills, morals, and communications are more important factors to make you a valuable employee for a good company than the number of programming languages that you have mastered.

Last month I proudly had a talk at the JS World Conference, one of the conferences that I have always been dreaming about. And when it was happening it didn't seem like a dream anymore; It was reality, and it was achievable. I still have my doubts and fears when it comes to doing the things that I have never done, but from the bottom of my heart, I know that all the dreams can become reality, and then they won't seem impossible anymore. There is no such thing as a superhero because everyone can achieve anything, they just need to keep on trying and take a new step forward once in a while.

...

Photos form unDraw

Use Git More Efficiently: A Simple Git Workflow

Negar — Fri, 07 Jun 2019 13:17:21 +0000

Git without a doubt is one of the essential tools for every developer. As helpful as Git is, not following best practices will make it completely useless. That's why there are different standard workflows to make most out of Git and its awesome features.
For a long time, my inception of Git and GitHub was a tool that back-ups the codes and let us access them online; Which was not completely wrong, but there are so much more about them that I didn't know until I start my work as a developer in YasnaTeam.
In our team, about 10 developers are actively working on the same repository. Having the same habit and so-called culture is necessary to avoid conflicts and chaos. With over 100 commits per day, things could get out of hand very soon. To avoid such problems we implement a modified version of Gitflow.

This post has been published on Medium, too.

Use Git More Efficiently: A Simple Git Workflow | by Negar Jamalifard | Medium

Negar Jamalifard ・ Jun 8, 2019 ・
Medium

How it works

Instead of having one single master branch, we have another extra branch named dev. These both branches are locked and no one can push directly into them.
master is reserved for production only. ‌After testing new features, the repository owner updates master before each release.
dev is the default branch that all of the developers create a branch from and merge back into. dev is always ahead of master and it's the only branch that will be merged into master, frequently.

Naming Branches

We have a pattern for naming our branches.

[Module Name]-[Type]-[Detail]
// Example
users-fix-attach-roles-issue#765

Module Name

Since we have a modular structure in our code base, changes related to each module should be committed on a separated branch with the module name. This part could be removed if you don't have such structure, in your project.

Type

According to the type of task, developers should choose between one of these types:

feature
enhance
cleanup
refactor
fix
hotfix

Type hotfix is for urgent fixes on the master branch and won't be used that often.

Detail

The detail is a short description of what is going to be delivered by the branch.

This branching rules force us to separate each task to meaningful chunks and merge frequently into dev and always have fresh branches. One great side-effect of this approach is to minimize conflicts.

Commit Messages

In order to have clean and descriptive commit list, we also have a naming rule for commit messages (I love rules!).

[[Module Name]] [Commit Message]
// Example
[users] add fetch users endpoint

Having the module name in each commit message might seem redundant since we have the name in our branch, but the truth is after merging all branches into dev (or master), looking at the commits history you cannot say which branch each of the commits was belonged to. Because right now they are all belonged to the dev (or master) branch. In order to filter through all commits easily, we need to have the module name somewhere inside the commit message.

The commit message itself should complete the sentence "This commit will…" grammatically.

Pull Requests

Title

Title of the pull request is automatically filled with the branch name. In case the branch name is too generic, more details are expected to be added.

Body

The body should contain details about the pull request. In our workflow pull requests are usually related to an existing issue. We create an issue for each bug or feature. So we link to the related issue inside the pull request body. We also mention highlights of the changes that are made inside the pull using bullet points. We have created a template for our pull requests, to facilitate the process.

Review

Code review is one of the most important parts of our daily job. Once a pull request is created, the creator should choose two of peers to review the code based on some prespecified criteria.
Once the pull is approved by reviewers, the creator can merge into dev and delete the branch.

We have been using this workflow for more that one year and update frequently based on our needs. Do you use some other git workflows on your team? Let me know how they are.

DEV Community: Negar