Presentation and Documentation

I am writing about this because I want to give this to someone who asks for feedback on projects, presentation and in general life.

Side note: Why should you even listen to me?

You don't need to. These are my experiences, observations and opinions squeezed into this blog.

And in fact — I didn't even make through the initial round in my first hackathon — even after working with experienced folks like Kartik Soneji and Harsh Kapadia. Our product, Swadeshi was complete, integrated and good to go. But I think we lagged in presentation.

And after that, I have won (first runner-ups) the last 3 Hackathons, one of them being the Code for Good Hackathon — a national level Hackathon by JP Morgan Chase & Co. And this is not a goddamn flex — It is some background, some facts that prove my reasoning.

I have seen a lot of marketing pitches, hackathon pitches. I have explored abundant LinkedIn profiles, GitHub profiles and other social profiles. I have explored projects, READMEs, documentation. So, this gives good exposure. I am able to differentiate between good and great.

It's like how an ML model is trained. The more data it is fed, the more better it gets.

We work in the same way.

The more we explore things, the more we'll be able to differentiate things for ourselves.

Introduction

I am someone who believes in

Presentation > Execution > Idea

Why is idea at the end? One doesn't need a billion dollar idea to build a good product.

Presentation

Presentation is something that will take you to places.

By presentation, I don't just mean a power point presentation or speaking on a mic in front of a thousand people. I mean a lot more.

By presentation, I mean:

How you present yourself to the world — physically and virtually.

And not just yourself, how you present your work, your ideas, your thought process — while you interact with the people.

Be a good communicator

Presentation is communication. A good communicator is good presenter.

It is how you want to convey your idea — and it is based on how you choose to do it.

Because everyone sees your work. You are your work. You are the work you do.

Enthusiasm

Presentation requires enthusiasm and motivation. It is something how the world sees you.

And in fact — It is something how you want the world to see you.

Presenting your projects — In a Hackathon? In a Project Showcase? In a Marketing Pitch?

If you're presenting your project, show some goddamn enthusiasm. It is something that you have built.

Take some charge.

Be your own cheerleader.

No one is going to market you. If you won't, who will?

And this is true in life, generally.

Structure

A basic structure I tend to follow.

Find the problem that you're trying to solve.

Clarify the problem you want to solve. Don't overcomplicate things. Reduce the variables.

Market Research

Look for existing solutions. Market Research helps you to understand the system. It helps you to innovate your solution better.

Lastly, it helps you realize if you even need to build the solution?

The world doesn't need repetitive solutions. We need innovative solutions.

User Research and Feedback

Find problems in those solutions after your Research. Try to solve that.

Observe, discover, implement. Fill the gaps.

Build your solution, where the existing system fails.

The research that you do will help more in your presentation — when you try to explain: Why us?

Presenting the solution

Present the solution by attacking those problems in the system.

Follow the same architecture of your thought process. Make them understand your thought process.

While presenting, talk about your thought process, your workflow, your strengths.

Don't talk code, talk features.

And talk about features that matter. Don't talk about authentication, until security is a major part of the project.

Talk about your achievements. Talk about your challenges.

Smile

Finally, smile.

A smile a goes a long way.

A smile shows confidence. A smile doesn't show that you're intimidated, even if you're anxious. A smile shows that you're not letting other person get inside your head.

And this isn't just true for hackathons, presentations, or interviews. It is true for every goddamn situation in life generally.

Life is chaos, success is completely arbitrary, and confidence is everything.

Gina Linetti, B99

Changing the direction of the blog

Now what if you don't have a platform to present? What if you don't get to present?

You don't "get" to present. This is absolute fucking bullshit.

You are your boss. This is your game. You write the fucking rules. You rule it.

You get to present — however you want it, wherever you want it, whenever you want it.

Now, this is yet another direction and I could go on and on about this.

Essentially, you don't need a platform to present. Use social media to showcase it. Post it on Twitter, LinkedIn, etc.

Show it to the world!

And a similar LinkedIn Post.

Documentation

Why on earth is documentation in the same blog as presentation?

Because the next best thing after the presentation is passive presentation — Documentation.

What even is documentation?

So, how the world is going to see your project?

You know your idea, you built it and you have a thought process around it. But the world doesn't know that.

So, how do you show that? By documenting it.

Writing down your thought process, your idea, your approach, tools and technologies you used, demonstration, et cetera, et cetera, will make you stand out.

And even if standing out isn't the goal, document the project for yourself. Creating a log for your understanding.

You might have built the best open-source project out there but it’s left teetering without an explanation.

Markdown (.md)

You don't need to know languages to write sentences. You can write it in a .txt file if you want, but just write.

Markdown Syntax just enhances your documentation - Adding headings, proper structure, hyperlinks, image support, code highlighting, etc.

Not only that, you can use HTML to write your README's as well.

Writing the perfect README:

This is highly inspired by a mentor/friend — Ankita Tripathi

1. Take it step by step

Go through your project process, explaining it like a 5 year old could also use it. Cutting down to the simplest form is crucial.

2. Add visuals

Out of the people who will see your project, only 7%-10% will actually set it up locally. For the rest of them, add these visuals.

Add architecture, add designs, add snapshots.

3. Adding external links/references

If you want people to install npm, link npm installation to follow the pre-requisites.

Want me to add env variables? Tell me to do so. Don’t let the user loosely hang through the cliff searching for installation docs.

4. Define the purpose

Explain your project, comprehensively. Why did you build it and what features could be added.

Conclusion: Think as a user. Act as one. Write those contingent issues.

References and Examples

Here is a list of some of my project documentations arranged chronologically.

Self plug :blushes:

And the pattern you'll see is - It gets better with time.

So, just start writing.

References to start learning

• Use this extensive Markdown_Cheatsheet by a good old friend.
• Use readme.so to create a great README.md.
• Use StackEdit - a refined text formatting of the editor to help you visualize.

Fin

What differentiates a good product from a great product is not intelligence, it's presentation.