DEV Community: Matheus Albuquerque

2022 Wrapped: Communities, Public Speaking, and Other DevRel Stuff From a Non-DevRel Engineer

Matheus Albuquerque — Thu, 29 Dec 2022 14:56:27 +0000

It’s that epiphany time of the year, again! But, before, a bit of an introduction!

My passion for developer communities started back in 2014-15 when I first experienced in my hometown (Fortaleza, Brazil) tons of developers meeting in their off hours to discuss their hot takes in the front-end realm back then—HTML5, canvas, Three.js experiments, CoffeeScript, Web Components, Ionic, and Angular to name a few—, challenges they’ve encountered, and different ways of doing things.

This passion only grew over time, but all of these were hit hard by the pandemics—just like the entire rest of the world, unfortunately.

I don't know you, but, especially in 2022, I feel all about celebrating the endless ways that thousands of front-end/back-end engineers, UI/UX folks, and overall creators of the web, connected in meetups and conferences throughout the whole year.

What You Can Expect Here

TLDR: Matheus' very own Hitchhiker's Guide to the Front-End Conferences, 2023 edition.

I’ve managed to present a few talks that I think went well, and I decided to share what's worked for me in my process of preparing a tech session.

Furthermore, throughout this year—in late 2021, to be honest—, I started running a new personal set of practices for organizing my participation in developer conferences—something I found to be even trickier if your official job position is not to be developer relations—and I'd say things went well too!

Last but not least, I've been to some really amazing conferences and, IMHO, many things went quite well!

So, that's what this post is about: sharing some lessons learned, a lot of “that went well” and other exciting stuff.

For Speakers

Preparing Sessions

There's nothing set in stone here, and I'd say every speaker has their own very personal tricks & tips. Of course, there are always some common denominators across great sessions, like having a concise idea, a clear execution, etc.—but you probably know that.

I thought of sharing here some practices I did throughout 2022 more than in any other year that I consider to play a key role in the execution of my talks.

Better Structuring The Session

One great thing I've always overlooked is having a good, concise, outline of the presentation from the very beginning.

I'd say this practice has an easy adoption: you can start with a vague outline, continuously work on it and throughout the process, it's going to help you fill out a lot of gaps and build out the content for each of your sections until there are no blank spaces left.

Overall, the structure will be more digestible in the end, not only for you but also for the program committees of the conferences you're submitting to, as many of them—e.g., GitNation and CityJS conferences—actually ask for an outline including a more detailed description of the shape and structure of your talk.

When building the outline, I often structure the presentation following the “Hero’s Journey” pattern. It's a classic story structure, often employed in literature and film, that follows the tale of a protagonist as they embark on a transformative journey.

Here's an example from my “Web Performance APIs That You (Probably) Never Knew Existed” session:

An initial conflict: A section that usually goes by “A Little Bit of Context” or “Why Am I Here?”. In this talk, the initial conflict is “I know this set of performance best practices, and yet, I've seen these problems with our loading times metrics via Real User Monitoring.”
Hero’s setup: Here, we're making the audience think about our journey, with topics like web performance metrics and our path of investigating native APIs for collecting and improving performance.
Energy peak where we beat the villain—bad perceived performance. In this talk, these peaks frequently happen after the audience sees a given technique and how it improved something, with examples and numbers.
Epiphany-alike closing ideas that will bring an enlightening realization that our performance problems can be understood from a new and more profound perspective. In this talk, there are two sections responsible for this: “Why are we here?”, which promotes the reflection on why we should care about perceived performance in the first place. Here, we have resources like impacting numbers and statistics about browsers, quality of connection, devices, etc., previous research about how this impacts people’s emotions, and studies on how to correlate them all with business metrics. The other one is “Closing Notes” where we wrap up with some key takeaways from the session.

In my personal experience, building the session within this framework makes it more interesting, increases audience engagement and in general, helps the messaging be more successful.

Dry Runs

Back when I had my college entrance exams, I'd draft the whole essay idea on a separate piece of paper and that'd go around 50/60 lines of text. Then, I'd go through the whole outline and key parts and cut it down to the allowed limit of 30 lines.

Once the first MVP—aka. Minimum Viable Presentation—version of the session is ready, I run it for the first time. And, just like those essays in high school, the first run is always larger than the allowed limit! So, this part is a lot about cutting off the outline, tweaking the slides, and iterating again.

When I feel I have the first “pre-release” of the session, I reach out to a few friends, schedule dry runs with them, and pretend it's the first time. I have a fixed list of people I always go with—a huge shoutout to Macabeus, Lucas, and Augusto—and who always provide great feedback on different areas, like the overall visual aspect, my selection of information and ideas, coherence throughout the session, the chosen level of detail and many others!

Last but not least, whenever I get an existing session approved for another event with a different time slot, I also run again—this time, only on my own—to understand how much I’ll need to cut. Usually, two scenarios fit here:

Sessions that are originally 45/50/60 minutes long—mostly tailored for general-purpose conferences which have long slots, like the NDC events—and need to be cut to fit front-end/React conferences with slots like 25/30 minutes.
Sessions that were 50/60 minutes long on my first rehearsals, had to be shrunk to fit 25/30 minute slots and then got approved to larger slots and need to be adapted again.

Audience Interactions

Last but not least, there's another practice that I've seen to increase audience engagement is to turn your presentation into an open dialogue.

I'd say there are a few different ways you can do this here:

#1 Contextualization Questions

Here you get to understand your audience's technical background. Examples are:

checking who's familiar with modern front-end development in a generic IT conference;
checking how much of your audience are advanced React engineers in a generic front-end conference;
checking who's familiar with a specific bundler, testing library, etc. in a React conference.

A few simple “raise your hands” questions might sound almost like sharing the mic with every attendee and give you powerful insights to guide your whole presentation strategy, including:

how much time you should invest in explaining a given topic;
whether you should spend some time addressing necessary previous knowledge;
whether you should focus on diving deep into every aspect of one topic or providing just an overview with a high-level, example-driven, approach.

Recent examples of this:

In Frontmania 2022, I found out that a considerable part of the audience was working mostly with Angular and Vue. Even though they had knowledge of React, given that my session (“Inside Fiber: the in-depth overview you wanted a TLDR for”) was a deep dive into the internals, I had to provide some extra context in some situations.
In Build Stuff 2022, I realized about 40% of my audience were primarily back-end engineers. Although my talk was framework-agnostic, in some examples, I had React components. Because I was aware a huge percentage of them probably didn't have a lot of familiarity with React, I spent some extra time in these slides, detailing what was happening there.

#2 Open Discussion Questions

These are probably my favorite ones because you can always spark exciting discussions and make the messaging of your talk more successful by gathering audience opinions and hot takes on a specific topic. I've done this a few times in my sessions, usually with tricky mental exercises:

“If you were to summarize web performance in one metric, what’d be your pick?” I asked during my session “Web Performance APIs That You (Probably) Never Knew Existed”.
“If you were to summarize Concurrent React in one word/expression, what’d be your pick?” during “Deep diving on Concurrent React”

This also allows you to run detailed reports and analyze the results after the conference. Then you can power the content/structure decisions we discussed a few paragraphs above for the upcoming talks with actual data/input from your audience.

In the example of the Concurrent React session, I was able to draft a few conclusions on top of the results:

There’s still a lot of confusion around “parallelism”, “multithreading”, and “workers” vs the actual cooperative, single-rendering-threaded, model.
Results like “pointless”, “madness”, and “difficult”, IMHO, show that it's still not clear how all the features fit together just by looking at the individual pieces.

These will turn into long-term insights you can also use to engage the audience after the session, like when I built a report around the impressions above of React engineers over the new Concurrent React features.

Depending on what you use for your speaker decks, there are different technologies you can choose to allow your audience to watch results come in live on the big screen. The best option I've found so far for Keynote was the Poll Everywhere plugin, which is also available for other platforms like PowerPoint and Google Slides.

Last but not least, this strategy is also great because it works whether you present virtually, in person, or in a hybrid environment—which is getting more and more common in this post-pandemic era.

#3 Tech Trivia Questions

I got this technique by watching a session about tricky/unexpected JavaScript behaviors—something along the lines of Wat—by Macabeus about two years ago, where he would play with the audience using a live Kahoot trivia game.

I admit I loved the idea so much I decided to do something similar with my colleagues at Citrix back then, and I put their knowledge about JavaScript to the test with a similar, five-questions-based-quiz, session in one of our internal front-end meetings. We had some nerdy fun in the process and the feedback was great!

I never got another chance to prepare something similar ever since, but the technique happened to be of great help this year at React Alicante, in September. I managed to convince Medallia to sponsor the conference—mostly to raise our awareness and brand visibility among the Spanish front-end community—and, as a part of the sponsorship packages, we got a booth at the venue.

During the ideation of the activities we'd be doing at the booth, the Kahoot idea popped up again and we decided to give it a try. We prepared some trivia React/TypeScript questions, targeting different seniority levels, and the result went way better than expected!

Everyone was hyped to test how much they knew about these technologies and learn a thing or two. The numbers went like this:

~90 people playing the trivia;
~10 rounds played during the coffee breaks;
70+ Medallia t-shirts given away as prizes;
12+ people filled out the form for working with us.

I am looking forward to my next opportunity to try live tech quizzes again!

Finding Events

One of the questions I get the most is how I manage to be aware of so many events and their Call For Papers.
Well, luckily enough, there are plenty of resources out there where one can hear about conferences. My list includes:

https://confs.tech
https://dev.events
https://app.speakerhouse.io/events
https://sessionize.com (More specifically, it's “Discover Events” tab that speakers have access to)

Orchestrating Sessions ∩ Events

Okay, now that we discussed the ideation process of a session and where to find events to present your fantastic talk at, we can explore the next step which is: how to coordinate the whole process of submitting different sessions across different events in different parts of the globe!

The Old Fashion

First, I'd like to share my strategy for 2019-20. I had a Trello board with:

Four different lists: Proposals, Submitted, Rejected, and Approved.
Labels representing the conferences/meetups.
Cards representing the sessions that I'd copy-paste all over the four different categories above and label them accordingly.

You could then think I'd have information for each of the sessions stored within the card for that session, right?

Nope! It turns out that Trello didn't have support for rich text descriptions of the cards back then. This was a dealbreaker for me, given that, when submitting a proposal, most of the conferences ask you for more information than a simple title/abstract pair; it's fairly common to get prompted for stuff like an elevator pitch, keywords, target audience, required knowledge of participants, etc.

To suppress this lack of RTE support, I started then using Trello alongside Google Documents.

Last but not least, I had another Google Document where I'd keep my personal data useful for submitting, like current location, position, company, etc.

I wasn't happy with the way things were going already—it simply didn't scale—and when I faced myself about to add a third app to the equation (Google Calendar), I decided it was about time to shift to something else.

The New Fashion

There are a lot of productivity apps on the market. I had a shortlist of some of them that included Monday, ClickUp, Evernote, and Airtable.

Because I was using Notion already to organize some personal stuff like traveling, I decided to give it a try as my all-in-one sessions ↔ conferences solution.

I start from the main sources I listed in the section above—I do check other websites, but these are the best ones IMHO. I then gather and reconcile all the data in Notion. It looks like this:

This also helps me organize their status on a calendar:

Last but not least, I track which sessions I submitted to a given event so that I can get a better understanding of the actual profile of this conference and what kind of topics they tend to approve/reject.

To be honest, I am still iterating on this approach but so far, I've enjoyed the experience! Among other stuff, I'd highlight in Notion:

It's got huge flexibility and a delightful user experience;
It's free for personal use;
It does have some tools that enable you to have a certain level of project and task management in one place.

For Conference Organizers

I have been involved in the organization of meetups and other small events in my hometown back in 2015-18, but I never really got to organize anything for more than 100 people. Given that, my views here are more biased as both an attendee and a speaker, but not an organizer.

There are a bunch of different practices that result in a remarkable conference experience and I would never come up with an exhaustive list, but here are some things that certainly would make your event great!

Budget

First and foremost, ensure you have all the basic stuff to be covered by your budget, including:

all the speaker expenses (traveling tickets, accommodation close to the conference venue, commute from the airport to the hotel, etc.);
speaker dinners and other fun activities;
proper A/V and room setup (LED displays, proper lighting, etc.);
food & drinks for everyone;
staff—of course, here I mean those who are not volunteer work from the community.

Audience Demographics

Now that's something I had never seen in a conference and I have to say it was just an incredible idea by the React India team!

A few weeks before the event, they shared some anonymous statistics describing the audience, which included in-person and online attendance numbers, seniority levels (ranging from beginner to expert), and companies they were coming from.

This demographic analysis is really helpful for speakers to consider their content beforehand.

Simple Feedback System

In my opinion, that's something most of the front-end/React events should learn from multipurpose development ones.

Usually, what you see out there are either some digital surveys emailed to the attendees or feedback gathered in apps like Eventee. Although these are great for more complex analysis and fancy stuff like weighted averages, what I notice is that unfortunately, only very few attendees take the time to fill out some sort of survey, no matter if that's during or after the conference.

I've always wondered what would be a better way to do that—not necessarily a replacement, perhaps a complementary solution—, until I went to DevConf PL and saw that they had ballot drop boxes available for feedback during the talks. Throughout the year, I then realized that it seems to occur regularly in back-end driven events or generic software development ones, after seeing the same system in conferences like NDC Oslo or Build Stuff.

The voting ballots were colorful cards (🟢 Green / 🟡 Yellow / 🔴 Red) outside the room. They are counted after each of the sessions and then each speaker gets an email after the conference wraps up with their numbers.

That simple!

Accomplishments

I'd say this year brought a lot of new experiences and a ton of wins! I know this post is a bit long already, but I will share a few of them as I feel fortunate and proud of them. Here you'll find some of those mentioned wins and also some not-so-great results.

I helped draft a developer communities program at Medallia from almost nothing with a fantastic crew and we went from zero to sponsoring three conferences: DevConf 2022, React India 2022 and React Alicante 2022. We learned a lot together and are still evolving. This is our Spanish squad in React Alicante! 🤩

I crafted eight different sessions, and four of them I managed to present throughout the year.
I submitted to 41 conferences in 25 locations—online + 24 countries—and 34 cities. Out of these:

😅 In 16 of them, I was not accepted.

🤩 In 13 of them I was approved and I managed to deliver the presentation successfully.

🤦 In 8 of them, I never heard back from the organization/committee. IMHO, this is a red flag that shows a considerable lack of respect for anyone who spent some time writing down ideas and filling up CFP processes.

😥 In 4 of them I was approved, but I had to withdraw my submission for various reasons (e.g., because of calendar conflicts or personal issues).

I traveled to 10 different countries.
I was invited to two podcasts, one in English and one in Portuguese—these are yet to be published.
I was invited to write one magazine article about web performance.
I improved my overall skills in writing/reviewing CFPs and preparing other less-experienced speakers.
Last but not least, I met dozens of amazing people who are now friends and who I'm already hyped to see again.

Closing Time…

Finally, I'd love to wish all of you out there a great Holiday Season! Happy Holidays and a Happy New Year, everyone!

See you all in 2023! 🎆

Driving Towards a Universal Navigation Strategy in React

Matheus Albuquerque — Mon, 13 Jan 2020 13:48:09 +0000

When I joined STRV, they had a specific request for me; to build a front-end app for iOS, Android, and Web, sharing component and business logic among all the platforms.

Since I’m a front-end developer who loves new areas, I couldn’t say no, and I had to jump at the opportunity.

I ended up facing a variety of challenges; from lack of real-world-scenarios content related to React Native Web to unexpected lack of documented stuff on popular projects, to struggling to build some platform-specific modules.

And this post is focused on – a very important – part of this journey: building a navigation solution.

But first…

A bit of context

I had only worked on an example React Native app before (uncompiled and unpublished). At the time of this project, I didn’t know much about React Native, to be honest.

I first heard of Expo and its experimental web support¹ but I decided not to go for it mostly because I enjoy having control over the project stack and being aware of what's happening; I want to be able to customize the installation, install custom versions of modules and have more control of project dependencies.

I then heard of two other initiatives on Github: ReactNative for Web and ReactXP. Both share similar goals but the approaches differ. As the official documentation for ReactXP states:

ReactXP is a layer that sits on top of React Native and React, whereas React Native for Web is a parallel implementation of React Native — a sibling to React Native for iOS and Android.

This post won't focus on covering the differences between these two but, after going through some technical blog posts and talks, we ended up going for ReactNative for Web.

After a bit of digging into articles and trying to implement each environment in its own realm, I found that for me, the best starting point was a great template, called react-native-web-monorepo², which brings support for universal apps using a little help from Yarn Workspaces.

Before starting to implement this approach into your project, though, I would suggest reviewing your requirements and checking whether these tools solve all of your needs.

What we have out there

Some popular routing solutions on the React.js ecosystem were not meant to support both DOM and native environments; <div>s are different from <View>s, <ul>s are different from <FlatList>s and most of the web primitives are different from the mobile ones – which makes it difficult to come up with a universal solution. @reach/router is one example of web solutions that have opted not to face the challenges of supporting both environments.

As of now (January 2020), though, we have a few ready universal web/native formulas. But they all ended not serving completely our needs:

react-router is a great option for the web, but when on mobile, it lacks screen transitions, modals, navbar, back-button support, and other essential navigation primitives.
react-navigation suits great on mobile but given its web support is still considered to be experimental – and has not yet been widely used in production – it's very likely you're going to face a few issues³ related to history and query parameters. Also, it lacked TypeScript typings – which made me write part of the definitions on my own since TypeScript was a must-have for the project.

And this brings us to the next part!

Thinking of a solution

The code from this post is available on GitHub: ythecombinator/react-native-web-monorepo-navigation

I admit one of the most puzzling things when we dived into this journey was not being able to find how popular apps out there using React Native for Web (e.g. Twitter, Uber Eats and all the others mentioned here) are doing navigation – and how they faced challenges like the ones I mentioned before.

So we had to work on our own!

Our new solution was based on abstracting on top of the most recent releases of react-router-dom⁴ and react-navigation⁵. Both evolved a lot and now them two seem to share a few goals which I consider to be key-decisions for properly doing navigation/routing in React:

Hooks-first API
Declarative way to implement navigation
First-class types with TypeScript

Given that, we came up with a couple of utils and components which aim a universal navigation strategy:

`utils/navigation`

Exposes two hooks:

useNavigation: which returns a navigate function that gets a route as a first param and parameters as other arguments.

It can be used like this:

  import { useNavigation } from "../utils/navigation";
  // Our routes mapping – we'll be discussing about this one in a minute
  import { routes } from "../utils/router";

  const { navigate } = useNavigation();

  // Using the `navigate` method from useNavigation to go to a certain route
  navigate(routes.features.codeSharing.path);

It also provides you with a few other known routing utilities like goBack and replace.

useRoute: which returns some data about the current route (e.g. path and params passed to that route).

This is how it could be used to get the current path:

  import { useRoute } from "../utils/navigation";

  const { path } = useRoute();

  console.log(path);

  // This will log:
  // '/features/code-sharing' on the web
  // 'features_code-sharing' on mobile

`utils/router`

This basically contains a routes object – which contains different paths and implementations for each platform – that can be used for:

Navigating with useNavigation
Switching logic based on the current route with useRoute
Specifying the path – and some extra data – of each route rendered by the Router component

`components/Link`

It provides declarative navigation around the application. It is built on top of Link from react-router-dom on web and TouchableOpacity + useNavigation hook on mobile.

Just like Link from react-router-dom, it can be used like this:

import { Text } from "react-native";

import { Link } from "../Link";
import { routes } from "../utils/router";

<Link path={routes.features.webSupport.path}>
  <Text>Check "Web support via react-native-web"</Text>
</Link>

`components/Router`

This is the router itself. On the web, it's basically a BrowserRouter, using Switch to pick a route. On mobile, it's a combination of both Stack and BottomTab navigators.

Wrapping up everything above, what you get is going through each screen of the app and seeing how useRoute(), useNavigation() and <Link /> can be used regardless of the platform you are.

If I was asked about future work on this, I'd mention as next steps:

1) Adding more utilities – e.g. a Redirect component aiming at a more declarative navigation approach⁶

2) Tackling edge cases on both platforms

3) Reorganizing most of the things inside a navigation library and leaving only the main Router component and utils/router to be written on the application side.

Conclusions

My feeling is that web, mobile web, and native application environments all require a specific design and user experience⁷ – and by the way, this matches the mentioned “learn once, write anywhere” philosophy behind React Native.

Although codesharing is a great advantage to React and React Native, I'd say that it is very likely that shared cross-platform code should be:

Business Logic
Config files, translation files, and most constant data – those that are not render-environment-specific
API / Formatting; e.g. API calls, authentication and formatting of request and response data

A few other layers of the app, like routing, should use a library that is most appropriate for the platform, i.e. react-router-dom for web, and react-navigation or similar for native.

Perhaps in the future, we can have a truly unified code base, but for now, it doesn't feel like the technology is ready and the approach shared here seemed to be the most suitable one.

Footnotes

1) There's an amazing talk by Evan Bacon on Expo for Web this year at Reactive Conf – if you haven't checked it out, I really recommend you to.

2) This one was authored and is the same used by Bruno Lemos, the author of DevHub, a Github client that runs on Android, iOS, Web, and Desktop with 95%+ code sharing between them. If you're interested in how he came up with this solution, check this out.

3) These issues include:

Functionality-wide
- Query parameters from URL not passed down (here)
- Pushing back not working (here and here)
- Some params pushed from one route to the other for convenience being encoded to the URL
Developer-experience-wide
- Lack of TypeScript typings (here) – which made me write part of the definitions on my own

4) React Router v5 focused mostly on introducing structural improvements and a few new features. But then v5.1 brought a bunch of some useful hooks which allowed us to implement the mentioned ones for the web.

5) React Navigation v5 also did many efforts for bringing a modern, hooks-first API, allowed us to implement the mentioned ones for mobile.

6) There's a very good post about doing declarative and composable navigation with <Redirect /> here.

7) If you're interested in this topic, in this talk I share a couple of lessons learned while building an app with code sharing as a primary objective — from project setup, through shared infrastructure, all the way up to shared components and styling — and how you can achieve the same thing.

It's All About Trusting the Magic of Beginnings

Matheus Albuquerque — Fri, 12 Jul 2019 07:59:22 +0000

After almost two years immersed in countless exciting challenges, it's time to move on.

My Journey in a Nutshell

One of the funniest things, when I started working at Beakyn, was realizing that every single piece of code I wrote would run in thousands of computers around America. Up to that moment in my career, I had only worked on small local startups, where the impact of their products had way smaller proportions.

At Beakyn, I had the chance to contribute to a couple of projects that impacted the whole assets inventory management and audience demographic analysis lifecycle of our client, Outfront Media – one of the largest outdoor media companies in America.

It all happened combined with efforts to shape a culture of sharing and openness, and I'm so proud of the achievements we've made!

Dope team; always doing some crazy dope stuff in the city that never sleeps! 🗽

I also had the opportunity to present some of the cool things I learned while working on our projects in conferences and meetups. This allowed me to grow my presentation skills (I know there is always a wide room for improvement here, tho) and to create a great network of contacts among our community.

I had never traveled that much to attend conferences. 🛫

On the personal side, I feel that I have grown so much! My remote working routine allowed me not only to travel a lot more through my country – not staying for too long in any city – but to visit new ones. This made me meet tons of great people, get to know wonderful cultures, experience great things and capture all of these moments in photos! By the way, it all showed me photography is a strong candidate to become the hobby I've been constantly looking for 📸.

Watching the sunrise by the window in a plane became one of my greatest moments of peace. 🙏

The Need for a Change

Earlier this year, though, I caught myself on LinkedIn, casually looking for a new job, and this made me think that it was time to move on. You know what they say… when you're feeling attracted by other opportunities, it's a big sign you need a change. I then applied to some companies and met plenty of great people during the interviews, but one of them really had me from hello…

Coming Next

In the coming days, I'll be joining the Front-End division at STRV – a mobile & web application development company that supplies start-ups all over the world with applications developed in such prestigious incubators like Y Combinator, 500 Startups, and others.

I must say that I couldn't be more excited about it, but many things need to happen before I move definitively to the Czech Republic. Meanwhile, I'll be working remotely.

I'm very enthusiastic about what's coming down the line. I really hope to make an impact on the projects, make countless new friends, and bring the best of me to this company and all of its clients and partners.

Furthermore, I also hope to keep pushing great things to production, attend conferences, open-source stuff and help to grow the React.js (and front-end) community.

For those who made it to the end of this post and are somehow part of this journey, thank you so much for everything. I learned more than ever during this time. I really appreciate all kinds of learning and experiences you guys provided to me.

Wish me luck! 🤞🎆