DEV Community: Ségolène Alquier

How to reduce back-and-forths on a pull request ⚡️

Ségolène Alquier — Tue, 10 Nov 2020 16:24:26 +0000

Having your code reviewed is a great opportunity to improve but it can also be very time-consuming at the beginning.

The more comments or requested changes you get, the more time your pull request waits before being merged.
If you work on a big codebase, this means... more possible merge conflicts!! (Noooooooo 😱)

If your team is struggling with pull requests taking too long to merge because pull requests bounce back and forth a lot, here's 6 tricks you can apply to shorten the code review process:

1. ✂️ Don't hesitate to split user stories

A user story is a description of a unit of work that needs to be done. It is usually written from the perspective of the user.

A user story (or ticket) should be scoped to a single feature that a user can do in the system being built.

Scoping a project in small tickets has the following benefits:

allows to ship features faster
keeps the team motivated
makes code reviews easier (less changes on a pull request)

At Doctolib, all tickets are expected to take between 1 to 3 days of development. If a ticket is supposed to last longer, we have to split it

2. 💡 Clarify what needs to be done before development starts

If there are still uncertainties regarding the feature, don't hesitate to discuss with the relevant people to find answers before you start coding.

It's harder to keep an eye on the big picture when you start coding (because there will be other issues to fix!), so you better start with a clear idea of what's expected.

From a functional point of view

Discuss the output, edge cases, final design e.t.c. with the Product Manager
Don't hesitate to challenge their vision if you think of another technical solution

From a technical point of view

If you're not sure how to implement the feature, discuss the possible solutions with the other developers or your manager

3. 📝 Add context to your pull request

Add the ticket link if there is one
Add a short description of the pull request if there is no ticket
Explain why you chose this specific solution if you hesitated with another approach
Add comments if you feel it's necessary

4. 📍 Tag reviewers when the pull request is 100% ready

Wait for all tests to pass
As the author of the PR, add the relevant comments and PR description beforehand

5. 🧐 Contact the author of a comment you don't understand

If a comment is not clear enough, reach out to the person and make sure you understand what they meant. This will reduce the noise of back-and-forth clarifications in the PR and will allow you to get your answer quicker!
Then document the answer in the conversation in the pull request, to make sure everyone has access to the answer

6. 🙅 Don’t hesitate to challenge some comments

I know it can be hard to challenge or refuse a comment (especially as a junior or as a new joiner) BUT you can!
Problem is: when applying all comments immediately, you can get the opposite feedback by the next reviewer… which can lead to a lot of back-and-forths.
When not sure, you can check with a third person if a comment is relevant or not.

I hope you enjoyed this article!

I am particularly interested in the topic of Code Reviews and reducing the back and forth on a pull request can definitely lighten the process!

If you're interested in how to be a great reviewer too, I have written an article about it:

Article No Longer Available

Also, feel free to reach out to me if you want to add anything on this topic or have some tips you’d like to share! I'd love to hear about them 🙌

Make your first pull request to an open-source project 💪

Ségolène Alquier — Fri, 16 Oct 2020 16:15:20 +0000

Does the world of open-source sound both mysterious and appealing to you? You're not alone!
The best way to demystify it is to dare making your first pull request on a project!

You don't know where to start? No worries, this article should help you do so 😌.

Find a project you want to contribute to 🎯

Think about the tools that you enjoy using: whether it's a CSS or JavaScript library, a VSCode extension, a gem...
Some of them could be open-source (it's the case for dev.to with forem ✨)

If you run out of ideas, you can get fresh ones by filtering by programming language for instance:

Find an issue you want to solve 🔮

Ok now let's say you identified the project you want to work on! Where do you start, right?

1 - 🔎 Find a good first issue

Filter issues

You can filter the issues by topic or level of difficulty. For a first PR, you can for instance look for the labels easy or first issue.

Make sure no one is working on it

Click on the issue and go through the comments to make sure no one is working on it. If the last comment dates back from a few weeks, you can probably comment and ask to do it!

2 - 🙋 Identify yourself

Leave a comment to ask if you can work on the issue. It's best if you wait for an approval before starting, as it can be frustrating to spend time working on something for nothing!

This way you'll also notify others that you are working on this issue.

3 - ✅ Make sure you understand what's expected

Don't hesitate to ask questions in the comments to make sure you are crystal clear on the following before starting:

what's the expected result
how you can test it
...

Start coding! 🔥

1 - 📥 Fork the repo

This will create a copy of the repository on your GitHub account.

You can then clone the forked repository on your machine and let the fun begin! ✨

2 - 📚 Take a look at the doc

Take a look at the README.md and the CONTRIBUTING.md if there is one.

They should help you getting started and explain how to:

create and name your branch: each project has its own conventions
start the server and set-up the dev environment

3 - 💻 Code the feature, fix the issue,...

Now that you got your server running, your environment setup, and your branch created... you can start coding! 🔥

4 - ✅ Don't forget the tests!

Make sure you don't forget to test your feature or bugfix!

Once again, take a look at the doc, it should explain how to add tests to the project.

Make your pull request 🙏

Once you're satisfied with your work, git push what you've done on the remote repository.

If you then go to the GitHub repo, it should now offer you to create a pull request!

Don't hesitate to provide details on what you've done, how you proceeded or why you chose this technical solution rather than another, in order to help the people who will review it and make sure your PR gets merged!

I hope you enjoyed this article and if it helps you take the plunge... I couldn't be happier! 🥳

If there are still bits that are not clear or you want to add anything, please don't hesitate to comment!

The art of giving and receiving feedback 💌

Ségolène Alquier — Mon, 17 Aug 2020 16:31:38 +0000

A few weeks ago @doctolib we had a great workshop about giving and receiving feedback.

We shared a lot of tips that I had never thought of and wanted to share them with you! 🤓

First thing first: what is a GOOD feedback?

A feedback is a return of experience from another person on yourself that helps you grow

💡 It has to be either:

positive or

constructive: give the receiver insights into improving

How do you usually give or receive feedback as a developer?

👯 With your peers:
- via code reviews, peer-programming...
👔 With your manager:
- during 1:1 sessions, code reviews...
🎨 With your product owner or designer:
- during planning poker estimation, when working on a ticket, when delivering a feature...
🤝 With your client(s) or user(s):
- through user interviews, A/B testing...

Why is it important to foster a feedback culture as a company?

Implementing a feedback culture will:

🌱 allow people to improve and grow
🤲 reinforce trust
💪 boost motivation

💡 Plus it's a virtuous circle: you get feedback, you get better, you feel more motivated, you give feedback to others...

How to give good feedback? 📤

1 - 🙌 Be prepared!

Know what you will talk about and how you will illustrate your feedback

2 - ✨ Create the right context: time and environment

For constructive feedbacks: prefer 1:1 sessions
For positive feedbacks: spontaneous or public feedbacks are a good option if the person is comfortable with
Make sure you are available: present and listening
Make sure your interlocutor is physically and emotionally ready
Find a calm place

3 - 📊 Be factual!

Support your feedback with concrete examples and figures, not only with your feelings
Praise efforts and not just results

4 - 🧐 Don't be judgemental

Don't judge directly but talk about perception: by using the first person 'I'. You could for instance use it seems to me that... rather than you are this way...

5 - 📋 Come up with concrete actions or solutions

Make sure you give clear next steps for the person to improve
But don't enforce them: it's way better if you can define them together

6 - 🗣 C-O-M-M-U-N-I-C-A-T-E

Ask how the other person feels after receiving your feedback
Make sure he/she understands and agrees on the actions
Understand how the person works and what's the best way for them to receive feedback
Don't make assumptions: if you assume what the other people are thinking, you’ll never get their truth but only your version of it... which leads to misunderstandings! Better ask the other person how they feel

7 - 📆 And there you go again

Make it a habit in order to demystify the process
If you have a regular dedicated time, you won't apprehend a 1:1 as a potential fearful encounter

On that topic, another Doctoliber wrote this fun article How to ruin a 1:1, in which he lists the worst things you can do to sabotage a 1:1 😈.

How to get the most out of the feedback you receive? 📥

Receiving feedback is not only hearing it without being mad or hurt. It also means being able to build on it, find meaningful actions and ask for advice.

1 - 👂 Practice active listening

Avoid interrupting your interlocutor

2 - 💬 Take the point

Make sure you understood, rephrase if necessary
But don't feel obligated to say something back!

3 - 🙏 Thank the person

For having the courage to give you feedback!
Remember it can be uncomfortable on both sides...

4 - 📝 Keep the feedback

Write it down or just keep it in mind, so you can go back to it when necessary

5 - 🏃 Don't avoid feedback

Be proactive: don't hesitate to ask for feedback
Suggest having regular 1:1 sessions when necessary

💡 If you don't feel comfortable with a feedback you received:

don't hesitate to reschedule until you're prepared

change the scenery: go grab a coffee, go for a walk...

I hope you enjoyed this article 🥳.

I am particularly interested in the topic of Code Reviews and giving / receiving feedback is definitely key in that process!

If you're interested too, I wrote an article about it:

Article No Longer Available

Also, feel free to reach out to me if you want to add anything on that topic or have tips! I'd love to hear about them 🙌

Which CSS libraries do you use with React? 🧐

Ségolène Alquier — Tue, 21 Jul 2020 21:03:38 +0000

Hi folks,

I'm starting a new project on RoR / React and was wondering which CSS library to use.
I've worked with Material-UI before but would consider trying something else!

Which CSS libraries do you use for your React (or not) projects and why do you love them? 😍

How to make great code reviews? 🤝

Ségolène Alquier — Thu, 28 May 2020 21:02:56 +0000

Today at @doctolib we had a very interesting workshop about code reviews: why they matter, how to ensure they are done well and how they serve both the team and the product quality.

I thought it would be interesting to share what I learned! 🤓

What is a code review?

Once you've finished working on a feature, you can push your work on your branch and make a pull request. Another developer will then look over your code and consider if your work can be merged to master (or another branch you specify).

What are the goals of a code review?

✨ Improve code quality and coding standards
🕷 Find bugs as early as possible: the sooner, the better
🎓 Share knowledge and learn from others: regardless of your level of seniority, you can learn a lot!

An example of a good code review workflow

1 - 🛎 Know there is a pull request waiting for you

Set notifications on GitHub / GitLab
Check your project management board (Jira, Trello, Asana...)

💻 As PR creator :

Tag reviewers on Github to make sure they are notified

Or ping them directly on slack or whatever tool you use

2 - ⏳ Take time: schedule the code review

Set a dedicated time to focus when you are assigned a PR to review
Or you can even have recurring dedicated times in your calendar

💻 As PR creator :

Don't hesitate to suggest a slot to the reviewer so you can go through the code together

3 - 💡 Get to know the task

Check the user story or bug report: to fully understand the context and the expected behavior of a feature or fix
Ask someone who knows: the developer who coded it or the product owner in charge
Read the tests: they can also be a good way to understand the expected behavior

💻 As PR creator :

Don't hesitate to add screenshots / gifs of the feature so that it will be easier for the reviewer to understand what's going on

4 - 🕷 Find bugs: what to look for?

Make sure the whole story is covered: check if the tests and implementation cover the edge cases you can think of
Performance issues: look at performance to make sure there is nothing slowing down
Conventions: make sure the naming, syntax, etc... respect the standards defined
Code quality/clarity: check if the code is easily readable and understandable and whether it could be refactored
UI design: make sure the changes respect the wireframes and user experience
Security: verify you don't see a security breach introduced by the PR

💻 As PR creator :

It's your responsibility to test as much as you can and ask for the PR only when it seems in order to you

5 - 🤝 Give feedback

It's harder to communicate in writing: remember that text can easily be misinterpreted so don't hesitate to emphasize what's good and choose your words wisely
Ask open questions: to make sure you understand the code and decisions
Have empathy: make sure you're making suggestions in a positive way and there is no frustration if things need to be modified
Focus first on what matters the most: don't spend too much time discussing minor syntax errors if you also spot serious bugs or security breaches
Request changes if necessary

💻 As PR creator :

Remember it's your code that is criticized... not you!

6 - 🎉 Approve the pull request!

When should you approve a pull request?

when the feature does what it is supposed to do
when you feel comfortable maintaining the code
when you feel comfortable debugging the code

This great workshop was made by Emmanuel Gautier, thanks! 👏

If you have other good practices, tips or tools for code reviews, I'd love to hear about them! 🙌

Mastering GIT step-by-step: collaborating on a project

Ségolène Alquier — Sun, 24 May 2020 20:50:13 +0000

Do you start freaking out when you have to use git commands? You're not alone, we've all been there. I still am to be honest 🙈. I am writing this as much for me as for you!

In a previous article, I went over GIT basics. I'd recommend to read it first if you're not too familiar with git.

Mastering GIT step-by-step: back to basics

Ségolène Alquier ・ May 19 ・ 2 min read

#git #github #codenewbie

Today, let's focus on the good practices when collaborating with a team on a project 👯‍♀️👯‍♂️.

Why is it a 🔥 topic on a coding project?

Coding a project means you will have to create, edit and eventually delete toooons of files or repositories. If you're on your own, no big deal: you just save the changes, and commit them when you're happy with.

Easy-peasy. Now let's say that you start working with your coding crew on the same project. You'll create a few files and edit them, and the others will do the same on their computers.

How do you access their work & vice-versa?

The magic of remote repositories

Remember the git push command? This is what sends your files from your local repository (your computer) to a remote repository (a storage server).
Everyone having access to this remote repository can then access the modified files.

So if you create and update files on your computer and then git push them on the remote repository, the others are now able to see these modifications and work on it.

In order to get the updates, the others will have to use the git pull command. This command will detect the commits that they don't have on their local machine (new repos, new files, new lines, new code...) and import them. This way, they'll have the files YOU created on THEIR machine.

Team collaboration with git: git branches 🌳

I bet you wouldn't like it if someone was to step on your work and overwrite things you spent hours working on 😡. Basically that's what branches are made for: protect you from that pain!

What are git branches?

As you start making commits, you’re given a master branch (the default and main branch) that points to the last commit you made.
Every time you commit, the master branch pointer moves forward automatically. That pointer is called the HEAD.

💡 The HEAD is the pointer to the current branch reference.
When you commit or switch to another branch, it moves to point to that new commit object.

Let's pretend you're committing your work regularly on master, your commits would be linear:

Now if you're two to work on it, it's better if you both create a branch. This way, you won't have to worry about what the other is doing. This is usually how branches are schematized:

💡 Branches don't represent anything physical. They simply are pointers to a commit.

The basic git branches commands

Get a list of existing branches

git branch: lists all local branches
git branch -a: lists all local + remote branches

Create a branch

the short way: git checkout -b <branch name>
in two commands: git branch <branch name> & git checkout <branch name>

Both will create a branch with defined name AND moves the head to this branch

💡 When you create a new branch and switch to it, you'll find the exact same file system.
Why? Because the new branch is just a pointer to the previous commit.

Delete a branch

git branch -d <branch name>: deletes the specified branch

Merging git branches

So far we have a notion of what git branches are and how they can be useful, how to create them and work on them.

Now if my teammates and I have been respectively working and pushing on our own branches, how do we put our work together? This is where merging comes!

The theory

In a repo, every commit points to the same, original commit: the root commit. This means there will always be a common ancestor for two commits.

When merging two branches, git will look for that common ancestor and compare the filesystems between this commit and the two child commits:

if both commits impacted an area with different changes: you trapped yourself with a merge-conflict. No worries, you can check and handle it manually
otherwise: you're good to go, the two branches are merged!

Once the branches are merged, a new commit is made with the changes from both branches integrated into the new snapshot.

The git collaboration workflow & commands

Prepare for merging

git status: to make sure that HEAD is pointing to the correct receiving branch. If needed, execute git checkout <branch name> to switch to the receiving branch.

Make sure you have the latest remote commits

git pull: on both receiving & merging branches

Merging

git merge <branch name>: this will merge the specified branch into your active branch (master by default)

And voilààà your work is merged. Take some rest, you deserve it! 🎉
If you want to continue, then just repeat that process!

Git best practices

I'd recommend the following:

give your commits explicit names: to be able to return to the one you need if necessary (I am a big fan of commits named "Please work for once" but trust me, they won't help much)
make a branch for each feature (rather than for each person)
give the branches explicit names
clean your branches regularly: check with your mates which branches are not used anymore and delete them

That's it for the basics of collaborating on a development project with git. Thanks to branches, you can develop features independently from the others without overwriting on your teammates' work! 🤝

I hope you got to understand those concepts better and it will help you coding with others.

In the next article(s), I want to cover some more advanced git concepts & commands! Stay tuned if you're interested in that topic 👋

Mastering GIT step-by-step: back to basics

Ségolène Alquier — Tue, 19 May 2020 18:11:22 +0000

Do you start freaking out when you have to use git commands? You're not alone, we've all been there. I still am to be honest 🙈. I am writing this as much for me as for you!

So I wanted to make a few articles to simply go over the basics and some less known - yet useful - commands. Let's go! 🤓

What's git?

It's a version control tool that allows you to take snapshots of your files at specific moments, so that you can easily go from a version to another.

Since it's not tangible, it can be hard to apprehend. But you can think of it as the revision history feature on Google Docs for example.
You can see all the modifications that were made on a document and choose to go back to the state of the document at any point of those revisions.

Who uses it & why?

It is mainly used by software engineers in order to:

keep track of files & files' modifications
be able to rollback to a previous version of your files if a bug occured
have several people working on a same project AND at the same time

The basic git commands: add, commit & push

In order to understand the basic commands, we need to understand the different component of a .git project:

Workspace: your file system, where you can view and modify files
Staging area: where git keeps the modified files before they are committed. After committing, your Staging area will be empty.
Local repository: it is the area that saves everything, where you will find all of your checkpoints or commits *.

💡 A *COMMIT IS A SNAPSHOT OF ALL YOUR FILES AT A POINT IN TIME

Remote repository: server where changes made to files are uploaded (usually shared with collaborators).

You can see the 4 different components on the diagram: workspace, staging area, local repository & remote repository.

But how do we move our files from one stage to the other?

By using the 3 following commands (also on the diagram). And yes, the order matters:

1 - Git add <filename>: the command will stage the file
💡 If you want to add all files, you can type Git add *

2 - Git commit -m "commit message": the command will take all the files in the staging area and save them in the commit (snapshot). Your modified files are now saved, yaaayyy 🎉!

💡 WRITE IN THE COMMIT MESSAGE WHAT MODIFICATIONS YOU MADE. 
THIS WILL BE USEFUL IF YOU NEED TO GO BACK TO A SPECIFIC COMMIT.

3 - Git push: this command will send the modified files to a distant instance - the remote repository - and make it accessible to other developers

That's it for the basics. I hope you don't hate git yet & you got to understand some concepts better.

In the next articles, I want to cover the good practices when working in a team (branches, merging,...), & some other useful commands! Stay tuned if you're interested in that topic 👋