DEV Community: Dipti Gautam

Useful (Doom) Emacs Commands/Shortcuts

Dipti Gautam — Thu, 07 Jul 2022 13:46:52 +0000

Hi!
This is a note to self sort of an ongoing post that I'll keep adding emacs shortcuts I come across to.

I use doom emacs in evil mode. So it might or might not be useful to you depending on your configuration. I'm new to emacs myself, but this has been an exciting journey, and I'm looking forward to making the most of it!

Disclaimer: I might include the more uncommon commands here than the ones I use in my regular workflow because of the muscle memory, whereas some might be too obvious for the same reason that it's new to me. So be prepared for a weird jumble ahead!

Enjoy:

markdown-cleanup-list-numbers: reorders the numbering in your file if they've been messed up somehow.
set-background-color: (and color selection) to choose a background for your frame. I actually got there by mistake but I like the ultra-dark mode the black background provides, so it's there to stay!

Building communities and conducting virtual events amidst the pandemic

Dipti Gautam — Sun, 31 Jan 2021 19:12:26 +0000

I am a software engineer by job, and I am involved in lots of communities around both tech and non-tech fields, locally as well as globally. I love being a part of them, and it gives me a place to socialize and vent when I need to, as I’m not particularly an outgoing person by myself. (Although I’m pretty sure that’s going to change post pandemic.) And that has especially been true during the pandemic.

That is even stronger in my case because I took a full-time remote job almost a year ago before the pandemic even began. My undergraduate was coming to an end, and my fellowship program with Women Leaders in Technology, an amazing community who I attribute much of my recent growth to, had ended a few months earlier. This only meant one thing. I was about to distance myself from everyone as much as I was excited about my new job, and as much of a bliss it brought to me. No, don’t get me wrong, I absolutely love my job and more so the fact that it’s full-time remote, commuting in the busy hours of Kathmandu in a packed micro-bus tripped every point of my anxiety, and I hitchhiked for the most of my six-month internship. Things couldn’t have been better for me.

But the loneliness aspect of it had to be checked too. I was about to go from having somewhat of an okay social life to nothing at all. While I did have lots of fun activities planned to make it as exciting as it could be (spoiler alert: I love planning!), one of my dearest friends, namesake and coworker at the time came to my rescue by pushing me to join a community she had just been a part of. I did kind of like the work it was doing too. I had seen it in the social media, and they were covering stories of powerful representations of Nepali women in tech in their monthly medium articles. I had also met the founder during an event, and had been instantly inspired. Plus someone I looked up to from afar but had never really met in real life was also part of the team, what was not to join? So I gave in.

News flash: not one month into my job, the pandemic started in full-blown panic mode. All the “fun activities” I had planned were out of question, and I was quarantined with no peers around. Thankfully, I had kept one outlet open for me by joining the said community. Since then, I’ve been talking to the community members at least once a month and have done lots of fun as well as educational things, and frankly, life in the pandemic without it would be unimaginable. Well, I have had my books and have been practically burrowing myself in them too, but sometimes, you just need to hear yourself speak. And even that can be as good as therapy.

Today I am the president of the same community, Nepali Women in Computing, and we’ve been conducting more activities since. A minority was harassed in social media as well as real life in our community, so that became the fury of our conversation in several meetings and most of our team had been enraged, so we decided to start an “Educate” series - where we go outside of tech and address the social issues that we collectively want to voice our opinions on and bring in experts from the fields to educate the community. So far, we’ve conducted two sessions, and it happens every month. More on NWiC Educate can be found here.

We also started a monthly book club this year, and we had our very first one yesterday, where we discussed the book “We should all be feminists” by Chimamanda Ngozi Adichie. It was a pretty short read but a powerful one, and we realized that the way a Nigerian and a Nepali society treats women is more common than you’d think. The feminist tag is supposed to be an insult and isn't something that signifies that we want equality. All of us had a lot of personal experiences to relate to and to vent about, and we busted a lot of things that society makes women do and oppresses them in the name of “culture”. We talked about how we unlearned it in the process of growing up, how we rebelled against these, and ended in the positive note that our generation will definitely do better and won’t even let the next generation feel the differences between the different genders.

We also conducted a pretty big event (for us) this month. I mostly overlooked the event, so I’d like to talk a bit more about it here. It was a three-week event on Open Source Contribution with each week containing speaker sessions, introductory workshops, and hands-on contributions. The urge to do this was born back in September when we were contemplating doing a Hacktoberfest event from our side as NWiC. But on further thinking, I gathered that there aren’t many women contributing to open source (at least the ones known within our community), and we didn’t even have any role models on the same. And NWiC had a pretty big audience and was in the position that it could actually make an impact if we decided to conduct any. So we decided that the best way to go forward would be to do something impactful by utilising our connections and reach rather than do a mere event on the Digital Ocean’s wing. (We’d still like to be able to host hacktoberfest events in the future, but we just felt the need to prepare our community for it first).

So we began discussing the options and instantly found 6-7 people in our connections, a majority of which were both women, and in commendable positions in open source as well as the tech industry, and decided that we’d just make their stories heard directly among our audience, and help spark the open source spirit. Inspired by GHC, we also wanted to have the participants contribute to actual projects in the end, so we decided to do it in two weeks. But then we feared that not all of them may have the technical skills necessary, so took it a notch forward and snuck in the workshops in the middle. Hence the three-part result.

Even though it was conceptualized around October itself, I had a lot on my plate till November end, so we decided we’d do it, but put it off to actually move forward with anything until December, and that’s when we finally set the dates, started confirming the speakers we’d initially reached out to, and publicizing them on social media. Our audience received it well, we had over 70 signups within two weeks. It was a huge deal for us. Of course, the turnaround was way smaller as you know is with any event, it was a good start.

Still, the speaker sessions had a good audience and even though we had a few bumps with technical difficulties, our speakers stole the show. We learned a great deal of things through their experiences. The number of audience decreased gradually over the next weeks, but we had a handful of recurring participants, and to them we were grateful, and we were making an impact, so we kept going. The second week went much better than expected with the workshops as they were engaging and the audience kept showing interest. The third week however, was supposed to be the contributions, so our audience was barely there. I was about to start a project that I was planning on making open-source, so I just used a bare-bones version of it to keep the audience engaged, and showed a demo. And while they followed along the technical aspects of it, and had a good participation in the beginning, the audience fell silent when it was time to contribute. It was understandable too, we were doing a virtual event within a pandemic afterall. I don’t think I’d have volunteered if I was in the audience unless I really really wanted to either. So we ended the session with no hard feelings with a channel to stay connected and take it forward from there should there be an interest later on, and we wrapped the three weeks up.

I would say the event was a good start for us as a community to set our foot on, but we had a great amount of shortcomings, and had a lot to learn.

Firstly, we had speakers from multiple time zones, so in the process of accommodating that, we forgot to accommodate the US time zone, where most of our members (who were really looking forward to it) were based in.

Then we took on too much responsibility on our hands. We didn’t have a lot of experience, and the two of us who were leading it had both full time jobs and the other member who was helping us was fairly new to the community and had university and other engagements.
We were both delivering workshops as well as overseeing the whole program. We had speaker sessions in later weeks as well to accommodate those who couldn’t join us on the designated week, so we were constantly torn between communications, actual execution, preparing our talk, delivering our sessions, and a lot of miniscule things we may have overlooked. Even though there weren’t a lot of things, there was still lots of pressure building up, hence led us to being burned out and procrastinating things till the last minute.

And then, I now feel that our last two weeks that we added with much enthusiasm during the planning process, were quite unnecessary. We didn’t plan well. Had it been an in-person event, these would have been impactful and had full participation, and we could make sure that our audience was actually engaged and learning something. But it was a bit trying to conduct interactive sessions and making sure that they were following along with you. I think it took a bit more toll on our mental health and time than it had the impact.
And if I may be so bold, I suppose it was the same for our participants. They also mostly had full time jobs or online classes, so sneaking in workshops wasn’t a particularly wise decision.

We could instead have reached out to more speakers whose stories we could have brought forth and inspired the participants with. And I’m pretty sure I could have delivered my workshop much better if it had been in person or if I was just focusing on the talk and not the entire three-week event.

But so as not to make it as depressing, we decided to end it on a positive note by accepting a few things and making notes of what went well! I’d like to end it in that note:

We conducted our very first technical event (series) as a community, that in itself is a big win!
Our internal communications coordinator, Rashika, learned how to use mailchimp and send mass emails.
Sarayu moderated the second and third weeks of the events graciously despite being not even a month into the team!
I gave my first ever workshop on Clojure, which I currently work in!
I got a chance to connect with so many speakers I wouldn’t otherwise have come across with.
And I finally gave a rough start to the project Open Encyclopedia, which I was hoping to start in 2021!
Most importantly, we realized that it’s still the pandemic, and things are going rough for everyone. We should focus on growing as a community and making it something to lean on rather than a work we have to do.

Of course, there were other things that we learned too, but these are some notable achievements, and even if it wasn’t what we’d have liked it to be, it’s been a great stepping stone for the things to come next, and it also in some ways, showed ourselves our limits! And personally, for me, it also made me realize that I haven’t taken a break at all this year, so I’m finally taking one in February, and will be going on about making a 2021 a relaxed but fruitful year for both me and my community from March. :)

What it means for you and your team to be going remote-first?

Dipti Gautam — Sat, 11 Jul 2020 16:38:25 +0000

The world is getting digital, and programmers and technologists are at the center of it. A lot of institutions are moving online, and companies who insisted on their employees with disabilities to be required to present themselves into the office are now talking about going remote-first and the possibility of continuing the same in the Post-Covid world. At the same time, companies are suffering because of the lack of a proper handbook for conducting their practices remotely, and a communication and delegation gap within their organizations. Not a lot of good things are happening, I know. And it’s okay, we’re surviving through a pandemic. But I’m not here to talk about that. I just wanted to give a brief overview of how companies that are remote-first generally behave.

I, actually, am here to talk about how there have already been hundreds, even thousands of companies globally that had already been working remotely with a distributed team for years now. And, I am fortunate to have been working at one of them. So this article is going to be about how things work in a remote-first company and what it means for the team members. And I’m saying this in the context of a world without this pandemic and lockdown, one, where you are free to travel where you want. And one where you can look at your same old laptop screen from a coffee shop, but with a good coffee and ambience, and a bit of life. (I’m sorry, I just miss Karma Coffee a bit too much at the moment.)

A brief introduction about me and the company, first. I’m almost a Computer Science Graduate, (I say almost, because my final semester results and internship defenses had been postponed indefinitely because of the pandemic, which seems to be ending soon now), currently working remotely full-time as a developer at Magnet.
Magnet is a digital solutions provider for companies in Spain. It has a global and distributed team, with offices in Spain and Poland, and team members working remotely from Mexico and Nepal (yes, yours truly!).

How did I get into Magnet? And how did I get onboarded remotely from halfway across the world? I guess, our favorite remote-working tools, great communication, and welcoming environment at Magnet takes the credit on that one! I found Magnet on Twitter, and reached out to them asking if they would be interested in working with me remotely, then we had a call, and we came to an agreement! After that, I picked a date for starting, got an invitation for working across all of the company's collaboration tools and services, and started on the said date!

Now, I know you wouldn’t want to hear about the gory details of what language and frameworks I used, what bugs I encountered, how I solved them (after hours of debugging and knowing it was a parentheses mismatch, which is most probably always the case with Clojure, or a docker-compose restart). Oops, did I already say that? Well, anyway, the first week was mostly about getting welcomed, learning the language, reading documentation, setting up the environment, and the likes! And what followed was a lot of pair programming sessions to get familiar and comfortable enough with the tech stack to the point where I could start working independently!

It may not even sound all that realistic when I sum it all that way, but you’ll know when I tell you the ways of Magnet that made it seem not too hard for me, and frankly, I feel a physical office would be way more difficult, and remote work is way more efficient.
So tech companies across the world, if you’re looking for a full shift to remote work, then I believe the following guidelines that we follow at Magnet could be handy for you:

Tools: Use the right tools: Zulip and Zoom are basically what are gluing us together. Zulip is for asynchronous communication, and Zoom for when we need to have it synchronously. We sometimes use Google Meet and Jitsi Meet as well.
And for communication with the client, we are in the client’s Discord server, where everyone working on the project is present, so we all have the communication first-hand.
And well, not to mention Docker and AWS for our development, test and production environments.
Communication: Dedicate channels according to your purpose. Have one just for the notifications, say “Good morning” when you log in, and “Goodbye” when you sign off for the day. Let this one take care of anything else that you need to broadcast to the team.
And proceed to create individual channels for the project, and then sub-channels for the areas within those projects.
Remember, organizing is the key. The more your channels are organized, the more your team members feel welcome to communicate. Because how else would they put their message forward if everything is all messed up, and anything they want to say might feel like they’re going off-topic even if it’s necessary? And, keep creating channels on the go. Don’t hesitate on that one.
And of course, don’t forget to include one to just share memes and random chit chat!
Establish Culture: At Magnet, we follow the rules mentioned in “Communication” regardless of whether the team is working from the office, or remotely. And personally, I think this is the key to being remote first. You do the same things that your remote team members are doing, it establishes a culture, and is easy for the new member to get used to the company’s ways of doing things.
Bi-weekly Learning Sessions and Book Clubs: Get together with the team. The whole team, every Friday. It keeps the team connected while not making the developers feel like they’re getting sucked up in too much meeting time. However, don’t just have them for the sake of doing it. Have an agenda.
For example, at Magnet, we have book-clubs and learning sessions alternately every Friday. Book clubs are about discussions from a chapter and brainstorming what could be done on the existing processes after the new learnings from the book; and learning sessions are when someone from the team teaches something new to the rest.
Save a few minutes in the end to make sure if someone needs to rant about a bug that just wouldn’t go away, or hear someone out if they want to say how badly they need the weekend. Share your plans if you have any. (Of course, it’s not mandatory).
Automate wherever possible: You probably saw it coming, didn’t you? I mean, how else would a blog about a tech company working (remote or not) be complete without adding a word or two without automation? Well, at Magnet, we have a bootstrapped project that we use everywhere, set the configurations, run a script, and BAM, there it is, a perfectly good new project waiting for us, just like every other we’d have already worked on! Besides that, our Bitbucket pipelines are prepared directly to deploy into the test environment once the builds are successful, and we use Git hooks with linting and eastwood so we are only able to commit once the builds pass locally, so as not to fail the pipelines. And yes, we push directly to the trunk.
Try following this, and it might as well take care of the numerous PRs for you. Also, while you’re at it, have a handbook that the team can refer to, so that you spend less time repeating the same procedure over and over again.
Value ownership over tracking: Get rid of “sprints”. They only take time, suck up the life from your developers, and give both you and your team an unnecessary headache with an ever-dangling deadline. Talk to your clients instead. Know what they actually want. Involve your team in the process. Have them take the ownership of it. Trust them to do the work, and they’ll deliver. I know that from having witnessed it firsthand, and I know it works. And not to mention how confident I have grown in taking ownership of tasks, and making my own judgement on how to make the code more efficient and take users and scalability in mind from this same practice.
Flexibility: If you’re opening your minds about getting all-remote, it’s also time to think about getting more flexible with the hours. Don’t expect everyone to show up 9-5, although still keep that as ideal. Since the team is already working remotely, there isn’t really going to be a toll on productivity if they have to run to make a doctor’s appointment or that friend’s wedding or even help their family out with something during their work hours and decide to work it out during the evening or the weekends. Have faith.

And, that’s it! That’s the secret sauce. Follow all this, and you would already be thriving with all your team members having a sound mental health, increased productivity, increased communication, set work hours and boundaries, and a great work-life balance! Not too hard, is it? Now, I know you’ll sometimes have FOMO from not being able to brag about your all-night binge watching and still being able to come to the office at 9 AM, but then again, you don’t have to ditch the office! Go slow. Make remote working a valid alternative, don’t make your team members come to the office no matter what, but don’t completely ban them from coming in, either. See what works best for you. And well, for what it’s worth, you could actually use that opportunity to hire someone that’s not privileged enough to live in the same place as you do. I’m sure there are a lot of talented people out there, waiting for such an opportunity. Be that gem of a company who starts this culture!

CEOs and executives, you can stop reading here if you want. Aspiring remote workers, keep reading, what’s coming next might be useful for you.
Whatever I mentioned before has been about what we do at Magnet to make the remote work work, and what you should be doing if you’re looking to set foot with your organization on the same. However, there are a few things that I want to mention that I have experienced personally, and what I think anyone working remotely for the first time might feel.

As for starters, it’s easy to feel like an outsider while also feeling extremely like you’re already blended into the team. I mean, it’s hard to explain, and you can feel both at a time. And I don’t quite know if I’m over that yet, but I sure am down a lot from feeling that way. And I guess, it’s because of never having met the team in person, but at the same time, you communicate on an everyday basis, and see them and talk to them almost everyday. So, take your time I’d say.

And then, there’s this good old getting trapped in tutorial hell and feeling guilty about having spent the time to learn something. It also applies for when you spend a lot of time on the same problem, and start feeling like you’re not doing enough, not pushing the code frequently enough to have been delivering enough. And as if you can in no way show that you’re still there, working, trying to make your way through this bug that just doesn’t go away.
It’s easy to feel nervous, and that’s okay. I don’t really have a concrete solution for this, but setting boundaries over how much time you allocate on a certain task helps to a great extent.
I use this Pomodoro timer extension on Chrome, that allows you to set your ideal work time and break time (and also custom block the sites you aren’t supposed to be using), and to me, it seems to have improved things a lot. But remember to experiment with the pomodoro work-break timings, because it takes a lot of hit-and-trials to figure out what’s best for your attention span. (For me, it’s currently at 50-8).

It’s natural to feel like you’re asking too many questions. I know when you’re new to the team, there would be a lot of questions, and a lot of things you’d be asking repeatedly. Especially when you’re a new developer, there are going to be a lot of processes, from setting up your dev environment to learning the syntax to maintaining uniformity everywhere, there are a lot of steps involved, and together come the same proportion of questions. But it’s okay to take help from the team and just ask it.
Although it’s easier said than done, I wish I’d take my own advice on this. It’s pretty easy to get sucked up on this particular thing sometimes, and today itself, I spent three hours reading documentation, comparing line by line of code in multiple projects, checking every stackoverflow and reddit threads on an issue, only to find out I had missed initializing a value at one point, which got resolved in less than two minutes by pairing with someone else. So you know, bottom line, do all this, but also, don’t hesitate to ask for help!

Create your own handbook. This particular thing is really helpful if you’re a shy kind and really refrain from doing what I said in the previous point. In software development, there will be a lot of tasks and processes that you will keep revisiting in the months to come, and frankly, you will keep forgetting. Because there are way too many of these things to remember. So each time you come across an important command, or figure out a pattern, just open that text editor and note it down. Your future self is going to thank you.

Now this one’s pretty common. Segregate your workspace. I know this is on every article about remote working, but it’s there because it’s a particularly important one. You don’t know what a wonder it does in helping you enjoy your post-work hours. (I say this as I suck at turning my work mode off, and stay here till it’s way past midnight. But the truth is, I don’t have much of a life anyway.) But seriously though, do it.
If possible, don’t work in your bedroom. It helps you to enjoy the off-hours much better and you are well rested. Don’t snack mindlessly when it isn’t a lunch break either. Trust me, you’d want to follow my advice on that one if you don’t want to be feeling like Penny on one of The Big Bang Theory episodes where she says “Oh my god, I need help”. Do you want to be that Penny? Do you? Now, stop snacking.

And last but not the least, Please Shower! I know you aren’t going anywhere, but also, look at that sentence from a different perspective. You haven’t been out in days! How do you think you are going to stay fresh for work? So please shower before work every morning so you are in the right headspace to kickoff your workday. You can also set it as a routine so you know that when you’re getting ready for shower, you’re leaving your free morning behind, and are entering the work zone. If you’re anything like me, this buffer period actually does wonders!

Now I know that’s a lot to digest and might as well feel a bit overwhelming as you go through all this, but remote working has way more perks than these mere ground rules, you know. No worrying about traffic, muddy roads, and the best part? You get to wish for rain and enjoy it from your window while playing your favorite playlist out loud, sipping your own masala tea, and working in peace. Sounds like the dream, doesn’t it?

And, I’m not sure if you have this, but I get kind of anxious when I have to get out of my home early in the morning, and seriously, I was dreading how I would manage to commute to work every single morning and reach there on time and work for a full day and get back home. Looks like the universe makes up for it all. ;) I seriously have to make up my mind about going out for days, wake up an hour early and stare into the wall, scroll mindlessly on my phone, or watch three episodes of F.R.I.E.N.D.S. back to back all the while worrying about getting late if I am to step my foot out. And trust me, I’m not kidding.

Besides, since I’m a late riser and also work on the European timezone, I have the added benefit of getting to start work past noon. That means, even if I somehow manage to stay up all night binging on something I wasn’t supposed to be doing, I can still sleep for six hours and take a shower and get all freshened up for work!
(No, silly. Of course, I wouldn’t do that! I’m not that deranged, okay? Oh wait, maybe I am. Nah, I’m better than that. sobs in the corner)

Coming to the end, I guess it all comes down to what kind of a person you are, and what activities you would want your day to be filled with to decide whether or not remote work is a good fit for you. I’m not a big fan of having to step out of my home every morning at 8 AM, you might like it. I’m okay with not having a real conversation face to face with people for days, even months, whereas you might crave social interaction. I feel at peace from remote work and it helps a lot with my anxiety, whereas it might be the other way around for you; by being by yourself for a long time. I know, it’s not all that black and white and easy to figure. But then again, even with all the reasons that I’m saying that I love remote work, it again differs with the kind of company you are working with, and the kind of people that you have in your team. And of course, how your values and goals align with those, and how well you can feel yourself at home even with a remote company. Because well, not everyone might be as lucky as me. And not every company might have a good remote-first protocol as mine.
But then again, we are all learning. And I believe that one good thing that’s going to come out of all this that’s happening in the world is that, people aren’t going to get all too crazy over coming to the offices, and that remote work will be considered as one of the valid options, and hopefully, we’ll see a lot of new companies on the rise leaning towards it.

Originally posted on Medium under Women Leaders in Technology's Publications on 11th July, 2020.

Picking off/restarting my #100DaysofCode Challenge

Dipti Gautam — Wed, 22 Apr 2020 17:25:32 +0000

Hi,

Around one and a half month ago, I had wrote my blog post here about getting started with my #100DaysofCode with bash, open source and linux. And I did to it for the first twenty days or so; but I hit a pause on it because I was supposed to give a webinar on April 26th, so I thought I needed more preparation and practice. Even though I did end up putting that preparation on hold till the last minute, I ended up doing a lot of great things outside of tech that have contributed to my physical and emotional well-being.

I have started French on Duolingo for almost two years now; but only now is it that I'm taking it seriously by not only taking a new lesson each day; but also making a short 10-50 second clip of myself speaking in French each day and posting it on my Instagram close friends list. I have also been writing a sentence each day on my journal.

I have started working out regularly, cleaning my workspace and room, and a lot of other healthy habits that have allowed me to feel better about myself and how I'm going about my life these days. And all of these things, I have done in the past twenty days; of which I took that break in. And my most important and biggest achievement has been me being able to create a proper sleep schedule and limit my sleep to a good 8-8.5 hours.

Also, generally; I'd have ticked off my daily to-dos at around 12 AM; after which I'd normally go to sleep, but last night, I finished off well at 11 PM, and even did some extra things that I had been meaning to do. To my surprise, tonight it decreased down to 10; and I was now finally going to prepare for that webinar, but we decided to push it a week further. And this got me thinking about how my healthy habits have made me more productive and now I can bring #100DaysofCode back to my daily schedule!

This time, however, I'm setting myself some ground-rules so that I would be able to keep my sanity and not have to drop midway as I had to the last time. I'm keeping weekends as off-limits because I'm always doing something as long as I'm awake during the weekdays. And amidst 8-hour work, workouts, language learning, and #100DaysofCode, it gets pretty tiring, even though I don't feel it while I'm doing those. That's why I will be reserving those two days for cleaning up, movies, books and simply resting.

Also, last time, since I was very new to the topic, I had kept my goals pretty vague, I believe. I was mixing up too many things at once. This time, I'm focusing on bash, and simply bash. The linux stuff that go on about it including the environment setup or just experimenting with the operating systems will be kept under my personal explorations; and I will not use the time allocated for #100DaysofCode to indulge in those. The same goes for contributing to open source. I will try things as I go, such as participating in Hacktoberfest, slowly exploring the channels where I would be able to contribute, and doing it. I will not pressurize myself into it, rather will focus on exploring them naturally.

I'm resuming my #100DaysofCode challenge officially from tomorrow; and for today, I will just enjoy an episode of The Simpsons and go to bed once I organize my materials to get started with! :D

Getting started with my #100DaysOfCode Challenge

Dipti Gautam — Sun, 15 Mar 2020 16:57:13 +0000

I've been fascinated by the unix system as a whole, working in the terminals, and feeling like a "hacker" while installing programs on a linux operating system ever since my first year in college. I even downloaded a lot of apps on my phone; a lot of pdfs on my laptop to get more familiar with using the command line interfaces, and being an "expert" on it some day. But like a gazillion other things I wanted to learn more during my four years in college, it got lost somewhere, somehow. Of course, I used Linux Mint as my primary operating system, and I absolutely couldn't stand using Windows after I got into mint, but still, I hadn't been doing anything on that OS as I had planned to, or as one should. This fact always irked me, but I also felt the instant gratifications while those big commands rolled on the terminal while installing any new application, and even just knowing the most basic sudo apt-get update after adding a package. I mean, how stupid and naive could I be, right?

There was also this wave of open source in my college when I first joined it; I could see seniors everywhere advocating for it, but while I got lost in the pool of having to learn things, it somehow got fainter and fainter and got dissolved completely. I'm not sure if it was me who got far from the right circle, or if it was the community that itself got not-so-active over time, but it looks like I had completely forgotten about it soon enough. There always used to be like a hundred things on my to-do/learn list, but it wasn't one of them. It wasn't until I started working with Open Knowledge Nepal as a Fellowship Co-ordinator for the Open Data Fellowship that I got reconnected with the idea of openness, and embraced it for myself. But that was just it. I still hadn't really known about actually contributing to open source projects, or let's say, not given it a thought. It was until I got the opportunity to attend the ApacheCon EU 2019 in Berlin, where I met so many developers and contributers from all around the world, binded by one main idea, "open software, open source, software freedom". Lucky for me that it was The Apache Software Foundation's 20th Anniversary, because of which I got to watch the documentary about how it started and how it went on to be one of the biggest non-profit organization with hundreds of projects and thousands of committers over the years. And then when I came back and started looking at some of the job descriptions of the companies worldwide, I could see a few projects from Apache that I knew of from the conference listed under the desired skills. It felt good to have known what that is after that, because I'm sure it would have felt like an alien language if not for the ApacheCon!Oh, by the way, you might or might not see me in the next documentary of it coming twenty years from now! ;)

After getting back here, I promised myself that I would start contributing to open source projects too, but you know how it gets, between exams, internships and other projects, it was always put off, and stayed on the wish-list. Also, while in ApacheCon, I heard about this program called Outreachy, which is like a Google Summer of Code Program, but for underrepresented groups in tech, where you participate in a remote internship and contribute to open source projects. I was especially happy about this because I only heard about GSoC last year, which was my final year of eligibility as an undergrad student, and didn't put in much effort, because I didn't have much idea of how it worked.Outreachy didn't require you to be a student, and my roommate while in Berlin had also been a past Outreachy intern, so I heard a lot about it and decided to apply in the next cohort; and I did, and got past the initial screening; but couldn't continue because I had already started working. It was a bit sad because I'd been looking forward to it since October, but what better way to get disqualified for something rather than by being employed, right? So, I looked on the bright side, and thought about how I would get on this journey regardless of it and maybe, become an Outreachy mentor someday, instead!

Okay, enough rambling about history and unrelated topics. Also, that's how I got into the idea of getting started with open-source projects; but how I decided to pursue bash is a short but different story altogether. So I have a fairly new laptop; but it has had problems with wifi on ubuntu and linux mint, and I have been using an external adapter for my use, but I also tried to fix it every now and then with some research, and I have been able to learn a fair bit about how those commands work and what they do, and for someone who got excited about knowing sudo apt-get update, it felt good knowing the other not-so-commonly known commands, and fixing the problems, even if just temporarily. I even joked here and there about exploring a career as a linux sysadmin, but since then, I've had this huge thirst of getting deeper into it, and actually doing something rather than wishing. And now that I finally have a job that I love and enjoy, and more time since I work remotely, I thought I would learn something I've been so curious about since so long, and actually explore all the areas that I've been meaning to explore!

Since I'm quite new to this, I haven't planned anything specific, and thought I'd figure it out as I move ahead, but here's a simple breakdown of what I mean to do in the upcoming #100DaysOfCode Challenge starting today!
Well, today, I'll install Fedora on my PC, and explore the OS. And I'd be trying out more OSs in the coming days if the wifi issues persist. (I have Ubuntu on my work laptop, so I'm free to experiment as I wish).
Over the next days, here's what I'll do:

Complete the Bash track from exercism.io in the first 33 Days
Complete the Unix Workbench from John Hopkins University in Coursera in the next 33 days
Complete the "Advanced Bash-Scripting Guide" by Mendel Cooper over the last 33 days. (Though I'm fearing that this last one will take longer than anticipated).

I'd be learning these for two hours each day, and tweet my progress every single day. And also document my learnings here in the blog every once in a while. Besides, I would be exploring how I can contribute to open source projects as a beginner on this topic over this week, and will contribute to those projects during the weekends.

I hope to have fun in the next 100 Days. Thank you for going through my not-so-interesting histories and monologues if you've made it this far! See you soon!!