On bootcamps and new jobs: My review of the Firehose Project

It’s almost been a year since I’ve graduated from the firehose project.

An entire year has offered me a lot of prospective to gauge my bootcamp choice and measure it against other possibilities. I’ve met students and those that have interacted with students from other bootcamps. My company’s office just recently moved out of 1871, a tech hub filled with bootcamp students of all varieties. I’ve seen their code, their portfolios and job applications and I can confidently say that if I was to do it all over again, I’d choose the firehose project without hesitation.

For me, it comes down to a combination of quality coursework, great value, and amazing people.

I think the root cause of all three factors comes down to the fact that the firehose project is run like a startup.

It’s small and nimble. Unlike some of the larger bootcamps out there with 20 different courses(some taught by other bootcamp graduates without any professional experience), there’s only one course at firehose. This means there is a lot of attention into improving the student experience on this one course. The founders created and teach it and their passion directly cascades to the rest of the firehose students and alumni. Besides the founders, I know there is a huge effort put into finding other amazing mentors with actual experience and their portfolios are all listed on firehose’s site. For a large bootcamp program operating nationally with huge cohorts, there’s just not way to maintain the level of quality as a small program run by the founders.

With that being said, I believe the greatest predictor of a boot camper’s success is their passion for coding, and their willingness to continue learning after they graduate. I took the extreme approach and treated every coding project post-graduation as an opportunity to push the boundary of my knowledge. In other words, how can I challenge myself and optimize for growth? How can I take on freelance projects and/or job responsibilities that best positions myself for the future?

If the proof of the pudding is in the tasting, how has the firehose project impacted me?

Before I enrolled in the firehose project, I was a non-technical entrepreneur. I also had dabbled for a month in html and css through online resources but that was the extent of my coding experience. Full disclosure though, I did graduate a year before that with a hybrid engineering/business degree (non computer science related though).

Over the last year, I’ve built two apps that have been published on the iOS and Android app stores. I’ve taken on over half a dozen freelance projects and I’m currently working full time for an amazing startup(foodjunky) as a hybrid front-end developer and UI/UX designer.

foodjunky’s yelp integration

At foodjunky, I have the responsibility for designing our company’s product and implementing the code to support it. It’s really rewarding to be able to take an idea or feature from design to launch and have it be used by thousands of people. That’s really cool to me. Since our company has partnered with yelp, I’ve had the opportunity to design and ship a food ordering integration for yelp’s desktop and mobile apps. Over the next months, we’ll be rolling out version 2.0 of our main site. I’m really excited to be given the responsibility of designing the foodjunky experience and to participate in building the actual business.

For new developers out there, I have one advice for landing your dream job: be ridiculously over-prepared.

Some job-seekers like to take a mass spam approach. I did the opposite. I was very selective about which companies I wanted to work for. I was looking for good opportunities that let me punch above my weight.

After that, I would invest a lot of time into understanding the market and their product. I’d come up with a list of business suggestions and use that as a launching pad to ask insightful questions about their business model. You have to “get” what they are trying to do beyond an intellectual level. It’s really important to be able to empathize with the pain points the company is trying to do. I came into job interviews or job applications with fully prepped redesigned home pages and user interfaces.

I think it’s silly not to do this. This is maybe a 10 hour process. By investing 10 hours, you put yourself way above the rest of the crowd. If you aren’t willing to invest 10 hours into your dream job, you don’t really want it bad enough. Plus, demonstrating this passion always comes in handy in the salary negotiation phase *wink wink*.

How to Solve Coding Challenges

Its been 8 months since I’ve graduated from the firehose project. Man, has it been a ride. Since graduating, I’ve learned half a dozen new technologies, brushed up on fundamental CS concepts, and even landed a job working full time for an amazing startup (more on that later).

Basically, I’ve done my share of coding challenges and I thought I might offer some insights and mindsets into how to systematically solve these problems.


When you’re solving a coding problem, I think its best to take a top down approach. Here’s the 5 steps I take. Don’t worry if it doesn’t make sense now, I’ll be walking through these steps with a detailed example.

1.) Read and understand the nature of the problem. Usually, a coding challenge has a “trick”. The problem description will outline the boundaries of the problem, you’ll need to play around to get a “feel” for it.

2.) Develop a high level strategy. Break the complex problem into smaller, simpler parts. Don’t freak out if parts of the plan are really hazy. You should realize that you’re not supposed to be able to know the solution right after reading the problem. I know this seems obvious but its a really crucial point.  Don’t freak out and give up because you don’t know the answer. Just start with what you know.

3.) Start blocking out the simple parts of your code. Keep things general and even in pseudo code. Don’t worry about implementation of the tricky parts. Solving a coding challenge is like solving a puzzle. It’s obvious where the corner pieces go but the pieces in the middle are a lot harder to place. Once you have enough of the edge pieces in place, the rest begins to fall into place as well.

4.) Start implementing the easy portions of your strategy. Just get something working. The code doesnt have to be perfect, and it DEFINITELY doesn’t have to be optimal. Once you get something working, you can go back and refactor it.

sketching15.) Repeat steps 2-4. Lots of times, you’re going to need to change your big strategy. That’s ok, take what you learn and revise it for the better. Being a good developer means trusting in the process and being comfortable with unknowns. Great code is written iteratively. Ernest Hemingway said “The first draft of anything is shit”. Code is no exception.


I’ll be using the Binary Tree Sort problem from the FHP as an example. So from here on out, spoiler’s ahead. 🙂

1.) Understand the problem. Go ahead and review the problem from the FHP. You’re told to build a binary tree and then traverse it. We’ll just worry about building a binary tree for now. The problem description tells you what a binary tree is and provides an example. Almost always, I like to sketch out a few more examples. If you do this, you’ll discover certain behaviors of a binary tree.

The key behavior is that the nodes on the left are always smaller than the nodes on the right.


And this also creates a systematic pattern for part 2, when we need to traverse a binary tree:


Notice that there’s nothing here that’s too tricky. All you have to do, is build out a couple example binary trees by hand, and then traverse it by hand and you get a feel for how the code could potentially work.

Now we move on to step 2, develop a high level strategy.The more you code, the more you start thinking like a computer. You’ll begin to think The Ruby Way™. This step becomes more intuitive with practice.

2.) I know I’m given an array and I need to build a binary tree out of it.

array -> [my code] -> binary tree.

From step 1, I also know procedurally how portions of the code could work. From a high level, I’ll need to start building from the first item in the array. This will be the root node. Take the second item, and if its smaller, put it to the left, if its larger, put it to the right. Then I’ll take the next item, and start from the root node again. If there’s already a node where the new item is supposed to go, I’ll travel to that node and repeat the process above, placing new items in the array as leafs of the outermost nodes.

3.) Break these instructions into composable components. You might only know how to translate small portions of these instructions into code, and thats ok.

Here’s the main components that jumps out at me:

– Ideally, I want to be able to run some code like this to get the answer:

Screen Shot 2016-05-01 at 10.36.02 PM

so, I’ll need a Tree Builder class that actually builds the Binary Tree.

Screen Shot 2016-05-01 at 10.27.59 PM

-I’m given an array, I’ll need to iterate through it to build the nodes of the binary tree, so I’ll probably need some kind of loop.

Screen Shot 2016-05-01 at 10.05.27 PM

-I’ll need to iterate the array through some kind of sorter that handles the logic for building the nodes.The sorter will somehow have to compare the current value to a node. At this point, I realized I should change the block iterator argument’s name for clarity. Here’s the logic I came up with.

Screen Shot 2016-05-01 at 10.14.48 PM

Note, I have no clue right now how I’m going to pass in the array or how I’m going to pass in current node. I don’t know how I’m going to insert the values or traverse the node. I don’t know those parts yet, but I’m pretty sure I need some kind of logic like the ones above.

3.) Block out the code.

Putting these three pieces together…here’s what I now have. In the initialization method, I build the root of the binary tree from the first element in the array and then shift it off the array.

Screen Shot 2016-05-01 at 10.32.52 PM

Steps 3-5) Iterate and flesh out the code.

Ok, so now we’re cooking. We just need to implement 2 more pieces of logic. Something that handles “insert” and something that handles “traverse”. The “build” method is getting a little bloated, so I decide to separate the insert logic into its own method. Be aware, I still don’t know how I’m going to pass in the “current_node” yet.

Screen Shot 2016-05-02 at 12.15.59 AM

This is all well and good for 7, 4, and 9.

Screen Shot 2016-05-01 at 10.52.56 PM

But now for the 4th item, TreeBuilder can’t just insert the node in. It’s gotta go down a node.


We’ll need to go from node 7, to node 4, and then insert node 1.

So to me for this iteration, the  insert_into_tree method will need to do something like this:

Screen Shot 2016-05-01 at 11.01.48 PM

This would work for value 1. But what happens if I need to traverse 4 nodes? I need to keep looping through the traversal and insert logic.

Screen Shot 2016-05-02 at 2.53.28 AM

Ok this could work. For the sake of being academic, how else could this be solved? To me, the traversal logic is a little ugly. I feel that a recursive approach could be more succinct and also better represent the logic of the problem (binary trees are recursive). Here’s what I came up with:

Screen Shot 2016-05-01 at 11.05.05 PMScreen Shot 2016-05-01 at 11.06.05 PM


Now with some refactoring of the “build” method…

Screen Shot 2016-05-01 at 11.11.00 PM

…and we’re at a solution! Note: This code can be refactored some more to be more readable, modular and dry. Bonus: What scenario would cause this code to break? Which version, iteratively or recursively, is more efficient?


Ruby Sets: Array’s and Hash’s love child

I’ve recently been diving into algorithm problems in preparation for my technical interviews. A lot of these questions aren’t just about finding a solution, but finding the optimal solution and figuring out its Big O complexity.

For those unfamiliar with Big O notation, it’s just a way of thinking about how well your code performs for really large inputs. Lets take a look at a concrete example.

Say we are given an array of numbers and we wanted to know if there is any combination of 2 numbers which can add up to 11. Here’s one implementation:

Screen Shot 2016-02-16 at 6.47.56 AM

For each number in the first loop, we compute the complement value, and loop through the array to check if it exists. (note: this code is a little sloppy because it does double count values, but for simplicity’s sake, we’re not going to worry about that. also note that for the inner loop we can use “numbers.include?” but under the hood, ruby would be doing the same thing.)

This loop inside a loop means if there are 6 numbers in the array, we are performing 6*6 operations. So as the input array becomes really large, we’ll essentially be doing n*n operations. This means our algorithm has a Big O(n2).

We can actually drastically improve the performance of our algorithm and achieve O(n) runtime by using a data structure called a ‘set’!

A set has a lot of similar functionalities as an array and it has the really fast look up times of a hash.

A set is very similar to an array; it’s a collection of values. However, there are 2 major differences:

  1. A set is unordered. There’s no index to a set. It’s just a pool of values. So while you can do ‘array[3]’ to return the value of the array at index 3, you can’t do this with a set.
  2. You can’t store duplicate values in a set. It’s all unique values.

Other than that, you can manipulate a set in a lot of the similar ways as an array because you have access to the enumerables methods.

However, since a set stores its values as hashes, we get constant time lookups! So no matter how big the input array is, the time to check if a value is in a set will be the same! Using sets is very simple.  We can refactor our code to this:

Screen Shot 2016-02-16 at 7.20.50 AM

There’s a lot of other interesting things you can do with sets. You might not use it much in the wild but it’s a fundamental data structure and something you should absolutely be acquainted with before you head out to the job interview! You can read more about it here.

Difficulty is a Mindset

It’s a pretty well known and well repeated experiment.

One version of it has two groups of asian american women take a math test. In one group, they are reminded that asians perform better on these tests and are asked to take it. In the other group, they are told that women usually do worse on math test, but to view this as a challenge and take the test anyways. The results are pretty shocking. The first group performed twice as well as the second group. I’m not exaggerating here:

They doubled their performance.

Note: You can read more about this series of experiments documenting the “stereotype threat” on wikipedia.

So what the hell is going on here?

When I was a child, I never thought of myself as “smart”. I wasn’t a fast learner and I definitely wasn’t a fast thinker. I remember we had these math quizzes in school where you are supposed to solve as many addition or multiplication problems as possible. I was never even close to being the fastest. When I started middle school, I was ecstatic when my teacher told my parents that I might be placed into an accelerated math class (it didn’t happen).

But something interesting started happening around the beginning of high school. Somewhere along the way, people just assumed that I was smart because I was asian. And it became a self-fulfilling prophecy. I just learned to do things because everyone told me this was just the way things are.

I’ve noticed a similar phenomenon in engineering classes in college. Some people are just so adamant that the class they are taking in engineering is really difficult. And when I studied with these people, things just magically became more complicated. It wasn’t like they were dumb or anything, but they seem so wound up that they couldn’t think straight. In their minds, there wasn’t a possibility that the problem they are working on could be anything but hard, and so it became so. Things become a lot more difficult if every step of the way you believe the topic is beyond your ability to solve: you’re constantly looking for evidence to support this belief and give up.

Here’s a thought experiment for you:

An online coding bootcamp, The Firehose Project, is supposed to be a 12 week course. What would happen if the entire coursework was marketed as a 6 week course, and all the students and mentors you met told you that it was a 6 week course, and also that, by being admitted into the firehose project, you had been rigorously selected as a bright and high potential developer? I bet suddenly (and magically), what would have taken you 12 weeks to complete is now accomplished by you in half the time.

But what does difficult mean anyway?

A useful way to view difficulty is “one’s personal tolerance for uncomfortableness”.

When we encounter a problem, we either look at it and give up, or we try to break the problem into simpler components. We keep breaking the parts down into even simpler parts until we can solve all the pieces and then put the pieces back into a solution. That takes a lot of work and work is generally uncomfortable for us (we’d rather not be doing work).

Some people have a high tolerance for uncomfortableness and they are able to do a lot of work before they give up. Your tolerance is something entirely within your control. You have to ability to determine where you set the thresholds for “easy”, “medium” and “hard”.

Note: this is one of the reasons why meditation can be so dang effective at increasing performance because it provides tools to work through these uncomfortable mental states.


I’m not writing this because I have some naive belief that “intelligence is illusory, if you just suddenly decide to, all the solutions will magically appear in front of you”. Nor do I think that you can just consciously decide one day to change where you set your tolerance thresholds.

I think that if you have respect for how strongly this phenomenon can influence performance, that if you stop identifying with the beliefs, and learn to productively work through these mental states, you will definitely become “smarter”. The mind is a muscle and through sustained attention and intention, you can gradually change these perceptions.

To conclude, I leave you with this amazing motivational clip:

Read this when the hard (fun) part comes.

There’s a certain draw to being an entrepreneur. An idea strikes you. You hustle and grind and eventually hit a wall. Through sheer determination and a little luck, you break through the wall and build a legacy that persists past your retirement. You’ve turned your vision into reality. You’ve made the world a better place all the while becoming a few dollars richer.

It’s an intoxicating story.  People want it. You want it. You take the mantle of entrepreneurship. But buyer beware: the hard part will come. You are not exempt from the process.

Go ahead and ring your bells, light your candles, and call out to God, but beware, because when He comes, he will put you on his anvil and beat you and beat you until he turns brass into pure gold.

Sant Keshavadas

You know what craziness is? We know everyone dies.

We know everyone will become old, their mind decays, their body loses its vigor. They will lose their hearing, they will lose their eyesight, and they will lose their mental acuity. But we never make the connection that this process will also happen to us.

I think something similar happens in entrepreneurship. You always hear stories of entrepreneurs who have doubted themselves only to find success on the brink of calling it quits. Or you hear of all the disasters entrepreneurs face that almost certainly spells the death of their company. But they prevailed. We think: yeah, disaster will strike, startup is hard, founders will doubt themselves. But not me. It’s going to be all rainbows and sunshine. It’s going to be smooth sailing for me.


Take a look at Paul Graham’s startup curve.


It’s the prototypical startup growth chart. Everyone goes through it. Here’s some examples:

AirBNB – People think airbnb was a overnight success. Balony. They struggled for two years before finally achieving product market fit. AirBnB was originally a company trying to provide overflow housing for conventions and festivals. Highly recommend watching the very entertaining and inspiring AirBnb story.

Slack – People think Slack, the newest billion dollar darling, was an overnight success. Wrong. The origins of slack actually began in 2009 as an internal communication tool developed by a gaming company, Tiny Speck. Fast forward a few years later, Tiny Speck fails, they lay off a significant portion of the company and re-formulate their chat tool into Slack.

Twitter – Originally a service to share podcasts which was made obsolete by Apple’s iTunes store.

Instagram – Originally a location-based check in service similar to Foursquare. The app was complicated and confusing. Eventually, they pivoted into an image sharing platform.

Ok, so you know the hard part will come. It always does, because it’s the real initiation into entrepreneurship. That’s right. I don’t think you become an entrepreneur when you ship your MVP or when you incorporate your company. Nor when you get your first business cards or a company email address. I think great entrepreneurs are made when they encounter their first crisis or moment of great doubt. It’s the feeling of the great abyss in your gut that threatens to swallow your entire existence. It’s your heart pounding so viscerally that you feel the palpitations induce a headache and you can’t think straight but you have to anyways.

But it’s also the fun part. It’s when the game begins and you are provided with opportunity to test your wits and discover what you’re made of. The hard part is the excitement of entrepreneurship. Because in reality, without the crisis and moments of doubt, entrepreneurship would be really boring. It wouldn’t be fulfilling. It wouldn’t be what you signed up for. Screw the smooth sailing. You want some waves baby.

With all this being said, the hard part is hard. Here’s are three concepts that might help you navigate “the trough of sorrow”.

  • Twitter’s original idea blew up instantly. They actually went through 3 or 4 more pivots before finally arriving at the product we recognize today. Tiny Speck blew threw millions of dollars of funding from some of the top VCs. They failed hard core. Great entrepreneurs don’t always make the right decision. But they will make their decision right. Given what you’ve done, how can you make the most of it? Every disaster is an invitation to reformulate your thinking, gather insight and recalibrate your push forward.
  • Ok, your traction sucks. Your retention is poor and your active user’s chart is sideways. But how fast are you learning? Because you should focus on your learning curve. How fast are you getting to where you need to be to make the traction curve better? Sometimes, product market fit is more like a step function than a continuous curve.
  • Find an emotional anchor. I have a playlist title “When the going gets hard”. Whenever I begin to doubt my ability. I go for a jog and listen to the playlist. I’ve anchored a certain mental-emotional state to this ritual. It reminds me of why I’m doing what I’m doing and to keep my eyes on the ball. Have a ritual that you can retreat to, recuperate, and come out fighting.

“Today is cruel, tomorrow will be worse, but the day after tomorrow will be beautiful. Most people stop tomorrow evening and never get to see the sun shine.”

Jack Ma

This is the hard part. Don’t give up.  This is where you make your glory. When you look back at this moment in 10 years, this will be your greatest war story. This is what makes you a bonafide entrepreneur.

This is where the game begins. Savor it.

Further reading:

How not to Die – Paul Graham, founder of Y Combinator

Startups don’t die, they commit suicide – Justin Kan, co-founder of Justin.tv and Twitch.tv

The Signal and the Noise

If you’ve ever tried to build something, you will get plenty of (unsolicited) advice.  During our startup’s interview for an accelerator, we asked the managing director “What is the most common challenge first time entrepreneurs face?”

His response was surprising. He said one of the biggest struggles that young entrepreneurs face is that they are given so much advice on which direction to take their company and 90% of it is complete BS.

So the question becomes, who should you pay attention to? Who’s advice is relevant and who should you ignore? In other words, how can you separate the signal from the noise?

As a rule of thumb, I disregard the advice, opinion, or criticism of anyone who isn’t doing or hasn’t already successfully accomplished the subject matter at hand. 

So following the advice of a championship bodybuilder is a great way to become a successful bodybuilder.

I know this sounds simple. It sounds deceptively simple. But if you are mindful, you would be astonished by how much attention you spend on the noise.

When you’re trying to do something new or different, you will inevitably be met with a lot of discouragement from the people around you. Some of that might be from people who subconsciously don’t want you to succeed.  Other times, the advice could be from someone who just doesn’t fully understand you idea.

Before you take their advice, or listen to their criticism, ask yourself: Have they accomplished what I’m trying to do? If the answer is no, ignore what they have to say.

Feedback – an underrated concept that goes a long way (part 1)

One of the most overlooked concepts that I have personally struggled with in the past few months is this idea of “feedback”. The response that an action gets. I’ve begun to apply the concept of “feedback” to as many facets of my life as possible. In this series, I will be talking about feedback as it applies to:

1.) Networking

2.) Management

3.) Product Development

First, networking:

As you carry about your business, you will encounter a lot of situations where you will need to receive mentorship, form relationships with business partners, create deals, or raise money from investors. No matter what the case is, the primary question on everyone’s mind is “is this person someone I can work with and are they capable of executing on my suggestions?“.

I’ve had the opportunity to work with some really amazing people, and one of the people that is the best at networking, being likeable, and forming relationships is the person that really mastered providing feedback.

Here’s what will happen: You will go into a meeting with a potential investor or mentor and during the meeting they will raise concerns or provide suggestions. When they do this, they are always looking at how you will receive this. Even if you completely agree and will likely implement their suggestion, its really really important to provide as much clear feedback as possible.

Yes, mhmm, that is really interesting point. I can see why ‘x’ could be an issue in regards to ‘y’. We will be conscientious of  ‘y’ moving forward. What do you think if we implemented ‘x’ in ‘z’ fashion, would that make a difference or no?

Similarly, after a meeting with anyone, we will always follow up through email. If there were any questions or action items during the meeting, we will execute on those. We will always summarize the meeting and provide feedback to the other party. A simple example:

Hi Fred,

We really appreciate you taking the time to talk today. A lot of the advice you shared will be very helpful as we continue to develop our product in regards to ‘such and such‘. As per our meeting, please find the document attached. We will follow up as we ‘meet such and such milestone’. Please let us know if you have any other questions. Have a great day.


It’s really that simple and very formulaic. But most people don’t do it. They don’t follow through. Implementing proper feedback will help you just crush it and rise above the crowd.

I’m a (serious) Business student with a (great) App Idea. What do I do next?

As the CEO and founder of an app startup and having minimal coding experience, I’m constantly approached by people with app ideas or inquiries of how to recruit engineers.

Most enter the discussion severely ignorant of the entire startup game. The following are some reflections and insights from someone who has successfully recruited some very talented and committed developers to join the team.

1. You can’t afford to pay upfront.

Many business people approach developing an app like a IT company might approach buying servers. You buy some, use it for awhile, then upgrade when it becomes obsolete. First, realize the product is a constant work in progress. It’s never finished. You’re going to need developers on your team working on the product on a consistent basis. That takes a lot of time (20 hours a week to make respectable progress), and if your developers have any experience, you should be valuing that time at roughly 30 dollars an hour. Just take a look at any app that you currently use, even something excruciatingly simple like snapchat or groupme changes every few months.

2. Do your due diligence

If your idea is really that good, why hasn’t it been done before?  There usually is some problem that others whom traveled down your path has encountered. What problem was that? And what makes you different, what do you know that no one else knows about this issue (ie what makes you particularly qualified to solve this problem)?

if you haven’t done atleast a hundred hours of research into the app idea and competing ideas, don’t even try recruiting a developer. why? it’s pretty unreasonable to ask a developer to spend several hundred hours developing your idea when you havent invested in an equal amount of time. i’ve had someone come up to me and say, “i dont know anything about apps, but i have a great app idea.” Take a moment to realize how crazy that statement is. If you dont know anything about apps, how do you know its a great app idea???

3. Have qualifications

If you’re going to make a consumer bar app, you want to have some knowledge of the pain points from the consumer side. But knowledge alone is not a qualification. Qualifications are based on skillsets not domain expertise. What experience do you have building a company, selling a product, or successfully executing on an idea? I would invest in a CEO with previous experience running a company thats never been to a bar in their life over a team of bargoers or bar managers who have no entrepreneurial experience.

The reason?

Domain expertise can be easily acquired. You can use google or take someone in that industry out for lunch. There’s no reason to even give up a substantial portion of equity for that. Skillsets are a lot more difficult to acquire. If you have no relevant skillsets and no past successes, think long and hard about why a team of developers should spend several hundred hours working for you.

4. Ideas are worthless,

I’m going to skip past the whole “no one cares about your idea and it’s all about execution” point that most people make. Almost no startup ever becomes profitable or successfully exits with their original idea. Your initial idea is just a starting point. You’re most likely going to pivot and figure out something that works along the way, so justifying equity for rough draft #1 is just silly.

One angel investor recently told me there is no place for “idea people” or “strategists” on a founding team. In a startup, you are either building or selling.

Just Start

I’ve been meaning to start a blog for awhile now as a way to organize, develop, and categorize my thoughts. I’ve been waiting for the perfect moment and the perfect subject to write about. Here’s the problem: the perfect moment never comes. So the first lesson that I will write about is this:

Just start.


It doesn’t matter how inconvenient or busy you are. Everyone is “busy” doing something, now be busy doing something productive.


Just start.