On January 26th I gave my first tech talk (ever) at the 

 virtual meetup and it was an awesome experience! I spent a lot of time getting ready for the presentation, choosing my talking points and also had to deal with the nerves of doing something for the first time and speaking in public.

The topic for my talk was “My first time building a blog with Sanity and Next.js” (this blog!) and here I’ll share the things I learned while getting ready and what I would do differently.

My slot for the talk was 20 minutes. When I first heard this I got a little scared because I thought it was a lot, 

“what am I going to say for 20 minutes?!?”

I knew that I was going to talk about my experience using Sanity and Next.js, therefore, when I started preparing the presentation I wrote down everything that came to mind hoping that I would have enough information to fill the time. This allowed me to have several content ideas which was great, however, at one point I ended up with 

When I first practiced with a timer it was more than 20 minutes and I wasn’t even sure that it was relevant information, it didn’t feel like the topics were connected. I realized that I had forgotten about the purpose of the talk and the message I wanted to convey, so I had to go back to the basics and identify my goal for the presentation.

Once I identified the purpose of the talk it was easy to pick my talking points.

Next time, I believe that a better approach would be:

Identify my main topic and goal for the presentation

Brainstorm talking points and information 

Using a draft, test the time so I know how much I can elaborate my main points

Depending on the time, see what other extra things I can add

Preparing content for a presentation is a big learning experience. I learned about organizing information, prioritizing ideas and it allowed me to understand a lot of coding concepts better.

I was very nervous. As a first-time speaker, talking about coding concepts and sharing my experience, felt very intimidating and I’m sure that happens to everyone (even people that have a lot of experience speaking in public!).

I practiced a lot every day before the presentation, some of my friends were really nice and heard me several times. I practiced alone in a Google Meet call to test sharing my screen and make sure that my windows looked good 🙉.

Practicing was extremely helpful, I gained some confidence while speaking and actually, the day of the presentation, I tried to pretend that it was just one of my practice sessions.

Last but not least, I’m extremely grateful that 

 team and community were so supportive and awesome. Instead of being nervous, I was able to have a lot of fun!

Giving my first tech talk

Last year when I decided to study web development on my own I had no idea how much of my life would change and I'm incredibly grateful to say that it's been one of the best decisions I've made.

4 months ago I landed my first job as a front-end developer so I thought this would be the perfect opportunity to share a little bit of my experience, the things I've learned while being part of an engineering team and hopefully help others that are going through a similar process.

I noticed that every time I've felt anxious while working, it was because I started making assumptions instead of just asking questions. Being the "new one" in a team will always feel overwhelming, (especially if you're a junior), and getting comfortable asking questions is one of the things I struggled with the most during my first weeks, therefore, I ended up assuming a lot of things.

I'm definitely still working on this but now that I've recognized the issue is a lot easier to try to avoid it.

If you're always assuming you know how others think and feel, you stop listening and communicating.

The quote above summarizes why I believe assumptions are a big problem. They prevent you from communicating effectively, and when you're new at a job, that means they prevent you from building relationships and trust with your team members. You also miss the opportunity to learn from them.

Maybe you start working on the wrong thing because you were too afraid to ask for clarification, or maybe your co-worker would have helped you understand the problem better.

It will always be easier to make assumptions because then you don't have to ask anything that might make you seem "dumb", but then the uncertainty can lead to anxiety. The more comfortable you feel asking questions, the better your experience in the team will be.

Like I mentioned before, recognizing that I do this has helped me to avoid it as much as I can, and these are some of the questions I try to ask myself to identify whether or not I'm assuming something: 

"Are the instructions for this task clear enough?", "Do they specifically state the definition of done?"

"Do I understand the problem I'm trying to solve or the feature that needs to be implemented?"

"Do I have all the resources I need to complete this task?"

If you have a doubt that's stopping you from working properly and after going through the instructions again or doing some research, you're still not 100% sure and you need more context, then it's time to ask a question.

When you're just getting started, you most likely will be given the "easy" tasks so they can get to know you and how you work, which is your opportunity to demonstrate your skills and also your work ethic.

In my opinion, even the smallest tasks should be done thoughtfully, because those are the ones that are often underestimated and can lead to a lot of bugs and weird behaviors if done badly.

Take that opportunity to get familiar with the codebase, understand how things work together, and take notes of the solutions you implement so you can apply them again in the future. The "easy" tasks will help you feel more comfortable to then tackle bigger issues.

The whole experience of being able to put my skills into practice on a real-life project that’s being used by so many people has been surreal, just doing some tiny changes like adjusting the margin of an element makes me feel like I have superpowers.

One thing I've realized is that organizing your workdays helps relieve and prevent anxiety. If you have a clear idea of what you're going to be working on for the week, then you're most likely to be productive and feel more relaxed.

You can use any time management system that works for you. In my case, writing weekly to-do lists works perfectly, as they allow me to visualize the whole week and make sure I don't miss anything.

If you're feeling uncertain, then it's time for some more questions!

Ask what's expected of you, make sure you understand your responsibilities, and that you make time each day/week for them.

You don't have to finish or accomplish something each day, we all want to deliver results and do it fast to prove that we're capable. We want to end the day with a win but it won't always be the case, and that's totally normal.

I'm trying to be better at taking breaks too, they're the ultimate productivity hack. Any time you feel stuck, please, take a break! Spending hours obsessively trying to fix a bug when you're already feeling tired will only do more harm than good.

Lastly, I want to remind myself and anyone reading this, to be patient while you adjust to new experiences. The most experienced dev was once a junior too and this also applies to any field so don't feel discouraged if some things take you longer than others.

Don't forget to take care of yourself and enjoy the process.

4 months working as a developer

Toggle menus are all over the internet and as a web dev you'll find yourself building a lot of these. There are a few things we need to take into account in order to create a nice and accessible toggle menu and in this post I'll share some tips I've learned that will hopefully help you next time you have to build one.

Create a menu that's accessible for keyboard users and screen readers.

Effectively show & hide the menu with a smooth transition to make it look professional 👩‍🎨.

I'll be using plain JavaScript to show & hide elements and CSS to add very simple styles. You can then apply these principles to your favorite framework.

Let's start by creating the actual button and including an SVG icon to keep things simple. The aria attributes will help us make our menu accessible:

 communicates the toggle state, without it, screen readers won't say anything different to the user, other than it's a regular button. We need to indicate that it's an expandable and collapsible area. Since the initial state of our menu is "closed", we're setting it to 

. Once the menu is expanded, this will need to change.

Buttons must have discernible text and since we're using an SVG, we can add it using 

 on the button itself. As stated in Sara Soueidan's blog about 

 is used on a button, the contents of the attribute will override the contents inside the button as the accessible name. This means that, if you have an icon or even other text content inside your 

, that content will no longer be announced as part of the button’s name."

Special thanks to 

, for sending me Sara's blog and for reminding me about the importance of discernible text on buttons.

Now, for the actual navigation menu, we'll have a 

 I learned that, if you have more than one nav element in your website, it's recommended that you label them, in that way users of assistive technology can differentiate them. You can do this by using 

I want to focus on the show & hide functionality and transition so the styles we'll be adding are very simple. First, let's add some initial styles:

Great! Now, let's focus on our toggle by making the button and navigation menu look a little nicer:

To illustrate things better, I'll be adding the properties in charge of the toggle to a different class, the one we added in the beginning: 

 (collapsed state). Additionally, we'll create a class called 

 (expanded state), which will be dynamically added with this short and sweet JavaScript event listener:

The first CSS property that comes to mind when you want to show & hide something is 

, which makes perfect sense! Well, this caused me a lot of headaches in the past because I just wanted to toggle my menu and have a nice transition, but it wouldn't work 🤦🏻‍♀️. This is why it's so important to learn from my mistake and get in the habit of reading documentation.

Display is one of the CSS properties that 

 be animated. In fact, it breaks the whole transition just by being there. Let's take a look at the following examples. In the first menu, we'll be adding a transition to the 

 be animated and in the second we're doing the same but we're also adding 

 to hide our menu because even though it's no longer visible, it's taking the same space and we can still access the links by hovering over them or by pressing 

 property. This property controls whether an element is visible or not and 

 does exactly what we want: it hides the element, its content (so keyboard users can't focus it when it's not visible) AND it can be animated 🎉.

 properties will effectively hide our menu from all users. These two are the only "mandatory" properties in our case.

To create a nicer transition, we can toggle between 

, which will make the navigation bar just 5% smaller in the beginning, and then it will have its full size.

 sets the origin for an element's transition", so by setting it to 

 we're changing the origin and the transition will start from there.

 property to the "initial state" class so it works both ways.

list of the CSS properties that can be animated

 to our toggle button because it's initially closed. Now, once it's open we need to communicate this change so screen readers know the difference and announce it to our users.

Once our toggle button is clicked, it will:

 in our button, otherwise, it sets it to 

Here's the final CodePen, try using a screen reader to see it in action! If you're on Chrome, there's a nice 

 allows us to communicate the toggle state so that screen readers can announce it.

Buttons must have a discernible name and if we're using an SVG we can use 

Having a CSS property that can't be animated breaks the whole transition, even if the rest of the properties can be animated.

To effectively hide an interactive element from the screen, we need to make sure that users can't access it when it's not visible.

Accessible toggle menus with cool transitions

Turns out that rebuilding your personal website can be a lot of work, who would have thought? 😆

Therefore, I'm very happy to announce that this is the second version of my portfolio! Even though the design didn't change much, the technologies I used did. The first version of 

 was built using plain HTML & CSS and now it uses Next.js (a React.js framework) to render the pages and Sanity (a very cool headless CMS) to handle the content.

For the styling I used Sass and finally, I used Netlify to deploy it, as well as their awesome form feature for the contact section.

When I first started to learn about web development all the new terms were very overwhelming but here I am, talking about frameworks and headless CMS's, pretty cool, right?

I decided to rebuild it because it seemed like the perfect opportunity to combine all the new things I've learned and it really was. It helped me to see how much I've improved.

For this new version, I really wanted to have some sort of "journal", a space where I can share some of my thoughts on what I'm learning and building so hopefully this is just the beginning.

Journal

Giving my first tech talk

4 months working as a developer

Accessible toggle menus with cool transitions

My experience rebuilding my portfolio