I wrote a script for the “How to download and Install Mixxx” video tutorial, as well as the sequence that I will be following. I haven’t gotten around to recording this yet (as I’m still planning), so this video will be done early next week once I’ve figured out exactly how to go about it.
Mixxx is a free/open source DJ performance software for Windows/Mac/and Linux. It was first released in 2003 as a graduate student project, and was picked up by the community and greatly enhanced. All contributors, from programmers to skin designers to translators are unpaid volunteers, hence it is entirely community driven.
Mixxx is a feature-rich DJ mixing application that supports many MIDI and HID DJ controllers. It supports effects, harmonic mixing, beat matching with thousands of users all over the world. It integrates the tools DJs need to perform creative live mixes with digital music files. Mixxx has an unusually broad community for an open-source project, encompassing performing musicians, C++ programmers and addicts, amateur DJs, Internet radio broadcasters and even casual users.
Besides being a fully-featured DJing application, the main problem that Mixxx is trying to solve is that a lot of DJing applications are either expensive or limited (for the free features). Mixxx exists for people who want to try DJing or do not have the money to buy equipment or the latest fastest computers. A large number of Mixxx users live in the global South, so Mixxx plays a vital role in allowing anyone anywhere to throw a party.
Before the Outreachy internship program, I had never contributed to open-source software. I didn’t know what open source software was (or how different it was from other software) until a friend explained it to me. Since applying to Outreachy, I have learned a whole lot about different open source software and the different ways that you can contribute. I thought it was rocket science (because of the term “open source”) but really, it’s not. I feel fortunate to have earned the internship contributing to Mixxx DJ, and now I can’t wait to share everything that I know about contributing to open-source software – Mixxx in particular.
I am contributing to Mixxx by improving their documentation (User manual). Mixxx’s user manual does a decent job of explaining the application, however, there is lots of room for improvement. Many users come to Mixxx without any prior experience DJing and are left wondering how to practically use the application to mix music. My job as an intern is to improve the manual by explaining not only how to set up Mixxx and how to use specific features, but also explain the bigger picture of how to play music with Mixxx. There is some information in the manual that is obvious or already explained in the application with tooltips but some of this may be deleted from the manual. Other text could be moved directly into the Mixxx GUI. One of my major tasks is to explain information that would take too many words to adequately explain in the Mixxx GUI. This also involves adding more links to specific sections of the manual from the Mixxx GUI (and edit the manual text with this context in mind).
This project is important because it will better the experience of many first time users of Mixxx. I had never used Mixxx before this internship and I think this turned out to be more of an advantage than a disadvantage. I say this because if I was using a software for the first time, I would need to refer to the user manual a lot, and one of the things that I appreciate as a first time user is when documentation writers make the effort to explain technical application-specific concepts to non-developers and first time users in the simplest way possible. Most long time users and developers of open source software might find difficulty doing this because they use these technical terms and apply these concepts every day in their work, therefore it comes easily to them. It might slip a pro user’s mind once in a while that some terms might not be well known to the ordinary user. So, as a newbie, I think that I am able to approach this project with fresh eyes and the perspective a first time user. Are the concepts understandable? Are they easily relatable to the Mixxx graphical user interface? What sections of the manual need more emphasis? Are the directions easy to follow? These are some of the questions that guide me as I work on this project.
Another Mixxx project that I am working on for this internship is the YouTube video tutorials project. Mixxx does not have enough updated video content on YouTube, and these videos are absolutely necessary for Mixxx’s documentation. In this project, I create illustrative videos to help Mixxx users understand how to use the software and thus, can be used by professional DJs, aspiring DJs, music lovers, and casual users. the project involves creating a series of short, brief videos for various playlists and they are mostly OBS Studio desktop recordings with voice-overs, coupled with some illustrative animations to keep the content fun and interesting.
One of the things that I love about working on these projects is that the tools that I work with (git, OBS Studio, Movavi video editor, VSCode) are easy to use. So I’m glad that I get to focus more on working on the actual tasks at hand, and not with the tools needed to get the tasks done (that happens sometimes 😊). I make edits in reStructuredText (.rst) for the manual and markdown (.md) for the website. I found these two lightweight languages easy to learn and work with, so I was happy to get over that learning curve in no time (I’m still learning though).
Another thing that I love about working on Mixxx’s “Improve User manual” and “Create Video Tutorials” projects is that I get to contribute to an open-source project that many people rely on. Some of the work that I do represents a solution to a problem that others may experience as well.
Through contributing to Mixxx, I have gained a much deeper understanding of the software. It was not easy in the beginning as I had to determine which part of the project was worth contributing to. Understanding the contribution guidelines also took me a day or two, and I made mistakes here and there, but that is all expected. It also took me a while to understand some of the issues that were opened in the manual repository on GitHub – determining where the problem was and why it was a problem, researching on the issue and then finally making the requested changes. Once you’ve gone through these steps, you will have gained a much deeper level of knowledge and understanding of the project at hand. Contributing to an open-source project, in the end, lets you reach a higher level of expertise. Something that cannot be easily achieved by simply reading books or using the project at hand.
Before I learned about Mixxx, I was experimenting with Virtual DJ but I didn’t use it often. I only knew the basics of loading a song on a deck, cueing, crossfading into another song, and beatmatching. (Man, I felt like a real DJ!) I knew enough to record a mix for my friends or get a high school party going, nothing too complicated 🙂
However, since I started working with Mixxx, I have learned a couple (understatement of the week) of new terms and concepts such as analyzing your tracks, the auto DJ feature (this is the coolest feature for me), microphone ducking (I always saw DJs do this, but I did not know that this was it was referred to), harmonic mixing, the difference between a crate and a playlist, kill switches among many other things.
When I first started contributing to Mixxx (during the contribution phase), I was fortunate enough to be in a community of really supportive people; developers, DJs, long time users of Mixxx, among others. I learned how to get started on making a contribution by following the community chats in the different streams. We (first-time contributors) all had the same questions. “What next after cloning the manual repo?” “Which branches should we be creating ours off of?” “Do you simply start working on an issue, or should you ask to have one assigned to you?” I remember asking why the bugs reported in the launchpad didn’t have documentation labels. 😌 Lol.
Starting out can be confusing, so, based on my experience so far, here are a few key suggestions that I would make to a first-time contributor of the “Improve User Manual” project or any other project:
If you ever get lost on how to start, try not to feel overwhelmed because you are not alone. You can always ask in the community Zulip chat, how to get started or even what tools you would need. But before you do so, I would suggest that you first read the README.md in the repository of Mixxx’s User Manual or the respective project that you’re working on. It has well-written guidelines on how to get started, prerequisites for the installation of some of the tools you will need, how to build your project and view it before you can commit it, how to troubleshoot in case you run into an issue, and so much more! In addition, there are high chances that what you want to ask in the community chat has already been asked in a previous conversation in the stream, so going through these messages can be helpful for you, especially if you’re shy. 🙂
Try to understand the working of Mixxx. Experiment with it. Learn about the different features and how they work, and how you can manipulate them to make good mixes. You don’t need to be a DJ to do this – the purpose for this is so that you understand better the project that you’re working on. It only makes sense that if you’re documenting a feature, let’s say microphone ducking, that you have Mixxx installed on your computer and that you have used microphone ducking before. I believe that doing this will give your work more context, and things will go smoother.
Take note of the git tree structure. While working inside any branch in the repositories, make sure to understand the git tree for that repository so as to avoid running into git errors and then spending a lot of time correcting them. I forgot to do this once, and I all I can say is, I have never been frustrated about git in my life. I had to open a whole new pull request in the end. I wrote about this in my blog about struggles. (you can check it out 🙂 )
Research on the issue you want to work on before you start working on it. This will help you understand what exactly you need to do and how to go about it. Some times the issues may not have enough detail in the description or the description may be too technical for you. Google is your best friend. I mean it. Leave no stone unturned by the time you start working on that issue! By doing this, you will find that you will have less commits as well (this is a good thing). It means that you understood what exactly needed to be done and did it.
Build the manual to see your changes, before you commit your work upstream. I think this is important to note because it helps keep your branch clean with fewer errors and less commits. I believe maintainers love working with clean code because it makes their work easier (remember that they maintain a lot of code already). So with an organised git commit history, I believe you’re more likely to get a review on your work faster because you’ve made the reviewers’ and mentors’ work easier. You might be tempted to depend on the Netlify deploy previews to preview your changes but that means you would have to commit every minor correction that you’re making and that could potentially make your pull requests messy.
Last but not least, your mentors are here for you. Do not hesitate to ask when you feel stuck. If you need more clarification, ask. Its okay if you ask the same question twice because what’s important is that you understand and learn. Even better, ask your questions in the community streams. Leave it open so that you can receive different suggestions from various community members. It might open your mind up to new approaches to solving your problem. On the other hand, I am also [very] happy to help in case you have a question about this project or my experience in the internship. You can reach me on email at email@example.com or even in the community Zulip chat at @Aanyu Deborah Oduman. I would be happy to hear from you!
That said, good luck with your first contribution, and happy documenting! 🙂
This is the fifth weekly progress report of my Outreachy internship with Mixxx DJ.
I finished working on moving “deck cloning” to the cookbook chapter BUT this pull request raised the question about how it differs from the “DJing with Mixxx” chapter. It seems that there is sufficient overlap to merge the two….
I also finally finished moving all my past Outreachy blog posts to the website repo.
I couldn’t go ahead with moving “DJing with Mixxx” to the cookbook because I have to first figure out how the two chapters differ, and thus make the content differentiable. In any case, one of this week’s tasks is to clean up this same chapter. There is a lot of stuff mentioned in it and I received suggestions from some of the contributors to look at it with the eyes of a beginner. In other words, after the introduction, what are the most important aspects the manual should mention first, besides pointing to Preferences > Recording? What topics are most requested for by users? Can the sub-topics be re-ordered in that format?
I also helped finish up a pull request opened up by one of the applicants from the Outreachy contribution phase. It hadn’t been worked on in a long time and I thought I would help. It was about finding a reasonable order for chapters in 3.2. The Mixer Section. This pull request is yet to be reviewed. While working on this PR, I learned that even though you want to make a correction as little as a spelling mistake, you can’t push to other people’s repositories without them giving you write permission to their repo. 😊
This week I will focus on working on the two chapters “DJing with Mixxx” and the “Cookbook”. The cookbook is my major internship project – so I think this will be a constant for the entire internship 😄. I will pick up on another open issue to work on as well, and then record a video tutorial – for real this time.
This is the fourth of many weekly progress reports that I will be publishing for the duration of the Outreachy internship with Mixxx DJ.
Last week, I mentioned that I was working on the cookbook chapter. I opened a GitHub issue for it here . I moved documentation about deck cloning that I found in this article to a new chapter of the manual that I called the cookbook. I opened a pull request for it here . I still have a couple of requested changes to make on it before it can get merged. I’m thinking that will be this week.
I also mentioned in my previous blog post that I would be moving all my blog posts about my internship experience with Outreachy to the Mixxx website repository. I did that too. I opened a pull request for that here. Just like the first, I still have a lot of changes to make (as requested) before it can get merged. I’m happy that I get to contribute to not just the Mixxx manual, but the website as well.☺
Christmas day was on Friday. So I took some time off to spend with family from the 25th – 27th. I didn’t do a lot of work on these two and half days.
This week, I plan to finish up on the above two pull requests. And then move onto moving the chapter “DJing with Mixxx” to the cookbook. I planned to do this last week, but I didn’t get around to doing so.. This task will be moved to this week.
I also plan to get/ create more content that I can add to the cookbook chapter….
….and then pick an open GitHub issue that I can work on this week.
I am not making Mixxx video tutorials as often as I hoped to. I think it’s because I am spending more time improving the Mixxx manual and contributing to the website repo – which is also okay. But this week, I should try to deliver on those promises that I made about making better Getting Started videos.
This is the third of many weekly progress reports that I will be publishing for the duration of the internship with Mixxx DJ.
I made a pull request #327 in response to this issue . I moved the standard effects mapping documentation to section 11.5 of the manual.
Currently working on the cookbook chapter. I am moving documentation about deck cloning that I found in this article to a new chapter of the manual that I am calling the cookbook. I will then move onto moving the chapter “DJing with Mixxx” to the cookbook as well.
This week, I plan to move all my blog posts about my internship with Outreachy to the Mixxx website repository, and then if time allows, I will record another video tutorial about Mixxx DJ.
I also plan to work on this GitHub issue and make a PR for it this week.
I lost a couple of days to non-Mixxx/Outreachy related tasks. I had a slack week in general, in between finishing with University, submitting my project, moving out of my room, and then travelling home for the holidays – among other things. Because of this, I was not able to achieve all that I had planned to do this week. (see Week 2 – progress report). However, I do plan make up for it this week, and at the end of the [official] internship period.😉
I hate feeling stuck. Staring at your screen blankly, at the verge of ripping your hair out because you have exhausted all the possible solutions and none of them has worked. It makes me second guess myself, what I know, how I got here, the education that I got and all of the things that have led me to this career path. I have been in this position many times before and yet each time, the feelings of self-doubt are as fresh as the first time that I encountered a bug in my code (it was HTML by the way). I was in this position last week, and I have to admit, its not a good feeling.
It’s not that I did not know how to approach the task at hand. I did, but perhaps, git had other plans that day. So what happened is that I hadn’t pulled the latest changes from the upstream branch in a very long time and by then, a lot had changed; the branches had been renamed (from manual-2.3.x to just 2.3, and manual-2.2.x to 2.2, and so on), new sections and content had been added by some of the Outreachy applicants during the contribution phase.
I needed my work to be updated I did the usual git pull and I thought everything was fine. I usually never break a sweat when working with version control because I have been using git for the longest time – I think it’s coming to four years now. I created another branch from the manual-2.3.x branch (remember it had been renamed) and I started working. I finished making edits, committed, pushed and sat back as my code got tested on GitHub. My problems began when my code failed all of the checks on GitHub. In my head, I was like, “Wait, what?”
I was shocked because my code wasn’t even passing the basic RST syntax check. I began to panic. I got the feeling that I had not pulled the latest work from the upstream even though I had run “git pull”. Maybe I did, but perhaps I didn’t do it the right way. So many thoughts were running through my mind at this moment.
Panicked, I began to run a myriad of Git commands.
In doing so, I was required to fix merge conflicts. Now we all know how badly this can go. You could easily push outdated work and set everybody ten steps back. Or you could easily commit completely wrong work – work that has been deleted or moved. I tried to avoid fixing merge conflicts as much as I could, but in trying to do so, I made things worse, and I was not making any progress. When I finally got the guts to fix the merge conflicts, my commits were actively trying to disorganise progress in the upstream. Git revert wasn’t even enough to reverse the mess that I had pushed.
Aimen Batool was right. It hurts when you don’t know how to resolve merge conflicts. You spend hours finding the solution to a problem and then you end up losing your code in an attempt to fix the merge conflict.
I looked for solutions from Stack Overflow, freeCodeCamp blogs, Medium blogs, closed GitHub issues, and run them in my command line but none of them was working for me. I got to a point where Google kept returning me the same search results, the same Stack Overflow solutions and that’s when I realised I was going in circles. I was not achieving anything. I thought that I had missed something the first time, so the second time (and many after that) I would squint at my screen looking through the same solutions with a more critical eye but nothing! I checked the code of the branch into which I was trying to merge on GitHub, and compared it with mine. I realised that the work in my repo was quite outdated and for some reason, my local repo was refusing to sync with the upstream.
By this time, I had run too many git commands in my git bash, therefore, in this process of trial and error, I couldn’t tell what had or hadn’t changed in my repo. I had spent over nine hours on the internet searching for solutions and suggestions by people who had come across a similar issue. I was tired, discouraged and all out of options. I heavily pondered on whether I should just come out and ask some of the contributors from the Mixxx community for help. For lack of a better option, this is exactly what I did. I explained the errors that I was getting and how I got there. They understood what the problem was and guided me on what to do. One of the things they told me to do was rebase on my branch, so I thought “okay….”. I had never rebased on a branch before so I looked up what it meant. I read a blog about it and after I had understood the concept, I told myself, I got it. I got it. I run a couple of other git commands and things looked like they would work out after all. I was happy. And then….
I got to building. sphinx-build generates documentation from the files in <sourcedir> and places it in the <outputdir>. It will create documentation in different formats whereby a format is selected by specifying the builder name on the command line – the default is HTML. So when I ran this command, I got extension errors. Could not import extension xxx (exception: No module named 'xxx')
I reached out again about this error and one of the contributors suggested that I install some build dependencies and build inside a python virtual environment. Again, huge relief! I do everything as told and then build. At this point, I’m pretty confident that things will work out this time.
The darned extension errors came back again. At this point, I just wanted to crawl under a blanket and scream. I am thinking “What is everyone going to think if I go back and ask about yet ANOTHER error?” “What if they think that I’m not good enough?” “What if they finally see me for the fraud that I am?” (not that I am a fraud) “What if they start to wonder how I even landed this internship?” “What if my mentors get tired of my endless questions?” “What if the questions never end?”
As hard as it was, I forced myself to ignore all these fears and just asked. Again. By then, this conversation with my mentors was happening under a GitHub issue and the thread had gotten too long. One of them then suggests that I should open a new topic in the community development help stream on Zulip so that the discussion on GitHub didn’t go too off-topic. So I move the discussion there and the community starts helping me debug. In my heart, I knew that nobody in the community would think less of me for asking about an error because, well, this is part of the reason for why the community exists in the first place – to help fellow Mixxx users find solutions to the various problems they are facing while using Mixxx. Even with this knowledge in mind, I was scared and felt small.
So the discussion in the community forum is going on very well, and I’m getting replies in not more than 10 seconds. I was pleasantly surprised by the community’s willingness to help with this (little) error. And then just as I was getting comfortable, one of the community members suggested that I run pip install sphinxcontrib-svg2pdfconverter. I was thinking “It can’t be that easy” when I got returned Successfully installed sphinxcontrib-svg2pdfconverter-1.1.0 . So I ran sphinx build one more time and it was successful! I couldn’t believe it took them all of two seconds (okay not two seconds, but it was really short time) to know exactly what was wrong with my code and provide me with the correct solution. It worked! I laughed.
I laughed at how simple the solution was even though I never would have guessed that that was it all along. I laughed at how long it took me to get here (it was a little over 9 hours) – to finally get the guts to ask somebody for help. I laughed because if I had just asked for help the minute I got stuck, who knows how many GitHub pull requests I would have created by now (not that many, but still…). I just laughed and shook my head. All my inhibitions seemed silly now, like, what did I think would happen, spontaneous combustion from embarrassment?!
So, moving on, I was able to build and preview my work before committing and everything looked good. I went ahead and created a pull request for this issue, feeling relief to my toes. I watch as the tests on Github run my code and then my heart dropped.
Again?! These errors just keep on giving, huh? This time I wasn’t going to panic. I told myself that I had been given all the resources that I needed to solve this, and if all failed, I would not waste time. I would reach out to somebody for help.
I decided to start afresh, on a completely new page. I created a new branch, made another pull request for the same issue, this time paying extra attention to the branch tree. Everything went smoothly and the checks passed (except for one) but I had been told before that that particular test was nothing to worry about. The joy!
So through this experience, I was able to learn new concepts in git merging, committing, rebasing, and resolving merge conflicts. But besides that, here are a few key things that this experience has taught me.
Firstly, we have to learn to ask for help when we need it, even when it seems like the hardest thing to do. Despite what you think people will think about you when you ask for help, the fact is, asking for help will get you to where you want in way less time than repeatedly trying the same solutions that aren’t working or remaining seated and feeling dejected. We have to be humble enough to acknowledge that indeed things aren’t working and then make the effort to try to reach out to somebody for help.
Secondly, it’s always good to ask for help but before you do, please, do your research.
Try to ensure that you have exhausted all the resources at your disposal so that by the time you ask, you are better informed about all the alternative methods you could have used, but didn’t for justifiable reasons. You will not feel completely clueless when asked if you’ve tried a certain solution because you know that you tried it, and it didn’t work or that if you had tried it, it wouldn’t work for reasons A, B, C and D. I believe mentors feel more enthusiastic to provide all the help that an intern needs if they see that the intern has put in the effort to look for a solution to the problem and they did it exhaustively.
Thirdly. In Syeda Aimen Batool’s words (who also got the suggestion from Sarah), “Do not take things personally and focus on learning”. I read this in his article just the other day and I feel like this piece of advice resonated with me. He said that it can be 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. The most important thing is to focus on the main points and have a learning attitude. We won’t be able to learn new concepts and good coding practices unless we put all our ego aside and focus on learning from the experience and knowledge of others.
And finally, it’s important to remember that everybody struggles. Every pro dev started somewhere. They all faced some pretty difficult bugs and blockers but this is exactly how they became the senior developers that they are today. It’s all part of the journey. Once we understand that it is completely normal to get stuck, then we can normalize asking for help when we need it.
I made my first YouTube Mixxx tutorial titled “Getting Started”. I posted the video in the chat, and got feedback from some of the other contributors. I plan to record another video, and make some adjustments this time (based on the feedback that I got from the first.)
I lost a day of work to correcting git errors while making the pull request #322.
I lost a day or two as well to re-recording the video tutorial and editing. I had recorded my voice and my computer screen at the same time, but that wasn’t working out too well. I later on decided to record my screen and voice separately and then merge the two in the final video.
Currently working on https://github.com/mixxxdj/manual/issues/157 – which is documenting the Rekordbox library import. I had run into a slight problem with pulling the latest changes made by (@hannydevelop) on “Using the Serato library” but @Holzhaus helped me finally figure it out. It took me longer than I expected but I hope to have made a PR for this issue by the end of today.
I have also been working on my first video tutorial on “Getting started with Mixxx”. The plan is to make it then share the link in the chat so that I can get feedback, before I make the final. This is my first time making a YouTube tutorial, so it’s taking me a little bit of time. I wanted to record my voice as I made the tutorial but I faced some difficulty doing both at the same time (focusing on the script and my actions at the same time). So I have decided to try making the video first, then recording my voice in the video after.
Lost a day of work (maybe two) to the last two issues.
I’m thinking of a proper way to start working on the cookbook. I will need to consult on this – whether it should be in GitHub pages, a GitHub repo with .rst files (like the manual) or….. a simple website or…. something else.
My name is Deborah Aanyu from Uganda. I am 23 years old. I come from a family of five children – I am the eldest. I have been in Catholic (single sex) school for most of my education, and it was during this time that I got to appreciate the beauty of God in the world, and in my life. I was in mixed school for only two years, up until University. As an adventurous person, I like to try out a lot of things; from art and painting, to singing, writing, sports (basketball), web development, among other things.
I am generally optimistic and believe the good in people. I like to read and write. I like to dream, talk, listen and see the sunrise in the morning. I like to see the moonlight at night and feel the rain on my face. I like flowers. I like delicious food and comfortable shoes. I like warm clothes and a nice cup of tea. I also love babies, nature and laughter. I love food and listening to music.
I have been studying a Computer Engineering degree at Makerere University, Kampala for the last four years, and I finished my final examinations just recently. So I’ve been really excited about getting done with school and having the time to focus on what I really want to do which is software development and contributing to Open source!!
I will be working on improving Mixxx DJ’s user manual for the Outreachy Internship. Mixxx DJ is an Open Source application for DJs that gives them the power to mix songs for free. Each day that I wake up, I am so grateful for the opportunities that I am given, and looking at how I got here, I can’t help but feel enthusiastic for the journey ahead, bumps and all! I’m here for all of it.
My top three core values.
Honesty. Respect. Adventure.
As a young teen, I was very shy – bordering on fearful. I feared everybody including my own parents. I feared to do the wrong thing because I wanted to be in everybody’s good books. I needed the approval of my friends, family and everybody who cared about me. Because of this, I was telling lies all the time. I was turning into a diabolical liar! I didn’t even lie because I had anything to hide. I lied so that I could tell only the best version of events. I lied to avoid attracting too much attention to myself. I lied to make people happy. I lied because I was fearful of the consequences, even if my actions were not wrong.
Eventually, I got caught. I saw how my lies were affecting the people around me and my father asked, “why do you lie so much?” and I had no real reason, except for my low self esteem. So it wouldn’t be enough to just stop lying (if it was that easy), but I had to work on my self-image, how I felt about about myself in relation to the people around me. One of the hardest things I had to practice at the time, was telling the [hard] truth, however terrible I thought it was. I discovered that people would rather be told the harsh, disappointing, heart-wrenching (lol) truth, than be deceived with words you think they would rather hear. I found that I would rather deal with the immediate, but brief disappointment that comes with telling the truth, as opposed to the hurtful or pained expressions on their faces when they found out about the lie. I practiced this everyday, even though some days were harder than others, but it got easy. Eventually, the truth became the easier, most obvious option. I didn’t have to think twice about it anymore and concoct stories. A huge burden is lifted off my shoulders every time I tell the truth in a difficult situation, because I know it would probably be easier to lie. I did not lie, and the world didn’t cave in.
It is because of this phase in my life that I appreciate honesty so much more. I appreciate it more because I know sometimes the truth can be very difficult, and it is not always easy to say. I appreciate honesty because it comes with no burden, and it leaves you free from guilt – of hurting others or causing even more damage. I value honesty because I have seen first hand how badly it can affect relationships with loved ones, how it can end a marriage and a life long friendship. Honesty is a core value for me because it has saved me from a lot of things and I can only imagine how my life would have been if I had been transparent from the start.
Respect has been a core value in my family for ages. Sometimes its easy to take what we have for granted and forget that there are people who do not have half as much. We make friends, and build relationships with people from different backgrounds with different stories. Along the way, we get to peek into other people’s worlds and see how things are done there. It can be easy to judge other people for the way they do certain things just because they do them differently than what you’re used to. And often times, this judgement can reflect in our actions and facial expressions, which might not be very respectful.
I believe that part of respecting other people in society is believing that we were all created differently and there is no singular way to get anything done.. I also believe that however learned we might be, there is always a thing or two we can learn from the people that we meet everyday. When we respect people, then we might be humble enough to learn from their experiences and add to ourselves one way or another. We all have different personalities, beliefs and values. We don’t always have to understand other people’s routines, cultures, beliefs and likes, but we can learn to accept that they are different than what our brains have accepted as the norm and that is okay. We are all human, we bleed the same, and we shall cease to exist some day. We all have that in common.
I truly believe everybody deserves to make the most of their time on earth! We only get one life, don’t waste it. Try new things, go to new places and meet new people! Adventure can be applied to every aspect of our lives, from the food we eat, to the clothes we wear, to the music we listen to it. You don’t need much to try something new – just an open mind! However, I do respect that some people might prefer to have a routine and live by it every single day. When we are willing to get out of our comfort zone and try something new, we learn a little bit more about ourselves. If you try out chocolate ice cream for the first time and you don’t like it, then at least you know for sure that you don’t like it! You’ve learned something new about yourself!
With an adventurous mindset, one is open to learning new things. One is willing to gain new information and accept that there could be better out there in the world. With adventure, we open our minds to new knowledge and become more willing to adjust to new changes and environments. Adaptability becomes ingrained in us.
My motivation for applying for Outreachy.
So my friend Jordan Rob, and I, are self-taught developers. Everything we know, we got off Stack Overflow or YouTube (lol). We have shared a number difficulties in trying to be better developers with each passing day. With this in common, we promised to always lift each other up and encourage each other to take up new opportunities. We promised that we would not get comfortable and we would always strive to get better at what we do.
So on a random day in August, Jordan tagged me in this tweet and simply said “let’s apply”. And I replied “kawa” meaning ‘okay’. I replied in a casual manner after finding out how competitive the application process was. Jordan and I probably shared the same thought. “Do we even stand a chance?”.
What Jordan and I have in common is that we are both passionate about software development and if we come across any opportunities for growth in the tech sector, we will always look into them. Jordan and I have had similar struggles both personally and professionally, and hence we kind of look out for each other in this particular field.
However, one of my setbacks was that I had a slight case of the imposter syndrome (a psychological pattern in which an individual doubts their skills, talents or accomplishments and has a persistent internalized fear of being exposed as a “fraud”). I was constantly thinking to myself that I needed to be a little bit better before applying for any job or internship. And so I found myself stuck in a cycle of tutorials, learning more and more and never really using the knowledge to contribute to any real life applications.
Before the start of this year, I did not know the meaning of ‘Open Source’. I had always thought that it was a fancy term for very-hard-to-code software. I had googled the term before, but the search results always brought up some blog posts (that I found quite intimidating) about “How to get started on your first contribution”, that I could not really relate with. So my friend Jordan Rob tags me, and I ask rather sternly what Open Source is really all about. And he breaks it down for me bit by bit.
Once I discovered that I could contribute to software applications that people use everyday, in a major way, my excitement grew! I did some research and found that I, too, could contribute to repositories of some of the most common and widely used software applications. I was happy because my fraudulent feeling was wrong! I didn’t have to be an absolute pro at code to contribute because there were other significant ways that I could do so! Through documentation, graphics and editing, video making, audio recording among several other ways. So when the Outreachy internship opportunity came along, I grabbed it with both hands!
But my motivation for applying for the Outreachy internship does not end here. I had always yearned for a chance to work on a project that I was really passionate about together with a group of really talented developers from whom I could learn a lot and come out of there several times better than I started. I have a strong will to gain technical expertise and use the knowledge to make people’s lives better. I was motivated by the thought that if I actively contributed to an open source project that people actively used, I would benefit from the transparency of collaboration and would be able to evaluate the risks associated with required features or bug fixes more precisely. Moreover, I could actively shape the roadmap (by contributing) or at least influence its prioritization. How cool is that?!