Why I Chose to ‘Build in Public’ for my 4th Startup
16
January
2022
Product

Why I Chose to ‘Build in Public’ for my 4th Startup

Why I Chose to ‘Build in Public’ for my 4th Startup
Arpit Mohan
0
 minutes ↗
No items found.
Product

It’s scary to have your work out there in the public eye. What if it’s not good enough? What if we’re not on the right track? What if we look foolish? All these insecurities are human, and CTOs are not immune from having them. But I can also tell you that they are the best reasons to build something (you’re incredibly passionate about) in public. Why? Because transparency and community involvement help us in both the short and long term.

This is my 4th startup and have seen many ups and down in my decade long journey. I saw quick explosive growth in my mobile gaming startup, an acquisition of my payment startup, failure of an AI based startup and numerous pivots in between. I’ve also seen investments from marquee investors like Sequoia, Accel and YC. And then worked for a few years to cool off. But the startup bug in me is too strong and I decided to startup again.

Along with my co-founders, I am now building Appsmith, a drag-and-drop framework to build functional and beautiful internal tools.

Why am I so obsessed with internal tools?

Well, I was the one building them and maintaining them in my previous companies. I know the drill all too well: There’s never enough time, specs are ever-evolving, and resources are always low. And they’re relevant at all stages of the organization. For a young startup, they’re critical as you find early scale and you need tools to automate the various tasks so that your engineering team has the time to focus on building our core product. And as a large company, you need a way to manage the hundreds of various internal tools that you have as well as use it as a way to empower multiple teams to take decisions without it burdening the engineering team.

It’s not just source code that’s public; everything we do, including our design strategy, is available for public view. (Our Figma files and Miro boards if you’re curious!)

Building in public is something I’ve begun to love, I’ll tell you why.

You Live, and You Learn

When you have a like-minded yet diverse community working together to create a product, the quality and value spec is incredibly high. The spirit of collaboration to solve problems drives open source projects. I can say this is true for Appsmith. For us, public road-mapping worked in a few different ways. It helped us get our priorities right and allocate the right resources for features. It also helped us engage with our community, gain valuable users’ input, and keep them hooked.

While we initially hoped to build a JS Editor quite early in our product lifecycle, it kept falling from our priority list. Having a highly engaged community repeatedly bring it up, helped us stay accountable to our plans. When we launched the JS Editor, everyone loved it!

Not just this, Git Sync is another community-led feature that we’re almost ready to launch, and it will enable developers to version control their apps. In fact, what we considered as some of Appsmith’s smaller features like the audio recorder widget, and document viewer were prioritized because people asked for it! One of our users contributed a custom chart widget which increased the availability of chart options to 100+!

Good things are great, but bad things take you to hell. There was a time when we introduced a change in how the row selections work in the Table widget (our most used widget). From a technical and UX point of view, it was an improvement to the Table widget. However, it inadvertently broke a lot of user applications. Feedback was unrelenting! We reverted the change within two days, and are now extremely cautious about versioning our changes so that existing user applications don’t break. It was a critical learning moment for us.

By trial and error, we have learned to think more deeply about product architecture before building on it.

Feedback is the Food of Champions

Everyone can openly see what we are working on, create new feature requests, influence product features before they are formally rolled out, and inspect the actual code base to understand why a particular bug exists. In some scenarios, they can also help us fix it! With all this openness comes honesty. And you don’t really have to ask twice for honest feedback from developers! While they can be brutal, they can also be loyal and supportive.

We often felt convinced about a feature internally, but immediate user feedback made us re-examine our decisions. Let me share a few examples here:

Floating Property Pane: We believed it was better to have the property pane as close to the widget as possible, assuming that it would make the property pane better. However, based on feedback from the community, we’ve now docked it to the right-hand side of the app, and of course, the response has been tremendous.

Entity Explorer: We modeled our entity explorer after VSCode to make all the relevant widgets, files, etc., more visible and accessible. We got feedback from users that it’s very cluttered and hard to navigate the explorer menu. We’re now simplifying and making it easier to read and grok for larger applications.

Deployments: Appsmith requires five Docker containers to run (Server, Client, MongoDB, Redis, and Auto update). Earlier, we shipped with a script that would configure all these containers as we believed that it would give developers flexibility in their installations. But we saw a lot of failures. We immediately changed course and now ship with a single container with everything included. Users installing Appsmith now see a 100% success rate on the first install. This is a massive difference in terms of experience.

We think of this feedback as a precious two-way communication, where we can evaluate our product thinking by involving our direct stakeholders (our users) in the conversation. It’s honest, it’s raw, and it’s a fantastic north star to have.

You Can’t Steal Communities

Transparency isn’t just great for us, it’s great for the entire ecosystem. Sure, features can be copied, but users’ love and investment in a product can never be copied or stolen.

At the heart of building in public is trust. Trust is a hard-earned, fragile value that no marketing spend can buy. We invest our time and energy into our product, and we see our incredible community of users do the same. What will help us go forward is to develop our user education initiatives to empower our users and make time to always listen to what our users have to say. Our learnings are as critical as our wins. I see them as essential milestones; they become moments of learning from the community.

As we’re pushing into 2022, I can’t help but think of the tremendous growth we’ve had here at Appsmith in the last 365 days. In quantitative terms, it has meant adding 28 new drag and drop UI elements to our widget library, increasing data source integrations to 16, fixing 3267 bugs. I could go on (alternatively, you can look at our exhaustive year-ender page)! Putting everything out there for public scrutiny has helped us take an authentic look at our production priorities, enabling us to focus on things that truly matter to our organization: Enabling developers to do their best!

A version of this blog was previously published on Product Coalition.

Appsmith Project Now Has 1000 GitHub Stars
12
November
2020
Announcement

Appsmith Project Now Has 1000 GitHub Stars

Appsmith Project Now Has 1000 GitHub Stars
Arpit Mohan
0
 minutes ↗
#
open-source
#
github
Announcement

I announced the Appsmith project on Dev.to for the first time on Aug 21st. While stars don't reflect the quality of a project, seeing 1K stars on our GitHub project makes me happy. 😺

Check out the project at: https://github.com/appsmithorg/appsmith

A few reviews from developers:

Alt Text
Screenshot 2020-11-12 at 5.47.17 PM.png
Alt Text
Screenshot 2020-11-12 at 5.50.06 PM.png

In the past two months, we've seen thousands of users from 65 countries who've used Appsmith for building all sorts of internal apps and admin panels. We've also seen over 40 contributors who've reported issues and code.

We built Appsmith because there is no open-source platform that helps you build custom and beautiful internal tools or admin panels. Today Appsmith ships with 17 UI components, 7 database integrations, and a REST API connector. There's a lot more coming soon.

When should you use Appsmith?

An Appsmith user said this: "This tool is perfect when you need an admin panel that needs to query multiple data sources in the same UI, update values from one with the other, and even use values retrieved from both to query external APIs."

Try Appsmith at appsmith.com

Hacktoberfest Week 1 Update
6
October
2020
Announcement

Hacktoberfest Week 1 Update

Hacktoberfest Week 1 Update
Arpit Mohan
0
 minutes ↗
#
open-source
#
hacktoberfest-1
#
hacktoberfest2020
Announcement

It's been a busy week at Appsmith, thanks to Hacktoberfest. There's no better way to end this week than by thanking all the developers who chose to contribute to Appsmith during this period. We are a small team of developers and this ❤️ means a lot to us.

Over the week, we've merged in 16 Pull Requests from contributors. That's insane!

"If you'd like to get in on the action, Appsmith is running a special challenge during the month of October where you not only get swag for contributing a valid PR but also a customized mechanical keyboard; for inviting other users to contribute to our repository."
"Check out details of the Appsmith Challenge here."

Here are the contributors (in no particular order) that I'd like to mention & thank.

Also, a lot of folks improved our documentation. We've merged 20 PRs just for our docs. Some of the top contributors to our documentation are:

Thank you everyone for being a part of this project. Look forward to more pull requests & contributions.

Happy Hacking!

PS: Join our Discord channel and participate in the Appsmith Challenge and become a part of a welcoming community.

Hacktoberfest Kickoff Event
1
October
2020
Announcement

Hacktoberfest Kickoff Event

Hacktoberfest Kickoff Event
Arpit Mohan
0
 minutes ↗
#
open-source
#
hacktoberfest2020
#
hacktoberfest-1
Announcement

Hacktoberfest is a month-long celebration of open source software. As developers, we stand on the shoulders of giants. Each year, in the month of October, as a community, we pledge to feed this giant.

Contributing to open source projects is fun and rewarding. At times, it can even be daunting to get started. Lots of people believe that only code that implements large features matter. That's not the truth. No contribution is too small — bug fixes and documentation updates are valid ways of participating.

I'm doing a livestream on Appsmith's Discord channel today at 8:30 AM PST / 9 PM IST to help you get started and show you how to open your 1st PR. This 30 minute stream is a tutorial for new and seasoned developers.

The agenda for the livestream will be:

  1. How to find the right projects to contribute to
  2. How to open PRs
  3. How to communicate to ensure your PRs get accepted
  4. Best practices when contributing to open source

As the lead maintainer of Appsmith, I'll use our repository as an example of how to contribute.

Register for the event here. See you on the stream!

Shameless plug: Appsmith is an open source low code product to build custom internal tools and admin panels. We are a welcoming community & have lots of issues that first time contributors can pick up.

One Open Source Project for Admin Panels, CRUD Apps, and Internal tools
21
August
2020
Product

One Open Source Project for Admin Panels, CRUD Apps, and Internal tools

One Open Source Project for Admin Panels, CRUD Apps, and Internal tools
Arpit Mohan
0
 minutes ↗
#
news
#
showhashnode
#
javascript
Product

We’ve all spent time on building internal tools which could be CRUD apps, admin panels, or complex workflows. These kind of internal tools are used for:

  1. Analytics and reporting
  2. Customer data views for sales & support teams
  3. Configuration managers for client-visible UI used by technical and non-technical people
  4. Multi-step data workflows which involve multiple participants(like content moderation tools or customer KYC at fin-tech startups)

These tools often aren’t very interesting to build because of the repetitive work involved like building UI, writing CRUD APIs, setting up authentication, & managing deployments.

Creating Admin Panels, CRUD Apps, and Internal tools quickly!

I decided to create Appsmith because I couldn’t find a project which did most of the work for me and also easily customizable.

How does Appsmith work?

1. First setup Appsmith using Docker. Read instructions here for a 2 min setup process.(docs.appsmith.com/quick-start#docker). Or try our online sandbox

2. Go to localhost or your machine’s public IP to see the login page. online sandbox.

3. Create a new application and name it.

Create an application

4. Connect to a database or API. Today MySQL, Mongo, Postgres, and REST apis are supported. The gif below shows me connecting to an API.

API creation

5. Go to the canvas section and choose a UI widget. Appsmith ships with 16 components like tables, different charts, map viewer, forms, etc. In the example below I’ve used a table component.

6. Modify the table property to display your query results by writing {{queryname.data}}. You can code in JS and use Lodash functions inside {{ }}.

7. Trigger an action through events like onClick, onTextchange, onSelectedrow, etc for CRUD operations.

Event trigger

1. Click deploy to see your app in a URL. (You can set up a custom domain in the setup script)

Deploy

2.Invite users after assigning them a role. They can sign up via a form login or with their Google/Github accounts. Make your app publicly viewable to allow access without a login.

Share & invite

So this is how you build a simple app in less than 10mins. Access an app I built on Appsmith here.

Appsmith is the first open source project to build internal tools. If you like the project, please star our GitHub project.

What features should we add to Appsmith?

TL;DR: Appsmith is an open source framework to build apps for analytics, workflows or CRUD operations. Replace all your internal tools with one project. See GitHub repo or try an example app here.

Appsmith's Remote Working Guide
12
March
2020

Appsmith's Remote Working Guide

Appsmith's Remote Working Guide
Arpit Mohan
0
 minutes ↗
#
career
#
productivity

We are living through an extraordinary time. People around the world are working hard to limit the spread of COVID-19 by completely stopping travel, mass gatherings, and events. We will do our bit and will be going remote for the next 2 weeks (maybe more). This document aims to address how we will work well together.

Office Timings

We still maintain the expectation that folks are online and available from 11 AM to 7 PM. It's important for all of us to stick to these timings to ensure that we solve blockers early. The option of working on your own schedule exists but at the beginning, we'd like to ensure that folks are available together for as long as possible.

Communication

Since a lot of human communication is non-verbal in nature, when everyone is remote, err on the side of over-communication. Try to use higher bandwidth communication channels such as Video Calls or Audio Calls. Most issues can be resolved by getting on a call for 5 mins v/s chatting for 15 mins. Iron out any confusions or issues early in their lifecycle rather than assuming the other party has understood.

This point cannot be stressed enough: Communicate

Daily Video Standups

Humans are social beings. We crave social & visual contact. Working remotely means that often, folks who don't work closely on a daily basis may not see each other's faces. Hence, we will conduct our stand-ups over video. This ensures that at the very least, we will all see each other's face once a day. We may also conduct video calls over lunch, where we get to interact with each other as if we were eating together in office.

Daily Stand-ups get a video upgrade! 
Don't forget to look pretty in the morning 😆

Bi-Weekly Check-ins

We will be checking-in with everyone more often than usual to ensure that we are on the same page. This means you will be having a conversation with at least one of Arpit, Abhishek or Nikhil on a bi-weekly basis. As founders, we will try to keep up the pace to ensure everyone is healthy and happy.

Tips:

For some of us, this may be the first time we may be working from home for an extended period of time. Here are some tips that I've found useful in the past:

  1. Create a dedicated space in your home where you will work. Don't work from your bedroom!
  2. Keep your morning schedule unchanged. Shower, change and go to your dedicated space when you want to work. This will ensure that you get your mental space into "work mode".
  3. Wear work clothes when you are working. It tricks your mind into thinking it's at the office.
  4. It may be hard to judge when to stop working. Set a personal target for yourself and start & end work at those times. Don't work outside those hours that you've set for yourself. This is important to maintain mental health.
  5. Try moving around often. Working from home means that your body may not get as much movement as it does on a normal day. Be mindful of this as it affects your sleep cycle.
As always, if you wish to speak your mind on any topic, 
your team is always available by your side. 
Leverage them to get your daily dose on social interaction.


Who Ate Docker's Lunch?
14
November
2019

Who Ate Docker's Lunch?

Who Ate Docker's Lunch?
Arpit Mohan
0
 minutes ↗
#
kubernetes
#
devops
#
docker

Yesterday, Mirantis acquired Docker Enterprise which includes the registry, the enterprise accounts and basically everything of value owned by Docker Inc. The company is now left with a shell of its former business. Even though the sale amount is not public, it is widely understood to not be a large sum.

Docker was once a darling of the tech world. Today we are left wondering - Who ate their lunch?

What did Docker do well?

1. Remarkable developer UX

Solomon Hykes & co. took an old not-so-well-known technology "Linux Containers (LXC)" and created a beautiful developer experience around it. It was like old wine (LXC) in a new bottle. It allowed developers to leverage the possibility of creating re-usable, re-deployable binaries and it was incredible. Once a container was built, you could run docker run on any Unix system and it would just work. This was the promise of Java jars in the past, just on a more generic and wider scale.

2. Faster REPL cycles

Creating a layered structure for the Docker container (akin to Git), was another masterstroke. A developer could re-use various pre-built layers in other builds. This reduced build time for incremental builds dramatically. In the developer world faster REPL cycles lead to faster adoption; ALWAYS. And it happened.

On the downside, this design created bloated Docker images. There were multiple hacks introduced to counter this force. But it remains one of the biggest challenges of the container world.

3. Run Anything, Anywhere

For better or for worse, most developer machines are not replicas of their production environment. For example, while I code on a Macbook, our production environment is a cluster of Debian machines. If you work in an enterprise, you might even be required to use Windows as your primary dev environment.

This disparity creates a whole new set of headaches. It's hard to develop & debug for a system that you are not very well versed with.

Allowing developers to run an OS inside another OS was a huge accomplishment.

4. Rise of "Devops"

The meaning of the word "Devops" is highly contentious. It means different things to different people. Docker was singularly responsible for getting developers to stop throwing code over the wall to sysadmins who then had to run & maintain the code in production. This led to the creation of a hybrid team where the dev & ops folks could work closely with each other. This could only happen by making ops more approachable to the devs (and vice-versa).

As a dev, if I could run a Docker container on my local machine and be promised that it would behave in the same manner in production, it gives me a lot more confidence in my abilities to troubleshoot production issues.

Where did Docker go wrong?

Most developer tool companies (IntelliJ, Terraform, etc) start out with a popular product that keeps them top-of-mind for developers. But it's hard to monetize & build a long-lasting company based on a single product. As a company, you need to build 2nd & 3rd tier products that ride on the popularity of the first one. This suite of products then come together and create a reckoning force.

Take for instance the successful developer tools company Hashicorp. Their first product that became popular was Terraform, a multi-cloud provisioning system. You could write a simple config file and provision computers across any cloud provider. They capitalized on its popularity and created a suite of products such as Consul, Vault, etc, each with enterprise plans in mind. This allowed enterprise teams to collaborate, cluster & monitor their production systems.

Docker, on the other hand, wasn't able to create a successful 2nd tier product. If you look at their website, product offerings are limited. Docker Hub was required but not enough to sustain the company. Docker Swarm (which could have been their consolidation) was an inferior technology as compared to Kubernetes - the big daddy of orchestration today.

While the initial promise of "Build once, run anywhere" is great, managing production environments is a whole different beast to handle. Running clusters of machines, security management, network partitions, redundancies at all levels is what keeps sysadmins constantly on their toes. The experience of using Swarm in production is less than ideal. It just doesn't live up to the requirements.

In this sphere, Kubernetes did a much better job (even though their dev UX sucks) at running production workloads with little hassle.

Observability products such as Prometheus, New Relic, etc capitalized on Docker containers being harder to monitor because they were isolated binaries. Another missed opportunity for Docker Inc.

Being able to expose monitoring data out-of-the-box could have been a huge win. It could have also ensured that as a developer, I was tied into the ecosystem.

All of these missed opportunities are hard problems to solve. They aren't solved overnight. But Docker had some time to solve this. It was the highly valued darling of the tech world, after all. At its peak, Docker had investors willing to invest in its future and developers dying to work for the company.

Docker Inc did introduce consultancy services for enterprises. But the revenue from it was considered service revenues. And service revenue isn't as highly regarded as product revenue because repeatability & scalability factors aren't high in services.

Docker was great at building its technology but the fact remains that it always struggled hard with monetization. There is a lot to learn from Docker's pioneering vision as well as from its market struggles.

I wish to see the technology thrive and I'm optimistic that Mirantis will do justice to Docker Inc.

Coding Practices Your Future Self Will Love You For
18
September
2019

Coding Practices Your Future Self Will Love You For

Coding Practices Your Future Self Will Love You For
Arpit Mohan
0
 minutes ↗
#
career
#
beginners
#
Coding
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
    Martin Golding

Here are 6 coding practices that I've adopted in the past 10 years to ensure that my future self has fewer sins to forgive.

1. Standardize code formatting

Any codebase is read a lot more than it is written. Code with consistent formatting is easily readable and comprehensible for everyone in the team. Standard formatting ensures that your eye, and your subconscious, can look for variables, braces, functions, etc seamlessly. Golang does a great job by providing the gofmt command in the standard library. This ended all formatting discussions that come up so often in code reviews in the Golang community.

2. Don't follow the DRY principle blindly

DRY (Don't Repeat Yourself) is almost a mantra for developers. But if applied indiscriminately, it leads to abstract code that’s hard to read & understand. It also stops different parts of the code to evolve to their full potential. Do not follow the DRY principle blindly.

It is a good idea to copy-paste the same function a minimum two times in the codebase. Only when you see the same requirement a third time, should you refactor the code and apply DRY. Doing this ensures that you are not prematurely assuming that two problems that looked the same initially, are still going to remain the same after a period of time. When you come across a similar requirement a third time, you have some data on what parts of the code are common. You also have three instances of repeated code to create a good abstraction.

3. Debug code via logs

Practice debugging code on your local machine via logs instead of a debugger. Debugging on your local machine ensures that logs are added at the right place. This, in turn, makes sure that you can debug production issues quickly because you would have gone through this cycle on your local machine before. Remember to not get too excited and add unnecessary logs everywhere. It will clutter your log file in production.

Too much logging == no logging.

4. Beware of premature optimizations

A primary goal of code optimisation is to improve performance. More often than not, performance issues are not where you think they are. Always benchmark your code before starting to optimize for performance. Without benchmarking, how will you ever know whether the code changes you make have any real impact on efficiency or not? Premature optimization, especially micro-optimization, is not a good idea because you don’t know whether you are working on removing a performance bottle-neck or not.

As a corollary, this doesn't give you the license to code like the wild west. Don't get the computer to do work that it doesn’t need to do just because you got lazy and didn't think of the most efficient way of solving a problem.

5. Don't complicate your codebase with unnecessary features

Don’t complicate the codebase with features that no user has asked for. This is a problem you need to avoid in early product lifecycles. Startup teams tend to assume that building more features will help them find product-market fit faster. This is an anti-pattern. Adding unnecessary features makes the code harder to read & debug. When new developers come on board, they will find it difficult to differentiate important code paths from the ones that were added on a whim. Eventually this technical debt slows the entire team down.

6. Setup a CI/CD pipeline early in the development lifecycle

Even if it’s a one-wo/man show, a CI/CD pipeline reduces the overhead of remembering (& doing) the build & deployment of a particular codebase. The common assumption is that CI/CD pipelines are important only in teams that are pushing a lot of code into production every day. In my experience, CI/CD pipelines are even more important for codebases that are rarely touched because you won’t remember how & where the code was deployed. This is especially true if you are updating the code only once a year. Plus, having a CI/CD pipeline ensures that you have a version-controlled script telling you exactly what you were thinking X months ago.

5 Tips for Beginners to Learn Better and Stay Motivated
5
September
2019
Engineering

5 Tips for Beginners to Learn Better and Stay Motivated

5 Tips for Beginners to Learn Better and Stay Motivated
Arpit Mohan
0
 minutes ↗
#
career
#
beginners
#
productivity
Engineering

Recently I met my college friend Aditya Rao. I've known him for more than a decade and always thought of him as a business & marketing leader. I was surprised to hear that he's been learning programming for more than 2 years now. I got curious to know about his experience of learning to code and we ended up chatting for about 2 hours about his journey as a 30-year-old beginner developer.

Here are a few tips he shared that helped him learn better and stay motivated through the course. I think other beginners will find these tips useful too, so I am sharing them here.

These are Aditya’s words, slightly edited by me for better readability.

1. Get rid of self-imposed starting barriers I took two computer programming courses during my undergraduate and I failed both. For a really long time, I thought that programming is some black box that's too complex & hard. This skewed view created a starting barrier for me. I know many people who are completely new to programming feeling the same way.

After 3 years, I can say that programming is anything but a black box. It is just beautiful. Something as simple as CSS is truly magical. Everyone has different mental barriers and most of those are self-created. Don’t get intimidated by these self-imposed views.

2. Be clear about your end goal When I was just starting out, an engineer friend told me, "When programmers can’t understand an error message in their code, they go and search the internet to figure out what that error is. There are probably other engineers out there who have faced and solved the same problem before. So, they take that solution and try it out. Of course, they have their fundamentals in place but everyone is still learning on the go.”

Learning on the go made sense to me. Moreover, it was quite liberating to hear this. I took this approach to learning & told myself - ‘I am not here to learn coding, I am here to solve a problem’. This approach of focusing on solving the problem at hand has empowered me to learn faster & better.

3. “You can get anywhere if you simply go one step at a time.” Pick up a small problem. Take out one weekend and just start solving it. The key is to get a small win and then to keep stacking up these small successes. The best thing about code is that it is repeatable. If you have a small piece of code that solves a small problem, you can always extend that to solve a larger problem later on.

Engineers take a big problem and break it down into smaller & simpler steps quite beautifully. If the small solutions for each step work, they can be put together to achieve a larger goal. This is the most valuable life skill I have learned while learning to code.

4. Ask for help & unblock yourself ASAP Coding isn’t hard by itself unless you are building a really breakthrough technology or the world’s next best search engine. But there are hard parts such as setting up AWS and setting up other infrastructure as needed. You will need a lot of help with these things. Always be ready to seek help.

When I asked my first question on StackOverflow, I got 5 downvotes on it. I was genuinely trying to understand something and people were telling me that I am not asking the question in the right way. It was demotivating for me as a beginner. Even if such things happen a couple of times, don't let random people deter you in asking for help from experienced engineers. The Internet, my engineering friends, and colleagues have helped me learn the most.

5. Build something useful to stay motivated I am a big proponent of the no-code movement. Technology should be like a bunch of Lego blocks anyone can play around with. Kids don't think how a lego block gets made, what is the material used or what its tensile strength is. They just use it to build something they want. I am sure there are people out there who care about the perfect piece of code. I have no benchmark on what is good code or bad code. The only benchmark I have is to build something that people find useful. I feel successful when I build something and people value it.

Checkout Aditya’s latest side project, TimeSpent.

What a CMU Professor Thinks About Failure and Future of Work
20
August
2019
Engineering

What a CMU Professor Thinks About Failure and Future of Work

What a CMU Professor Thinks About Failure and Future of Work
Arpit Mohan
0
 minutes ↗
#
interview
#
story
#
career
Engineering

Chinmay Kulkarni grew up in Bengaluru, India. He doesn’t recollect when he used a computer for the first time but vividly remembers that, "the first time we were taught anything to do with computers at school was with LOGO, which was sort of this drawing thing."

Playing around with the ‘turtle cursor’ of LOGO was the humble beginning of Chinmay’s experiments with computers. He took on a Computer Science major during his undergraduate at BITS, Pilani and even went on to pursue a Ph.D. in Computer Science from Stanford University. One of his friends from undergraduate days describes him as "the guy with a knack to simplify & explain things. He was just really good at breaking down things to their core fundamentals."

Today, Chinmay is an Assistant Professor of Human Computer Interaction at Carnegie Mellon University. He directs the Expertise@Scale Lab there that is trying to answer a prevailing question concerning the future of work in the age of automation.

"If we have better & better technology and greater & greater automation, what should people learn and what should people work on."

The findings from this research will mature to suggest new skills people should learn and technologies we should be developing for meaningful & interesting work & learning opportunities for millions of people to exist in our future that isn't only remote but also intertwined with lifelong learning. In this future, where learning opportunities need to be available at massive scale, Chinmay stresses on the usefulness of having conversations among peers: the non-experts, the people who are themselves learning or working in the same space.

In practice, research from his group has resulted in computational systems that structure peer learning at a massive scale. This includes creating the first MOOC-scale peer assessment platform and building PeerStudio, a comparative peer-review system. These systems and the associated pedagogy have been used by 100,000+ learners in MOOCs & thousands of students in university classrooms and have been adopted by companies such as Coursera and edX, in classes across disciplines including computer science, psychology, and design.

Heather McGowan, Future of Work Strategist, succinctly describes that in the future where not only more automation of physical work but also automation of cognitive work will happen,

"We need to stop learning ‘a set of skills’ in order to work. Instead, we need to learn to learn and adapt."

Learning to learn means to become good at being a beginner and not only embracing failure but by seeking it out in order to improve. Chinmay embraces this ideology through constant parallel experimentation.

He says, "If I have an idea, I try three or four different ideas in a similar space. Some of them are bound to fail but in contrast, I can see some of them succeed. You start out thinking all of them will succeed. In some way, it is useful information that you know that things you thought would have succeeded but didn’t not succeed give you a nice baseline to compare against the things that did succeed."

When he writes article drafts, he usually writes three different outlines, sends them all to people and asks them which one do they like more. He says, "I know that two-third of my work is going to be thrown away so I don’t spend too much time doing it. But on the other hand, once I have done this I can very quickly find things that don’t work and discard them." This way of learning about anything seems quite logical to him but he has also noticed that people don’t do parallel experimentation very much.

It is not surprising that humans stay away from trying out different ideas in parallel. Embracing this mindset of experimentation is innately bundled with accepting multiple failures at the same time.

Chinmay admits that it is a lot easier for a researcher to fail than it is for people whose jobs are to not fail at something. He says, "As a researcher, you have it a little easier. You are expected to fail. And also just because something you do fails people don’t think of you as a failure. Even the things you try that don't work have some merit."

He suggests that a simple change of perspective in how we look at what we do that can enable us to embrace failure much better. He says, "I think you can think about things that you do as a series of experiments rather than a series of missions that you are trying to complete. Experiments always have some chance of failure. So, just by thinking of things as experiments seems like you give yourself a chance to say, 'okay, maybe this is not going to work and that’s fine'. If you think about it like a mission, then you invest too much of your self-worth in succeeding."

Some of the most successful companies and professionals experiment and fail all the time. In one of Jeff Bezos’ letters to Amazon shareholders, he expounds on this:

"One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there. Outsized returns often come from betting against conventional wisdom, and conventional wisdom is usually right. Given a ten percent chance of a 100 times payoff, you should take that bet every time. But you’re still going to be wrong nine times out of ten. We all know that if you swing for the fences, you’re going to strike out a lot, but you’re also going to hit some home runs. The difference between baseball and business, however, is that baseball has a truncated outcome distribution. When you swing, no matter how well you connect with the ball, the most runs you can get is four. In business, every once in a while, when you step up to the plate, you can score 1,000 runs. This long-tailed distribution of returns is why it’s important to be bold. Big winners pay for so many experiments."

Chinmay recognizes that it is harder to fail for people whose jobs require them to succeed and that everyone has a different way of looking at and dealing with failure. He ponders, "The real question isn’t ‘are you okay with things failing’ but what you do when they fail. You can either have somebody learn from your mistakes or you can learn from them yourself. If you are really smart you can learn from other people’s mistakes too."

Is it Worth Joining an Early-stage Startup?
31
July
2019
Engineering

Is it Worth Joining an Early-stage Startup?

Is it Worth Joining an Early-stage Startup?
Arpit Mohan
0
 minutes ↗
#
startup
#
hiring
#
career
#
beginners
Engineering

This post is an attempt to put some method to the madness behind deciding whether joining an early-stage startup is worth it.

"The short answer is that it depends."

For the long answer — I have a framework to share that has helped me decide this multiple times in the past. Over the last 10 years, I have co-founded two startups, Gharpay & Bicycle AI, and worked at a few early-stage startups such as Exotel and Cure.Fit. About a month ago, I started building my third startup, Appsmith.

The challenge of working on new problems for new markets is a heady combination for me. But each time I started up or joined an early-stage startup, I found myself asking, “Is it worth it?” Though my answer has always been a resounding “yes”, my reasons behind the “yes” were different each time. I found that clarity on my reason behind the decision was critical.

We all have different life contexts, priorities, personalities and dreams. These unique factors influence our reasoning for choosing one career path over another. You shouldn’t let anyone tell you to ignore this stuff and just jump in.

So, here is my framework. It is quite simple and focuses on a few fundamentals.

Step 1: Ask three questions about yourself and answer honestly.

Step 2: Explore three reasons why it may be a bad idea to join an early-stage startup.

Step 3: Explore three reasons why it may be a fantastic idea to join an early-stage startup.

Step 1: The Three Critical Questions**

1. What kind of life do you want — right now and in the long term?

The answer depends heavily on your personal and professional goals. What are your priorities? Are you willing to invest a considerable amount of mental energy & time in your professional life right now? How does working at an early-stage startup fit within those priorities? Does it help or hamper your progress towards your long-term goals?

Personally, If I have a lot going on my personal front, I will want to prioritize that and hold out on making major commitments on my professional front. Try getting some clarity on what is your priority right now & what you want from life in the long-term. Clarity of thought acts as a great north star for all the decisions that you will end up taking.

2. What kind of a person are you?

Early-stage startups are not better or worse than late-stage startups or even large corporations. They are just different. And from what I have noticed, most people who fit in and perform well at early stages have a few overarching traits.

They are generalists. They look at their work as their craft and take great pride in it. They love challenges and are self-motivated to figure things out. They are quite comfortable saying ‘I don’t know’. They ask for help without hesitation. They also index heavily on finding a solution instead of focusing on the problem. Last but not the least, they are resilient.

Do parts of it seem like you? Look within and answer candidly.

3. What do you expect to gain from it?

Begin with the (expected) end in mind. What kind of professional growth do you need? What are your “must meet” and “good to meet” expectations from yourself at this point? Define these clearly. Take a step back and ask yourself — why are you even thinking of joining an early-stage startup in the first place?

If you don’t know what output you want, you can’t really decide what input to give and how to program the system, can you? State clearly what you want to gain from the experience.

Step 2: Why is joining an early stage startup a bad idea

1. Ambiguity gets a seat on the table

"No company (of any scale) has everything figured out."

The earlier a company is in its lifecycle, the more the number of unanswered questions. The work environment at early-stage startups can be a little (or very) chaotic because of this inevitable ambiguity.

You will not face much ambiguity on a daily basis at a late-stage startup or bigger company because they have already gone through their ambiguous phase. Whatever ambiguities are left to be figured out exist at the management level while you are shielded from it.

Everyone at an early-stage startup must embrace ambiguity. If you are not okay working with some level of uncertainty & ambiguity, early-stage startups may not be a good choice for you.

2. Get it right and get it fast, please.

"You can have something good or you can have something right now but you can’t have something good right now."

Early-stage startups don’t subscribe to this thought process. You got to deliver on everything super fast. You got to think fast, plan fast, build fast, ship fast and iterate fast. The company’s survival & success depends on how quickly it can execute & iterate on multiple things simultaneously. Some people choose to accomplish this by working longer hours, while others choose to do it by creating leverage (a topic for another day).

Timelines are mostly tight. You’ve got to deliver things right and you’ve got to deliver them fast. If you don’t subscribe to this work-style or if you feel this may stress you out, early-stage startups may not be a good professional choice.

3. ROI is subject to market risk and yes, it takes a long time to get any returns

The answer to ‘will your investment reap financial returns’ is always a probabilistic one. Same is the case with startups. Reaping any sizeable financial returns on your equity or ESOP (Employee Stock Option Pool) takes quite a bit of time. Standard equity or ESOP vesting periods span over four years.

Yes, there is a potential of high returns (more on this later) but you must also consider any financial trade-offs you are making. And don’t ignore the time frame of any expected ROI. Most early-stage VCs invest with a 10-year horizon.

"A garden takes time to cultivate before you see the flowers bloom. Early-stage startups are definitely not get-rich-quick schemes. "

If you need to make a lot of money quickly, early-stage startups are not your best bet.

Step 3 : Why is joining an early-stage startup a fantastic idea

1. A free ‘personal growth 101’ class

There is a lot to be done and everyone has limited bandwidth. You are mostly on your own. You will need to figure out how to do things yourself. How do you make technical choices? How do you sell the product to a potential customer? How do you pitch the team and its culture to a potential candidate? How do you say no? How do you prioritize for maximum output & outcomes?

There are no manuals to refer or company best practices to follow at early-stage startups. You’ve got to write these yourself. The learning curve is really steep when you get down to laying the foundation. Once you do these things from scratch, you’ll realize that you can figure out most things in life. You don’t have to rely on external folks/factors to accelerate learning. This builds a lot of self-confidence.

"Startups test your character and your core beliefs. "

How do you react when you are under pressure? What choices do you make when nobody is watching? How do you handle rejection from investors and customers? Are you able to take critical feedback and improve? You will uncover a lot about yourself while navigating such choices.

2. Diverse exposure

Are you an engineer? Great! You also have to pitch and sell the product to early customers. Are you a sales ninja? Cool! Please pitch in for writing the social media posts too. You do marketing? Awesome! Can you get on some customer feedback calls as well?

Sure, late-stage startups and large enterprises allow you to develop vertical depth of subject matter. But early-stage startups equip you with practical knowledge of how different verticals work and how they interact with each other to form a well-functioning organisation.

Early-stage startups push you to get out of your comfort zone regularly by exploring things out of your domain.

This experience will equip you with a lot more tools in your professional kitty. This diverse exposure is really useful in the job market of today and of the future.

3. Low risk, high reward investment (equity/ESOP)

I understand the value of equity wealth. In fact, one of the main reasons that I quit my day job to startup was to generate equity wealth.

Typically, early team members at startups get 0.2% — 2% equity share (depending on your experience, contribution, stage of the company etc). Early equity is given for risk rather than contribution. That’s why a founder’s equity is much higher than that of early team members.

Let’s run the numbers and see how early equity pans out in three scenarios. The assumption here is that you work at a fictitious startup that’s paying you a salary of 100K USD per year along with a total of 100K USD stock options (vested over 4 years).

Scenario 1:

equity-1.png

Assuming the startup is growing at 2x in valuation for the first couple of years, your equity will be worth 1.6 million USD. In contrast, you’d only make 400K USD as salary over the 4 years.

Scenario 2:

Assuming the valuation grows at the rate of 2x for the first two years; post which, it grows at 1.5x each year. In this case, your equity will be worth 900 K USD.

equity-2.png

Scenario 3:

Let’s take an even more conservative approach and assume that the valuation only increases 1.5x each year for the entire 4 years duration of your vesting period. Even in this case, your equity will be worth 506,250 USD.

equity-3.png

While the gap between equity wealth and salary wealth has narrowed down significantly from scenario 1 to scenario 3, equity wealth is still higher than the overall salary for a startup walking a conservative growth path. Of course, the equity wealth can reduce to zero too if the startup shuts down or the valuations take a downward spiral.

Since most startups pay competitive salaries, ESOPs give you an extreme financial upside while limiting the downside. This ensures you can pay your mortgage, send your kids to school and also save for the future.

In light of the context above, you should have more clarity on whether the decision to join an early-stage startup is worth it for you.

I hope this helps you in reaching your decision. Happy to answer any other questions that you may have around early-stage startups. You can reach me at arpit@appsmith.com

P.S — In case you decide that you want to join an early-stage startup, we are hiring for engineering roles. Hit me up and let’s chat.