In the process of trying to identify my knowledge gaps I’ve realized that many of the coding misconceptions I used to have go way back from when I first started to learn how code. There were many things I interpreted in the wrong way when I was first being introduced to 

 of new concepts, which is totally normal because at that stage you just don’t have enough context.

Another thing I realized as well is that knowledge gaps are not necessarily the stuff you don’t know but also the stuff you 

 you know and it’s not exactly accurate.

One interesting misconception I used to have was related to asynchronous JavaScript. When I was first introduced to the topic I remember being very confused and after going through several tutorials I ended up assuming that JavaScript’s code execution was asynchronous by default.

I carried this thought with me for a long time until one day I stumbled across this definition:

JavaScript is an asynchronous and concurrent programming language that offers a lot of flexibility. It's single-threaded like sync, but also non-blocking like async. 

Although it's synchronous by nature, JavaScript benefits from asynchronous code.

I realized that there was a more complex explanation to what I believed and I kind of had a misleading idea about JavaScript’s default behaviour, it wasn’t blocking me from doing my job but still misleading, and was probably causing me to expect the wrong things from my code too.

It was actually pretty cool to revisit a concept and be able to understand it better now so I could adjust my mental model: JavaScript is largely synchronous, meaning that each line runs after the previous one finished running but there are functions that allow JavaScript to behave asynchronously, like 

Of course, that is my very summarized explanation but just wanted to mention one example of the coding misconceptions I noticed I had.

I definitely noticed a change in my perspective after adjusting my mental model about async JavaScript, and it got me thinking, when learning something for the first time, it’s fine to understand it 

 to get started but as you gather more context, it’s a great idea to go back and review the fundamental concepts because it’s really interesting to see how you’ll be able to understand it better when having more experience, and also to check if your understanding of something is actually accurate.

Misconceptions & Asynchronous JavaScript

In the programming world there are so many things to learn and so many courses out there, it's really easy to start one and then never finish it, 

To prevent this from happening I've been trying to adjust my mindset and one thing that's been helping is to remember that it's totally valid to only do the parts of a course that interest me or the ones I think will benefit me the most, so now to me, completing a course it's not necessarily about going through the entirety of the content (especially for really long courses).

 by Dan Abramov and Laravel from scratch on 

, taught by Jeffrey Way. The teaching methodology of both is really different and I thought that was interesting. In both cases I did end up going through all of the content because it was really good.

Just JavaScript focuses on improving your mental model and it has a lot of helpful exercises that made me question my knowledge and also allowed me to solve a few misconceptions I had about JavaScript.

I decided to go through the Laravel from scratch course because despite working with Laravel on a daily basis at my job I really wanted to go through the basics to consolidate as much as possible my understanding of the fundamental concepts in the framework (and also because Laravel is pretty cool, lol). The course goes through some more advanced features as well and I thought that was great.

This post is to keep me accountable and to remind myself that going through a course is way easier when you're excited about the content you'll learn. ✌️

I completed a course

Back in December 2021 I wrote "4 months working as a developer" which is a blog I'm very proud of, as it has some good personal reminders. Now I'd like to make an update on my experience because to this date I've been working as a front-end developer for 17 months (time flies, I know) and oh boy, I've learned 

I won't lie, when I first started working as a developer I was very overwhelmed with all the new information I was receiving and most importantly, all the new responsibilities. I had to fulfill a role in which I had no previous professional experience. Even though I had worked so hard to prepare myself, studied and coded for many many hours, I was still very insecure of my skills (which is completely normal being a junior).

I tried to constantly remind myself that I needed to give me some time and be patient while I adjusted to the whole new experience, but of course, it wasn't as easy as it sounds and I would get very frustrated sometimes. But guess what? Giving it time worked! I did eventually start to feel a bit more confident and less anxious.

I realized that "being confident" wasn't just about having the "perfect" skills, there’s so much more in being a developer than just having great technical skills. Having a good understanding of the codebase, business logic and tools used in the company play a huge part. Understanding the product development process, having a good communication with your teammates and being organized with your daily tasks is just as important as your coding skills.

So focusing on understanding all of these things helped me feel more confident on those days where my coding skills were making me feel like an imposter.

I know I still have a long way to go and there are so many things I want/have to learn to improve my skills, and even though I still get anxious sometimes there’s one thing I'm 100% confident about and it's that I might not know how to do something right now, but you can bet I'll do my best to figure it out!

I've realized that a very significant portion of my time while coding goes into making decisions.

From the very first moment you start coding you have to start making decisions: which syntax to use, which approach to follow, how to name your variables and functions, which CSS properties to use, "to abstract or not abstract?", and so much more… But now that I've been doing this for more than a year, working in a real life application with a team, I can see/appreciate better the impact these decisions can have, so I’ve learned to not underestimate them.

Now I feel like I have a broader understanding of the questions I should be asking myself and the things I should be considering when coding something and deciding which approach to take. For example, I've learned that it's important to consider how my changes will impact the readability of the codebase, as well as the performance, accessibility and user experience of the app.

 type of decisions we have to make, like deciding how to manage our time, prioritizing daily tasks and other stuff like identifying when you're spending too much time on something that's not an actual issue or bug (lol).

I've also learned that these aren't decisions I always have to make alone and collaborating with teammates is extremely beneficial to get ideas and come up with a solution together, and it's also way more fun! (more on this later)

As I started working on a codebase I was seeing for the first time and in a framework I didn’t have a lot of experience (which was Laravel), I would always try to look for existing patterns in the code to get some ideas or to know which syntax and functions to use.

This approach worked fine for smaller issues but as I started working on bigger fixes and features I realized (and my teammates helped me realize) that there was a big problem with this method, which is that a very significant portion of the app was legacy code and we had code that was (sort of) working but it wasn't written in the best way possible, for example, it was working but it could potentially represent a security issue, or it wasn't performant. So, without realizing, I was learning some bad principles.

Now I've learned that when possible, it's a healthy practice to question why something is written the way it is (especially when talking about legacy code) and look for areas of improvement instead of just following current patterns.

I should also mention that what’s been helpful to know when and how to question something is that I've dove deep into the Laravel docs, taken a few Laracasts courses and most importantly, I've had the help of my senior devs.

One of the biggest highlights of the past 6 months is that I started having recurring code collab sessions with my senior devs and I can't explain how helpful it's been, especially being a completely remote team!

Being able to talk through problems, think about possible solutions, and make decisions together is really nice and has helped me gain more confidence as well. It feels like a safe space to try new things, to learn and ask questions without feeling judged.

Never trust user input, only store validated data

A bug is a missing test AND writing tests can really make you question your skills

Working on a big feature and then seeing it live is extremely satisfying!

17 months working as a developer

A lot of things have happened in the last 5 months. Here’s a life update!

Ever since I started my first developer role I’ve been having a hard time trying to balance work and the side projects I want to build. Well, if I’m being honest, I should say “the side projects I feel like 

 to build”. While learning how to code, I developed a strong habit of practicing every day and building stuff, and to this day, I still feel the pressure to continue doing it at the same pace. Like spending most of my day coding at work it’s not enough, right?

I believe most developers experience a similar pressure as well, which is not great. In my case (regardless of how cheesy it sounds), I’ve learned that side projects should be something you enjoy to some extent, or at least something you’re excited to build, otherwise, it’s difficult to find the time for them.

So, during this time I’ve been learning to listen to my body and focus on the things I really want to build & learn outside of work at a better pace, without forcing myself.

 so this Airbnb clone uses Sanity to handle the content and 

 on the front-end. I used this project to try two other libraries that looked really interesting: 

I implemented a likes feature as well, using API routes and serverless functions. It doesn’t work great for now, but it was fun to implement!

Ticket to Ride is currently my favorite board game (thanks to my friend Juan for introducing me to it), however, the scoring process can be very tedious, so I created this calculator to help with that. You can add several players, add points for each one and end the game to filter the players by ascending score. For now, it only has the destination cards from the Europe version.

I’ve been focused on improving my React skills, especially, studying to improve the way I handle the state of my applications. The new 

 have been a HUGE help for that, I’ve going through the documentation and interactive exercises regularly.

I’ve also been going through Josh W Comeau’s 

 course. It’s amazing and can’t recommend it enough.

In August 2022, it will mark one year after I landed my first job as a front-end developer at Castos! The past 6 months have been great and I’ve been learning like crazy. I’ve also worked on some super cool projects that I’m really proud of.

While handling work & study, I was also in the middle of a big move! My second time moving to another country, this time to meet my family in Portugal (my new home).

Last but not least, I also traveled to Chicago for the company retreat, and was able to finally meet my co-workers. This was my first time in the US and I had such a great time!

What I've been up to

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