Lesser Known Form Of Procrastination
A subtle form of procrastination that most people often don't talk about is overpreparation.
This is not a type of procrastinator who doesn't like to do anything. This is a type of procrastinator who wants to perfect themselves for the task before taking action.
They want to read everything and watch all the available tutorials. When asked questions they can answer with rather surprising details.
But here is the problem. They don't seem to get anywhere regardless of their knowledge.
Someone with minimal knowledge may be having adventures but they are stuck.
Personal Story
I'm one of those who wants to learn everything beforehand and acquire every piece of information before doing anything.
I classify myself as an analyzer or rather over-analyzer. Someone who takes pride in logical reasoning and coming up with the best solutions by taking all the alternatives into account. I take my time before every decision to make sure it's not a stupid one.
This is bad because most successful people share a trait which is that they make decisions quickly with firmness. They do think about it but not as long and hard as average people. They don't take a lot of time before reaching decisions and once they reach a decision they don't easily change it.
They have a problem-solving approach to life they have the confidence to fix things that they overlook and nothing is set in stone. They will always have the option to ask forgiveness if they made a huge oversight in their decision and hurt someone.
Unsuccessful people take a long time before reaching a decision and once they reach it they don't commit. They are quick in changing the decision they previously made and are easily influenced.
I have my share of annoyed impatient people who want everything quickly. I label them as someone with short-term vision who can't resist the lure of instant gratification and they are doomed to fail. Are they?
Nope. It's not that simple. There are a lot of them who are successful. I am just projecting my insecurity on them. I don't want to seem impatient myself. I want to seem like a secure person. Who offers freedom and doesn't going to bother someone with constant pressure to be quick in their act.
I frown upon people who just can't seem to wait. I don't want to be frowned upon myself. That's probably why I keep distancing myself from my impatience and keep rejecting it as bad.
I should find a way to integrate my shadow side into my personality, instead of suppressing my impatience. I should view that as a sign something is wrong, I should act quickly instead of waiting around.
Problem With Information Overload
The problem with gathering unnecessary information is that most of the time it leads me down the road of acquiring unnecessary information that I don't even use. For example, I once watched a 4-hour course and never applied that knowledge anywhere.
Gathering useless information beforehand is counterproductive because:
It gets outdated quickly and you will eventually need to get updated with the latest information.
You waste time learning everything that you don't even need to know to do the task at hand and since you didn't use that knowledge you eventually going to forget it. You lose what you don't use. If you just want to know how to create a branch in Git then Google it. There is no need to go through a 20-hour course.
Before we go further I want to emphasize that anytime I say tutorial or course. It doesn't mean it has to be paid. YouTube is filled with free courses and tutorials.
Value Of Doing Long Courses
The value of going through a long course like I once did a 60-hour course is to save time. I think wasting months if not years to acquire the same knowledge with trial and error is worse than taking a long course.
You learn what experts in the field know rather quickly. It's a form of delayed gratification. The only thing that will be left for you is to figure out a way to apply and practice the knowledge that you acquire.
What I am against is learning something that you think is good to know without asking yourself if you need to know that right now and for what purpose.
If you're a beginner you need to pay your dues and need to spend time acquiring the essential knowledge. It's either through trial and error also known as building things and Googling your way through it. Or you can do a long-winded course and learn everything. One learning approach is more active while the other is more passive.
Combining Active & Passive Learning
I prefer doing both. I built my website after completing a basic web development course. You can check that out here: http://wasimapinjari.netlify.app
I learn a lot doing this. I have to figure out SEO, security, how to install Google Analytics, and check reports to name a few. I lose track of time building it. It's interesting. I don't think that's in the scope of the course to teach that. That's why actively learning and doing things on your benefits you more than passive learning. You learn the most important stuff first and learn the optional good-to-know stuff later as you move forward in your journey.
To illustrate the value of combining both approaches, let's take an example.
Let's say you're doing interviews after interviews and no one is telling you what you're doing wrong. You're just getting rejected left, right, and center.
After some frustration, you decided to take an interview course from someone who had experience interviewing people at Google. That person tells you what they look for and you gain valuable insights about what you may be doing wrong all along in interviews.
You may learn that:
You want to keep your intro short since you're not going to get infinite time to solve the interview problem. Quickly go through your resume in reverse chronological order and tell them what value you bring to the company by matching the skills you have with the job description. You can put your open source contribution as relevant work experience if you don't have much experience to talk about.
You need to tell the interviewer what different ways you could potentially solve a problem (algorithm design skills).
You should ask clarifying questions about the problem and point out the edge cases. Figure out the limits by asking what you can and cannot do. They might test you by not providing you with any details to see how you deal with ambiguity because you're paid to do the work and you may have to figure details out yourself as a part of the job.
What is the algorithm's time/space complexity (algorithm analysis skills)?
What makes you decide to choose one algorithm over another to solve the given problem (maybe because you have less time or maybe because it's more optimal or maybe there are space restrictions)? Sometimes you may point out some algorithm that is hard to write like the KMP algorithm just to let them know that you know what might be a better-performing algorithm. They might be hoping that you solve the problem with the easy less-optimal solution and know you're on a time limit which shows you're aware and good at time management. Also, you're not just some over-optimizer freak who is oblivious to deadlines.
You have to explain the thought process behind your code as no explanation (code analysis skills) means you're a bad communicator and unsuitable for a leadership position that you might get promoted to. You will make decisions at work without bothering to explain your thought process to the team. Ideally, explain as you write but it's not required you can write the code and explain your thought process later.
You may have to write the code in small handwriting and start from the top-left of the whiteboard for further code refactoring and solving follow-up questions to your solution.
You may need to write clean good looking code using classes, methods, and properties (writing maintainable code skills).
You may need to know how to handle behavioral questions beforehand like tell me how do you handle a conflict in the past? What's something that you didn't like about your last job? Where do you see yourself in 5 years? The pattern of answering all these questions is the same just be honest and positive. Being honest doesn't mean you tell them everything you can omit negative information since they are strangers and you can't expect them to accept you as flawed and have empathy. You will get plenty of time to make them understandable friends later once you get hired. Resist being negative in your answers. If they ask what your biggest weakness is then don't say you're an arrogant narcissist say your good-bad qualities followed by how you fix that problem. For example, I have high standards for my work and people might get frustrated at me for being slow. I figure out that managing expectations through communication is key to solving interpersonal problems. The reason for reading the job description carefully before interviewing is they might be a startup and looking for someone to work fast. Even if this answer is good they might not like to hear that and reject you.
It may be a good idea to bring your resume and whiteboard pens with you. If the interviewer can't find any one of those or worse both then it's your fault and you won't get extra time to solve your problem.
Come up with nice questions beforehand to ask the interviewer in the end. For example, what is the best part about your job?
You may want to say thanks to the interviewer and possibly end the interview on a high note. Since the last impression is the lasting impression. How you made them feel is the last thing they will remember about you. This itself won't be going to make them hire you on the spot. But if they have another more suitable opportunity in the future they might reach out since you're so nice to them and feel free to send them a thank you letter over email as well after the interview.
These are a few guidelines. Sure you can figure these things out yourself through expensive trial and error or you can learn that from someone more experienced than you.
Limits Of Imagination
Another argument for why I don't consider a long-winded course a tutorial hell is this: For me to come up with a solution I must know what tools I have at my disposal. How I am supposed to figure out a solution to a problem without having a proper understanding of what tools I have? I can't Google what I don't even know exist.
For example, let's say I don't know if there is an array map method in JavaScript. I am not going to Google search that because I don't know it exists. I will use a for loop to find a solution to my problem. Is it going to be right? Yes. But are there other better and easier ways? Definitely.
Knowledge of tools allows us to come up with better solutions and be more productive with our time. Sure if you're contributing to open-source projects you will learn these things by either looking at the code and figuring out what this new-looking code does, or asking more experienced developers in the community or you may get this knowledge as feedback to write your code in this way.
A lack of knowledge or perspective is a hindrance to our ability to imagine and come up with novel solutions.
Sure you don't need to be hyper-optimized, productive, and obsessed about performance. The difference is not going to be major anyway unless you're doing something crazy like rendering a 4K 3D model in a game. You just need to ship the working product. And iterate as you go. There is always going to be time for writing better algorithms and code refactoring.
Understanding Tutorial Heaven
Tutorial hell is an over-hyped notion. I think it's tutorial heaven if you're gaining knowledge from someone whose content is extraordinary. You saved the pain they went through to acquire knowledge.
You may be wondering what about the fact that when we learn things ourselves through pain they stay with us longer. Is it better to learn things the hard way?
Maybe. It's your choice.
What I learned through doing open source contributions is learning actively is way more fun and engaging because you are solving real problems, you get feedback from other people, and sometimes instantly if you're contributing to an active project.
You feel good and get a sense of accomplishment when your pull request gets merged and you grow with the community which is there to support you. You see the project getting better with time and sometimes that can be satisfying to watch.
It might be not as painful as you imagined. You might be misled by someone like me. It's only painful when you're completely oblivious and you are looking for spoon-feeding.
Overcoming Analysis Paralysis
I also tend to waste time gathering information beforehand that I could collect on the spot by just asking simple questions and paying attention.
What this looks like is I start paying attention to someone and start assuming things about their wants, needs, personality, where they might come from, whether are they going to find me interesting, etc. instead of going there and just starting a conversation and figuring that out on my own rather quickly. I argue that I need to know more about them before I open my mouth. I need more data.
Or another example is I could listen to talks about open source and hear what's the best practices and whatnot. Rather than actually jumping in and just playing around and figuring things out as I move forward.
The problem with too much data is it often fails us. The more you know about something the more certain you get. With certainty comes confidence or rather over-confidence.
And certainty is the root cause of most bad decision-making. Uncertainty makes you look for alternatives being certain makes you blind to them.
Their also a paradox of choice at play here the more options you have the more that will freeze you and the harder the decision-making gets. It's exhausting and anxiety-provoking. The more unsatisfied you will be with whatever choice you make. Grass will be always greener on the other side.
This is what happens when you look for the best. If you strive to find the best you risk not even enjoying the best after you find it. You wasted too much time in your quest for perfection and you know too many other alternatives. You're induced with this question of whether is this the best one. Did I make the right choice? What if there is something even better out there?
The other problem with looking for the best is that human beings are adaptive. They get used to things. If I go around looking for the perfect coding language. I might discover they are all the same with slight variations in syntax and features. Everyone has their strengths and weaknesses. I might be better off just choosing anything that's not too far off from meeting my standards.
The ideal action is often to just get started doing things and gather information as you go. It's way more fun to live life like that just take whatever is good enough for you and stop looking.
Let your intuition and unconscious take over after getting started. Your brain is constantly analyzing patterns to get better at rapid decision-making.
It's life and death for your brain. We are forced to do things instantly all the time. Imagine finding your friend approaching a bus while being on the phone. That's when we rely on our instincts and gut feelings. All the unconscious learning is at play. There is quick pattern recognition and you know what to do in a split second.
This is one reason why you see everyone saying learn by building and get out of tutorial hell.
Your brain is a machine that feeds on data. The more data it has the better. It starts catching up with the patterns and you start honing and developing accurate instincts and gut feelings.
The best way to illustrate this is for you to start recalling how you learn your mother tongue. Did you go through grammar lessons or a dictionary containing the meaning of every word? No.
You're forced to learn it. You must know what people are saying. You're a dependent infant. You start making sense of what people are saying by watching them closely. Their tone of voice, body language, and behavior. You try to feel what emotions they are feeling to assess the situation. You take clues from the environment, the objects they are holding or wearing or showing off or giving to others. Every detail and nuance is the raw unprocessed data to make sense of the words that come out of their mouth.
If you see they are holding a piece of paper and calling it money. Then you associate that paper with the word money. You see them getting emotional over money. You figure out that must be important.
You're learning actively rather than passively.
Passive information gathering is a form of procrastination to keep ourselves from failing. It also comes from a desire to please with flawless perfection. Which seems to me a defense mechanism to keep oneself from looking flawed and signaling others that they are indeed unworthy of attention.
Or maybe it's not and you might have high standards for your work. You may have good taste and know what good things look like.
I am attracted to amazing things and I unconsciously know unless I have that I will have a hard time getting any attention.
And it often takes a lot of time to get recognition by progressively pushing out mediocre work rather than something extreme and extraordinary that grabs people.
I don't know the exact science/psychology behind procrastination. The only thing I know is that awareness is the first step toward change.
A Better Alternative
I will recommend starting small and building upon it. Go one step at a time. First, get comfortable and practice the basics and avoid learning too much too soon. You must practice what you learn to make knowledge stick and see results quickly.
Don't just learn everything and ask what now.
For example, if you want to learn to become a social butterfly then start by holding eye contact with people, after you get comfortable doing that you may want to start asking strangers for time, after you get comfortable asking try to hold a conversation a little longer by asking random questions after asking for time. And so on.
When I first started with open source. I only know a handful of Git commands. I didn't know how people collaborate using Git.
I watch a video of someone walking me through how to find an issue in an open-source project and fix it. I learn I have to fork a project, run the project locally, find an issue, create a branch, solve the issue, commit changes in a newly created branch, push it to the forked repository, and make a pull request.
This is me learning incrementally. I don't have to finish a 20-hour Git course and learn every single command. I just learned what I needed to do the thing I want to do.
I started by opening small easy issues and fixing them. I am looking forward to moving on to solving other people's issues.
Considering A Gray Area
I may seem all over the place with this article.
I realize most people including myself have black-and-white thinking caused by having a limited perspective on things but everything exists in a gray area.
For example, someone is not untrustworthy or trustworthy. It's not an either-or. It's more like someone is untrustworthy to do some things and trustworthy to do other things.
For example, you can trust me to help you with your CSS code but don't trust me to fix your teeth because I am not a doctor.
What's good about something is often bad about it. Procrastination is good if that means the end result is close to a perfect product filled with creativity which is often the result of delay since coming up with novel new ideas takes time, curiosity, and some showering. You shouldn't expect much creativity and originality if you're rushing to do something.
Similarly, if you think free software is amazing maybe it's not as amazing as it could be because it's free and some developers don't have enough resources to make it better by hiring amazing people to work on it. Why should they? What do they get? Bunch of complainers and pissed-off people.
Just like I don't have the resources to hire a good editor to edit this messy article. It seems like I mixed three different unrelated articles into one.
All jokes aside, thanks for reading!
Follow me: Wasim A Pinjari
Links: wasimapinjari.bio.link