Last month I’ve took part in the RubyRampage hackaton. Our team consisted of 3 members: me (as a back-end developer), a front-end developer and a Project Manager.

I always wanted to challenge myself in that way and see how much me and my partners could achieve within 48 hours. I also wanted to have fun and I definitely achieved that goal! It was an awesome experience. Besides the fact that we didn’t win any prizes, we actually achieved a lot. We tried out our idea, we finished everything we planned and we made the project visually appealing.

These are the things I found relevant when I looked back on the whole experience.

Set achievable goals

This works as well with any projects you are planning to do. At first you need to define what would your MVP version contain and those goals have to be realistic, achievable and within your current available time frame. Of course, you may have a lot of great ideas and you might want to implement all of them because they are cool, but that will obviously take more time. That’s why you need to focus on the most important features, implement them and implement them well.

Describe your ideas as tasks

Instead of having raw ideas, try to split your ideas into the small tasks and describe and elaborate them as much as you can. It will help you better understand what exactly needs to be done. Splitting tasks into small chunks will prevent having to think through the task again mid-way into implementation.

Good planning should consist of half of the work.

Estimate them

I have found that estimations are also very important. They help understand how much you will be able to achieve within a certain time range. It will also help understand if a feature is within the realm of achievability or not.

Aim for less

This is somehow related to “setting achievable goals”. Do not plan to implement every single idea you have in mind. Choose the ones with the highest values and try to implement those in less time. You need to have some sort of time buffer when you reach the end of the project in order to fine tune some of the things you implemented.

Non-dev person are also very important

Your team does not necessarly have to consist of only of developers. It is a very good idea to have someone with a different mindset. Those team members are very precious in the sense that they can bring great help with for instance: creating mockups, preparing stock images, testing your features and so on.

Finish earlier

Finish all the planned features before the deadline. It will give you time for checking and fixing your features.

Polish stuff before submitting

At the end of the Hackaton, you ultimately submit your project to the jury. Besides the members of the jury, there could be other participants who can see the end result of your work. The opinions of those people are very important. You can have a project that stems from a brillant idea, showcasing awesome functionalities, but if for example the front-end does not look good, you might receive negative feedback. What I am trying to say here is that you should try to spend some time polishing up everything you’ve done. Don’t aim to turn everything into perfection itself, but at least you should have an end product that is free of functionalities that look and feel unfinished.

Check everything from the complete beginning

During the features implementation, you will collect some data on your local and test environment. You will probably have some test data on your pages. Some of your tables will have evolved quite a lot. Chances are that you’ll have missed something. There might be a bug or an important omission. Some of these things I can catch just by looking at your projects from the blank page. Very often people forget to look at empty pages. With empty pages, the pages which users usually see right after they register with your app, people just don’t realise the potential they have in terms of problem solving. It is always a good practice to add some hints which could help people to understand just that.

Prepare a good welcome page

You are the people who understand your product and what it has to do and how it should do it. But the jury members and other people have absolutely no idea about that from the get-go. A good practice here is to provide them with the “HOWTO” page. It would surely help them get a good overview of your project and will help guide their judging efforts.

Ask for feedback before submit

Last but not least. Try to ask for feedback from someone who did not see or participated in the project’s implementation. Go through all the features with this person and check how easy (or not!) it is for him/her to understand and use your project. It could be your wife or roommate. Those people can give you feedback right away and provide you with some good guidance and ideas on how to improve your functionalities.

If you did not participate in any Hackatons yet, I would strongly recommend you to try it out someday. It is in itself an awesome and very rewarding experience.