My first Hacktoberfest, from contributing to receiving contributions
Tags: hacktoberfest, css, react
Published: 2019-10-17 15:56:49

After hearing about Hacktoberfest for the first time last year but did not actually take part because it was not a habit of mine to contribute to open source projects, i took a leap of faith this year and planned my start early. At last 11pm today, i did it!
![Hacktoberfest](https://thepracticaldev.s3.amazonaws.com/i/s5qkg7ooq0uxes0bsdmn.png)

To my last year's self, this is what i can tell you now:

##1. It is okay to step in first
It is okay to put your foot in the water first before knowing what exactly that entails.
That should have you already making the correct guess that i registered first before even knowing which project i wanted to contribute to. However as soon as i did that, i realised that there was already plenty support for lost souls like me, in the form of various repositories tagged with *hacktoberfest* and even repositories to search for those with such tags. One year ago, when i were hesitating and not starting, i would have never known this. i would have told myself again and again *"nah it will take me weeks to read the code in the first place, there is just no way"*. But to me there were certainly repositories that you are already qualified to contribute, like this [Single Emoji project](https://kimberrypi.github.io/emojidiv/). Your friends can help you too; i got to know about emojidiv from a friend who knew that i liked to [draw with CSS](https://smokinclove.github.io/writeups/a-tale-of-css-drawings/).

##2. Keep moving
If you think that those "beginners" issues that i mentioned are found in the manner above are too simple, you are most likely right.

But as a beginner, if you try to aim too high, you may risk forever being scared to even start. So it is okay to aim for one step at a time.

That being said, starting and not continuing is not much better than not starting, in my opinion. Habits need repetitions to really stick. And those repetitions are what make us better at what we do.

As long as i keep moving, even if it is one baby step at a time, i will not stand still. *And that is all that matters. Do not stand still and keep moving. Start small first and it will get better.*


In short, do not deter yourself even before you start, self!

##3. It is okay to (shamelessly) tell people you are open to help
Naturally, since i felt that i benefited from those tags, i wanted to do that to my own in case anyone might be interested. i tried my luck and announced that [my pet repo](https://github.com/SmokinClove/moon-walker) is open to PRs in case anyone wants to do something light and fun. First it was only sending a shoutout in my team's group chat, then broadcasting on my Twitter account, and then eventually i added the tags *hacktoberfest* and *good first issue* to the repo's issues. All of them are valid strategies, though the last step attracted the most traffic because of the handy tools mentioned earlier.

It is okay to be shameless. Or call it [Learn In Public](https://twitter.com/swyx/status/1009174159690264579), if you will. Thanks to being shameless, i knew that [my Tiny Dancer can do such a cute duck walk](https://github.com/SmokinClove/moon-walker/pull/8). Thanks to being shameless, i got to see how a senior developer uses Hooks in an advanced way. Thanks to being shameless, i get a beautiful sky full of stars (no intended Coldplay reference but it's cool) for my Tiny Dancer to slide his heels on.

##4. Be clear about what you want to say
More than once i had PRs that overlapped with each other or, did not do what i imagined it would. The second is mostly on my part because i assumed that everyone would think the same way i did, which is not true. If i wanted a shadow, i need to specify where or how or give a prototype - a shadow of what? Where? At the dancer's feet? In front or behind him? Which direction?

Just as in other aspects of our everyday communication, we should ensure that the descriptions in the issues are clear, or ask people to clarify their solutions first before starting (which i have seen people do in other repos but did not execute in my own, being the noob that i am), so that 1) people know that someone is already working on it and 2) avoid any miscommunication before efforts are spent.

##5. Enjoy, enjoy, enjoy!
So much of being a full time developer is the pressure to do your job well. What is better than a fun short challenge to let your guard down and share the joy of programming with the rest of the world? We will learn much better when we learn with different people with various programming backgrounds.

So, shake that stress off, and have fun.



Cheerio!