Forem: Pedro Lopez

Emoji Issue Classifier

Pedro Lopez — Sat, 20 May 2023 15:28:24 +0000

What I built

I built an Emoji Issue Classifier, a machine learning-based solution that automatically adds relevant labels to GitHub issues based on their content. The classifier analyses the text of an issue and predicts appropriate emoji labels, such as "🐛", "✨", "📈", and more, to help categorise and prioritise issues.

Category Submission:

Maintainer Must-Haves

App Link

https://github.com/marketplace/actions/emoji-issue-classifier

Screenshots

More examples here: https://github.com/plopcas/gh-actions-test/issues

Description

The Emoji Issue Classifier is designed to improve the issue management process by automating the labeling of GitHub issues. It utilizes natural language processing and machine learning techniques to analyze the issue's title and description, perform sentiment analysis, and extract keywords. Based on this analysis, it adds appropriate emoji labels that represent the sentiment and topic of the issue.

This solution saves time and effort for both issue submitters and project maintainers by accurately categorising and prioritising issues. It ensures that issues are properly labeled, enabling efficient issue tracking, organisation, and decision-making.

Link to Source Code

https://github.com/plopcas/emoji-issue-classifier

Permissive License

MIT license

Background (What made you decide to build this particular app? What inspired you?)

The inspiration for this project came from my own experience with managing GitHub repositories and the challenges faced in efficiently processing and categorising a large number of issues. I wanted to automate the process of labelling issues, allowing project maintainers to focus more on issue resolution and providing a better experience for issue submitters. I also wanted to do this with a twist, hence the emojis.

How I built it (How did you utilise GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

To build the Emoji Issue Classifier, I used GitHub Actions and GitHub Codespaces. GitHub Actions allowed me to automate the process of applying labels to issues based on the classifier's predictions. I integrated the classifier into a GitHub Action workflow, which runs whenever a new issue is opened or edited.

GitHub Codespaces provided a convenient development environment. It allowed me to work on the project seamlessly in the browser without worrying about the setup or compatibility of development environments.

Throughout the development process, I learned and applied various natural language processing techniques, including sentiment analysis, keyword extraction, and data augmentation. I trained a machine learning model using scikit-learn and employed the TextBlob library for sentiment analysis. I also used the NLTK library for data augmentation and synonym replacement to enhance the training data.

Count triaged issues week on week

Pedro Lopez — Sat, 13 May 2023 16:13:39 +0000

What I built

A Jupyter Notebook that will allow you to count issues that have been applied a specific label week on week, for a number of weeks that you choose.

This is particularly useful if you use a specific label to triage issues e.g. "triaged". You can then see how many issues were triaged week on week and by whom.

Category Submission:

Maintainer Must-Haves

App Link

You can try it directly in GitHub Codespaces.

Screenshots

Description

This Python script is used to count the number of issues in a specific GitHub repository that have been labeled with a specific label within a given number of weeks. The script uses the GitHub API to fetch and process the repository's issues.

Here's a breakdown of what each function in the script does:

get_start_of_week(): returns the datetime object of the start of the current week (Monday at 00:00:00).
get_total_issues(repo_owner, repo_name, access_token, label): returns the total number of issues in the given repository with the given label. It does this by sending a GET request to the GitHub API's search endpoint.
count_labelled_issues(repo_owner, repo_name, access_token, label, weeks): main function of the script. It counts the number of issues in the given repository that have been labeled with the given label within the given number of weeks. It does this by sending a GET request to the GitHub API's issues endpoint, then iterating over the response data and counting the number of issues that meet the criteria. The function also prints a report for each week, listing the issues that were labeled during that week, their titles, their URLs, and the user who labeled them. I also included closed issues in the output.

The script uses the colorama library to print coloured text to the console (it doesn't show in the Jupyter Notebook version).

Link to Source Code

https://github.com/plopcas/labelled-issues-jupyter

Permissive License

MIT license

Background (What made you decide to build this particular app? What inspired you?)

Trying to gather metrics for triaging process. GitHub doesn't make it obvious to work with events like "labeled". This script allows me to generate metrics week on week.

How I built it (How did you utilise GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

I used GitHub Codespaces with the Jupyter Notebook template which allowed me to very quickly test the functionality as I was building it.

What advice would you give to a younger version of yourself?

Pedro Lopez — Tue, 06 Oct 2020 09:00:00 +0000

A few weeks ago, as part of my regular 121s with the team, I decided to ask them the question “What advice would you give to a younger version of yourself trying to get to where you are today in half the time?”. Now, this is typically a question that I would ask a mentor of mine, not that my mentor would ask me. However, I decided to try this question as a self-reflecting question for a change, and the results were pretty amazing as you will see.

Ultimately, I think this exercise is not something most of us would normally do on our own. So I gave it a go for you, with my team 💙 I hope you like it.

These are not to be blindly followed, but rather, I hope most of these (if not all) will resonate with you, and you will take them as food for thought.

Ask, ask, ask and then ask a bit more

Asking is the fastest way to learn new things. Especially when you find yourself in a new environment or working on a new domain. Having the conversation has the additional benefit of bringing people together. Human interaction is sometimes underestimated. Reading something on a wiki is efficient, having a chat is insightful, and opens the possibility of a deeper conversation about the subject.

In an environment with the right culture, I’ve never really heard something like “John asks too much”, so generally speaking, don’t be afraid to ask. But if you feel that you can’t ask freely, then ask yourself “is this the right environment for me”.

Sometimes it makes sense to try for yourself first, of course. But there is no need to bang your head against the wall for too long if you’re not making enough progress, particularly if a quick hint from someone else can go a long way.

Get a mentor and become one

Getting a mentor early on in your career is hugely beneficial, yet most junior professionals wait for a few years before even considering formal mentorship as an option. In fact, having more than one mentor for different things is also an option. Think of a mentor dedicated to career growth, another one to soft skills and a third one for technical competencies. This can definitely boost your progress. Don’t be afraid of “wasting” people’s time. Mentoring is a two-way street, and mentors get as much from the relationship as you do.

Which is also why you should consider becoming a mentor yourself as soon as you are (reasonably) comfortable with the idea.

Seek feedback like there’s no tomorrow

Biases are real, and they are everywhere. Some examples are overconfidence bias, self-serving bias (good things are due to skill, bad things are due to environment), confirmation bias (seeking out information that confirms pre-existing ideas). A simple step towards overcoming biases is to increase awareness. And nothing like good old constructive feedback to open your eyes.

Asking for feedback regularly is one of the most common traits of high performing individuals, and it shows and invested interest in self-development. You want to understand how your actions and behaviours are perceived by others, so that you can improve.

Don’t get too comfortable

This is the typical “get out of your comfort zone”. But what does that mean? If you know basically everything that there is to know about something, it’s time to start expanding your horizons. You can start by teaching others what you know for instance.

Seek for opportunities that are aligned with your career goals. Ask for help finding opportunities if you get stuck.

A reasonable amount of discomfort with your tasks is good, because it keeps you on your toes, and it pushes you to think outside of the box.

There are probably opportunities around you at the reach of the hand, like joining a project that uses a technology you’ve never used before, assuming a different set of responsibilities within your team, or swap teams to get exposure to an unfamiliar area of your business.

Ultimately, if you feel too comfortable for too long, and there are no opportunities that catch you eye in your environment, it’s probably time to start considering changing jobs, and that is actually ok.

Be curious

Learn beyond what’s in your hands at a given moment. Read what’s new in your industry. Expand your knowledge by proactively seeking opportunities, like hackathons, meetups or conferences. Don’t take anything for granted and always keep an eye on future trends.

But at the same time, Stay focused

Looking outwards helps to find new opportunities, generate a (healthy) discomfort and expand our knowledge. However, it’s also crucial to stay in the moment, and balance out that explorer mindset we talked about earlier, with laser focus.

Once you’ve identified an opportunity, or an area of interest, you’ll need to invest enough time to really get the grasp of it and understand it inside out, to the point that you could teach it to others maybe, that’s a good benchmark usually. Setting uninterrupted time aside, to get in the flow, working on something, is the best way to make the most of your efforts and really master that one thing before moving on to something else.

Changing careers slows you down but it may be worth it

At some point, most of us face a dilemma. And that is whether we should stay in the track that we are in, or we should change. A classical example is IC vs management. But by no means it’s the only one, think back-end vs front-end, integration vs data, machine learning vs distributed systems, or even just changing sectors like healthcare vs travel (like in my case). The good news is that usually these decisions are reversible, and a career change will teach you loads regardless, so it won’t necessarily be wasted time if things don’t work out. However, be aware that every time you change paths significantly, it’ll take some time to go over the learning curve and master your new skillset. So you want to give it a serious thought before making a career move like this, and definitely consider your context and personal circumstances. But remember change is not bad per se, it’s just scary, and it may be worth it.

Pay attention to impact (at scale)

A very common motivator between software engineers is to be able to work on things that make a somewhat big impact. It’s very rewarding knowing that your contributions made the life of others a bit better, or more interesting or simply more fun. Therefore, when choosing your opportunities, it’s generally a good idea to consider the impact and scale of the problem you are trying to solve. Please note this doesn’t mean you should disregard any work that is not high impact / high scale, it just means you should be mindful. On a daily basis, there are things you can do too, even if your feature or task has a relatively low impact at first glance. You can share learnings with a wider audience, you can think about what it would take to expand beyond the current scope and maybe make a proposal, you can tweak aspects of it so that it can scale virtually indefinitely if needs be. In any case, the definition of impact in the context of a career conversation is not always obvious. So that is also something to keep in mind.

Work towards your next job

An interesting way to keep you on the right path is to think about your future on a regular basis and make investments on things that are aligned with your mid-term to long-term goals.

For example, even though at Skyscanner this is more of hat that you wear, let’s say you are looking to become an architect one day, sign up for opportunities that will allow you to work on architectural designs, stay closer to senior architects within your organisation and learn from them, stay informed about the latest developments in the field and bring in those learnings so that they become part of your current job as much as possible.

Politics are part of the job

Some places are more “political” than others but in all companies, it is possible to promote yourself and your cause without compromising your values or those of your organisation by playing the office politics correctly (and positively).

This is not (or shouldn’t be) about backstabbing, it’s about understanding the organigram and the informal networks, building connections and developing “people” skills. By leveraging your circle of influence, you can increase your impact and promote win-win situations.

The bad, the good and the ugly, all of it is worth it

It is important to learn from the bad things as much as the good things. Nothing tells as much about ourselves as how we reacted to adversity. Using misses as learning opportunities is also hugely beneficial because it gives us the opportunity to have somewhat awkward and difficult conversations that can push us forward when done correctly.

There are also lessons to be learned from the tedious work (ugly) that we must do from time to time, even if it just how to automate it for next time it comes our way.

Hugo S3 Deployments

Pedro Lopez — Sun, 23 Aug 2020 14:20:58 +0000

My Workflow

I have created a new GitHub Action that deploys to S3 using a configured deployment target in Hugo. Additional information about Hugo deployments is available in the official documentation.

Why?

I use Hugo for my personal website, and every time I make a change or create new content I need to build the site locally and then deploy it. But not any more. Now, with every commit, GitHub will build the site, deploy it to S3 and invalidate my CloudFront distribution so that fresh new content is available immediately.

Are there similar actions out there?

Yes and no. I explored the Marketplace and could find workarounds. For example, there are actions to build a Hugo site, and there are actions to deploy it manually by uploading the output folder (public typically) to a remote destination, like S3. And there are actions to invalidate CloudFront distributions.

However, Hugo already provides a mechanism to do all this for you, the hugo deploy command. Yet, there was no GitHub action I could find to run your this command and execute your configured deployment.

This action solves this.

Implementation details

I have created a Docker Container action for this. Documentation available here.

Dockerfile

To define my container I use a Dockerfile.

FROM pahud/awscli-v2:node-lts

RUN yum update -y && \
    yum install -y curl jq

COPY entrypoint.sh /

ENTRYPOINT ["/entrypoint.sh"]

I'm using a base image that contains AWS CLI already, so that I can perform the CloudFront invalidation. Reference at the bottom.

Then I'm installing curl and jq which I'll use to install Hugo in the container later on.

Finally, I specify the entrypoint.

entrypoint.sh

Important to remember to make it executable as explained in the documentation.

chmod +x entrypoint.sh

The entrypoint is what contains the logic that will be executed when the action runs.

First, fail the pipeline immediately if there are any errors.

set -eo pipefail

Check the different parameters that we pass as environment variables. E.g.:

if [ -z "$AWS_ACCESS_KEY_ID" ]; then
  echo "error: AWS_ACCESS_KEY_ID is not set"
  err=1
fi

Create an AWS profile for this action.

aws configure --profile hugo-s3 <<-EOF > /dev/null 2>&1
${AWS_ACCESS_KEY_ID}
${AWS_SECRET_ACCESS_KEY}
${AWS_REGION}
text
EOF

Then install Hugo by fetching the latest version with curl (not adding the code here, but can be found in the repo).

Build and deploy the site.

hugo
hugo deploy

And finally, we clean up the AWS profile (not really needed if the container is destroyed immediately afterwards but good practice to clean up after ourselves).

action.yml

Contains the metadata for the action.

name: 'Hugo S3'
description: 'Deploy Hugo with an S3 target'
author: 'Pedro Lopez'
branding:
  icon: 'book'
  color: 'purple'
runs:
  using: 'docker'
  image: 'Dockerfile'

Submission Category

DIY Deployments

Yaml File or Link to Code

This action is now available in the GitHub Marketplace
https://github.com/marketplace/actions/hugo-s3.

plopcas / hugo-s3-action

GitHub Action to use `hugo deploy` configured with an S3 target

Hugo S3 Action

GitHub action to run hugo deploy provided there is an S3 target configured in your Hugo repo.

Usage

name: Hugo S3
on
  push
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    
    runs-on: ubuntu-latest

    steps:
      - name: Check out master
        uses: actions/checkout@master
          
      - name: Deploy site
        uses: plopcas/hugo-s3-action@v1.3.0
        env:
          AWS_REGION: 'eu-west-2'
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Configuration

Set the following properties as secrets in your repository under Settings / Secrets.

Name	Required	Description
AWS_REGION	Yes	AWS region
AWS_ACCESS_KEY_ID	Yes	Access key with permissions to execute your deployment
AWS_SECRET_ACCESS_KEY	Yes	Secret key

Information about how to configure a deployment to S3 in Hugo can be found here https://gohugo.io/hosting-and-deployment/hugo-deploy/.

You can optionally include a CloudFront distribution ID in your config.toml file. Make sure the key you use can grant permission to invalidate it as well as deploy to S3 in that case.

…

View on GitHub

I've also configured it on my personal site https://retrolog.io/, which is also publicly available on GitHub.

An example of a successful run is available here
https://github.com/plopcas/retrolog/runs/1018289670.

Usage

name: Hugo S3

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - name: Check out master
        uses: actions/checkout@master

      - name: Deploy site
        uses: plopcas/hugo-s3-action@v1.3.0
        env:
          AWS_REGION: 'eu-west-2'
          AWS_ACCESS_KEY_ID: ${{ secrets.ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.ACCESS_KEY_SECRET }}

Additional Resources / Info

GitHub repository https://github.com/plopcas/hugo-s3-action
Personal site using the new action https://retrolog.io/
Personal site on GitHub https://github.com/plopcas/retrolog

References

GitHub actions documentation https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action
Hugo on GitHub https://github.com/gohugoio/hugo
AWS CLI Docker base image https://hub.docker.com/r/pahud/awscli-v2

A Pragmatic Approach to Roadmapping

Pedro Lopez — Sun, 28 Jun 2020 17:30:00 +0000

Creating a roadmap can be a challenging task. I can't really say I am an expert on the matter, but have done it a couple of times. The most recent one, I put together a workshop that got fairly positive feedback and so I'm sharing it for the benefit of anyone interested.

This post describes a pragmatic approach to creating a roadmap for half a year, but can be extrapolated to cover whatever time period you need. Just be aware that the longest the period, the fuzziest it will be after the first 6 months, particularly in an agile environment with quarterly OKRs.

1. Plan out the session

I used a Miro board as the canvas for the workshop. Having a tool that allows for realtime remote collaboration is essential.

Lay out the different steps (which I cover below) and add a time estimate, so that everyone can check if each part is overrunning.

You don't need to cover absolutely everything in one session. Do it if you can, but this can be quite challenging, as there is a lot to cover, and probably people will be tired after max two hours.

A high level overview of the board we used looks like this:

2. Ice-breaker

It's usually a good idea to start with an ice-breaker that will get people in the right mood. During the workshop, everyone needs to be participative. Spending a few minutes at the beginning, having a laugh and chatting informally, will definitely be beneficial.

You can use classic exercises from your retrospectives, like guessing everyone's favourite food or describing your current mood with an emoji. The sky is the limit.

3. Set out expectations

It is worth spending 5-10 minutes clarifying the expectations for the workshop. What are we trying to achieve, what's in scope and what's not?

As the facilitator, come prepared with a proposal. Read through it during the meeting and get agreement or make amendments.

Some of the categories we covered last time were:

What we should do if we had unlimited time
What we are actually doing today
What we are not doing today
What we should follow up on

These are just examples, feel free to come up with your own version.

4. Build individual roadmaps

Here you will start the actual roadmapping exercise. It has a few steps.

4.1. List all the projects you can think of

In a column, list all the projects/epics in your area. Doesn't matter if they have been discussed previously or not, and you are encouraged to think out-of-the-box.

As a facilitator, it is a good idea to pre-populate the list with the projects you know of already. This will save time and will serve as an example for others to contribute.

Remember you are listing projects, not tasks nor programs.

Give people time to add projects to the list. You can use different techniques for this e.g. round robin, silent brainstorming, 1-2-4-all, free for all.

At the end of this stage, you will have an unestimated, unordered and unowned list of projects that contains everything everyone in the room knows about the work you need to do in your area.

4.2 Estimate using t-shirt sizes

Estimates are context dependent. What is big for one team, might be medium for another. Here, use whatever makes more sense to your team/area. For example, if you always work on one single thing at a time vs you usually parallelise two or three things, your estimates might differ. These are just ballpark figures, so don't worry too much.

The sizes we used were:

Small = 1/3 of the quarter
Medium = 2/3 of the quarter
Large = 1 quater
Extra large = more than 1 quarter

In Miro, it is easy to resize rectangles (projects) to match the reference sizes at the top of the list (see the template).

Go through the projects from the top and estimate all of them. On a second pass, try to break down the biggest ones into smaller chunks.

4.3 Order projects using a naive approach

A simple bubble-sort will do. Starting from the top decide wether the next project should be done before or after the previous one. Very quickly we started moving things up or down, and ended up with a reasonably well sorted list. Doesn't have to be perfect, but it should help to group things that need to be done roughly at the same time, and identify things that can probably wait.

4.4 Roughly define which team should own each project

If you are building a roadmap for more than one team, at this point is useful to colour-code the projects to highlight which team will be the official owner of the project. In practice, this means the team that will provide an Epic Owner for the project. If you are unfamiliar with the concept of Epic Owner, it's the person in charge of an epic acting like the project manager (plus other things, but that's a topic for a different time).

Sometimes ownership is shared, and sometimes you just don't know. This is absolutely fine at this point, especially for things that will happen 2+ quarters away from now.

4.5 Build roadmaps individually

Give people 10-15 minutes to build their own roadmaps with the projects on the list. The goal is to prioritise and parallelise things. Think about dependencies and respect the order as much as possible. But don't feel constrained by the order that came out of 4.3. It was ordered naively after all.

5. Build a straw-man roadmap together

At this point, everyone should be pretty familiar with the items in the roadmap, the non-controversial topics, and the trickiest ones.

As a group, try to put together a final version. Use arrows to explicitly flag dependencies between projects.

It's very important to remember that this is just a straw-man roadmap, meaning it's an advanced draft. Not something to be publicly shared, as it needs more work still. But a helpful internal tool nonetheless.

The output will be useful in deciding what to do next, and for OKR planning. But things can, and most certainly will, change.

6. Reconcile with OKRs

Let's think for a minute about what we have. We have a list of things that we want to build as an area (area meaning the part of the business you are roadmapping for, made out of a subset of the total of teams in the organisation). We know how those different things relate to each other in terms of dependencies. And we roughly know who is best placed to own each of the work streams.

The are two missing pieces still.

Strategy

Ideally you should write your strategy briefs first. We had some drafts, but we made a conscious decision to invert the order. Our aim was to gain clarity about the future and prepare ourselves for the imminent OKR planning.

If you have already written a formal strategy, for the most part, your projects will come directly from it.

OKRs

Company-driven goals might clash somehow with your roadmap. You wouldn't know until close to the beginning of next quarter, when company OKRs are refreshed (this might be different in your case, depending on the cadence of your organisation).

Even though adjustments might be necessary, company OKRs don't invalidate your roadmap, but you might want to reserve certain capacity to make sure you can accommodate unexpected needs. Typically this will be in the form of OKRs that require enabling others to deliver their goals, or to contribute to pushing metrics in reaction to a market change (like during COVID).

Having a roadmap will prepare you better with the tools you need to accomplish company OKRs. It'll be much easier to find something in your roadmap that supports one of those company goals, than having to come up with an entirely new project on the spot. So you are increasing the chances of having something ready, that is aligned with both the company goals and your long term vision for your area.

7. Share with the teams and keep iterating

It's important to get buy-in from the team that will actually work on the projects. You want to give everyone a chance to contribute and provide input if they have anything to add. Share your roadmap, ask for feedback, learn and iterate. Do that a few times and you will have a solid and always up-to-date roadmap, ready for any planning cycle.

One Remote, All Remote

Pedro Lopez — Thu, 14 May 2020 19:45:52 +0000

This post was originally intended as a compilation of suggestions to promote a “one remote, all remote” approach to meetings. That is, instead of using room equipment that can make the experience less than ideal for remote attendees, if one person joins remotely, everyone does.

During COVID-19 lockdown, I've confirmed with my team that all of these apply to a full remote setup as well.

Also, as we start going back to “normality”, some people will return to the office from day one, while others will stay home for a bit longer. As a result, hybrid team configurations, like the one this post was originally intended to address, will be very common for a while. Now more than ever, these tips might be relevant to you too.

NOTE: these tips mention Zoom specifically, just replace with you video conferencing software of choice.

🎧 Use headphones

Any type is fine, but noise cancelling ones work best because they provide with a higher level of sound isolation. If there is more than one attendee in the same room, because of the lag, you might want to set the volume high enough so that is not distracting to hear the other person speaking at the same time. But not too high, you'll still need your ears after the meeting, safety first.

There is an exception. If you are in a phone booth, or you are the only person in the room, feel free to use your laptop internal microphone and speakers (or equivalent). Consider double checking that there is no undesired echo for everyone else in the call.

🎥 Use a camera

General rules for remote meetings still apply, and it's generally better to see the person speaking. Please make sure you either have an external webcam or you keep your laptop lid open during the call so that you can use the laptop camera. Consider enabling your camera by default or turn it on right after joining the call. Feel free to disconnect video temporarily, though, if you are not speaking or if the signal is bad.

🙊 If you are not speaking, mute yourself

This is paramount in a set up where multiple people is in the same room joining the same call, otherwise the audio experience will be bad due to unwanted echo. Depending on the configuration of the meeting, the host can also mute all participants if needed.

Extra tip: Use the “Mute microphone when joining a meeting” setting that you can find in Preferences → Audio.

✋ Consider using the raise hand functionality to indicate that you want to talk

In a remote setup it's hard to see when someone has the intention to speak, particularly when the screen is shared. You might be hidden in the gallery if many people is in the call. One effective way to tackle this is to use the raise hand functionality in Zoom. If the number of people is small (typically less than 5) this might not be necessary.

NOTE: with recent versions of Zoom, the host can enable Nonverbal feedback. Click on the participants tab and you'll see icons for things like “go faster”, “thumbs up” or “need a break” that will be seen by the meeting host.

🙋 Every meeting needs a facilitator (and if you don't know who that is, it's probably you)

You need someone to tell others to mute themselves if they don't realise, and to coordinate who speaks when the conversation doesn't flow naturally. The facilitator in this particular case could just be the meeting host, but in large meetings it might make sense to get some help. As a rule of thumb, if there is no clearly designated facilitator, please jump in and help.

🔍 Font size matters

You might have your laptop connected to a high resolution monitor, but most attendees probably won't. Some might even be using a room monitor and looking at the screen from a distance. Also the image will not be as crisp because of video compression. Be mindful of this and zoom in a little 🙏

This applies to every tool or tab that you switch to, not just the first one.

➗ Divide and conquer using Zoom breakout rooms

Useful for brainstorming topics that are too complex to discuss with a large audience. Break down the topic into questions, divide up people into groups to work on those questions, then re-group and share learnings.

⏳ Be mindful of time and let others have a chance to speak

A facilitator could help with this by intervening when someone is dominating the discussion and not leaving enough time for others to express their opinions. This is more difficult to do in a remote setting, as body language cues do not work as well here, so everyone just needs to be more aware and understanding of each other 🙂

The raise hand feature could help (encourages people to pass the mic more), and other formats like silent brainstorming and zoom breakout rooms also ensure everyone can contribute, even if they are not vocal.

💚 Zoom virtual backgrounds

As we recently learned, they are super cool! And for those that are working from home are worried about accidental photobombs by their housemates/partners/kids in the background, this offers a layer of privacy.

🔁 Ask for feedback

You can't see people as clearly when everyone is joining remotely and crammed in a small gallery of thumbnails, so there's less visual feedback. Pause during presentations to ask if anyone has questions. As participants, a big thumbs up/down or a verbal “yes/no” is much more noticeable than a nod/head-shake.

👔 VPN etiquette still applies

If you have a corporate VPN, disconnect from it when joining a remote meeting. Otherwise you will be using precious bandwidth and likely affecting others that need it.

Kudos to my teammates Grace, Leandro and Stuart, who helped to put this together. Thanks!

Continuous Performance Assessment

Pedro Lopez — Sun, 10 May 2020 17:30:50 +0000

Have you ever struggled evaluating the performance of your direct reports? Or have you been surprised in your performance evaluation meeting with your manager? In this post I'll explain a different approach and will give you some tips and guidelines to implement it yourself.

Is this 1-pager worth your time?

As managers, it is important to provide support and guidance in regards to performance so that people continue to improve and grow. And this should be happening regardless of the performance assessment cycle.

Let me start by trying to show you why I think this technique is for you, and also why Continuous Performance Assessment matters regardless of whether you are manager or a managee. This is for everyone.

How long do you spend on average preparing your performance notes?

Something between too long, and “please don’t ask me about that painful time of my life” → keep reading

How often do you discuss performance with your direct reports / manager?

Not often enough → keep reading

How do you track wins and misses?

I don't do it → keep reading

How do you know everyone in your team has the same understanding of the competency framework?

I don't know it, and just mentioning competency frameworks makes me feel goosebumps and a cold sweat on the back of my neck → keep reading

How confident are you that there will be no surprises when discussing the results of the performance evaluation with your direct report / manager?

Anything less than 100% → keep reading

I practice Continuous Performance Assessment with my team, and have been doing it for some time now. In this post I'll explain the benefits of this approach and will give you some tips and guidelines to implement it yourself.

Avoiding the big rush at the end

Being consistent at writing notes about performance is hard.

It requires a lot of discipline.
You need to know enough detail about the items you are capturing.
It doesn't scale - In fact, it becomes exponentially harder as the number of direct reports grow.

Managers (me included) know this, and build mental barriers to avoid a process that is unpleasant to their eyes. As a result, it is often left to the very last minute, when there is no other choice but to sit down and write.

But what if this was part of your regular 121 conversations? You already have time booked for this.

Remind yourself of the benefits. At the end of the cycle you will have notes covering the whole period. This will help you remember details that you would have forgotten otherwise, so your notes will be much more thorough. And fairer. Recency bias will be less relevant, because you will have been capturing information more evenly.

Choosing a frequency

Should you update your notes every week? once a month? once a quarter? Only you know what works for you and your team.

Personally, every two weeks is the cadence I find more useful, which also maps to the frequency of my 121s. So if you can afford doing this every single 121, do it. If not, do it as frequently as you can. Seriously, this is important. Having a chat about performance should be as easy and comfortable as talking about the weather or asking about the weekend.

There are pre-requisites, of course. You'll need:

Trust
Transparency about the process
Engagement

It's a self-reinforcing cycle, you need transparency to generate trust, when you have trust and people see the benefit of having an open discussion about performance, there comes engagement. With engagement, there comes more feedback and proactivity, and more data. And with more data, there are even more reasons to be transparent and give clarity about how that data will be used.

Creating structure

Keep it simple. Use a table (or a nested list but I prefer a table). Define categories that are relevant to your environment, typically areas of your competency framework. Bias in favour of outcomes and impact, instead of actions. And use the same structure with everyone.

If you have an official structure for your performance assessment notes, you are half way there, use the same one. You don't want to reinvent the wheel and then have to spend time mapping between different formats. Equally, from the manager's perspective, you want to have meaningful discussion with other managers about the performance of your reports and their reports, and having a common framework makes it easier and more efficient.

Make sure competencies are fully understood by everyone in your team. Spend 121 time going through each competency and share examples of bad/good/great behaviours in each one. Consider having a refresher session every 6 months or when competencies get an update.

Don't forget to include misses. Discuss impact, foreseeability and response. It is paramount for your reports to understand what they should've done instead of what they did, and this will help them grow much faster. Also, it will give them the chance to turn the tables and come out stronger if you have these conversations early.

Avoiding surprises

This is the absolute key. If you are the manager, after you prepared the table, explained the competency framework, got alignment and common understanding, and started the process with some notes of your own, there is one last thing for you to do.

Let go.

That document is no longer yours. It's your report's. From this point on, most of the updates in the performance assessment will have to be done by them. It's no longer your performance assessment, it's a self-assessment now, with your input.

As a result, you will have frequent conversations about wins and misses. Performance will not be something to be evaluated at the end of the cycle, it will be a way to assess how I'm doing against my own career path in real time. And equally as important, It will become a framework to have meaningful discussions about what's next and how to get there.

Takeaways

If you want to try Continuous Performance Assessment:

Avoid the big rush at the end by capturing performance on a regular basis.
Choose a frequency that works for you and your team, but the more frequent the better.
Use a structure that is compatible with your official performance evaluation notes.
Avoid surprises at the end by making it a collaborative effort, and letting go.

COVID-19 Peak Detector

Pedro Lopez — Sat, 18 Apr 2020 17:39:50 +0000

What I built

COVID-19 Peak Detector is a Java Spring Boot application with a DynamoDB store that displays graph information with stats about COVID-19. You can select the country you are interested in and you can create an alert by entering your phone number.

A scheduled process will check the data periodically and will send the alert when a peak is detected.

For simplicity and to avoid unnecessary spam, after sending the alert the process removes it from the database.

In addition to that, there is an anonymous chat available, in which COVID-19 news are posted every 5 minutes. People can comment on the news or just talk about the weather.

Demo Link

http://covid19.plopcas.com

Link to Code

https://github.com/plopcas/covid19-peak-detector

How I built it (what's the stack? did I run into issues or discover something new along the way?)

In a nutshell, this application uses the following techonologies:

Spring Boot as the web framework
DynamoDB as the database
Thymeleaf for templating
Chart.js for graphs
Twilio SMS for alerts
Twilio Chat for in-app messaging
Twilio Sync for news
Gradle as the build tool

For the COVID-19 data and the news, I'm using free APIs that are available via the Postman website here https://covid-19-apis.postman.com/.

The demo application was deployed in AWS using Elastic Beanstalk.

Additional Resources/Info

https://dev.to/plopcas/twilio-hackathon-covid-19-peak-detector-5hfk

Twilio Hackathon - COVID-19 Peak Detector

Pedro Lopez — Sat, 18 Apr 2020 16:00:00 +0000

I'm taking part in the Twilio x DEV.to Hackathon and this is my project. I'll show here how I built it and how it works. Keep reading if you want to know more.

The application

A scheduled process will check the data periodically and will send the alert when a peak is detected.

For simplicity and to avoid unnecessary spam, after sending the alert the process removes it from the database.

In addition to that, there is an anonymous chat available, in which COVID-19 news are posted every 5 minutes. People can comment on the news or just talk about the weather.

How I built it

In a nutshell, this application uses the following techonologies:

Spring Boot as the web framework
DynamoDB as the database
Thymeleaf for templating
Chart.js for graphs
Twilio SMS for alerts
Twilio Chat for in-app messaging
Twilio Sync for news
Gradle as the build tool

For the COVID-19 data and the news, I'm using free APIs that are available via the Postman website here https://covid-19-apis.postman.com/.

The demo application was deployed in AWS using Elastic Beanstalk.

I'll explain some of the most interesting pieces.

The Welcome controller

This is where everything starts. The controller is in charge of calling the different services to fetch the necessary data to populate the view.

From here, we call the DataService to fetch the historical data, and we use Faker, a Java library to generate random data sets, to assign a random username to the user landing the page. This username will be important for the chat widget.

Fun fact, all the usernames are characters from Game of Thrones 🤓

It is important to mention that the data about COVID-19 doesn't change very frequently. Therefore, I'm caching the data in memory for 12 hourse before calling the third-party API again.

This is a small optimisation, because those APIs are not very flexible, and they force you to fetch all the historical data in every call. This way, we minimise the amount of data transfered over the wire in exchange for a bit of up-to-dateness.

The Data API

We expose our data in an endpoint available at /countries/{countryAndProvince}. This endpoint is called using AJAX from the browser everytime the user selects a different country from the dropdown.

When called, it will pass the request to the data service so that we can load the data for the selected country and craft a response for the caller.

We then read the information form Javascript and update the graph using Chart.js.

This is a monolithic application, so typically we render the views on the server-side using Thymeleaf. However, it is useful to also call the back-end from Javascript and render changes without refreshing the page. This provides a better user experience.

Creating an alert

Another thing we can do here is to create an SMS alert for a given country. When the user signs up, a confirmation SMS will be sent. When a peak is detected, a second SMS will be sent and the phone number will be deleted from the DynamoDB.

But before that, we need to insert the data in Dynamo. For that, we use spring-data-dynamodb. This library allows us to set up our repositories like normal JPA repositories. It's very convenient, and it makes it very easy to read and write from your tables.

The key components here are the DyanmoDBConfiguration class, the model and the repository.

@Configuration
@EnableDynamoDBRepositories(basePackages = "com.plopcas.twiliohackathon.cpd.repository")
public class DynamoDBConfiguration {
    @Value("${amazon.dynamodb.endpoint}")
    private String amazonDynamoDBEndpoint;

    @Value("${amazon.aws.accesskey}")
    private String amazonAWSAccessKey;

    @Value("${amazon.aws.secretkey}")
    private String amazonAWSSecretKey;

    @Bean
    public AmazonDynamoDB amazonDynamoDB() {
        AmazonDynamoDB dynamoDB = new AmazonDynamoDBClient(amazonAWSCredentials());

        if (!StringUtils.isEmpty(amazonDynamoDBEndpoint)) {
            dynamoDB.setEndpoint(amazonDynamoDBEndpoint);
        }

        // check table and create if it does not exist
        DynamoDBMapper mapper = new DynamoDBMapper(dynamoDB);
        CreateTableRequest request = mapper.generateCreateTableRequest(Alert.class);
        request.setProvisionedThroughput(new ProvisionedThroughput(1L, 1L));
        TableUtils.createTableIfNotExists(dynamoDB, request);

        return dynamoDB;
    }

    @Bean
    public AWSCredentials amazonAWSCredentials() {
        return new BasicAWSCredentials(amazonAWSAccessKey, amazonAWSSecretKey);
    }
}


@DynamoDBTable(tableName = "Alert")
public class Alert {
    private String id;
    private String country;
    private String phone;

    @DynamoDBHashKey
    @DynamoDBAutoGeneratedKey
    public String getId() {
        return id;
    }

    @DynamoDBAttribute
    public String getCountry() {
        return country;
    }

    @DynamoDBAttribute
    public String getPhone() {
        return phone;
    }

    // setters and constructors

}


public interface AlertRepository extends CrudRepository<Alert, String> {
    @EnableScan
    public List<Alert> findAll();
}

I am creating the table upfront, on app startup, if it doesn't exist already.

Of course, all the sensitive information is externalised as environment variables.

Like usual with Spring JPA repositories, all the CRUD operations are automagically available. I'm explicitely declaring the findAll one so that I can annotate it with @EnableScan. All methods of the repository are implemented as queries by default. However, if there is no index to query, these will fail. So you need to explicitly enable the scan operations with the annotation.

More information can be found here.

Once these pieces are reading, we can call the save method in the repository (it's not there, it's magic), to insert new alerts. This is done in the AlertService as expected.

Alert alert = new Alert(country, phone);
alertRepository.save(alert);

The scheduled peak detector

In order to detect peaks we use a very naive approach. It's a hack project, please bear with me. We check if the number of cases today, is lower than yesterday and lower than the day before yesterday.

If that is the case, we consider a peak detected, and we send an alert to all the phone numbers that subscribed to that country.

In order to run the process periodically, we use the @Scheduled annotation with a fixedRate of 12 hours.

@Scheduled(fixedRate = 12 * 60 * 60 * 1000)

The SMS service

Twilio makes it very easy to send SMS messages. Once you have your account set up, it's as easy as using their SDK, get an access token and start sending messages. Note that you need to get a phone number first, that will be the number from which the messages will be sent.

@Service
public class SmsService {
    private String fromPhone;

    public SmsService(@Value("${twilio.accountSid}") String accountSid,
                      @Value("${twilio.authToken}") String authToken,
                      @Value("${twilio.fromPhone}") String fromPhone) {
        this.fromPhone = fromPhone;
        Twilio.init(accountSid, authToken);
    }

    public void sendConfirmationSms(String toPhone) {
        Message message = Message.creator(
                new com.twilio.type.PhoneNumber(toPhone),
                new com.twilio.type.PhoneNumber(fromPhone),
                "COVID-19 Peak Detector - Your alert has been created, thanks!")
                .create();
    }

    public void sendAlertSms(String toPhone, String country) {
        Message message = Message.creator(
                new com.twilio.type.PhoneNumber(toPhone),
                new com.twilio.type.PhoneNumber(fromPhone),
                "COVID-19 Peak Detector - A peak has been reached in "
                        + country + "! Thanks for using our service :)")
                .create();
    }
}

To get the tokens, I created a dedicated TokenService that uses the API key and API secret to generate tokens with the necessary grants depending on the service. In my case I need two types of tokens, one for the Chat service and one for the Sync service.

The Chat

The idea behind the chat is to have a forum for people to talk about the situation, ramble and share. I created a very simple UI, and using the Twilio Javascript SDK, I create a channel, and sychronise all the messages between all the users.

In addition to this, to spice things up, I use the Sync service to store a shared state that contains COVID-19 news. Every 5 minutes, a process posts one headline for people to chat about. Using Sync, I can post the same headline to every browser at the same time.

Keeping state in a distributed environment is not easy, and Twilio makes it very straightforward. Again, this requires some configuration in you Twilio console, but it's fairly simple and it's all explained in their documentation.

That's it!

I hope you enjoyed this post. All the code is publicly available in GitHub here

https://github.com/plopcas/covid19-peak-detector

and the demo application (at least for a few days) is available here

http://covid19.plopcas.com

Stay safe, stay strong, stay home 👋

The COVID-19 Retrospective

Pedro Lopez — Sat, 28 Mar 2020 17:26:26 +0000

In an attempt to lighten the mood a bit during this difficult time, I put together a new retrospective technique inspired by the latest developments on COVID-19 and what we know about how to fight it. Keep reading if you want to know more.

Like in previous posts, I use miro as a virtual whiteboard. This is now more important than ever given the lockdown restrictions in most countries around the world, so chances are that your team is working fully remotely at the minute.

Set the stage

Divide the board in 6 sections like in the image below.

Consider adding an ice-breaker as well to warm things up.

Gather data (10 min)

Give participants 7 minutes to write down their thoughts on virtual post-it notes in the five sections allocated for it. The 6th one is just for the facilitator to take notes.

What are our biggest challenges? Like with Coronavirus, teams face difficult challenges that need to be explicitely called out and discussed to ensure alignment and enable continuous improvement.
What are our main pain points? Like staying at home for a few weeks to fight a virus that spreads easily, teams suffer from technical debt, processes that require more than they should or organisational issues that get in the way. Use this section to write down all those things that are keeping you awake at night. Note that this section differs from the one above in that challenges are things we need to achieve in order to move forward, whereas pain points are typically a consequence of past decisions or contextual circumstances, but based on things that have happened already.
What quick wins will make us succeed? Small things like washing your hands can have a huge impact if done right. Think of all the short term things you can do now that will take you closer to your long term goals further down the line. Focus on low hanging fruits here.
What will make us succeed in the long run? For what we know, even at record breaking speed, a vaccine for Coronavirus is not likely to be available for at least another 18 months. Yet, we need to start working on it now because it's the right thing to do and it will had the biggest long term impact. Similarly, what things does your team need to start working on now that will pay off in a few months.
What should we avoid? At the moment, you should only travel if your journey is absolutely essential. Anything else will mean you are increasing the risk of spreading the virus and affecting key workers like healthcare professionals, that are trying to get to their workplaces. Similarly, what things does your team need to avoid as you move forward? These are not pain points from the past, and not necessarily challenges that you know you'll have to overcome, but rather things that you know already will get in the way if they materialise. Include here risks that you are aware of.

Generate insights (30 min)

It's time to brainstorm and generate lots of ideas, but in the interest of time, filter first so that you can focus on the most relevant ones.

Go through the notes and cluster similar topics.
Give participants 5 votes each and set a 3 minute timer.
Start discussing from the most voted idea.
Ask questions to trigger conversations if they don't flow naturally e.g. why did you vote this note? what did you mean by X when you wrote it down? Is this related to a particular event that happened recently? How have you seen this apply in previous experiences? If you had unlimited resources, how would you tackle it?

Decide what to do (10 min)

For each discussion, make sure that you identify potential actions for the team to work on in the next iteration. Each action must have an owner. You can do this as you generate insights in the previous step, no need to wait.

Use some time at the end to ask people to sign up for the unassigned actions, and wrap things up by summarising the main points that were discussed as well as the final set of outcomes.

I hope this is helpful. Take care, stay safe and until next time 👋

A Saint Patrick's Day Inspired Retrospective

Pedro Lopez — Tue, 10 Mar 2020 08:00:00 +0000

Saint Patrick's Day is around the corner. The 17th of March is celebrated in green and gold all around the world. I thought it might be fun to design a retrospective based on this festivity.

I use miro as a virtual whiteboard. It's a visual collaboration tool that makes it very easy for remote teams to share and organise ideas. Perfect for retrospectives!

If this is not your first retrospective, take 5 minutes to review actions for previous ones.

The layout

Divide the board in three sections like in the image below.

The Trinity and the Shamrock

The first legend of Saint Patrick says he used a shamrock to explain the Holy Trinity to the Irish back in the 5th century.

Let's use that analogy to discuss three fundamental areas that need to be considered by high performing teams, Technology, Processes and People.

Technology: which technologies are we using at the moment that help us achieve our goals? which tools and patterns?
Process: which processes help us be efficient and keep us on our toes?
People: take a moment to shout out any remarkable things your team mates did during the last iteration.

Give participants 5 minutes to write down as many notes as they can in each of the categories.Review notes and cluster similar topics to simplify the discussion later.

Banishing all the Snakes

The second legend of Saint Patrick says he banished all the snakes from the island, chasing them into the sea.

In this section participants should focus on all the things that are affecting team performance and should be “bannished into the sea”. Feel free to focus on similar areas than the ones above i.e. Technology, Process and People, but do not limit the list to those. For example, you might want to include incidents or events that happened in the last iteration.

Give participants 5 minutes to write down as many notes as they can in each of the categories.Review notes and cluster similar topics to simplify the discussion later.

The Walking Stick grows into a Tree

The third legend of Saint Patrick says he thrust his walking stick into the ground wherever he was evangelising, and at the place now known as Aspatria (ash of Patrick), the message of the dogma took so long to get through to the people there that the stick had taken root by the time he was ready to move on.

You will use this last section to capture actions that will help the team take root and grow.

Voting and discussion

Run a poll to identify the most relevant clusters. Discuss focusing on two aspects:

Situation: what's the reason behind the notes? what is the context?
Action: what can we do to leverage a strength even more or mitigate a recurring issue? How can we improve our tools and processes?

End the meeting by making sure each action has an owner. And if it's the end of the day, maybe go to the pub and grab a traditional Irish beverage. Cheers! 🍻

Mastering Pair Programming in 5 Minutes

Pedro Lopez — Sun, 08 Mar 2020 16:41:21 +0000

This post is heavily based on https://martinfowler.com/articles/on-pair-programming.html (38 min read). That is, however, a very long (yet very good) article. For those of us that can't or don't want to afford spending that long, I collated its main points and added a few twists of my own. I hope it's useful.

Why bother?

According to some studies e.g. https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF, some of the most significant benefits of pair programming are:

Many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews)
The end defect content is statistically lower (continuous code reviews)
The designs are better and code length shorter (ongoing brainstorming and pair relaying)
The team solves problems faster (pair relaying)
People learn significantly more, about the system and about software development (line-of-sight learning)
The project ends up with multiple people understanding each piece of the system
People learn to work together and talk more often together, giving better information flow and team dynamics
People enjoy their work more

The development cost for these benefits is not the 100% that might be expected, but approximately 15%. This is repaid in shorter and less expensive testing, quality assurance, and field support.

How to pair

When the task involves coding, three options:

Driver and Navigator

Driver is the person with the keyboard focused on completing the immediate goal at hand, temporarily ignoring larger issues. Should talk through what they are doing while doing it.
Navigator is the observer while the driver types, reviews the code on-the-go, gives directions and shares thoughts. Keeps an eye on the larger issues, potential bugs and makes notes for next steps and obstacles.
Driver thinks tactically and is detail-oriented while the Navigator thinks strategically and has the bigger picture in mind.

Tips:

Start with a reasonably well-defined task
Agree on one tiny goal at a time e.g. defined by a unit test or a commit message
Switch roles regularly
As Navigator, avoid tactical thinking, you'll be tempted! Make notes on potential obstacles and ideas and discuss after the tiny goal is done, so the Driver can stay in the flow

Ping Pong

TDD oriented
Ping - Person A writes a failing test
Pong - Person B writes the implementation to make the test pass
Ping - Person B writes a failing test
Pong - Person A writes the implementation to make the test pass
…

Tips:

Start with a clearly defined task
Each Pong can be followed by a code refactoring step done together by both (Red - Green - Refactor)

Strong-Style

For an idea to go from your head into the computer, it MUST go through someone else's hands
Particularly useful for knowledge transfer
Driver is a novice
Navigator is much more experienced with the task at hand
Participants do not switch positions throughout the session

Tips:

Driver totally trusts the Navigator and should be comfortable with incomplete understanding
“Why” questions and challenging the solution should be discussed after the implementation session
Don't overuse this technique
Great for initial knowledge transfer but the goal is to transition to the other styles after a while

When the task does not involve coding.

Planning - what's our goal?

E.g. pairing on Epic Ownership or aspects that overlap multiple epics
Understand the problem, read through the story and play back to each other how you understand it to make sure there is alignment
Clear up any questions or potential misunderstandings with the Produc Owner / Engineering Manager / Epic Owner
Double check your Definition of Ready to make sure you have everything to get started
Brainstorm a potential solution, together or individually and then present ideas to each other. If one is more familiar with the domain or technology, take some time to share context.
Plan your approach, list out the steps to get to the solution you chose and how you will test it. Write them down! so that we can track progress (e.g. in JIRA as subtasks)

Spikes - research and explore

Define a list of questions that you need to answer
Split up, divide and conquer. Alternatively, try to find answers for the same questions separately.
Search your company's intranet and messaging system, and any other resources you can find
Read up on concepts that are new to both of you
Get back together after a previously agreed upon time-box, share and discuss

Documentation

Reflect together if any documentation is necessary for what you've done
Create a document together. Alternatively, one person creates it, then the other reviews it and “wordsmiths”.
Pairing reduces the chance of skipping documentation

For time management you can use the pomodoro technique, small breaks after 25min and longer breaks after 2h.

Pair rotations:

Don't stay in the same pair for more than 2-3 days
This avoids silos, increase collective code ownership, and favours more code review on-the-go
It also keeps things fresh, particularly when you are working on something tedious and energy-draining
The person who stays is called the Anchor

Plan the day:

Pairing requires a certain level of scheduling and calendar coordination
Start the day by agreeing on how many hours you are going to pair, and whether you need to plan around meetings or other commitments
If someone is off-sick or on leave, rotate the pair
Consider leaving some time at the beginning/end of the day for other activities e.g. checking your email or self-studying

Physical setup:

Make sure both have enough space, chairs included, clear up the desk if necessary
Decide if you want to use one keyboard or two, same for the mouse. No hard rule, whatever works. Some other factors into play are hygiene and how much space is actually available.
Consider using screen share on Zoom so that each one can use their own laptop
Agree on a default the first time, so that you don't have to discuss this every time
Remote pairing is ok as long as the internet connection is good enough, there is no background noise (use mute otherwise), and both of you agree to it.

Celebrate when you have accomplished a task together, you earned it!

Things to avoid:

Drifting apart during the pairing session e.g. reading emails or using your phone. These can come across as disrespectful and distracts you from the task at hand. If you really need to check something, make it transparent, say what you are doing and why
Micro-managing e.g. “Now type this…", “Now we need to create a class called…", “Press Cmd + Shift O…”
Impatience, apply the 5-seconds-rule instead (when the Navigator sees something “wrong” and wants to comment, wait at least 5 seconds in case the driver already has it in mind, so that you don't interrupt their flow unnecessarily)
Keyboard hogging, are you controlling the keyboard all the time? Sharing is caring ❤
Pairing 8 hours per day, it's not sustainable, it's too exhausting and in practice there are other things you need to do other than coding

There is not “THE” right way, try different approaches and find what works for you and your team.