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.