DEV Community: Syeda Aimen Batool

How to add RTL support in Figma

Syeda Aimen Batool — Mon, 02 Nov 2020 20:09:20 +0000

Around 20 countries in the world speak a language that is written RTL (right-to-left). Thus, RTL support is necessary for any digital device either web or mobile.
Currently, Figma doesn't support RTL language but there are a few community plugins that help us achieve the goal. Let's look into it.

Problem:

By default when we write an RTL text in Figma it does the following:
It won't show the text IF you haven't selected an RTL supporting font.
It won't automatically make the text RTL. Rather, the individual characters of your text will be written LTR.

Solution:

To fix the issue above we need to install a third-party plugin developed by Figma community members. I have selected the Arabic & RTL Support plugin developed by Ahmad Alhaddad for this tutorial.

Steps:

Click on the mentioned link and it will take you to the plugin page
Click on install and it will automatically load into the Figma
In Figma, write some RTL and from plugins select the installed plugin to fix the direction of the text

There is a list of a few more RTL plugins in the library you can find and install the best that suits your requirements.
Learn what is Redux and how it manages the state Or tweet me @aimenbatool.

How I got a remote, paid internship with Mozilla through Outreachy

Syeda Aimen Batool — Sun, 12 May 2019 17:17:04 +0000

I started learning JavaScript 10 months ago and the journey has been full of frustration, hope, and motivation. Before starting JavaScript, I thought I knew most of it — but I was wrong. There was a lot to learn, Vanilla JavaScript, Node.js, React — and then making some dummy side project to apply the knowledge. And time was short because I wanted to learn and implement everything in just 2–3 months to start a job as soon as possible.

Being jobless and not having the skills you want to work with is the worst feeling ever. And you need great willpower and motivation to keep learning and keep going, staying hopeful for the future.

I started the freeCodeCamp curriculum along with a couple of other tutorials (I’ll share more about them in another post) to learn and polish my JavaScript skills. After grasping a good amount of knowledge and making a fully functional web app in Express.js, Node.js, Handlebars, and MongoDB, I got some confidence and decided to jump on the front-end and learn React.js. Then I got hold of some basic knowledge of React and made some throwable apps.

But I couldn’t focus on learning more, as I wanted to earn now. It had become hard for me to work without making money anymore. So, I actively started applying to remote JavaScript jobs. I used to apply for at least 2 jobs a day but for most of them, I was not the perfect candidate so the answers were NO.

After applying for numerous jobs I realized that most companies are not interested in hiring a junior developer remotely. They prefer to have juniors on site, while those who have some experience can work remotely.

Disheartened but motivated, I decided to fully focus on completely learning React, and went back to my freeCodeCamp curriculum. I decided to make a portfolio in addition to making myself worthy enough to get a fine remote job.

One morning when I opened my mailbox there was an e-mail from the Outreachy newsletter announcing the opening of their applications. I had signed up for this newsletter a few months back when the applications for the previous rounds were about to close and I was just starting my journey. I almost forgot about it and it popped up again after a few months right at the time I needed it. So I forgot all the jobs I applied to, stopped looking for more jobs, and fully focused, deciding to work hard to get the Outreachy Internship.

I read numerous articles by the previous alumni, noted down their suggestions, explored Outreachy, watched Youtube videos and what not. I gave myself a chance to prove myself. I couldn’t see anything else except Outreachy. I worked hard, learned about open source, stayed awake late nights, and worked on weekends to achieve my target. It was a chance to prove myself to myself.

Today, I’m sharing my journey with you to help you. To help someone who is struggling to code, who is struggling to survive in this tech world, who is dreaming of a great remote job and a dream home office desk. This article is for you, Outreachy is for you.

What is Outreachy?

Outreachy is a program that provides 3 months paid internships in Free and Open Source Software for people who are typically underrepresented in those projects. Interns are paid a $5,500 stipend and a $500 travel grant to attend any national or international event related to their project approved by their mentors. Outreachy internships are not limited to programming only. They also include UI/UX, documentation, data science, graphic design, video documentation, and illustration.

The best thing about this internship is that it is remote and Interns can work anywhere from the world without the differences of color, nation, religion, gender or culture affecting their work.

Many dream tech companies share their projects and accept interns to mentor them and give them the opportunity to work with their best developers. Mozilla, Debian, Git, GNOME, Kubernetes, and OpenStack are a few.

Previously Outreachy was only accepting Women, Transgender, Trans-men, gender-queer and some other underrepresented people in Tech. But the good news is that from this round it is open for all now.

How I won the Outreachy internship at Mozilla

Here is the Outreachy application process and how I went through it.

1) Initial Application

After creating the account I found an initial application form. You provide some information and they decide whether an applicant is accepted or rejected for the next stage. In this form, you provide info such as your name, gender, country, city and most importantly your availability during the internship.

Outreachy requires interns to be available full time during the internship, which is 40 hours per week. I came to know that one applicant couldn’t make it to the next step because she was not available for full-time. So the first step is to filter those candidates who qualify through the criteria. I qualified for the next step which is selecting a project and starting contributions.

2) Project selection and contribution

Ahhh! This is the most important step and a bit of a tough part of the process. A wrong project choice can cause you to lose the internship or the right choice can open doors of learning and exposure for you. After clearing step one, interns now can see the list of all projects and their details.

The project I was selected for

Wrong way of selecting:

Going through every single project and company, reading details, and not remembering anything and thus ending up getting all confused.

You don’t need to read and see details of every project and switch from one to another. It will burn your time and energy.

The right way:

Just shortlist the projects based on the required skills which match your skillset. Now you have a few projects in your bucket. Next, you can further shortlist based on the supporting skillsets required with the major skill. Or you can choose based on your area of interest.

In my case, I am good at JavaScript. I had many JavaScript-based projects but I was interested in ReactJS to enhance my skills. It was easy for me to choose a project and stop wasting time on other projects because I was clear in my mind that I wanted to work with React.

3) Setting up the project, understanding the codebase, and starting contributions

Ladies and gentlemen, tighten your seat belt as you are going to experience a lot of different emotions at this stage of the application. You are going to feel dumb, not confident at all, fear of contribution, fear of rejection of pull request, fear of not writing quality code, fear of asking questions of the repo owner to help you set up the project, and much more.

Throw that syndrome out the window :)

This is what my mentor asked me to do in response to my fears. And I recommend you do so, too. Once you throw it out you will do well. You will win it. Fear is going to take you nowhere!

Now you have to set up the project repo, make it run on the local machine with the help of available documents, and start finding good first issues. It is helpful to start with good first issues as they get solved pretty easily and you gain a lot of confidence and motivation to continue.

Remember, Outreachy requires at least one contribution to be eligible for the final application and internship — but they highly encourage interns to keep contributing to increase chances. Now, based on my experience I warn you not to get trapped and feel accomplished with one or two contributions.

Competition is tough, people contribute more than once from around the world and increase their chances of selection. So make sure you have more than one — and really good contributions increase your chances.

I had never contributed to any project ever before, I didn’t even know what a Pull Request was and how to do it. In fact, I learned everything during the application process.

I found one issue unassigned and opened a Pull Request with a solution. My mentors were in a different time zone, so before they would wake up I had two Pull Request opened and I couldn’t sleep just waiting to see the response. I stayed up till 3 AM until I got the response on my PR. And to my surprise it was…

and then

Yay :-D

You can’t imagine how happy I was. I felt like flying, like Superman going up above the sky. In short, I was in 7th sky!

But I had to come down to solve more issues. This gave me great confidence and then I didn’t stop contributing. By the time of the last date of application submission, I had 6 Pull Request merged. I submitted my final application and kept contributing afterward.

Before the Outreachy results were announced, I had a total of 10 Pull Requests in my bucket which made me a stronger applicant for this project.

Results announcement

It was hard to wait for the results. I was impatiently counting days to get the news. With confidence and hope, there was nervousness too. And the news of acceptance was nothing more than a cool breeze in the weather of frustration and journey of learning. I was excited and happy and whatnot. A long journey of learning and making test applications got me here at Mozilla working with the finest developers on earth.

I couldn’t stop imagining learning more and become another fine developer in the next few months. And then the news of a getting a MacBook Pro from Mozilla was like a cherry on the cake. I already started disliking my HP machine. :-D

Finally, I am now going to start another journey of learning by working on a real project with mentors in one of the world’s top tech companies. My internship is starting on 4th Dec 2018. I’m excited and can’t wait to start it. I am hoping to learn and get the most out of it.

Why I found Mozilla so special

Interns at Mozilla get three more benefits other than the stipend and travel grant, which make this internship even more exciting.

All Mozilla interns get the latest MacBook Pro with cool heavy specs.

My MacBook Pro is arriving in a few days with the following specs:

2.9GHz 6-core 8th-generation Intel Core i9 processor, Turbo Boost up to 4.8GHz
32GB 2400MHz DDR4 memory
Radeon Pro 560X with 4GB of GDDR5 memory + Intel UHD Graphics
512GB or 1TB PCIe-based Flash Storage
Touch Bar

Mouthwatering? It definitely is!

An Invitation to Mozilla All Hands, which is an event where all the company’s employees are invited to meet their colleagues in person and share experiences and interact with other people they may not normally meet in person. Interns get a chance to meet other employees, volunteers and more specifically their mentors of the project.
All Mozilla interns get LDA credentials which mean they will have an official Mozilla e-mail id — username@mozilla.org.

Nuggets of wisdom to win Outreachy

Based on my experience and observations, here are the things which led me to win this opportunity that I suggest you do:

Leave every fear, insecurity or moment of low confidence behind and jump into it. Apply for Outreachy, contribute, learn, ask questions, try to solve the issue. It is okay if you don’t get it correct at first attempt — you will get feedback and you can make it in the 2nd or 3rd or 4th attempt. In the end, learning matters — not the number of times you made mistakes.
Don’t feel too accomplished or overconfident after making one or two contributions. Try to solve as many issues as you can. Keep contributing even after the deadline until you get the results. This helped me a lot. It made my mentors realized that I’m a learner, enthusiast, and an active participant and they always appreciated it. So I recommend you to keep contributing.
Don’t be afraid of asking questions even if they are stupid. For one issue I asked too many questions from my mentor, but he was kind enough to answer them all. Still, make sure you are asking after some personal research. Don’t throw any random questions out there. Ask if anything is not clear to you. Ask. Ask. Ask.
Keep an eye on your competitors. I used to visit the project repo daily to check how many new applicants were trying to solve the issues. How many PRs were opened and who would be my biggest competitors. My heart used to beat really hard whenever a new applicant popped up which helped me not to stop.
Start as early as possible. Sign up for the newsletter. If you start early you will have a lot of unassigned easy bugs which you can solve. You will have a good chance to understand the project and solve the most issues. The application process is long and time-consuming, and you can’t make it in one or two weeks.
Engage with the project mentor. Don’t let them forget you. Contribute, solve bugs, and ask (valid) questions.
Most Important: I already knew that Mozilla offered a Laptop and All Hands meeting invitation, but I didn’t apply to the Mozilla project for these two things. I applied because, among all listed projects, there were only a few projects that required JavaScript and React — and only 2 projects I could understand a little bit. And one of them was from Mozilla. Your primary purpose should be winning the internship with any organization, gaining knowledge, learning and making your way towards a better future. Don’t select one company because of a few perks. You will end up losing a good project and banging your head against some other project that’s not of your type. Select a project if you really feel that you can do well there.
Focus on one project and give your best to it. In case your project doesn’t have more issues, ask your mentors to refer you to some other project. This happened in my case.
Forget about the outcome. It’s okay if you don’t win the internship, you will learn a lot. You will get some mentors and a start to the opensource journey. At a point, I decided to keep contributing to the project even if I didn’t win the internship. Because the amount of knowledge I gained during the process was significant compared to what I gained working on demo projects over the past few months.

Hah! I have a lot to say. I should keep other things for the next article. I’m excited to start my internship at Mozilla. And I highly encourage struggling newbies to apply for Outreachy. You don’t need to be a great developer — you just need to be a great learner.

These internships are here to teach you to increase your knowledge. If I can get it you can definitely get it. Anyone who is motivated and willing to learn and work hard can get it. Next round of Outreachy is starting in Feb 2019. Don’t miss it!

A Big Thanks

In the end, a big shout out to Outreachy organizers Sage Sharp, Marina, Elizabeth Noonan at Mozilla and everyone who supports Outreachy helping newbies to learn and excel in open source. Lastly, a big big big thanks to my husband for telling me about Outreachy, sending me the link, and motivating me to apply and work hard. This wouldn’t be possible without his moral support.

It would be totally unjust if I don’t mention the support and motivation given by my mentors Armen Zambrano and Dustin Mitchell. I feel blessed to have supportive mentors who celebrated little achievements. Needless to say, their unwavering support was always there to sort out all kinds of issues I faced. Thanks a bunch for being so kind and helpful.

Ahh! I can’t wait to start!

Motivated?

If you are planning to apply for the next round and not feeling confident or feeling lost in the application process, feel free to get in touch. I would be happy to help you. I want Outreachy to reach out to everyone struggling for a good career start.

Remember

“People are capable, at any time in their lives, of doing what they dream of.” -Alchemist

My code is @aimenbatool and I tweet @aimenbatool. Contact me if you need help.

This article was originally posted here.

An intro to Redux and how the state is updated in a Redux application

Syeda Aimen Batool — Tue, 07 May 2019 16:24:19 +0000

Photo by Fabian Grohs on Unsplash

I started learning Redux a few days back and it was an overwhelming concept for me at the start. After polishing my skills in ReactJS by making a personal book reading application, I headed towards Redux to learn more about it.

Today, I’m going to share a few core Redux concepts without using any view library (React or Angular). This is a kind of a personal note for future reference but it can help others as well.

Let’s dig in together!

What is Redux?

Redux is an open-source library to improve the predictability of the state in a JavaScript application. It is an independent library. It is commonly used with other libraries like React and Angular for better state management of the application. Redux was created by Dan Abramov in 2015 to handle complex state management in an efficient way.

When an application grows larger it becomes harder to manage the state and debug for issues. It becomes a challenge to track when and where the state is changed and where the changes need to be reflected. Sometimes a user input triggers some API call which updates some model. That model in turn updates some state or maybe the other model and so on.

In such a situation it becomes grinding to track the state changes. It happens mainly because there is no defined rule to update a state and state can be changed from anywhere inside the application.

Redux tries to solve this issue by providing a few simple rules to update the state to keep it predictable. Those rules are the building blocks of Redux.

Redux Store:

As we discussed earlier, the main purpose of Redux is to provide predictable state management in our applications. Redux achieves this by having a single source of truth, that is a single state tree. The state tree is a simple JavaScript object which holds the whole state of our application. There are only a few ways to interact with the state. And this makes it easy for us to debug or track our state.

We now have only one main state which occupies the whole state of the application located at a single location. Any changes made into the state tree are reflected in the whole application because this is the only source of data for the app. And, this is the first fundamental principle of Redux.

Rule #1 — Single source of truth

The state of your whole application is stored in an object tree within a single store. — Official docs

The ways you can interact with a state tree are:

Getting the state
Listening to the changes in the state
Updating the state

A store is a single unit that holds the state tree and the methods to interact with the state tree. There is no other way to interact with a state inside the store except through these given methods.

Let’s talk about the methods a store gives us to interact with the state.

getState() — Returns the current state of the application.
dispatch(action) — The only way to update a state is by dispatching an action and dispatch(action) serves the purpose. We will talk more in detail in a bit.
subscribe(listener) — The purpose of this method is to listen for the state changes. Every time a state is changed, it will be called and will return the updated state.
replaceReducer(nextReducer) — Replaces the reducer currently used by the store to calculate the state.

Now when we have a store which contains a state tree and a few ways to interact with the state, how can we update application state?

Updating state in the application:

The only way to update a state is to dispatch an action. This is the 2nd rule.

Rule #2 — State is read-only

An action is a plain JavaScript object to keep track of the specific event taking place in the application. What makes it special is a ‘type’ property which is a necessary part of it.

{
 type: "ADD\_BOOK\_TO\_THE\_CART"
}

The main purpose of this property is to let Redux know about the event taking place. This type should be descriptive about the action. Along with the ‘type’ property, it can have other information about the event taking place.

Actions can have as much information as you want. It is a good practice to provide less and necessary information — preferably an id or any unique identifier wherever possible.

Here we have an action to add a book to the cart.

Once we define our action we pass it to the dispatcher. store.dispatch() is a function provided by the library which accepts an action to perform an action against the state. Redux restricts updating the state to this method only.

This strict way of updating the state ensures that the state can not be changed directly either by view or any network callback. The only way to update a state is by defining the action and then dispatching it. Remember that actions are plain JavaScript objects. Actions can be logged, serialized, and replayed for debugging purposes.

We now have a store, a state, and an action in our app to perform some tasks against the state. Now we need a way to use these actions to actually do the update. This can be done by using a pure function and this is rule #3.

Rule#3 — Changes are made with pure functions

Magic happens here. We need a simple pure function, which, as a parameter, takes the current state of the application and an action to perform on the state, and then returns the updated state. These functions are called reducers.

These are called reducers because they take the collection of values, reduce it to an updated state and then return it. Since reducers are pure functions they do not mutate the original state. Instead, they return the updated state in a new object. Our application can have one or more than one reducer. Each reducer can have a relevant state to perform specific tasks.

Since reducers are pure functions, they should have the following attributes:

Given the same input, it should return the same output every time — No mutation is allowed.
No side effects — No API call data change from an external source.

The process.

If we connect the dots, Redux is a library which has a store that contains a state tree and a few methods to interact with the state. The only way to update a state inside a store is to dispatch an action and define a reducer function to perform tasks based on the given actions. Once dispatched, the action goes inside the reducer functions which performs the tasks and return the updated state to the store. This is what Redux is all about.

State update flow in Redux

What have we learned so far?

Let’s summarize what we have learned so far to connect the dots.

Redux — An opensource predictable state container
State Tree — A plain JavaScript object which contains whole application state
Three ways to interact with a state (the only ways):

Store — A single unit which contains state tree & methods to interact with the state tree

Actions — Plan Javascript objects to describe the action taking place

Reducers — Pure Javascript functions to take current state and an action to return a new state

Since Redux is an independent library which can be used with React, Angular or any other library, I avoided making a sample application with any of these view libraries. Instead, I focused on the core Redux concepts only.

Redux can be overwhelming at first and if you are a newbie or junior developer it can give you a tough time. But consistency and a positive attitude is the key to success. If you are struggling to survive as a junior developer and looking for some motivation, you can read how I struggled to overcome the challenges I faced as a junior dev.

Say Hi @aimenbatool.

How Mozilla takes care of Firefox’s health — and what you can learn from it

Syeda Aimen Batool — Thu, 24 Jan 2019 21:55:03 +0000

Currently, I’m working on a Firefox health dashboard as a part of my Outreachy internship with Mozilla. And here are the major goals we intend to achieve during the internship.

Add new features to the graphical presentation of performance data
Transfer existing JS Team (Firefox Performance) dashboard to the health dashboard
Enhance existing information on charts and fix some bugs

The main purpose of this post is to explain the project to someone who is not in the community and not familiar with the stuff we are doing at Mozilla. The intention is to help newbies and other contributors to understand the dashboard so they can contribute to this opensource project with more sense of what is going on inside.

Photo by rawpixel on Unsplash

What is Firefox Health Dashboard?

Firefox health is a project to create dashboards for project managers and engineers. It displays Firefox matrics and insights to help meet release criteria. It allows including data/metrics from Mozilla’s issue tracker (Bugzilla), performance data (Perfherder), product metrics (Telemetry) and few more sources. All data is displayed in the form of graphs using an open source graphing library ChartJS to display insights against different dates and platforms.

It was previously known as Platform Health. It was refactored in Jan 2018 as Firefox Health Dashboard. One of the major changes in this refactorization was to separate backend from the front-end. This improved code maintainability.

Technologies:

The backend is written using NodeJS and Koa. The front-end is built using ReactJS along with an open source graphing library ChartJS. Some of the data is coming from different hosts through different libraries. For example, perf-google is querying Mozilla’s Perfherder for performance data. Information about the reported bug is coming from Bugzilla. So if you are planning to contribute some time in the future, you need to have an understanding of the technologies mentioned above.

This dashboard caters to performance of different Firefox versions and devices. But today we are going to talk about Firefox android and how engineers at Mozilla take care of its performance.

Data/metrics for Firefox android

Currently, data for Firefox android is coming from different sources. We display the data in the form of graphs for better understanding and analysis. You can see all insights to Firefox android on the health dashboard. Here are some sources and information about Firefox android to help engineers improve the performance of the browser.

Bugzilla:

Developed by Mozilla, Bugzilla is a free, open-source tool for tracking bugs, issues and change requests in large complex applications. It is used by thousands of organizations to keep track of their product performance. We are using it in the Health Dashboard to keep an eye on the bugs popping up in Firefox Android.

A graph displaying bugs from Bugzilla

As mentioned above, we are using ChartJS to display data. Here we have a graph representing the number of bugs reported on different dates for Firefox Android at Bugzilla. Bugs with P1 label have the highest priority. They need to be fixed as soon as possible. Then comes P2 bugs with the 2nd highest priority. P3 level bugs are with lowest priority and engineers can fix them whenever they have time. This helps developers and product managers to review bugs of different priorities more effectively and solve them according to the priority.

NimbleDroid:

We are using a third party service called NimbleDroid to get some data insights after running the tests against Firefox Android. NimbleDroid is a functional performance testing service for android and IOS devices.

Monitor every critical user flow for every build of your mobile app. Pinpoint issues that degrade user experience early in the dev cycle. Seamlessly integrate with your CI workflow. — Official Site

Showing data insights given by Nimbledroid

Telemetry:

A telemetry is a tool that has the capability to provide performance and usage information to Mozilla to help engineers and decision makers to measure the performance of Firefox in the real world. It has the ability to collect performance, hardware, usage, customization, and other non-personal information from the user of Firefox and send it to Mozilla on daily bases to help engineers improve the quality and efficiency of the browser.

Telemetry graph view

For an Android device, the browser measures the time taken by it to load a content page on a device and reports it back through Telemetry. We then display it in graphical form. For instance, the screenshot says 75% of the users reported a total content page load time of 4.9 seconds on Sep 19, 2018. And this data is gathered from different devices from different users. This helps the engineers to keep an eye on the loading time of the browser to improve its speed and make it more efficient.

Perfherder:

Perfherder is a system to help engineers visualize and analyze the performance data produced by the many automated tests run against Mozilla products such as Firefox or Firefox Android. Perfherder is a part of Treeherder project. It is another dashboard for check-ins to Mozilla’s projects. The main goal of this tool is to make sure that the performance of Firefox gets better over time. It assists developers in the understanding of their changes and potential fixes by reporting regressions.

In the coming articles, we will talk about Firefox Quantum and JS team dashboard. We will see how these tools are working to improve the performance of the Firefox browser.

Contribution guide:

If you care about the health of Firefox or interested in contributing to the project, then here is the way.

Clone and set up the project on your local machine
Follow the readme
And start with good-first-issues if you are finding it overwhelming to start

Stay tuned to know more about the awesomeness we are doing at Mozilla.

How I’m working to overcome my struggles as a junior developer

Syeda Aimen Batool — Wed, 09 Jan 2019 23:00:51 +0000

Photo by Stas Aki on Unsplash

I believe the other name for coding is the “struggle”. And if you are a beginner or a junior developer, this struggle often is multiplied by 100. Learning to code, finding the right resources, making a portfolio, hunting an internship or a junior dev job, and then working on a real-life project — everything can be a struggle.

But the good thing about struggling is that you learn and come out of your comfort zone to experience new things and implement new ideas, eventually polishing yourself to be a better version of you.

In the tech industry, there are a lot of success stories presenting a long journey of struggle and learning. Everything looks fascinating from the outside. Especially for junior developers, their senior colleagues and mentors are the best people who come up with great logic and astonish them with their amazing ways of writing code.

But when we get closer and see things clearly we realize that everyone has to face challenges, everyone gets stuck with bugs and errors. But through time and experience, we see that they just get stuck on bigger and complex challenges than we do.

Let me share my two favorite tweets from two people from whom I learned a lot. These tweets always make me smile and motivate me. I realize that perhaps we are all in the same boat and sharing the same vision for the same destination.

This is MPJ one of my favorite tech YouTubers

Life let me see this tweet at the time when I was a struggler and trying hard to get JavaScript into my brain. It was an awful concept a few months ago. And it took me around 10 months to learn, explore, implement things and finally getting a remote paid internship.

In the learning phase, I was always in search of appreciation and acknowledgment that I would ever become a good programmer. I wanted to know if programming was my thing or not, or if I would ever be able to write good logic and code as other great programmers do.

Getting stuck on small issues and not being able to fix things quickly used to make me flustered and frustrated. But seeing some top programming celebrities being honest and displaying to their followers that they are also not perfect helped me believe in myself.

And my second most favorite tweet during my time of struggle was from one of the finest developers and the author of the You Don’t know JS series, Kyle Simpson.

Haah! Feeling good? I’m not sure about you but this made me feel a bit more relaxed for some time at least.

After sharing my story of learning and not earning in my previous article, today I’m going to share another phase of my technical journey: after a long struggle of getting a job, struggling to survive in that job.

A bit of recap

I recently started a remote internship at Outreachy. I’m working with Mozilla on the Firefox health dashboard for the next three months. I realized that with learning and experience, my fears and insecurities about my career also changed. This article is part of my internship assignment — to write down the fears and challenges I faced during the first few weeks of the internship. I hope it helps newcomers and those junior developers who are struggling to get in the race or survive and lets them know that everyone struggles and it is necessary for learning.

I was excited and a bit nervous to start my first week at Mozilla with everything ready the night before. but I didn’t see an unexpected thing coming: a nine-hour long electricity shortage at my place. I was unable to communicate with the mentors and start anything at work.

Thankfully, it came back at 5 pm and I had a very welcoming onboarding meeting with Outreachy fellows and the mentors from Mozilla. Things were quite interesting and new to me, like meeting people from around the world and communicating in English for almost an hour. I met my mentors Armen and Dustin for the first time, and it was good to see them. It felt totally different than emails and messages.

My mentors already had a trello like boardorganized at GitHub with some issues placed according to their complexity. Starting the next day, I had to pick issues and start working on them. After starting to work on the issues I realized that the party has just begun. The previous struggles were just a trailer.

It’s all about understanding the code.

My feelings while applying for the internship were totally different from the feeling when I started. Now the fears of not getting this opportunity got replaced with the fear of not doing well and ending up losing it.

And it was really hard when I was stuck with my first issue which was to customize the graphJS tooltip according to the requirements. At first, I thought I would be able to do it easily but it really gave me a tough time. I was unable to figure out the solution for two days.

I asked a couple of questions from the mentors and was trying my best to solve it. But for a moment, I believed that I wouldn’t be able to fix it and that was depressing.

At that time, my mentors didn’t pressure me. Instead, they gave me the confidence and the idea that it is totally okay to struggle with a new, large code base. Sometimes it takes time to understand things and the code written by others, so we shouldn’t be hard on ourselves. We need to take our time to grasp new things.

After realizing that I was struggling to understand the code base, with hundreds of functions and files, my mentor told me about the Rubber Duck Technique and asked me to explain the code to the rubber duck. This would help me get a better understanding of the code and what was going inside.

“It is okay to get stuck, we all get stuck with issues and errors. With the years of experience, we get stuck less, but we still get stuck.” — Armen Zambrano

So here are my findings

Knowing where to start is half the battle

Most of the time you know the solution, and maybe the logic, and how to implement it, but you don’t know WHERE TO BEGIN! With a lot of code files and functions, you get confused as to where this solution should be placed to work well. My mentor Dustin Mitchell suggested that I use comments to understand the code and functions, in addition to my own technique to console.log(everything that comes in the way).

After the first issue, things went a little smoother but were still challenging. I got stuck again on a relatively complex issue and it took a few days to get fixed. But luckily, our mentors and people in opensource are kind enough to understand that we, the junior developers, sometimes struggle — and they don’t make us feel bad for this. We need more people like these in tech who are willing to help and mentor, who provide juniors with the best resources to learn and not to burn out.

Merge conflicts hurt!

Ah!! If you are a beginner and new to open source, I want to warn you about merge conflicts. It hurts badly when you don’t know to how to resolve them, you have spent hours on finding the solution of a problem and you end up losing your code in an attempt to fix the merge conflict.

I ran into some conflicts and I messed up with a few git commits. It was annoying and scary. But I wouldn’t have learned some new concepts in git merging, committing, and resolving conflicts if I hadn’t done this. Thanks to Sarah Clements and Dustin Mitchell for helping me get out of the merging trap.

Recognizing your own code is a struggle

This holds true for almost everyone, and it is really funny that even after a few days we fail to recognize our own code, written by our own hands. After solving a bug, I tried to solve a similar bug and went back to the previous one for reference. And I was like… how come I wrote this code and why the hell is it working?!

The working code can be as confusing as a non-working code. In most cases, the working code gives us a tougher time. And sometimes after coming back to old code, you rethink it and you can come up with a better solution. So you don’t need to worry or feel bad if you don’t understand your own code or others’ code. Maybe you are close to learning something new.

Tell me how to survive

Based on my first few weeks as an intern, I have some suggestions for myself (and others) for the rest of the internship. And most of these suggestions are from my mentors and awesome people I met at Mozilla during the internship. I am sharing them with you, so that maybe they can help you, too.

Photo by Darran Shen on Unsplash

Don’t take things personally and focus on learning

This suggestion is by Sarah and I second that. It is hard to not take things personally and feel insulted when a senior dev or mentor makes a correction or suggestion. It’s even harder when you’re working in open source and it’s in a public platform.

But I recommend that you focus on this point and have a learning attitude. You won’t be able to learn new concepts and good coding practices unless you have a humble and learning attitude. Put all your ego aside and focus on learning from the experience and knowledge of others.

Absorb the maximum amount of information and ask about new things

Keep your eyes and ears open and try to absorb the maximum amount of information and have a thirst to learn new things. Don’t be afraid of trying new and different things which are not in your comfort zone. Sometimes we feel comfortable with our way of thinking and writing code but there are some good practices and design patterns we aren’t aware of. Try to learn as much as you can. This is only possible if you follow the advice mentioned in the first point.

Do your homework before asking questions

Asking questions is not a bad thing, and especially when you are stuck. But it is good practice to do your homework and due diligence first and come up with some valid questions or a solution. Then you can get a review from your mentor or seniors.

This will help you to figure out how to do things on your own. Your mentors will also not feel that you are not putting in the effort before asking. People in open source and in senior positions are often nice and willing to help you if you come up with a valid question.

Do not compare yourself with others

Do not keep comparing yourself with others. It will affect your performance and you will end up losing your confidence. Remember, every master was once a beginner. Everyone struggles, and even your seniors were also at your place in the beginning. They are familiar with the pain and the challenges a junior developer goes through. No one becomes a master just in one night — there is a process and everyone has to pass through the process. Wait for your time to come, and until then, work hard.

Remember, every junior developer is in the same boat you are — you are not an exception. What we study in college is very different from what we have to implement in real life, and we need to learn a lot of things to be a competent developer in the industry. And every senior has been at your place and is familiar with the pain you are in. You just need to focus and have a learning attitude to keep learning and keep growing.

I’m planning to share more things based on my experience and learning. This is the 2nd article of the series I am writing after getting my remote, paid internship through Outreachy.

Feel free to share your thoughts @aimenbatool.

This article was originally published here