Forem: Victor Cassone

How to use Deliberate Practice to learn programming more efficiently.

Victor Cassone — Tue, 19 May 2020 18:52:48 +0000

I truly believe anyone can learn to code.

At the end of the day, programming is a skill, and acquiring skill is open to anyone.

Sometimes getting good at something appears to be a magical process. But in reality, there’s a clear process to follow.

Anders Ericsson, a professor at Florida State University, is a leading researcher of expert performers. He studies the process of acquiring skill and what it takes to become an expert.

Through his years of research, he concludes that what separates top performers from everyone else is the amount of time spent in something he calls Deliberate Practice.

He believes that “The right sort of practice over a sufficient period of time leads to improvement. Nothing else.”

I believe the Deliberate Practice framework developed by Dr. Ericsson can be used to help people learning to program.

Implementing Deliberate Practice has helped me in my personal life and I believe it can help you learn programming more efficiently.

Below I’ll explain each component of Deliberate Practice and I’ll explain how you can incorporate Deliberate Practice in your coding practice.

Deconstruction

The first step of Deliberate Practice is to deconstruct and analyze your desired skill.

Deconstruction requires you to take a bird's eye view of your overall goal and break it down into small manageable components. You're trying to find the most efficient path from where you are to where you want to go.

There are two ways you can go about deconstructing a skill. You can either break down the components yourself or learn from someone who has already acquired the skill.

For someone learning to code, I'd recommend leveraging the knowledge of other developers instead of reinventing the wheel.

Most of the material out there(like freeCodeCamp) was created by people who have put effort into deconstructing the learning process and have iterated on the material.

You can leverage their expertise and effort when you're looking for your own path forward.

Flip through a few different coding websites or read the Table of Contents of various coding books(you can preview books on Amazon for free). Also, read a few blogs or ask a developer friend about their opinion.

After a while, you'll get a sense of the best path forward.

Also, make sure your interests have a vote. It's hard to learn quickly if you're not interested in the material.

The most efficient route to learning to code is at the intersection of what the experts recommend and what you're interested in.

Don't obsess about perfectly deconstructing the path to becoming a programmer. You'll never find the perfectly efficient route.

It's better to do a little research, start somewhere and readjust as you go.

Stretch goals

The next key component of Deliberate Practice is creating stretch goals.

A stretch goal is a small task that pushes you outside your current abilities and moves you along your deconstructed learning path.

Creating stretch goals isn't so much about having a huge list of tasks you need to complete. The more important part is setting up your learning in a way that pushes the boundaries of your programming skills.

We humans naturally favor the things that are easy and automatic.

However, if we push ourselves outside our comfort zones for long enough, our body will try to normalize the new behavior and make it a habit.

The objective of a stretch goal is to consciously put yourself outside your comfort zone and wait for your body to adapt.

The trick to creating a stretch goal is making the task difficult but still achievable.

If the goal is too difficult, then you'll get lost and won't know how to move forward. If the goal is too easy then you won't develop as quickly as you could(or not at all).

It will take some time to find the sweet spot.

At the start, a stretch goal could simply be a lesson on freeCodeCamp. As time goes on, a stretch goal could be implementing a button on your portfolio website without using Google.

The key thing to remember is that if a task feels easy you're probably not pushing yourself enough.

Focus and attention

Focus is a foundational component of memory and skill acquisition.

When you try to encode new information into your brain, the strength of the encoding is directly linked to the intensity of your focus.

When your focus is weak, new information will be less sticky which will result in slower learning and more time studying.

A common trait among people who learn programming quickly is they have the ability to intensely focus on whatever task they're performing for long periods of time.

Think about how any world-class performer practices. They're probably not checking their phone every 5 minutes. They're most likely mentally locked into whatever task they're performing.

Having good focus means eliminating all unwanted distractions.

There are two types of distractions, internal and external. Decreasing external distractions means shutting off your phone, going to a quiet room, and/or putting a site blocker on your computer.

Taming internal distractions means not letting internal thoughts consume your time. This can be done by practicing meditation or having a notebook to write down whatever is on your mind.

The key is to build a distraction-free environment and have a plan when a distraction inevitably pops up. You're probably already well aware of all the things that distract you.

(If you want more insights into where your time goes, I'd recommend using something like RescueTime)

Improving your focus is a process. In the beginning, try to be fully focused for a few minutes. As time goes on, slowly dial up the duration of your focused coding.

When deliberately practicing your programming skill, it’s better to be 100% focused for a shorter amount of time than 70% focused for a longer amount of time.

It's might feel impossible to maintain focus since we live in a world that's constantly trying to grab our attention. Nonetheless, you must find a way.

Perform

The only way to get better at something is by actually doing it.

People often confuse acquiring knowledge with acquiring skill. Knowledge is useful but it isn’t a substitute for actually attempting something.

Knowledge, in many ways, gives you a false sense of progress. You can watch 100 coding tutorials and feel like you're capable of coding your own website. However, once you go out and try to build one for yourself, you end up falling on your face.

It's like the difference between watching baseball and playing baseball. Watching helps you play but you can't become a good baseball player just by watching your favorite professional baseball team.

Acquiring skill requires you to go out into the world and test your knowledge against reality.

This isn't always easy. Practicing something new will attack your ego and make you feel incompetent. You'll want to quit or go back to something that feels more comfortable.

Unfortunately, it's impossible to learn something new without looking incompetent(at least at first). You might as well get used to it.

As we talked about above, learning doesn't happen inside your comfort zone. Don't be surprised if you start to feel uncomfortable as you code. Discomfort is usually a sign you're headed in the right direction.

Make sure you're constantly testing out your knowledge against the real world. Don't settle for reading tutorials or watching videos. Put your fingers to the keyboard and write some code that you can run.

Feedback

It's impossible to get better at anything without feedback.

Imagine trying to improve your golf game but you are unable to see where the ball lands. There'd be no way to know if you're getting better.

Feedback is the way reality communicates with you. It allows you to see the gap between what you think you know and what you actually know.

There are two ways to get feedback. You can get it through self-study or someone else can provide it.

Self-study requires you to compare what you attempted with the correct solution someone else posted.

This naturally happens when you go to websites like Stack Overflow or GitHub to find an answer to a problem. The feedback happens when you discover the gap between your answer and the correct answer.

When you go to websites like Stack Overflow, make sure you spend time understanding why a chunk of code works and how it’s different. Copying and pasting without understanding the difference will rob you of important feedback that will help improve and update your skills.

You can also read through someone's code on Github and compare it to your own code(or compare it to your current understanding of how to code).

Ben Franklin used a similar strategy when he was improving his writing skills.

He would read an article from his favorite newspaper a couple of times. Then he would deconstruct the techniques the author used. He would put the article away and try to replicate it in a similar fashion. After he wrote his version, he would compare the results and analyze his execution.

The other way to get feedback is by letting a more experienced developer see and comment on your code.

Having a fresh pair of eyes can help you solve individual problems and also can help you get back on track if you’re heading in the wrong direction.

It might be scary having someone else look at your code(or even having a conversation with an experienced developer). None of us want to look dumb. If you can get over your fear, getting feedback from others can have a big impact.

One of my biggest regrets when I was teaching myself to code was that I didn't get enough feedback. My code was a mess and I was wasting a lot of time on unimportant things.

Getting feedback from a more experienced developer would have saved me a lot of time and struggle. They would’ve instantly seen what I was doing wrong and put me on a straighter path.

Think of feedback from an experienced developer as a compass. They won’t physically get you to your destination, but they will make sure you are going in the right direction.

Adjust

Feedback is worthless if you don’t actually use it.

Learning to code is like moving through a dark room. You start walking, bump into some furniture, adjust your route, and try again.

Based on the feedback you receive, it’s important to take some time to think about the gap between what you wanted to do and what actually happened. Based on that gap, make adjustments as you move forward.

If you don't make adjustments, you won't improve.

You'll need to adjust specific lines to code to make your program work. You'll also sometimes need to adjust your approach at a macro level.

Our initial instinct when we aren’t making progress is to try harder. This is only effective to a point.

If you are not getting the results you want, try attacking things from different angles. It might take some experimentation to get it right.

Repeat

Performing a task once isn’t enough.

Our minds don't store information like computers. We tend to forget new information just as quickly as we learn it.

Learning something new requires you to repeat a task multiple times before it sticks.

Repetition is a signal to our brains that a new piece of information or a new behavior is valuable and shouldn't be forgotten.

The repetition stage of acquiring skill is not easy. It’s not supposed to be. You are consciously trying to reprogram your brain and your body will naturally want to do what's familiar.

You will need to consistently apply effort towards learning to become proficient.

The only sure-fire way to fail at learning to code is quitting. If you don't quit and maintain consistency, you will be able to repeat the important coding material and everything will eventually start making sense.

No matter how tough it feels, make sure you develop a consistent study habit. It is nearly impossible to learn coding without one.

For a deep dive into how you can be more consistent, I wrote an article about specifics techniques you can use.

Conclusion

The process of acquiring skill is simple, but it’s not easy. You are your biggest enemy in the process.

Old habits are hard to break. Each new skill is its own battle to be won.

Stay focused, make sure you're pushing yourself, adjust based on the feedback, rinse, and repeat.

If you follow the Deliberate Practice framework, I believe you’ll surprise yourself with the speed that you pick up programming.

Best of luck.

If you want to hear about other insights I've learned along the way, follow my account Zero to Programmer on Twitter. The goal of the account is to help you learn programming more efficiently.

How to create a focused coding environment

Victor Cassone — Fri, 01 May 2020 13:56:24 +0000

If you want to increase the odds of achieving your goal of becoming a programmer, it's important to craft a distraction-free learning environment that allows for long uninterrupted stretches of focus.

The environment where you learn to code has a large influence on your actions and your success.

Focus is a foundational component of memory and skill acquisition.

When you try to encode new information into your brain, the strength of the encoding is directly linked to the intensity of your focus. When your focus is weak, new information will be less sticky which will result in slower learning and more time studying.

Ultimately, having a distraction-free environment will accelerate your learning and help you achieve your goal in less time.

How to craft your environment

There's a pretty simple framework to follow when crafting a distraction-free learning environment. It relies on the Fogg Behavior Model that I talked about in a previous post.

To recap, the Fogg Behavior Model points out that a behavior occurs when three things are present at the same time: Motivation, Ability, and a Prompt.

Motivation — Hopes, fears, pleasure-seeking, pain avoidance, social acceptance, and social rejection.

Ability — Your ability to perform a task, which includes: time, money, physical effort, mental effort, social deviance, and routine.

Prompt — An internal or external trigger that reminds you to do the behavior.

Since motivation is unreliable, you should avoid learning in an environment that requires a high level of motivation to be productive.

Instead, focus on adjusting the other two variables of the Fogg Behavior Model: Prompt and Ability.

1) Prompt

Remove Prompts that'll trigger distracting behaviors.
Add Prompts that will help you stay focused on coding.

2) Ability

Make your coding habit small and easy to do.
Make distracting behaviors harder to perform while coding.

At the end of the day, crafting a learning environment is a design problem. Each person will have different constraints based on their life circumstances. It will require some forethought and trial and error to get right.

Below are a few techniques you can use when designing your own distraction-free learning environment.

Find a location where you can’t be interrupted

I've found changing locations or simply coding in a designated workspace is a useful tool when avoiding distractions.

Our day to day life is filled with various people and objects vying for our attention. Whether it's our gaming systems, friends, family, the dirty dishes.. etc. They all want our attention is some shape or form.

The best way to avoid getting sucked into one of these distractions is to find a location where they have no influence over us.

As the saying goes "Out of sight, out of mind."

If you're not around something then it can't prompt you to interact with it.

In normal times, I'd usually do a lot of my coding in a nearby coffee shop. The coffee shop allowed me to get away from the distractions of my home and put some distance between friends and family.

Since the outbreak of COVID-19, I don't have that option. I've had to create a designated workspace at my home that allows for a similar environment.

I sit outside when the weather is nice. When it’s not, I post up in the corner of my bedroom.

The main thing to avoid is TV and other highly stimulating surroundings that might prompt you to change tasks or grab your attention.

Ideally, you’ll want a location where nothing unexpected happens.

If you can’t avoid a distracting environment, a pair of headphones can go a long way

Headphones not only remove the surrounding noise but they also signal to the people around you that you’re busy and shouldn’t be bothered.

Airplane mode + Site blockers

The digital world needs to be managed with the same effort as the physical world.

Cell-phones and the internet are one of the biggest distraction creators of all time.

Social media and news companies have teams of employees whose sole job is to figure out ways to grab and hold your attention. Through algorithms and psychological tricks, they've become dangerously good at their job.

The internet in its current form is designed to distract you. Relying solely on willpower is a losing battle against its attraction.

The best thing you can do is remove the need for willpower and block access to these distracting apps and websites outright.

When you’re coding, put your phone out of sight and in silent/airplane mode.

There are various services you can use to block distracting apps and websites. The ones I've found useful are listed below...

BlockSite (Chrome Extension)

StayFocusd (Chrome Extention)

SelfControl (Mac App)

Freedom (All platforms)

Find a quiet time of day

Sometimes, changing the time of day of when you code can have a big impact on your focus.

Find a time of a day that you feel you have the most control over. For many, this time will be late at night or early in the morning. But it can also be over a lunch break or when the kids are napping.

When I was teaching myself programming, I'd wake up at 4:30 am every day because I knew no one would be trying to contact me and there was nothing from that day I needed to do yet.

This early morning coding habit allowed me to consistent and focused which ultimately lead to my success.

Have a notebook nearby

Sometimes it's hard to focus because our minds are worried about other things.

We'll be working on something and out of nowhere, we can't stop thinking about the dinner plans for tonight or something that happened 5 years ago.

One way to avoid being lost in thought is to write down any tasks or ideas that pop into your head. I use a plain notebook but you can also use a note-taking app.

I've found writing down my thoughts magically helps me move past whatever I was thinking about. It allows me to come back to the idea at a later time and helps me avoid being stuck in a rabbit hole of random thoughts.

Conclusion

Above are just a few personal examples of how you can craft a distraction-free learning environment.

When crafting your own learning environment, remember to use the Fogg Behavior Model from above. Focus on adjusting the Prompt and Ability variables in the formula.

Once you’ve found a learning environment that suits your needs, do everything you can to make sure distractions don’t start creeping in.

If I missed anything, I’d love to hear your thoughts in the comments below.

Make sure to follow my alter ego Zero to Programmer on Twitter.

How to handle the negative emotions of self-taught development

Victor Cassone — Mon, 20 Apr 2020 17:58:55 +0000

When I think back to my time teaching myself programming, one of my most vivid memories is me in my small, hot college room helplessly stuck on a programming problem.

I was trying to teach myself programming so I could build a mobile app that I was sure was going to be the next big thing.

There was only one problem. I had no idea what I was doing. Nothing worked and every line of code was a struggle.

My life was a cocktail of doubt, frustration and an overwhelming feeling of being lost. The whole world was going on around me and I was stuck in my room trying to figure out why a trivial line of code wouldn’t work.

I was constantly questioning if learning programming was worth my time.

(Granted, I made it much harder on myself, more on that another time).

Over time, I’ve come to learn that my experience wasn’t unique. Most self-taught developers I talk to share similar stories of having to overcome a range of negative thoughts and emotions.

As I’ve expanded my skill set, I’ve come to accept these negative thoughts and emotions. I’ve discovered they are simply apart of the process of teaching yourself programming.

To help me handle the inevitable onslaught of negativity, I’ve developed a few techniques that I think you might find useful.

Make it smaller

Teaching yourself programming is a large undertaking and can feel overwhelming when you look at it as one big thing to accomplish.

To avoid feeling overwhelmed, I break my large goals into many small pieces and I only focus on the things I need to accomplish today.

At the start of each day, I make a list of all the specific things I want to accomplish on that day. Each task is small and has a clear completion requirement.

When a goal is too large and/or abstract, it starts to feel out of my control. Breaking my large goal into day-sized objectives helps me clearly see the path forward and makes me feel more in control.

Ultimately, I can’t control what’s going to happen a week from now but I can control what happens today. If you can’t cross something off of a checklist then it’s not worth stressing about.

Making my goals smaller also allows me to celebrate the small stuff. It feels good to cross something off a list. If my todo list is complete, I don’t stress about the other things I could be doing.

Remember your why

Why are you learning to program?

Do you want to build a cool app? Start a new career? Follow your passion? Make more money?

There's a specific reason why you started down this path.

It's easy to forget why you're learning programming in the first place when you're in the day-to-day trenches of tutorials and various projects.

It’s important to not let the reason you started on this journey slip away. It will give you a boost when you’re feeling down and/or unmotivated. You'll also be able to handle more adversity that comes your way.

Nietzsche says it best…

"He who has a why to live can bear almost any how."

I like to write my why on a Post-it note and stick it on my computer.

You can also make it the background of your phone or put it as a daily reminder on your computer (among other things).

It doesn’t matter too much where you put it, just make sure you don’t forget.

Lean into the discomfort

Learning new things and creating new habits will always be uncomfortable.

Discomfort is simply apart of the process of pushing yourself beyond your current abilities.

The world's strongest man still gets sore after lifting weights. The world’s smartest mathematician still gets frustrated when he can’t solve a problem.

When you’re developing new skills, discomfort is unavoidable. The best thing you can do is accept the discomfort and lean into it.

Every successful self-taught developer eventually figures out that the feelings of fear, doubt, insecurity, being lost, etc. are just apart of the process. They keep going in spite of these negative emotions.

I like to look at my negative emotions as an old grumpy friend that’s along for the ride.

Any time it appears, I say hello, pat him on the head and keep going.

Comment below

If you have any techniques that you use that I didn’t mention, I'd love to hear them in the comments below.

Sign up to the Zero to Programmer Newsletter for other content related to the non-technical side of teaching yourself programming and starting a career as a software developer.

What self-taught developers can learn from peacocks

Victor Cassone — Sun, 12 Apr 2020 18:58:02 +0000

Have you ever wondered why male peacocks have such large and colorful tails?

You’d think their tails would make them more visible to predators and increase their chances of getting eaten.

A male peacock's tail actually plays an important part in his survival.

Female peacocks can’t focus on every trait of a male. They need to selectively find features in their counterpart that will convey important information about their fitness. For whatever reason, the tail became that feature.

Male peacocks are at the mercy of the preferences of the female. If a male wants to be selected by a female, he needs to be able to signal his value through his large and colorful tail.

I believe applying for a job is similar to a male peacock trying to impress a mate. It might feel awkward thinking about in these terms but I find it a useful framework.

Programmers are competing with each other for jobs, but it isn't a direct competition like fighting. Job applicants try to display their value through information signals and employers make a decision based on the qualities they observe.

Just like a peacock, self-taught developers need to focus on creating their own colorful tails to signal their value to potential employers.

Self-taught developers can’t rely on 4-year universities or code schools to boost their signals. A hiring manager can’t rely on the authority of a university when making a decision (or blame the university if the employee doesn’t work out).

Programs like freeCodeCamp have done a great job helping self-taught developers in this respect. But more will need to be done.

In a way, self-taught developers need to be their own marketers.

Marketing oneself can sometimes feel slimy. I personally don’t enjoy doing it.

However, marketing is necessary because both sides don’t have access to the same information.

Imagine a car company that’s recently developed an awesome new feature. Everyone at the company is aware of how great the new feature is but the general public has no idea.

The car company needs to come up with a way to spread this important information and help consumers understand what the car company already knows. Marketing allows this uneven information distribution to be flattened.

The same logic applies to marketing oneself as a programmer.

You might know you are a competent programmer. However, the only way an employer will know this fact is through the information you signal to them.

The important thing to remember is that there are two sides to any signal. The sender and the receiver. Both sides need to be in sync for a signal to be effective. Different types of companies will have different signals they are listening for.

It’s the responsibility of the self-taught developer to figure out what employers prefer and create information signals that will honestly convey their value.

The internet has made it easier for people to create and amplify their signals. You can boost your signal through blogging, contributing to open source projects, developing portfolio projects, and completing online courses(among other things).

Moving forward, make sure your signal is strong so future employers can know how great you are.

A peacock flaunting its tail is not wasted effort if it keeps its genes in the gene pool. Similarly, spending time on your own signal will only help you in the indirect competition of finding a job.

Sign up to the Zero to Programmer Newsletter for other bite-sized content about the non-technical side of teaching yourself programming and starting a career as a software developer.

How to use Tiny Habits to create a consistent study habit.

Victor Cassone — Sat, 22 Feb 2020 14:43:01 +0000

If there’s only one thing I could teach someone before they started learning to program, I’d teach them how to be consistent.

Successful self-taught developers don’t have any special abilities that others don’t possess.

What they do have are the habits, routines, and/or life circumstances that allow them to consistently apply effort towards their studies.

I believe the hardest part of teaching yourself programming isn’t the difficulty of the material but rather setting up your life in a way that allows you to consistently chip away at your goal.

Existing habits are hard to break. Expectations of the people around you are hard to manage. These factors are often overlooked.

The key difference between someone who has successfully taught themselves programming and someone who has failed is that one person stopped before the job was done and the other person didn’t. It’s that simple.

A slow learner who shows up consistently will always outperform a fast learner who quits early.

Regardless of who you are, learning to program is a large undertaking that requires a sizable commitment of time. Until we discover a way to upload memories into our brains, the only reliable way we can make it through this large pile of hours is through consistency.

Shortcuts and hacks don’t work. It’s not possible to become proficient at programming by drinking a case of Red Bull and studying for 3 days straight.

Just like eating an elephant, learning programming can only be done one bite at a time.

Tiny Habits

Tiny Habits is the best methodology I've found when it comes to changing your behavior and becoming more consistent.

Tiny Habits is a behavior change framework developed by Dr. BJ Fogg. BJ Fogg is the founder of the Behavior Design Lab at Stanford University and is largely considered one of the world’s leading experts in behavior and habit change.

In my opinion, Tiny Habits provides the best framework for behavior change. It’s backed by both research and real-world applications.

Through his years of research, BJ Fogg has found only 3 ways people change their behavior.

1) Epiphanies
2) Environment changes
3) Taking baby steps

Out of the three options, epiphanies are the most unreliable. People can’t usually create an epiphany on demand. If you can, well, you might have some sort of superpower.

Changing your environment is a good option if you can manage it. However, most self-taught developers I meet are trying to fit their studies into their already busy lives.

This leaves taking baby steps as the best option. Taking baby steps is available to everyone and it’s easy to apply to your life once you know the basics.

Tiny Habits is a framework centered around taking baby steps.

Tiny Habits have three main pieces.

1) An anchor
2) A tiny behavior
3) A reward

In the remainder of the article, I’ll explain the three parts of Tiny Habits and look at ways you can apply it to self-taught development.

The Fogg Behavior Model

The core component of Tiny Habits is the Fogg Behavior Model. The Fogg Behavior Model is represented by the formula B = MAP.

Behavior = Motivation * Ability * Prompt

Motivation — Hopes, fears, pleasure-seeking, pain avoidance, social acceptance, and social rejection.

Ability — Your ability to perform a task, which includes: time, money, physical effort, mental effort, social deviance, and routine.

Prompt — An internal or external trigger that reminds you to do the behavior.

The Fogg Behavior Model is represented visually by the graph below.

A behavior occurs when motivation, ability and a prompt converge at the same time. If these three variables converge above the Action Line then a behavior occurs. If not, then nothing happens.

As you can see, our motivation and ability work together to bring behaviors into existence. Hard to do behaviors require a high level of motivation and easy to do behaviors require a low level of motivation.

I like to think of the Fogg Behavior Model as a bit of code that runs in our brains.

The prompt triggers a code block that checks the variables ‘ability’ and ‘motivation’. If either variable is high/low enough then it returns a behavior. If not, then it returns nothing.

The Fogg Behavior Model is a simple but powerful discovery that can have a large impact on your approach to learning software development.

It will act as the foundation for developing Tiny Habits and should be referenced frequency.

Avoid motivation

A habit can only be created when a behavior consistently stays above the Action Line.

There are only two ways this can occur.

1) Maintain a high level of motivation.
2) Make a behavior easy to perform.

Maintaining a high level of motivation over a long period of time is possible. As Neicheze said, “He who has a why to live can bear almost any how.”

But I wouldn’t bank on it.

As I’m sure we’ve all experienced, our motivation comes and goes without warning. One day we're excited about a new project and the next we struggle to find the energy to get off the couch.

We're often tricked into feeling like the wave of motivation we're riding will last forever. But it never does.

Our external motivations lose their power or shift away. Our internal motivations slowly dwindle due to the constant assault from our fears and doubts.

We lose the fire we once had and we end up right back where we started.

We humans are complex and our motivations are inconsistent.

For these reasons, motivation is the most volatile variable in the Fogg Behavior Model.

James Clear, author and blogger, developed a fantastic graphic illustrating the effect of motivation on our habits.

Motivation should be thought of as a fair-weather friend. Its presence is nice but it shouldn’t be trusted with anything important.

The safe thing to do is to side-step motivation and design your study habit with the assumption that your motivation will always be low.

Staying under the ebbs and flows of motivation is the only reliable path to consistently repeating a behavior.

Identifying a tiny behavior

A common mistake people make when developing a new habit is starting too big. We tend to think of behavior change as one big step rather than a series of smaller steps.

Big behaviors are attractive because they feel like the most efficient route. We tell ourselves something like, “If I study for 3 hours a day then I’ll learn programming in no time.”

However, big behavior changes are fragile because they rely on a high level of motivation.

Since motivation can't be trusted, easy to do behaviors are the best path towards consistency.

Unlike motivation, prompts and ability are almost completely in our control. We can choose a well-crafted prompt or decide on a behavior that’s within our ability.

A tiny behavior can be discovered by experimenting with the subcomponents of the Ability variable from the Fogg Behavior Model (time, money, physical effort, mental effort, social deviance, and routine).

Imagine each one of these subcomponents as a dial you can turn up and down. The key is to turn them as low as possible without changing the nature of the behavior.

For example, BJ Fogg recommends flossing one tooth to start a flossing habit. It’s hard to say no to flossing one tooth.

The tiny behavior for learning to code could be something as simple as logging into your computer and opening a browser.

As the illustration in the last section points out, it needs to be “so easy, you can’t say no.”

It might seem like a waste of time doing something so small.

Remember, what we’re after are long-term changes. Each tiny behavior acts as the foundation that future behaviors are built upon.

If you want to do more, go for it. Treat it as extra credit. Just make sure you never do less than the tiny behavior.

Setting up a prompt

Next, we need to identify a prompt that will act as an anchor for the new habit.

Prompts are simply a reminder to act. These can include notifications, people, remembering something or other habits (among other things).

Behaviors can’t exist without a prompt.

Spend some time making sure your prompt is worthwhile. The new habit will fall apart if the prompt isn’t well-established and well-anchored in your life.

I’ve found the best prompts are those that leverage existing habits. You can make the end of one habit the prompt for a new one. I’ve also found visual cues like sticky notes to be effective.

Use the following fill-in-the-blank sentence when trying to figure out your prompt. After I _____ I will ______.

For example, after I make my morning coffee I will sit down and open freeCodeCamp.

You will probably need to rework your prompt if you find yourself consistently forgetting to do your tiny behavior.

Moving from the prompt to your tiny behavior should feel natural. If it’s not, then either your prompt or tiny behavior needs to be reworked.

Finding a good anchoring prompt will require some experimentation.

Identifying a reward

The last thing you need to remember when developing your study habit is to reward yourself.

We are hardwired to repeat behaviors that provide us with positive feedback. It’s a signal to our brains that a behavior has value and is worth repeating.

Rewards need to be immediate and positive. If either of these two things is missing then the reward won’t be effective.

Avoid negativity if you fail. Positive reinforcement is the only way to grow new behaviors. Negative reinforcement can only shrink existing behaviors.

At a minimum, you need to reward yourself immediately after you complete your tiny behavior. For bonus points, you can also reward yourself when you remember your prompt and during the actual tiny behavior.

The easiest reward at your disposal is an instant celebration (out loud or quietly). Try telling yourself “Good job” or give a little fist pump. These small acts can go a long way.

Rewarding yourself after each tiny behavior might seem silly. However, rewards are a fundamental part of habit formation.

BJ Fogg points out that, more than anything else, emotions create habits. Rewards are the mechanism that injects positive emotions into the new behavior.

Setting up your prompt and tiny behavior only plant the seeds. Rewards provide the sunshine and water that allow a habit to grow.

You won’t need to reward yourself forever, just until the behavior becomes a habit.

Tiny behavior to Tiny habit

Once you have a solidly anchored prompt, a tiny behavior identified, and a reward setup, the only thing left to do is let time work its magic.

As time goes on, the new behavior will slowly move to the right on the Fogg Behavior Model.

As your programming ability increases and your new study habit becomes routine, increasing the time and intensity will feel natural.

The key is to only increase the time and intensity of your study habit when you feel comfortable doing so. Don’t force it.

Forcing the behavior will cause both your Motivation and Ability to decrease, which will slowly push you below the Action Line.

You are trying to build a solid foundation that future habits can be built upon. Moving too quickly can put that in jeopardy.

If you fail at any point, don’t look at it as a personal failure but rather a design failure. Your behavior either wasn’t small enough or your prompt wasn’t a solid anchor.

As I’ve mentioned, it’ll take some experimentation to get it right.

Life can be hectic sometimes so don’t get upset if you abandon your new Tiny Habit altogether. When the opportunity presents itself, reassess your prompt and tiny behavior and start fresh.

Conclusion

I truly believe anyone can learn to program if they are consistent.

Teaching yourself programming isn’t easy. Each day can be a grind. However, you don’t give yourself a chance if don't consistently show up.

I hope you've found Tiny Habits useful. I think it's an important tool when designing a consistent study habit.

You'll be surprised how easy and fun behavior change can be once you start small.

Big changes start from small beginnings.

Join hundreds of other self-taught developers on my Zero to Programmer Newsletter. I write about what it takes to become a successful self-taught developer. Sign up here

The foundation of self-taught development

Victor Cassone — Fri, 07 Feb 2020 11:54:41 +0000

If there’s only one thing I could teach someone before they started learning to program, I’d teach them how to be consistent.

All learning is built upon the foundation of consistency.

We are all capable of learning hard things. Successful self-taught developers don’t have any special abilities that others don’t possess.

What they do have is the habits, routines, and/or life circumstances that allow them to consistently apply effort towards learning.

I believe the hard part about learning programming isn’t the difficulty of the material but rather setting up your life in a way that allows you to consistently chip away at your goal.

Existing habits are hard to break. Expectations of the people around you are hard to manage. These factors are often overlooked.

Intelligence and natural ability aren’t the limiting factors. Anyone can learn to program if they spend enough time on it.

A slow learner who shows up consistently will always outperform a fast learner who quits early.

Regardless of who you are, learning to program is a large undertaking that requires a sizeable commitment of time.

Unless we discover a way to upload memories into our brains, the only reliable way we can chip away at this large pile of hours is through consistency.

Repetition, time and effort are the only ways to signal to our brains that a skill is worth holding on to.

Short cuts and hacks don’t work. It’s not possible to become proficient at programming by drinking a case of Red Bull and studying for 3 days straight.

Just like eating an elephant, learning programming can only be done one bite at a time.

The keys to consistency

As I see it, consistency can only come from two places; habits and/or motivation.

Most of us rely on motivation anytime we start anything new. The excitement of the moment drives us to buy an online class or start on a new project.

Motivation works great for a while but it usually runs out of steam(as I’m sure we’ve all experienced).

External motivations eventually lose their power or shift away. Internal motivations are under constant assault by the fears and doubts we all carry.

We lose the fire we once had and we end up right back where we started.

Relying solely on motivation for long periods is a risky endeavor.

Yes, it’s possible to teach yourself programming through sheer willpower and motivation. As Neicheze said, “He who has a why to live can bear almost any how.”

But I wouldn’t bank on it.

Your best bet is developing a set of reliable habits and routines.

Developing habits

Luckily, there is a lot of great research and insights when it comes to developing habits. The technique I’ve found the most effective is the Tiny Habits method developed by BJ Fogg who is a professor of social science and the founder of the Behavior Design Lab at Stanford.

I’ll dive into Tiny Habits more deeply in a follow-up article. For now, I want to focus on the most important component outlined by BJ Fogg and others: starting small.

A common mistake people make when developing a new habit is starting too big. We tend to think of behavior change as one big step rather than a series of smaller steps.

The problem with big changes in behavior is that they are fragile. Changing a lot of things at once creates many points of failure.

Big changes in behavior are attractive because they feel like the most efficient route. We tell ourselves something like, “If I study for 3 hours a day then I’ll learn programming in no time.”

But the fact is big changes in behavior are much less likely to be codified into habits. Habits need time to develop and big behavior changes usually don’t stick around for very long.

If consistency is the goal then it’s important to start small.

Starting small

I like to think of starting small as the minimum viable behavior required to perform a new desired habit.

Here’s an example from my personal life.

I used to have a lot of trouble going to the gym consistently. One day I decided to change what I deemed a successful trip to the gym. I told myself all I needed to do was physically put myself inside the gym.

During my first few weeks, there were days where I would show up, sit in the locker room for a few minutes, then leave.

I didn’t care. I counted it as a win. I was happy because I was building a routine of going to the gym. The rest came later.

Apply the same logic to learning programming.

Find a specific time of day where you can sit down at your computer and do one exercise or write a few lines of code.

You can always do more if you feel like it. Just make sure you never do less.

It might feel weird at the beginning focusing on something so small. However, starting small forces you to focus on the handful of actions that are essential to the new habit. Starting small also lowers the effort required to perform the new behavior.

Don’t worry about how focused you are or about how much time you spend. You can increase the quality and quantity of your learning at a later date.

Consistently showing up creates the foundation that everything else can be built upon.

As time goes on, the new habit will get easier and you’ll be able to add more layers to your study routine.

Once you’ve successfully started small, guard your new habit with your life. If the foundation crumbles, everything else will come crashing down

Teaching yourself programming isn’t easy. Each day can be a grind. However, you don’t give yourself a chance if you don’t show up.

In part 2 of this article, we’ll dive into the various techniques you can use to develop good habits. We’ll take a deeper look at BJ Fogg’s Tiny Habits behavior change model and look at ways you can apply it to self-taught development.

Until then, best of luck.

Sign up for the Learn to Code Newsletter to receive non-technical content on how to successfully become a self-taught developer. http://bit.ly/36HmcFC

Lessons learned from my journey as a self-taught developer

Victor Cassone — Tue, 10 Jul 2018 11:21:25 +0000

The path of the self-taught developer is tough and clouded with uncertainty. There is no straight line from newbie to career programmer. Because of this, I believe all self-taught developers have a unique story to tell.

In this article, I've shared a few stories and lessons learned from my time teaching myself programming. Hopefully reading about my experiences will help you reflect on your past and motivate you moving forward.

Focus on the process

When I first started learning to program, I never had the intention of making a career out of it. I just wanted to make a specific app.

My journey started when I was a senior in college. I just finished Richard Brandon's book, Losing my Virginity and I was probably reading too much TechCrunch. I was pumped up full of entrepreneurial energy. I was constantly reading about how college kids were receiving massive amounts of investment for their mobile app ideas. I thought I could be one of those people.

One day, while walking in-between classes, an app idea hit me. The specifics of the app aren't important. The point is, the idea was unique and had a lot of growth potential (at least in my mind).

I was convinced I found the next big thing. I was consumed by the idea and stopped paying attention to lectures. My excitement for the idea quickly grew to the point where I felt the need to take action.

There was one big problem. My idea was a mobile app and I didn't know anyone who could build mobile apps.

So I thought what the hell. How hard could programming be? I was losing interest in my major and I was spending a lot of time playing Xbox. I could allocate some of my free time towards building this mobile app.

Sometimes being naive helps you take action when you normally wouldn't.

What you had was a college student with no programming, business, or design experience trying to learn Android so he could build a complex app. I guess that's what you get when you mix a big idea with the Silicon Valley hype machine.

I wish I could tell you things went well from here. 😉

I bought a few books on Android development and spent many hours in my room trying to duct-tape this app together. I didn't care how the app worked. I just wanted a finished product, if that meant copying and pasting code from any source I could find.

I thought I could get away with learning very little about programming. I became too focused on the end result. The light at the end of the tunnel kept driving me forward.

Time went on and the app turned into a Frankenstein of copy and pasted code. The app didn't have many features and it barely ran without crashing.

It wasn't until I accidentally got into a Computer Science class did I realize that maybe I should focus more on learning. My inability to program lead me to abandon my initial app idea. I had come to the realization that I wasn't going to make the next big thing, at least not yet.

Luckily, over time I corrected my behavior and took learning more seriously. I started to enjoy programming and eventually started a career as a software developer.

Take Away

Having a big idea is great but beware when the idea becomes all-consuming. It's a powerful force and it consumed me for a long time. It put my focus on the end result rather than the process of getting there.

It's important to remember that learning anything big, like programming, requires many small steps. The only way you are going to learn anything is by focusing on and mastering each individual step.

When you get too focused on the end result, you start taking shortcuts. Shortcuts might lead you to short-term progress but in the long run, your lack of knowledge will always catch up on you. Learning new things is like building a house. You start with the foundation and build up. If the foundation is faulty the whole thing will crumble down sooner or later.

Sometimes building a strong foundation requires you to slow down. There's no shame in going slow. The people who understand the basics the first time will end up going ahead of the people who have to go back and relearn them.

I was a perfect example. From the outside, it might've looked like I was a programming whiz kid. In reality, I couldn't build an app to save my life.

There's an old Chinese proverb that goes:

It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward.

Focus on the process each day and you will surprise yourself with how much progress you make.

Stack Overflow is awesome (and dangerous)

As I was building the app, Stack Overflow became my best friend. Anytime I got stuck I would try to craft together a question to ask the Stack Overflow community. I averaged a few questions a week.

Not only would I post questions, I would treat the answers on Stack Overflow as Gospel. I would spend a crazy amount of time scouring the site to try to find an exact chunk of code that would fix my problem. Once I found the answer, I would copy and paste it right into my codebase and try to make it work. I spent little time trying to understand. I made brute-force trial and error a new art form.

This process went on for a while, until eventually, I wised up and realized the flaws of this approach.

Take Away

Copying and pasting is a terrible way to learn how to code.

Stack Overflow is a blessing and a curse. It's great at helping you solve and fix problems. But it also can become a crutch that you always depend on if you aren't careful.

Sometimes, the website is too good at solving your problems. It creates a false sense of confidence that will only lead to more headaches down the road.

It's impossible to learn anything if the answers are constantly given to you. Make sure you make a few attempts at solving your problem before going to Google.

If you do find yourself copying and pasting code, make sure you spend at least a little time understanding the code block before moving on. There are no short-cuts in the learning process.

Find experienced help

The first thing I did after I decided I wanted to learn programming was buying two Android development books.

At the start, I followed the exercises in the books closely and worked through all the example projects.

I quickly got bored and/or frustrated following the book. I decided to go off on my own and figure out programming myself.

As you've read above, that slowly resulted in disaster.

I would spend many hours a week isolated in my room or at coffee shops. I cut myself off from the world. I felt like there wasn't anyone who could help me because no one I knew had any experience with Android development.

Days turned into weeks and I wasn't making much progress.

At one point I had the bright idea to download a massive C library called FFMPEG. My app needed to edit videos so I thought it was a good idea to utilize the library's robust functionality. It wasn't the smartest move, considering at the time, that I could barely get my Android app working.

I wasted a lot of time trying to read the C code and figure out how I could use it in my app. I became frustrated and eventually abandoned the library.

Luckily, around the same time, I signed up for an Object Oriented Programming class and somehow got in. I was the only non-Computer Science major in the class. I don't know how or why I got selected. I think there was a bug in the enrollment software.

The first assignment was to build a Blackjack program. I'd been teaching myself programming for 5 - 6 months at this point, and I felt confident with my skills.

I finished the assignment and felt good about my work. However, that feeling quickly faded.

My whole program was written in one huge method. Just about everyone else in the class was able to pick up on the fact that the program needed to be separated into classes. Not good.

Take Away

Luckily, the classwork and guidance from the teacher allowed me to take a step back from my Android app and reflect on my development abilities. I started to value learning a lot more and reigned back my desires to make a completed app.

If I had spoken to just one experienced developer in those early days, they would've seen what I was doing, set my priorities straight, and talked some sense into me. They would've helped me correct my path when I was going down useless dead ends (like trying to work with FFMPEG).

As I outlined in a previous article, experienced developers are like a compass. They won't get you to your destination but they will make sure you are pointed in the right direction. Their help can often be the difference between success and failure.

In hindsight, there were a lot of ways I could've found help. I could've tried to find a professor/student at the university with Android experience. I also could've tried finding an online Android community.

Instead, I isolated myself.

Isolation is a double-edged sword. On one side, it helps you focus on the task at hand. On the flip side, it removes you from the world starving you of crucial feedback.

Make sure you seek out guidance where ever you can find it. It will save you time and frustration down the road.

Craft your environment

This might be the only thing I felt like I did right when I was teaching myself programming.

Throughout my life, I've been really bad at studying for tests or doing my homework at home. There are just too many distractions at any given moment. I would often try to find refuge in libraries or coffee shops.

Luckily I applied this rule when I was teaching myself programming.

I ended up becoming a regular at a few local coffee shops around town. I preferred coffee shops over other study locations because it provided some variety and it's easy to hide yourself (easy access to caffeine doesn't hurt either). Coffee shops are also nice because you can choose a location where you know you won't bump into people you know.

If I was studying at home, I made sure my door was shut and my roommates knew not to disturb me for a certain period of time.

Regardless of where I was, I would make sure my music was loud enough so I couldn't hear what was going on around me. Upbeat music without lyrics worked best for me.

I can't say I was perfect at finding a distraction-free work environment but I was able to succeed a majority of the time.

Take Away

Having the right work environment is often an under-looked part of learning. Your work environment shouldn't be distracting and should allow for long uninterrupted stretches of focus.

Focus is a foundational component of memory and skill acquisition. When you try to encode new information into your brain, the strength of the encoding is directly linked to the intensity of your focus. When your focus is weak, new information will be less sticky which will result in slower learning and more time studying.

Take any world-class performer and look at how they practice. Do you think they are checking their phone every 5 minutes? Probably not.

The easiest way to increase your focus is by crafting an environment where there are minimal distractions. This can be done in a few ways:

Finding a location where people won't interrupt you

Putting your phone in airplane mode

Using some sort of timed website blocker for social media and news sites

Wearing headphones and listening to non-distracting music (preferably a long playlist so you don't have to constantly switch songs)

Avoiding TV or other highly stimulating surroundings

Having a notebook nearby to write down any tasks or ideas that pop into your head

Only you can decide where and how to craft your environment. But make sure you do because it's worth it.

Get out into the world and meet people

My first programming job was sort of a random occurrence. I just moved to Omaha, Nebraska and I had around a year of self-taught development under my belt.

I only knew very few people in Omaha so I searched Meetup.com to try and find other people interested in Android development. Luckily, at the time there was a Mobile Meetup which covered both iOS and Android development. So I built up the nerve and decided to go to the group.

Going to that first meeting was nerve-racking. I spent around 10 minutes in my car at the venue deciding if I should go in or drive off. I was intimidated. I wasn't confident of my programming skills and I knew everyone at the meeting had much more experience that I did.

I finally said, screw it and went inside. I'm glad I did.

I started to attend regularly. During one Meetup, not too long after I moved to Omaha, I met a recruiter who was looking for an Android contractor. We talked for a while and I got an interview for the job later that week.

Before the interview, I felt confident. During the interview, I was a deer in the headlights. The interviewer was talking about the project I'd be working on and it all went right over my head. I tried to stay engaged but they could tell it was out of my range.

After the interview, they asked me to hang-out for an hour so I could talk to someone else. Knowing I blew it, I walked around downtown trying to clear my head.

I ended up interviewing with someone else, and shortly after, they offered me an internship. The CTO was doing all the Android work at the time and they needed someone to take on the load. I started that day.

I was so shocked that after I signed all the paperwork and got my work laptop running, I went over to the CEO and asked if it was a paid internship or not.

The internship turned into a full-time job and I started my career as a software developer.

Take Away

When you are self-taught, people are not going to come and seek you out. You will need to step out and find the opportunities.

People graduating from four-year universities and code schools have the advantage of leaning on the schools to help them find jobs. Self-taught developers don't have this advantage.

The best way to find a job as a self-taught developer is to go out into the world and meet people. Websites like Meetup.com are great for finding programming specific groups that meet monthly or bi-monthly.

Do what you can to build up the nerve to go to these groups. Be friendly and talk to people about your experiences. Make sure people know of your long-term goal of finding a job.

Put yourself in situations where something positive might happen. You can't win a raffle if you never buy a ticket.

Consider any opportunity that comes your way, because even if it looks like a dead end, it has the potential to lead to something bigger.

The key is to think of job opportunities in the long-term. Internships or part-time jobs might not give you your desired salary upfront but they might open up doors in the future.

Conclusion

As you can see, I made a lot of mistakes in my learning journey.

Learning something new is never a straight road. There will be turns and dips (maybe a few will take you off the road).

I encourage other self-taught developers to share their stories. Not only will they provide valuable insights, they will also help shine a light on the unique paths we've taken.

Hopefully, my story and the lessons I learned will help you moving forward.

Did you enjoy this article? Sign-up for my Self-Taught Developer E-letter. You will receive content like this along with other exclusive tips and tricks.

A beginners guide to finding a mentor

Victor Cassone — Tue, 19 Jun 2018 12:03:51 +0000

One of my biggest regrets during my time teaching myself programming was that I isolated myself too much. I tried to do everything myself and didn't seek out help from others. I would spend hours, sometimes days, beating my head against the keyboard trying to solve a problem that could've been explained to me in 10 minutes. I was too shy, oblivious, and stubborn to put in the effort to find help. The amount of time I wasted in those early days still haunts me.

It took me awhile to realize that finding a mentor is an important tool in the learning process. They provide crucial feedback where there normally wouldn't be any. It puts a stress test on your skills and challenges the knowledge areas where you might be weak.

Evidence of the effectiveness of mentors can be seen throughout history. Apprenticeships used to be the primary form of education before the university system took over. Some of the world's greatest artists and creators studied under someone else.

There are a few ways you can use mentorship to your advantage. It will require some extra effort to find one but I believe it's worth it.

In this article, I will explain why mentorship is important and suggest an simple way to find one for yourself.

Feedback is the key

You can't learn anything if you don't get feedback. It's simple as that. Feedback is a fundamental requirement of the learning process. Imagine trying to improve your free-throws without seeing if your shot went in. It'd be impossible.

There's really only two ways to receive feedback; you can give yourself feedback through self-study or someone else can provide it.

The self-study method is the most common in the programming world. Usually, when we get stuck or need to learn something new, we go websites like Stack Overflow or Github. The goal is to learn new information so we can reflect on our work and approach the problem from a new angle.

Self-study will always be apart of a software developers job because we are constantly running up against new problems. A good developer isn't someone who has an amazing memory but rather someone who can efficiently understand their problem and know where to find the solution.

At my first programming job, I was blown away by how fast the experienced developers could find the answers to my problems. It felt like they knew exactly what to search and where to find the important information.

Self-study is important but there are two big problems.

First, it takes time to hone the skill. Searching for relevant information is intuitive for an experienced developer but feels more like a wild goose chase for someone who is inexperienced. It might seem simple but it takes a lot of practice to know how to search Google or figure out the best places to look for answers. When I first started learning programming, I either didn't know where to look or didn't know exactly what I was looking for. I often felt lost and overwhelmed.

Second, relying too heavily on self-study makes it hard for you to take a step back and understand big picture concepts. It's easy to find yourself solving individual problems without having a good understanding of how it fits into everything else. You might learn how to do something but not know why it's necessary.

It's also not always clear if you are going down the right learning path. In the beginning, it's hard to know where to start. People do a little research and pick a path. As time goes on, the path you initially chose might not be the best route for you. You might not correct course until much later down the road. You could be wasting time learning something that doesn't align with your big picture goals.

To avoid these traps, it's important to supplement self-study feedback with feedback from an outside source. Relying too heavily on self-study can result in wasting time on both the micro and macro level.

How to find a mentor

There are many advantages to finding a mentor. They help you develop a firmer understanding of the material and create a stronger foundation of skill. As you are interacting with them, they poke holes in your current understanding and stress test your abilities. They have the experience to help you understand hard concepts and will be able to point you in the right direction when you hit an impasse.

Finding an experienced mentor is very useful but it's easier said than done. There's no Yellow Book for looking up software developers who can mentor you. People going through a traditional 4-year school or a code school have the advantage of asking the teacher questions when they get stuck. Self-taught developers don't usually have this luxury.

To find a mentor, you will need to be prepared get out into the world and meet people.

Meetups and user groups are a great place to start. If you live in a decently sized city, there are most likely a variety of different tech events happening each week. Just go to meetup.com and look for an event that you find interesting.

Going to a meeting with a bunch of strangers is nerve-racking. At my first Meetup, I remember sitting in my car at the venue for 5–10 minutes before I finally built up the nerve to go inside. I'm happy I did. The people I met at that first Meetup ended up helping me land my first software development job down the road.

It's important that you overcome your fears so you can put yourself in a better position to succeed. At first, if you are too nervous to talk to anyone, then don't. Sit in the corner, watch the presentation, enjoy the free pizza, and consider it a win. The next time you goto a meeting you will feel more comfortable and be ready to interact with others.

Once you start interacting with people, make sure to remove your ego as much as possible. You have nothing to prove to anyone. People have a tendency to overstate their abilities when interacting with people with more skill or experience.

Overstating your abilities can be a tragic move. The point of going to the meetup in the first place is to build connections and find people who might want to help you. Acting like you know more than you do will either make you look stupid or will make people think you have it all figured out.

The key is to be vulnerable and embrace the fact that you are a newbie developer. Don't be afraid to admit you don't know something. Let other people know you've just started learning and you are open to any advice they can give.

Come prepared with questions. Ask something like "How would approach learning if you were in my position." You'll be surprised how much people will want to help you. Every developer at that meeting can sympathize with you because they were at some point in the same position as you. There are many valuable insights you can gain just from these conversations alone.

Once you've met and talked to a few people, ask for their email address just in case you have follow-up questions.

Getting some sort of contact information is crucial. It allows you to stay in touch with the person and it opens up opportunities for future meetings.

After the meeting, reach out to the people you've met and ask if you can buy them a cup of coffee. It might feel like you are inconveniencing them but people generally enjoy helping others (especially software developers). As long as you are respectful of their time and show them you are grateful for their help, they will most likely be happy to meet with you.

A word of caution before proceeding. It's important to not abuse the relationships you build. If you email a person 5 times a day and are constantly bugging them, they will stop wanting to help you. It's ok to ask for help but it's not ok to have them do the work for you.

You aren't going to get all your specific technical questions answered through this network of people. If you do find yourself asking them technical questions make sure they are well thought out, precise and short. Give them the opportunity to answer you quickly. Try to avoid questions with lengthy answers unless you feel they are willing to answer them (especially in emails).

Think of an experienced developer as a compass. They won't physically get you to your destination but they will make sure you are going in the right direction. This will help you avoid wasting time on things that might not be helpful in your pursuit of a job. At a minimum, they will give you new things to think about and will help you self-analyze your progress.

Remember, the relationship you build is more important than the answers you receive. Answers are like casing a check. Relationships are like receiving interest over time.

Conclusion

Finding a mentor is just one way to increase your feedback. You might have other ways at your disposal. If you do, great! Use them as much as you can.

If meeting someone in the physical world is out of the question, then move digitally. Look for Facebook groups, online forums, or subreddits where you can interact with experienced developers. There are many articles written about all these different places so I won't go into it here.

The key here is to understand receiving feedback as a newbie developer is hard. You will need to actively seek it out. But make sure you do. There is nothing more crucial in the learning process than receiving feedback.

If you've enjoyed this article, sign-up to the Self-Taught Developer Newsletter. You will receive information like this along with other exclusive tips and tricks.

The Inner Game of Self-Taught Development

Victor Cassone — Sun, 10 Jun 2018 23:47:04 +0000

Teaching yourself software development is hard. Anyone who tells you different most likely hasn't done it before.

It's a huge life commitment to go from newbie to career programmer. You have to sacrifice a lot to make it happen. There are many good reasons people quit. People usually don't have the time or interest to put themselves through hours of watching tutorials or building demo sites.

After thinking about my own experiences, I feel like there is an aspect of self-taught development that people don't talk about enough. I believe there is an internal game you need to learn how to play to be successful. The people who learn how to play and win this internal game are the ones who make it through to the other side.

In this article, I'm going to describe the inner game of self-taught development and discuss how you can ultimately win.

Discomfort is unavoidable

Anytime you learn something new, you have to step outside your comfort zone and try things beyond your current abilities. From an evolutionary point of view, this makes sense. Breaking habits are dangerous because doing something new can put us in a situation where our survival is at risk.

As a result, discomfort is not optional in learning something new, it's a requirement.

Self-taught programmers experience the worst of it. In other learning environments, you have a coach or other peers to help you through the discomfort. However, teaching yourself programming often happens in isolation. Self-taught programmers are required to learn how to deal with the discomfort on their own. You are required to be the coach, student, and cheerleader all at the same time.

Learning programming can be an especially uncomfortable experience because it's often a non-linear learning process. There are times where you feel like you are at the same skill level for days or even weeks. You're still learning little bits of information but there are no signs of tangible progress. While teaching myself Android development, I vividly remember being helplessly stuck for over a week trying to set up and query my database.

I like to compare the learning process to doing a 10,000 piece puzzle without a picture to guide you. Even if you find a few subsections that link up, it takes a lot of time and energy to figure out how it all goes together.

On top of all of this, there isn't a guarantee that the skills you are developing will give you a future pay-out. The app you are trying to make might not be good enough or the job you are hoping to land might not be there when you are ready. Self-doubt creeps in and you start asking yourself "Is this worth it?"

The internal game

The internal pressures stated above, among others, are constantly working against you making the learning process harder. These opposing forces set the stage for what I like to think of as the inner game of self-taught development.

Since every game needs an opponent, the opponent of this game is best summarized by what Steven Pressfield, author of The War of Art, calls Resistance.

"Resistance cannot be seen, touched, heard, or smelled. But it can be felt. We experience it as an energy field radiating from a work-in-potential. It's a repelling force. It's negative. Its aim is to shove us away, distract us, prevent us from doing our work."

The ultimate goal of Resistance is to keep you out of 'danger' and in your comfort zone. It doesn't want you to progress in your life because progress cannot happen without risk.

This is why Resistance finds such a good friend in the learning process.
It's not a stretch to say everyone reading this knows exactly what Resistance feels like. It's that feeling you get when you know you have something important to do but just can't seem to make it off the couch.

The feeling itself isn't the dangerous part, it's how we act in response to it. Resistance will never show its facing directly. Rather, it will manifest through other means. You might be familiar with some of its greatest hits…

1) Binging Netflix
2) Self-doubt
3) Procrastination
4) Happy hour
5) This article

These things are harmless on their own. The danger comes from letting Resistance win for multiple days in a row. If it wins too often, you will find yourself giving up and back where you started.

How do you win?

Here's the catch, you will never fully beat your internal opponent. Resistance will always be with you trying to distract you from the important work. Important work is something new and different and Resistance hates the new and different.

Which brings me to my original point. The people who successfully teach themselves programming have accepted the permanence of this internal opponent and have learned how to play the internal game anew each and every day.

Pressfield says it best:

"I feel it in my guts. I afford it the utmost respect, because I know it can defeat me on any given day as easily as the need for a drink can overcome an alcoholic"

Unfortunately, there is no easy strategy to winning this game. However, there are a few things you can do to increase your odds.

Know thy enemy

"I'm keenly aware of the Principle of Priority, which states (a) you must know the difference between what is urgent and what is important, and (b) you must do what's important first."

Don't just be aware of what Resistance feels like. Also be aware of all the different ways Resistance will manifest. As stated above, it's not always obvious.
The best way to identify Resistance is to be mindful of the root causes of your actions. For example, if you find yourself cleaning your apartment for no great reason, stop and ask yourself why cleaning right now is important. Once you think about it rationally the true reason usually shows itself (and you'll realize your apartment is probably not that dirty).

Keep your third eye strong and always be on the look-out. The more you notice the ways Resistance manifests itself, the more ready you will be to combat it.

Remember, anything that is keeping you from your important work, that's not urgent, is most likely the work of Resistance.

Value Consistency over Passion

"Resistance outwits the amateur with the oldest trick in the book: It uses his own enthusiasm against him. Resistance gets us to plunge into a project with an overambitious and unrealistic timetable for its completion. It knows we can't sustain that level of intensity. We will hit the wall. We will crash."

Passion is great. Don't get me wrong. But passion is short lived. It's like a sugar rush. The highs are high but there will always be a crash. Maintaining high passion over a long period of time is difficult and draining.

Resistance actually likes passion and will use it against you. You will find yourself saying stuff like, "I don't feel as passionate as I did yesterday. I should take it easy." Resistance - 1. You - 0.

The better strategy is to value consistency over passion. Consistency allows you to find freedom through discipline.

Rome wasn't built in a day, it was built brick by brick. I know, I know it's cliche, but it's true. It takes time and patience to learn how to become a software developer. Knowledge and skill aren't things you can just upload to your brain. You need to apply consistent pressure to make new things stick.

Habits are one of the most powerful tools human possess. They allow you to automatically do things without having to think about it. Resistance hates habits.

Resistance wants to you to think. It wants you to sit there and consider all the other things you could be doing. But don't let it. If you develop a good study routine, you can let your habits play the internal game for you.

Conclusion

If you truly want to succeed, you will need to embrace the tough reality of the self-taught programmer. Be ready each and every day for whatever the Resistance throws at you. Be aware of its tricks and keep the strategies from above in mind.

The game isn't easy, but it's winnable. We are all capable of winning this internal game because we all already have in some capacity of our lives.

So suit up, dig in and be ready each day for whatever comes at you.

Did you enjoy this article? Sign up for my email list to receive similar content.