Thoughts on hackathons

After attending 7-8 hackathons, at the time of writing this. I feel there has been a missing link in each of them. Not each of the product I made at hackathon went into production, except for 2. If it isn’t ready for production, it’s not worth it. Motto of each hackathon should be

Ship it!!

Hackathons are best to meet like minded people and get introduced to cutting edge technologies. It’s an fantastic opportunity to learn from others and get evaluated for your implementation. Hackathons can be daunting at first, but that’s always the story for something good ahead.

Back at issue, production code matters. It’s a mindset. A hack in hackathon won’t last long and would add to technical debt later. A well thought code base goes long way ahead. So the protocol for any hackathon should be writing production ready code, always!.


Tips while using raspberry pi for development. Let’s face it, it’s cumbersome to ssh into raspberry pi and write code there.

  1. Configure your ssh keys for direct login instead of password based login.

  2. Use Rsync to sync folder from working location to remote location. For example:

 rsync manual-interface/ -azP pi@ 

This command will sync the content of manual-interface on host computer to remote location which is at raspberry pi. If ssh keys are configured, one won’t need to enter password for raspberry pi.

  1. Usage of watchdog for automatic syncing the code to raspberry pi. watchdog is wonderful python package for monitoring events on file system. One can write a python script using watchdog package or simply use watchmedo shell command. For example:
watchmedo shell-command \
    --patterns="*.py;*.txt;*.js;*.css;*.html" \
    --recursive \
    --command='rsync . -azP pi@' \
    . \

Here I am looking for pattern recursive inside the current location, on detection of changes on file system, rsync comes to rescue for syncing.

  1. Using VNC viewer for accessing GUI interface. VNC is excellent software for remote accessing the desktop, this can save extra monitor configuration.

These are few tips which are helpful to me, while working on an exciting project. Till next time.

See you in 2017. Happy New Year. Best wishes.


Answering by questioning.

Often times I will be fighting with the problem I created out of the solution for a given problem. I have a solution which appears to works but it isn’t complete. This solution arise based on the familiarity of the problem I have in mind. That’s the wrong way, I need to describe the problem and work out on the solution on top of existing efforts.

One can relate this, when they find a solution on StackOverflow for a problem which has some familiarity with their problem. The solution might be superset or subset for your problem. But it’s a mistake to not get the real problem first. How do we do that? Often times the solution appears out of nowhere on reading documentation when I describe the problem in words to my peers or StackOverflow. Not just because of thinking out loud solves the problem but I understood the problem before describing it.

Solution isn’t fixing the existing solution but re-describing the problem.

If you don’t step forward you will always be at same place.

Everyone got questions, doubts. It’s important to feed them. Sometimes internet isn’t enough, sometimes you need to discuss the approach, show how you did it or internet is just broken. One common way is to ask personally for help or guidance. But sometimes it’s shyness, sometimes it’s ego, sometimes it’s the feeling of asking for a favor. It’s important not to spoon-feed yourself at the same time.

Also don’t be afraid to be wrong, do correct yourself.

You have to make efforts to get to the answers yourself, others’ help/guidance will just be a catalyst. It’s you who have to complete the “reaction”. Also don’t turn anyone away if they ask you for the same, afterall it’s just a cycle to be completed.


#Why ETA?

It’s important to have ETA, not just because someone else wants to coordinate with you. But it’s important for self introspection, self assessing, it’s important for one to know what all are the puzzle blocks in the problem. I remember a quote

A problem well put is half solved.

So ETA is thinking about the problem. ETA is not to impress anyone with your skills especially in software development, otherwise you would be fighting the bugs rest of the time. Some times there is pressure of determining the correct ETA, don’t give ETA for whole problem, break the into chunks and give ETA for individual chunks.

Think ETA as assembling the Rubik’s cube. It may seem messy initially, but step by step it will be solved. Solve the first layer, then second layer and lastly the third layer.

Also ETA is no excuse to comprise on quality, a half baked product to match ETA is no worth.

*ETA = Estimated time of arrival