Part I. Coder Skills

Chapter 1. Discovering the Tipping Point for Developers

If you've been programming for a while, a question that has most likely crossed your mind is this:

"Am I a good developer?"

Before we go on, let me share a little secret with you… Every developer, even senior developers, have insecurities when it comes to programming. Few individuals like to share that information, mainly because confidence and even arrogance has become a developer stereotype for some stupid reason.

However, I won't BS you. I can tell you that the more experience I have as a coder, the more I realize how much more there is to learn and how far I still have to go.

Tipping point for developers

With all that being said, I want to discuss topic of defining the tipping point for developers, which is essentially the point at which a developer goes from a beginner to a pro. Since this topic is a bit abstract, it's not possible to point to a specific point in time and say:

"Here it is, this is when it all clicks and makes sense."

There's not a sentinel moment when programming mastery occurs. It's different for every individual.

My own experience

I remember when I was originally learning programming. Understanding the syntax and context did not come easy for me. It seemed like I spent 99% of my time looking things up and copying and pasting code from others just to get my programs running.

The doubt machine

Needless to say, my confidence as a programmer was very low in the beginning. I kept being plagued by nagging doubts, such as:

Maybe programming isn't for you
Even if you code works you won't be able to write your own programs
You're only typing in what the book is saying to do, you won't be able to build anything custom

And the negative thoughts continued from there

The painful process

If you're a new developer maybe some of this sounds familiar to you, or maybe it doesn't and I simply lacked confidence. Either way, I trudged along, trying everything I could think of to improve as a developer:

Going through dozens upon dozens of programming books in various languages
Trying to build up a portfolio of project
Following online guides

However, back when I was originally learning how to code, the online resources weren't quite as good as they are today.

The tipping point(s)

So, what did the trick and pushed me over the edge to become a professional developer? None of those things… and all those things. I persevered through project after project and I consumed every training resource I could find. And slowly something amazing started to happen:

"Everything started to make sense."

The first tipping point

Even though it was a while ago, I still remember the moment my first development tipping point happened. I was sitting in front of my computer in a coffee shop and working on a web application.

A few hours went by and I stopped dead in my tracks, realizing that I had just spent the afternoon building a project and hadn't looked up a single code snippet. It wasn't like I programmed the space station, the project was incredibly basic. However, it was one of the most exciting moments I can remember in my life.

The second tipping point

As great as that was, I still had very far to go. I remember the next moment when I felt like I reached another key milestone. Even though my confidence had increased as a developer, the thought of anyone seeing my code was a very scary thought. However, I had started to build my freelance business and a client (who was also a developer) asked me to perform a pair programming session with him.

He had run into a bug with the program we were building and asked me to jump on a screen sharing session where we could work on the project at the same time. Honestly, I was scared to death when he asked. I had never coded in front of anyone before and the thought of doing it with this client pretty much gave me a panic attack. However, I didn't really have a choice in the matter so I started the session with him. After a few minutes of nervousness, I started to relax and to my surprise not only did I not make a fool of myself, I actually figured out the bug in his code and got the feature working.

The secret

So, what was my secret to getting over the hump and going from a beginner to a professional developer? Unfortunately, there is no easy-to-follow recipe. However, there is a process that is guaranteed to work. And the process isn't specific to becoming a programmer, it's the same whether you want to be a developer or a professional athlete… it's hard and smart work.

The book

In the book The Tipping Point, by Malcolm Gladwell, Gladwell gives countless case studies of what it takes for individuals to achieve mastery in a specific field. The key comes down to how dedicated an individual is to a specific skill. The book postulates that it takes around 10,000 hours for an individual to become a true master of whatever they're pursuing.

I'm not sure I believe in the 10,000-hour rule, mainly because there are a large number of variables when it comes to learning a topic or skill and rarely does a single rule apply for all fields. Also, I think the quality of your practice makes a significant difference.

For example, if you're learning how to play the violin: 5,000 hours of practice with a world class instructor is probably equivalent to 10,000 hours trying to figure it out yourself. However, with all that being said, one thing cannot be denied, the key to mastery is hard work.

The solution

I'm sorry if you were hoping for a quick fix. I can tell you from experience that there are no shortcuts to becoming a developer. You need to learn:

The fundamentals of coding
How to build projects on your own
Various process for working through bugs

Becoming a great developer is not an easy road. However, be comforted in the fact that you are 100% in control of how skilled you will become. The formula is straightforward: the harder you work, the better you will get. So, get your hands on all the material you can find on the language and framework you want to learn. Work through challenging applications and you will be well on your way to mastery.

And soon you will be able to have the exciting moment of clarity when everything starts to click.

Chapter 2. Are Developers Born or Made? – Debunking the Myth of Prodigies

When talking to development students, I've discovered one topic that constantly arises in conversation. And that topic is the misconceived notion that great developers are born with a special programming gene. So, let's walk through the question are developers born or made, from a practical perspective.

Are prodigies real?

Before tackling this question, let's take a step back and discuss the topic of prodigies. Because whenever someone thinks that a certain group of individuals are born with superhuman-like talent, they're essentially saying that these special people are prodigies.

The Mozart case study

But are prodigies real? Let's take a look at one of the most famous prodigies of all time, Mozart. At the age of 5, Mozart was playing concert grade music to the royal family. Surely, this would qualify Mozart as a prodigy, right?

In his book, Peak: Secrets from the New Science of Expertise, researcher Anders Ericsson dispels a number of commonly held prodigy myths. He had this to say about Mozart:

"If you compare the kind of music pieces that Mozart can play at various ages to today's Suzuki-trained children, he is not exceptional. If anything, he's relatively average."

In his book, Ericsson dedicates a full chapter to debunking the concept of prodigies. And in each case, he illustrates that the individuals achieved their respective levels of success through massage amounts of work.

Are developers born or made?

Extending the Mozart case study, let's discuss how this applies to developers. Whenever we see a skilled coder it's easy to think that they were born with the innate ability to build applications and that learning new languages and frameworks comes easy to them.

However, nothing could be further from the truth. Over the years I've known more developers than I can count and I have yet to find a single one that was a born developer. I know programmers that work for Google and Amazon, along with computer science professors who specialize in research that boggles my mind to think about. And as amazing as all of these individuals are, each one of them became a great developer through hard work and dedication.

The tipping point

In Chapter 1, Discovering the Tipping Point for Developers I've discussed the tipping point for developers. The longer I teach and the more I work on my own coding skills, the more I'm convinced that the key to excellence is as straightforward as focused practice.

If you want to become a skilled developer badly enough, and you're willing to:

Dedicate the time
Learn from experienced teachers
Fight through frustrating challenges
Continually build projects with features you've never developed before

You're going to wake up one day and realize that everything is clicking and that you've become a professional programmer.

Why we love the prodigy myth

Before I end this chapter, I want to address a subtle issue that explains the reason of why we, as humans, love the idea of prodigies.

The concept of prodigies, individuals born with a natural ability to be successful at a certain skill, such as sports, math, or programming, can be detrimental to our own success. This belief is dangerous because it causes our minds to have negative responses to failure.

For example, if you're an aspiring developer who thinks that programmers are born and not made, when you come across a bug that you can't seem to figure out or a feature you can't build, your first reaction might be:

I guess I wasn't born to do be a developer.

Or:

I wish I had talent like XYZ programmer, everything seems to come so easy to him.

If you catch yourself with thoughts like these, remind yourself that prodigies aren't real.

Developers achieve greatness through smart work and perseverance. The 10,000-hour rule from the Tipping Point book by Malcolm Gladwell may not be exactly accurate. However, it does give a general guide for how much work is required to reach a level of mastery.

If you feel like you weren't born with the "developer gene", go and knock out 10,000 hours of focused practice on building applications. I think you'll be pleasantly surprised to find that you'll become so good, that other people will look at you, and they'll think… that you were just born this way.

Chapter 3. Do You Have to Be a Genius to Be a Developer?

We've discussed the topic of whether great developers are born or made. And in this chapter, we're going to look at a similar topic from a different angle. And we're going to answer the question do you have to be a genius to be a developer?

Because of the near-magical nature of coding, one of the most common remarks I hear from individuals who hear what I do is:

"Oh wow, you're so smart!"

In fact, just recently I traveled to meet with a group of developers and the head of the company introduced me by saying:

"This is Jordan, he's just here to be smart."

I know that when people say things like this it comes from a good place. However, it bothers me. And it bothers me for a couple reasons:

First and foremost, these type of comments make it seem like all it takes to become a great developer is being smart.
Following up on the above point, these remarks devalue the countless hours of work that are required to learn development.

The running man

I'm going to get off my soap box for a moment and discuss the life of Steve Prefontaine. If you've never heard of him before, Prefontaine was one of the world's greatest runners during his time. Before tragically dying in a car accident at 24 years old, he had already broken seven track world records.

During his climactic rise to success, many people would try to compliment Prefontaine by saying how talented he was, and by calling him a prodigy, such as on the cover of Sports Illustrated.

However, he was famous for getting furious at people for this type of statement. He said that his success had literally nothing to do with talent. In fact, he said he wasn't born with any innate ability as a runner. Instead he credits 100% of his success with his legendary work ethic.

Do you have to be a genius to be a developer?

It's important to take the same approach that Prefontaine took as developers. If you fall into the trap of thinking that only geniuses can become good coders, it will most likely lead to quitting when tasks become challenging. This is because our minds constantly are searching for ways to work less. And if you believe that being a genius is a requirement for development, you will have a built-in excuse for faltering on your developer learning journey.

The way the mind works

In a comprehensive educational study published in Scientific American (http://www.scientificamerican.com/article/the-secret-to-raising-smart-kids1/), kids were broken into two groups and taken through some academic assignments. Both groups scored around the same for the assignments. One of the groups were praised by their parents and teachers, and the focus of the compliments centered around how smart and talented the kids were.

The second group of students were complimented in a different manner. Instead of complimenting students on their innate ability, students were complimented on how hard they worked.

After going through this cycle of compliments, the same two groups of students were presented with new, and very challenging assignments.

The first group of students, the ones that had been told that they were brilliant, ended up giving up and not completing the tasks that were assigned to them. However, the second group of students, the ones that were complimented on their hard work, performed dramatically better than group 1.

The reason

So why did two groups of students have such different results when, by all appearances, the students had the same level of actual skill?

The researchers concluded that the students from group 1 felt like the top priority was maintaining their genius status. So, they quit the second assignment early because they didn't want to look bad and tarnish the genius label that they had been given.

However, the second group of students didn't feel the pressure to maintain a genius status. Instead, they wanted to maintain their new reputations as hard workers. With this mindset, the second set of students worked through the challenging topics instead of giving up.

A smarter approach

So, instead of taking the mindset that you need to be a genius to become a developer, take the mindset that best developers are also the hardest working developers. With this approach, your potential for skill is literally limitless. You are 100% in control of how good you will become as a coder. And your success will completely be determined how hard (and how smart) you are willing to work.

The way the mind works

In a comprehensive educational study published in Scientific American (http://www.scientificamerican.com/article/the-secret-to-raising-smart-kids1/), kids were broken into two groups and taken through some academic assignments. Both groups scored around the same for the assignments. One of the groups were praised by their parents and teachers, and the focus of the compliments centered around how smart and talented the kids were.

The second group of students were complimented in a different manner. Instead of complimenting students on their innate ability, students were complimented on how hard they worked.

After going through this cycle of compliments, the same two groups of students were presented with new, and very challenging assignments.

The first group of students, the ones that had been told that they were brilliant, ended up giving up and not completing the tasks that were assigned to them. However, the second group of students, the ones that were complimented on their hard work, performed dramatically better than group 1.

The reason

So why did two groups of students have such different results when, by all appearances, the students had the same level of actual skill?

The researchers concluded that the students from group 1 felt like the top priority was maintaining their genius status. So, they quit the second assignment early because they didn't want to look bad and tarnish the genius label that they had been given.

However, the second group of students didn't feel the pressure to maintain a genius status. Instead, they wanted to maintain their new reputations as hard workers. With this mindset, the second set of students worked through the challenging topics instead of giving up.

A smarter approach

So, instead of taking the mindset that you need to be a genius to become a developer, take the mindset that best developers are also the hardest working developers. With this approach, your potential for skill is literally limitless. You are 100% in control of how good you will become as a coder. And your success will completely be determined how hard (and how smart) you are willing to work.

The reason

So why did two groups of students have such different results when, by all appearances, the students had the same level of actual skill?

The researchers concluded that the students from group 1 felt like the top priority was maintaining their genius status. So, they quit the second assignment early because they didn't want to look bad and tarnish the genius label that they had been given.

However, the second group of students didn't feel the pressure to maintain a genius status. Instead, they wanted to maintain their new reputations as hard workers. With this mindset, the second set of students worked through the challenging topics instead of giving up.

A smarter approach

So, instead of taking the mindset that you need to be a genius to become a developer, take the mindset that best developers are also the hardest working developers. With this approach, your potential for skill is literally limitless. You are 100% in control of how good you will become as a coder. And your success will completely be determined how hard (and how smart) you are willing to work.

A smarter approach

So, instead of taking the mindset that you need to be a genius to become a developer, take the mindset that best developers are also the hardest working developers. With this approach, your potential for skill is literally limitless. You are 100% in control of how good you will become as a coder. And your success will completely be determined how hard (and how smart) you are willing to work.

Chapter 4. How to Study and Understand Complex Topics?

When I was younger I used to struggle learning a new or difficult subject, and over the years and about a decade of university and grad school have helped me put together a strategy for how to study and understand complex topics. Typically, I apply this learning system to subjects such as algorithms and software engineering; however, it can be applied to any topic.

While there is a near infinite set of study strategies out there, I like this approach because it utilizes a divide and conquer strategy, focusing on breaking a complex topic into easy-to-understand components, and putting the pieces back together at the end to see how they all work together.

A system for how to study

Let's take a case study example: understanding how logarithms work. Logarithms are used throughout the fields of mathematics and computer science; however, unless you use them regularly it's easy to get rusty on them:

The first task that I will do is take a piece of paper and write Logarithm in the center and circle it.
Next, I'll go to a comprehensive post on the topic, such as one on Wikipedia. When reading the first sentence, I come across a few terms that are a bit fuzzy:
- Inverse operation
- Exponentiation
I will stop reading the logarithm article and go and read those two articles until I feel comfortable with what they represent. After I feel good about those two items, I write them as their own circles that connect to the Logarithm circle. I will also add any examples that will help me understand what the terms mean if necessary.
Next, I'll go back to the original Logarithm post and keep going through the article repeating this process until the entire page is filled with a mind map that explains each component that makes up logarithms and how they work together. This may include base case examples, such as:
64 = 2^6 is the same as log 2 (64) = 6

If this seems like a dead simple approach to study…it is. The goal of studying is to learn a topic, and one of the easiest ways to understand a complex subject is to break it into easy to comprehend components. For example, if you're trying to understand an advanced algorithm in computer science from scratch, you may feel a little intimidated.

However, if you break the algorithm down into small enough components you'll see that it's essentially a process of steps made up of connecting simple modules such as loops, manipulating variables, and using conditionals. A problem is only hard when you try to think of it as a whole. However, any concept can be understood if you simplify it down to easy to comprehend pieces.

Obviously, the more complex the topic, the longer it will take to deconstruct; however, I am a firm believer that anyone can understand any topic assuming they dedicate themselves and put the work in. I hope that you can leverage this mind mapping process to understand complex topics and that it will help you learn how to study properly and truly learn.

Chapter 5. Effective Study Practices for Developers

Let's imagine that you're back in school and midterm exams are coming up. How would you study? Some common approaches might be:

Re-read the study materials or lecture notes
Highlight and memorize the key terms
Go over your notes constantly until test day comes

Those all sound like effective study practices. However, cognitive research has shown that many of the traditional study patterns that students have followed for decades simply do not work.

I didn't make up that list of study patterns. That's exactly what I used to do in preparing for exams. However, I discovered (after failing a number of tests) that these strategies failed miserably when it came to helping me to truly learn new concepts.

Why traditional study habits don't work

This type of approach to studying doesn't work because our minds don't function like computers. A computer can take in information and then spit it back out. However, our minds are more relational in nature.

By relational in nature, I mean that our brain functions like a graph-based network. If new information attempts to enter the brain without being connected to any of our previous knowledge, it will simply be rejected.

For example, let's imagine that you are new to learning programming. If you simply run through a list of programming terms and syntax rules, you might memorize them in the short run.

However, because your brain hasn't been properly introduced to the concepts, it will eventually eject the information, viewing it as useless since it's not related to the rest of your view of the world.

However, imagine that you take a different approach. In this new, more enlightened approach, you work with your brain and allow it to connect each of the new programming concepts that you're learning to knowledge and experiences that you already have.

An effective study practices case study

Whenever I'm teaching a new programming concept to students, I try to draw a fitting analogy to a real-world concept. This process is called reification and I view it as one of my most important tasks as a teacher.

Let's imagine that you are learning about the MVC (Model, View, Controller) design pattern in software development. You could take the approach of trying to memorize each of the roles of the Model, View, and Controller. However, that strategy wouldn't help you answer questions related to how each of the components work together. And if you memorize quiz questions and answers, you probably will have issues answering anything that you haven't memorized.

The reification example

What if instead of trying to memorize key terms about the MVC pattern you focused on drawing a real-world analogy to the process? My favorite way to understand this type of architecture is comparing it to a restaurant:

Model: The model is the chef in the kitchen. In the same way that a chef prepares the meal for customers, the model works directly with the data for the application.
Controller: The controller works like a restaurant waiter. In an application, the controller's role is based on taking requests and managing communication between the model and the view. This is much like a waiter who takes customer orders, communicates with the chef, and eventually brings the food out to the table.
View: The view is like the table that a customer is sitting at. It doesn't do much besides provide a platform for placing the food on. This is exactly like how the view should operate in an application. If built properly, a view should simply be a place where data is shown to users.

Do you see what we just did? We learned about the MVC design pattern in a way that our minds can actually comprehend. I could fall out of bed and recite back the role of each component of the MVC architecture, not because I spent countless hours trying to memorize them, but because I connected the concept to my real-world experiences.

The reification example

What if instead of trying to memorize key terms about the MVC pattern you focused on drawing a real-world analogy to the process? My favorite way to understand this type of architecture is comparing it to a restaurant:

Model: The model is the chef in the kitchen. In the same way that a chef prepares the meal for customers, the model works directly with the data for the application.
Controller: The controller works like a restaurant waiter. In an application, the controller's role is based on taking requests and managing communication between the model and the view. This is much like a waiter who takes customer orders, communicates with the chef, and eventually brings the food out to the table.
View: The view is like the table that a customer is sitting at. It doesn't do much besides provide a platform for placing the food on. This is exactly like how the view should operate in an application. If built properly, a view should simply be a place where data is shown to users.

Do you see what we just did? We learned about the MVC design pattern in a way that our minds can actually comprehend. I could fall out of bed and recite back the role of each component of the MVC architecture, not because I spent countless hours trying to memorize them, but because I connected the concept to my real-world experiences.

The hard way

Over the years I've concluded that if studying is easy…I'm doing it wrong. I used to follow study pattern of:

Read
Memorize
Repeat

This was partly because it was easy. It wasn't mentally taxing to sit down and read through a textbook or my notes. However, research is proving that this type of study habit is not only ineffective, it is also damaging.

Additional negative effects

How is it damaging? If you have followed this type of study system you know one thing: it takes time. This time spent reading and memorizing could have been used in countless other ways that would have proven more effective in the long run. And when it comes to studying, time is one of the most valuable assets that you have, so wasting it is akin to an educational felony.

Additional negative effects

How is it damaging? If you have followed this type of study system you know one thing: it takes time. This time spent reading and memorizing could have been used in countless other ways that would have proven more effective in the long run. And when it comes to studying, time is one of the most valuable assets that you have, so wasting it is akin to an educational felony.

The comprehensive study system

In addition to the process of reification, there are a number of other study strategies that research is showing to be more effective than traditional study practices. In their book Make It Stick, cognitive psychologists Brown, Roediger, and McDaniel give the following recommendations for studying:

When learning from a textbook, use the key terms from the back of each chapter to test yourself.
List out key terms and use each one in a paragraph; this will test to see if you understand a concept outside of the realm of how the textbook or instructor supplied it.
While reading new material, convert the main concepts into a series of questions and then go back and answer the questions when you're done reading the chapter.
Rephrase the main ideas in your own words as you go through the material.
Relate the main concepts to your own experiences, much like the reification process we've already discussed.
Look for examples of key concepts outside of the text. When I'm learning a new programming language I never rely on a single source. If I come across a concept that doesn't make sense I'll usually review 2- 3 other sources that provide alternative explanations to what I'm attempting to learn.

Summary

In summary, when it comes to effective study practices, make sure that you're making the most of your time. Remember that the most important goal with studying is retaining knowledge so that you can use it in real-world scenarios. And the best way to accomplish this goal is by following strategies that work with your mind's learning patterns.

Chapter 6. Defining Deep Work and What It Means for Developers

Standing on the podium, Michael Phelps stares at the American flag and listens to the National Anthem after winning gold once again. After watching Phelps win 21 gold medals (at the time I'm writing this), it's natural to ask: "Was he simply born for greatness?" I don't know. Yes, his body type has helped him take advantage of physical elements of swimming.

However, there are millions of individuals with his height and wingspan who watch him at the Olympics from their couches every four years. There is no magical swimming gene that Phelps was born with. Instead, the secret to his success can be found in his discipline to a practice called deep work. Muscle Prodigy (https://www.muscleprodigy.com/michael-phelps-workout-and-diet/) research claims:

"Phelps swims minimum 80,000 meters a week, which is nearly 50 miles. He practices twice a day, sometimes more if he's training at altitude. Phelps trains for around five to six hours a day at six days a week."

If Malcom Gladwell's 10,000-hour rule is even close to being accurate, Michael Phelps surpassed this benchmark years ago.

In case you're wondering how this applies to coding, don't worry, I haven't forgotten that this is a show for developers.

Definition of deep work

As you go through these chapters, you may discover that one of my favorite books is Deep Work by Cal Newport. (The fact I referenced the book a few dozen times may given it away). So, what exactly is deep work? A dead simple explanation of deep work is:

"Deep work is the ability to focus without distraction on a cognitively demanding task."

Whether you believe that swimming is cognitively demanding or not, I believe that Phelps's example is fitting. If you have ever attempted to train with the level of intensity that Phelps does, you can attest to the mental toll that training takes. So essentially, deep work can be simplified by saying that it has the following characteristics:

It's a real-world action. It's not a theoretical concept, it's something that you can practically implement.
To work properly you have to eliminate 100% of your distractions.
The task has to be challenging.

The deep work strategy for developers

Let's dissect the definition of deep work and build a practical strategy for how it can be implemented from a developer perspective. Let's imagine that you want to learn about the computer science topic of asymptotic analysis. If you've never heard of asymptotic analysis, don't worry, you can trust me that it qualifies as a challenging topic.

Taking action

Let's start with the fact that deep work is an action. With that in mind, you will need to make a clearly defined time slot. If you have never practice deep work studying before, I'd recommend limiting the slot to around two hours. As you'll discover deep work is a draining task. For our example, let's imagine that you have designated 9 AM to 11 AM as when you're going to study asymptotic analysis.

Removing distractions

With your time slot set, now it's time to remove any and all potential distractions. Let me be 100% explicit; this means:

You cannot check your email.
No phone calls. In fact, put your phone in airplane mode to ensure no one calls or text messages you.
Don't even think about checking Instagram, Facebook, Twitter, or Tinder. All your swipe rights will have to wait for a few hours.

If I missed any distractions you can add them to the list. It may also help to listen to classical music to block out any potential sound distractions while you study.

Study hard and smart

Now that you have dedicated a few hours to studying asymptotic analysis and have removed all your distractions, it's finally time to get down to business. If you think that now you can simply start reading a few Wikipedia posts, I'm sorry, that won't earn you a deep work badge.

For deep work to be truly effective, it has to be difficult. If I was learning about asymptotic analysis for the first time and wanted to practice deep work while studying it, I'd take the following approach:

I'd begin by reading a number of online resources on the subject.
Next I'd watch an online lecture while taking notes.
I would then find practice exercises where I would attempt to figure out problems from scratch.
Next, I would write a blog post or record myself teaching the concept.
Lastly, I would have another student or instructor review my teaching and exercises to ensure that I understood the concept properly.

Do you see how much more comprehensive this type of studying is? Even if you had never heard of asymptotic analysis before your deep work study session, you would be fluent in it after you were done.

Multiple sessions

When I mentioned earlier how you should limit your deep work sessions to around 2 hours, I don't mean that you can understand any topic in that period of time. Some complex topics may take days, weeks, months, or years to properly understand. So, it is completely fine to spend a number of sessions working through the same concept. If you are going to do this, I recommend that you make notes for what you were doing when you stopped. This will allow you to pick up right where you left off.

Summary

I hope that this has been a helpful introduction to what deep work is and how you can practically implement it as a developer. If you want to learn more about the topic I suggest that you pick up Newport's book. It will give you a great set of tools for learning how to use deep work to constantly improve as a developer. When it comes to learning, deep work is the closest thing you can get to steroids. Good luck with the coding!

Chapter 7. Task Switching Costs for Developers

In this chapter, I'm going to discuss the concept of task switching costs. Task switching, commonly referred to as multitasking, can be detrimental to your performance as a developer and can even lead to errors in your projects. Our world has changed dramatically over the past decade, whether for good or bad is not a topic we'll discuss in this chapter. However, one thing is sure: we are constantly bombarded with distractions.

As I was researching this chapter, I received over a dozen emails, 7 Snapchat messages, 30 notifications on Instagram, 7 Twitter notifications, 5 Skype instant messages, and surprisingly only 9 text messages. If you were counting, that's around 72 various notifications that were pushed to me in the past two hours. Beyond that, I researched this chapter at a coffee shop filled with potential distractions.

So exactly how bad are distractions? Research from Gloria Mark (https://www.fastcompany.com/944128/worker-interrupted-cost-task-switching), who is a Professor in the Department of Informatics at the UC Irvine, shows that it takes, on average, 23 minutes and 15 seconds to get fully back on task after being distracted. That's a very, very bad thing when it comes to productivity; however, I've seen it myself, I've lost track of how many times I'll be in the middle of a development project and receive an email on a completely unrelated matter and instead of ignoring it and continuing to work I'll read it and then spend time working on another task before returning to the project.

This may not sound like a major issue, except that when I come back to the project, I don't pick up from where I left off. Instead I have to re-familiarize myself with what I was working on the moment that I was distracted. If the problem was complex, it may take me even longer than the 23 minutes in order to get back in the zone and working on the project.

So, in a world filled with emails and social media distractions, how can anyone get any real work done? After reading Cal Newport's book Deep Work, I started to put together some practical ways that I can work efficiently and still stay in touch with the world.

A system for decreasing task switching costs

If I'm working on a project, I set aside a specific amount of time that morning. For example, if I'm working on Project X for 2 hours, I will put it on my calendar and say that from 9 AM to 11 AM I'm working on Project X.
I remove any and all negative distractions during that time. That means I'll usually put my phone on Airplane mode so I don't receive any social media notifications. Notice how I said negative distractions? I made this distinction because in the same research report from UC Irvine it revealed that not all distractions are bad. If the distraction is related to the task that you're working on, it can actually be beneficial. For example, if I'm working on the routing engine for a web application and the client messages me to discuss the application, what they say may actually influence the work that I'm doing or give me an idea on how to refine it. That's a good distraction and it's why I typically will keep my email and instant messenger on while I'm working. However, if I see that the Skype message or email is coming from another client or is completely unrelated I'll simply ignore it. I do know many Deep Work proponents who would say that 100% of your distractions have to be eliminated; however, that's not always practical.
Have a clear conclusion for whatever you are studying or working on. If you don't establish an end for the task, your mind is going to be prone to wander in the same way that a runner without a finish line won't be able to effectively compete in a race. The research around task switching costs also reveals that even planned distractions are harmful, so if you are planning on working for 2 hours straight on a project, don't plan any breaks in the middle of the task. Maintain your focus throughout the allotted time and then you'll be free to relax afterwards.

I hope that this has been a helpful overview of task switching costs and that you now have some practical methods for staying on task.

Chapter 8. How to Use Willpower Limits Instead of Letting Them Use You?

There are a number of common characteristics among great developers. However, few virtues are as important as willpower. World class coders constantly are forced to work through complex concepts, and without willpower they would give up before experiencing any kind of breakthrough. In this chapter, I'm going to walk through the topic of willpower limits.

This will include a practical walk through on:

What willpower limits are
How you can improve your personal willpower limits
A plan for being intentional about managing willpower limits

What are willpower limits?

For graduate school I have performed extensive research on the topic of task switching costs. While studying about task switching, I came across the topic of willpower limits and how they related to performance. Essentially, the study of willpower limits says that individuals have a limited amount of decision making power each day.

How many decisions do you make each day?

If that sounds weird to you, don't worry, I had a hard time with the concept right away too. So, let's go through a typical day for a developer. What are some decisions that you make each day?

Deciding to get up or press snooze on the alarm clock
Picking out what to eat for breakfast
Selecting your clothes for the day
Deciding if you want to go to the gym, a run, or walk around and play Pokémon Go
Deciding on which route to take to work
And the list goes on and on

Notice how none of those items are related to development at all. And in fact, those were all common decision items that you have to make each morning before you even get into work. If you actually count the number of decisions that you have to make each day, you'd discover the number is probably in the hundreds or even thousands. If you include subconscious decisions such as staying in your lane while driving, the number is most likely in the millions every day!

Why is willpower important?

Hopefully, I've helped you see all of the decisions that we make daily. So why do willpower limits matter when it comes to making decisions? Mainly because without willpower the quality of our decisions will suffer dramatically.

Imagine yourself without willpower for a second. With no willpower, you:

Would eat whatever you wanted, harming your overall health
Wouldn't study, thus never improving as a developer
Would recklessly spend money on whatever popped into your mind, forcing you into debt and eventually bankruptcy

It's not a pretty picture, which is why willpower is so important when it comes to making decisions. Willpower gives you the self-control to make the right decision, even when it's not the easy one.

Are willpower limits real?

So, with all of that in mind, is there really a limit to the amount of willpower you have each day? I recently went through the book, The Willpower Instinct, written by Dr. Kelly McGonigal (no relation to Professor McGonagall that I'm aware of). In the book Kelly presents research and countless case studies that clearly show that we do indeed have a limit to our daily willpower.

Imagine that your willpower is like a bottle of water. Each morning you start with the bottle filled to the top. And each time you make a decision or have to use willpower, such as deciding to get up instead of hitting snooze on the alarm clock, a little of the water gets poured out. As you go through your day you'll eventually "pour out" all of your stored-up willpower.

When the willpower well runs dry

So, what happens when the willpower well runs dry? Typically, it leads to poor behavior, such as:

Procrastination
Making bad decisions
Poor performance

If you find yourself experiencing these types of thought patterns, it could very well be due to hitting your willpower limit too quickly.

I know from experience that I typically write my best code in the morning when I'm fresh, whereas I find myself running into more development bugs when I work later in the evening. When I realized this pattern, it made me believe even deeper in the concept of willpower limits and how they can negatively affect performance.

Saving up willpower

With all of this in mind, the concept of saving up our willpower reserves seems like a pretty important concept. Let's go back to the water bottle analogy. If you were in a desert and had a limited supply of water, what would you do? I think the obvious answer is that you would only use the water when it was needed.

So, if we treat our willpower like a precious resource, it would make the most sense to use it on our most important tasks each day.

What's a practical way of doing this? Let's walk through a simple but practical example.

One outfit to rule them all

If you watch my show on CronDose you may have noticed something… You get a gold star if you noticed that for the last 13 weeks (14 weeks if you include this week) I've worn the same shirt. Please note, it's not the same exact shirt. When I decided to experiment with the one outfit concept I purchased eight identical shirts.

So why am I doing this? By wearing the identical outfit each day, it completely removes the set of decisions that I would normally have to make each morning when I'm getting dressed. I no longer have to pick between 100+ shirt and jeans combinations. And it has the added benefit that it's quite comfortable.

Does wearing the same outfit each day really help improve my performance? I can't scientifically say one way or the other. Most likely it has a negligible effect. However, it has a much more powerful benefit than simply removing my morning outfit decision. Each day when I put this shirt on it reminds me that I have a limit to my willpower and that I need to use it wisely. And having that mindset does make a difference.

Being a copycat

As a side note, the idea of wearing the same outfit is not an original idea. Steve Jobs, President Obama, and Mark Zuckerberg all have a similar ritual and that's where I got the idea from. If some of the most successful individuals in the world make it a priority to remove any and all unnecessary decisions, I thought it would be a good idea to try out.

Focusing willpower

Wearing the same outfit each day is a good idea for taking care of some low-hanging decision-making fruit, but it's only the beginning. To really ensure that you get the most out of your willpower each day, you need to be intentional with how you use it.

For example, I've talked before about how I have a daily list of to-do items that I follow religiously. To ensure that I'm getting the most out of my day, I always schedule my most challenging tasks in the morning. By taking this approach, I don't risk running out of willpower while I'm working on a vital project. From there I save my lower priority to-dos, such as reading, for the end of the day.

By following this pattern, I've noticed a significant improvement in my work over the past few months and I also feel more relaxed at the end of the day.

Summary

I hope that this has been a helpful discussion on the topic of willpower limits and that it has given you some ideas on how to manage your own willpower.

Chapter 9. Cramming Versus Consistent Study and a Study System that Works

In this chapter, I'm going to discuss the concept of cramming versus consistent study. And don't change the channel if you're not in school, if you're a developer, or if you want to learn software development the learning never ends.

On an average, I typically go through over a dozen books at the same time and around 4-5 various online courses because the deeper I get into development, the more I realize how much more I really need to understand.

With that in mind, I think the topic of cramming versus consistent study habits should be beneficial since the way that we study is just as important as the volume of how much we study. Most of us have been in the situation where we put off studying for too long and before we know it an exam is upon us that we have to cram for. If you can remember back to the last time that you crammed for an exam or project, how much of what you studied can you remember today?

If you're like me, probably not much. While I was in college I was very bad at this and ended up cramming for many of my midterms and finals, with mixed results from a grade perspective. However, once I got to computer science graduate school at Texas Tech I ran into a problem—cramming didn't work at all.

Software development concepts build upon themselves, so what was taught in the Fall semester would be the foundation for even more complex topics that would be discussed in the Spring. In the Fall, I would learn about logic programming and in the Spring, I'd have a course where I had to build a production application using the Prolog programming language.

Using cramming as a study technique resulted in me having very poor retention of what I was learning, which meant I had to go back and relearn the topics that I had already forgotten from the previous semester. I don't have to tell you how stressful this made my academic life, not to mention the fact that I was working as a full-time developer at the same time. So, I knew that something had to change and I put together a system for helping me retain what I learned each day through a consistent study pattern. Much like a function in programming, my system for consistent study takes in a few parameters:

Scheduling
Fighting procrastination

For scheduling I created a to-do list, segmented by day, for what I needed to study, which included academic papers, books, and watching online lectures. I put these in a drag and drop to-do list on Basecamp. After I studied a particular item I would drag it up to the next day's to-do list so I would have a visual cue that I was done for that day.

For me, I would procrastinate studying because staring at the list of the books I had to read was intimidating, and this was mainly due to the fact that I didn't set any practical goals for studying. If you stare at a Discrete Mathematics textbook and tell yourself to study, it's natural to want to put it off; however, if you set small goals, you're less likely to put it off.

With that in mind, I'll put a note, such as read 3 pages of my Information Retrieval textbook, and 3 pages doesn't sound nearly as scary as the vague "just study" mindset. The interesting result in making small, manageable goals for studying is that not only does it help curb procrastination, but typically I will also read much more than the 3 pages. There have been plenty of times where I set of goal of a few pages of a book and ended up reading a few chapters.

With all this being said, there are times where I plan deep work study sessions. In one of these sessions I will set aside 2-3 hours of time to sit down, without distractions, and work through a complex topic. However, I always limit the time to no more than 2-3 hours per day, and I will usually not study any other topics on these days since I'm usually mentally drained by the end of them.

I hope that this chapter has been helpful and will help you develop your own system for studying so that you can retain when you learn and be able to use it when it matters most.

Chapter 10. Is Reading Important for Developers?

Throughout this book, I have written quite a bit about improving as a developer, specifically discussing various ways to study from a practical perspective. However, in this chapter, I want to specifically answer the question: is reading important for developers?

The short answer to the question is: yes! However, as computer scientists it's poor form to simply take someone at their word. So, let's dive into why reading is critical to improvement.

Why is reading important for developers?

Let's analyze a few key statistics with regard to reading.

CEOs and reading

How many books do you currently read a year? If your answer is that you're too busy to read entire books, let me ask you another question: are you busier than the CEOs of the world's most successful companies? Probably not.

However, research from the Rype Academy (http://rypeapp.com/blog/5-easy-ways-to-read-more-books-and-double-your-knowledge/) shows that CEOs such as Elon Musk, Mark Cuban, and Peter Thiel read around 60 books a year! That's 4-5 books each month.

Compounded learning

So why do some of the most successful individuals in the world take the time to go through so many books? At a high level it may seem excessive, but if you truly believe that knowledge is power, wouldn't it make sense to dedicate whatever time is needed to attain more knowledge?

If you look at reading like a form of linear learning, then yes, reading would be a waste of time. Linear learning would be a 1 to 1 transfer of knowledge. For example, if it took the author of the book 10 years to research a topic and it took me 10 years to go through the book, that would be pretty pointless. At the end of the day this type of reading would be pointless.

However, I look at reading like it's compounded learning. What is compounded learning? Good question! Compounded learning is the process of taking the knowledge from an individual, but not having to spend the same amount of time that it took that individual to research the topic.

A compounded learning case study

For example, imagine that you read a book on How to Become a Better Developer. The author of the book had to spend years researching the topic (assuming that it was a well-written/well-researched book). However, if you go through the book in a few weeks, that means that you were able to gain years worth of knowledge in a few weeks!

Research (http://blogs.plos.org/neurotribes/2011/06/02/practical-tips-on-writing-a-book-from-22-brilliant-authors/) shows that top authors will spend a minimum of two years researching a book. And that research time doesn't take into account the fact that authors draw on their entire lifespans to write a book. All of this means that each time you read a book it's as if you were able to gain a lifetime's worth of experiences and wisdom from the author.

The CEO who didn't have time to read

A few years back, I was offered a CTO position for a startup in New York City. The job had a good salary, great stock options, and an excellent product.

However, during a dinner meeting with their Founder/CEO, I asked him about a book I had finished reading that discussed best practices for tech startups. He said that he had never heard of the book.

This wasn't a problem, there are millions of books and I don't judge someone for having different literary tastes than myself. However, the CEO followed this statement up by saying that he didn't have time for reading. He was too busy building the business.

The CEO's view of reading resonated with me during the job consideration process. And I ended up turning down the job. If the CEO didn't dedicate time to read and learn from others, that means that he would be relying solely on his own knowledge and life experiences. And even the most brilliant business person will fail if they think that they already have all the right answers.

My reading system

It's one thing to say that reading is important; it's another thing entirely to go through a large number of books on a regular basis. With that in mind I've developed my own reading system. This system also takes into account a number of complaints that I've heard others say about reading.

The reading schedule

First and foremost, I schedule a set amount of time each day for reading. Usually, this equals around 1-2 hours; however, on weekends this number can be double that number. At any given point of time, I'm usually going through a dozen books ranging from mind/skill hacking through technical programming books.

Audio books are books too!

I'm not sure where the stigma of audio books came from. However, with my travel schedule, I've discovered that audio books are an invaluable tool in my learning arsenal. Obviously, you can't go through programming books via Audible. However, you can go through skill and business-based books. And I personally have hundreds of books in my Audible account, many of which I've gone through multiple times. In fact, many of the books I've discussed and quoted from were books I listened to rather than read.

Books are too expensive

One of the top complaints I hear from students is that books are too expensive. My response is always: if you're not willing to sacrifice to improve, then you're not going to attain your goals. And that includes sacrificing financially.

With that being said, there are ways that you can go through a large number of books, even if you're on a budget. To start off, your local library has countless books that you can learn from each day. And assuming that you bring the books back on time, a library is a completely free option. I have a library within walking distance of my home in Scottsdale, AZ, and I will visit it a few times a week to discover new books.

Additionally, you can sign up for book memberships. Safari Books Online offers an All You Can Read package. I have this membership and have gone through a large number of technical programming books in their database over the years.

Summary

In summary, is reading important for developers? I believe that it is. Reading enables you to activate compounded learning. And if you have the chance to gain years' worth of knowledge and experiences in a few weeks, it seems insane to pass up on an opportunity like that.

Chapter 11. Learning How to Code – Getting Past Skill Plateaus

A common pattern I see with students learning how to code is:

Quickly learning a massive amount of information.
Then running into a seemingly insurmountable wall. In this phase, the student typically feels like they've reached the zenith of what they're going to be able to accomplish about development.

This second phase is called a plateau. In this chapter, we're going to walk through strategies for getting past skill plateaus.

It's important to understand that everyone follows a similar pattern when it comes to learning a new skill. This means that you will experience times where it seems like every day you're soaking in a wealth of new information. But it also means that you will run into times where it feels like your mind will limit you from learning anything new.

What is a learning plateau?

When it comes to hitting a learning plateau, it's important to look at the potential root causes for why it's occurring. It's been my experience that no two plateaus are the same. And until you've diagnosed why you're not learning, you won't be able to move on to your next level of skill.

False ceiling

Before I continue I want to reiterate something: you will never reach a point where your level of skill is maxed out. Maybe if you're a professional athlete and getting older, then your body is naturally going to decrease in performance. But when it comes to concepts such as understanding development, if you continue to dedicate yourself and if you're willing to listen to experts, your skill will never reach a peak.

Getting past skill plateaus

Over the years I have witnessed a few key reasons why individuals (and myself) run into skill plateaus.

Proper information/resources

When a student lacks access to proper information, it makes learning a more arduous process. Imagine a talented developer in high school who had been relying on her teacher (who had limited skill). In cases like this, the student will need to find additional resources, such as online courses, that will help teach her concepts she's never been taught before.

Best practices

During a phase of the learning cycle when best practices are the focus, students may feel like they are hitting a learning plateau. I remember when I was first learning about test-driven development. The concept seemed counterintuitive. I would spend 2-3 times the amount of time on a feature. And this became incredibly frustrating. It felt like I wasn't learning anything new because my new knowledge wasn't affecting anything on the screen.

However, this phase isn't actually a skill plateau. There are many times where developers need to take a step back and focus on quality over quantity when it comes to building applications.

My advice for going through this phase is to embrace it. Be patient. As soon as you have a firm understanding of how the best practices can be utilized, you'll be able to move onto learning new concepts. The only difference is that now you will be able to leverage your new skills, the result being that you'll be a more refined developer.

Challenging/new tasks

In my experience, the main cause of students hitting a skill plateau is when they stop challenging themselves. If you remember back to when you were first learning development, it seemed like your knowledge was skyrocketing each day.

The reason for this was because each of the concepts you were learning were completely new to you. However, after a certain period of time it seems like it's natural for us to want to become comfortable. Instead of trying to learn something new each day, we simply try to duplicate the work that we've done up to a certain point.

This approach is less taxing mentally. However, it has the nasty side effect of limiting how we improve. Whenever I feel like I'm getting into a rut, I will look at popular websites and I'll start to put together a list of features that I want to learn how to build. From that point, I can put a plan together for what concepts I need to learn in order to implement them.

Frustration = skill

One of my favorite illustrations of getting past skill plateaus was made by the calligrapher, Jamin Brown:

Notice in this illustration how the learning process is filled with plateaus? This is a natural component when it comes to improving at any skill.

But also notice that the key to overcoming a plateau is called the Frustration Zone. I think that's a great name for it. Learning complex topics is not easy. As you've probably heard countless times, "if it were easy, everyone would do it".

Becoming a developer can be one of the most rewarding experiences that someone can have. And part of what makes learning how to code so fulfilling is how many challenges you'll need to overcome to succeed.

Proper information/resources

When a student lacks access to proper information, it makes learning a more arduous process. Imagine a talented developer in high school who had been relying on her teacher (who had limited skill). In cases like this, the student will need to find additional resources, such as online courses, that will help teach her concepts she's never been taught before.

Best practices

During a phase of the learning cycle when best practices are the focus, students may feel like they are hitting a learning plateau. I remember when I was first learning about test-driven development. The concept seemed counterintuitive. I would spend 2-3 times the amount of time on a feature. And this became incredibly frustrating. It felt like I wasn't learning anything new because my new knowledge wasn't affecting anything on the screen.

However, this phase isn't actually a skill plateau. There are many times where developers need to take a step back and focus on quality over quantity when it comes to building applications.

My advice for going through this phase is to embrace it. Be patient. As soon as you have a firm understanding of how the best practices can be utilized, you'll be able to move onto learning new concepts. The only difference is that now you will be able to leverage your new skills, the result being that you'll be a more refined developer.

Challenging/new tasks

In my experience, the main cause of students hitting a skill plateau is when they stop challenging themselves. If you remember back to when you were first learning development, it seemed like your knowledge was skyrocketing each day.

The reason for this was because each of the concepts you were learning were completely new to you. However, after a certain period of time it seems like it's natural for us to want to become comfortable. Instead of trying to learn something new each day, we simply try to duplicate the work that we've done up to a certain point.

This approach is less taxing mentally. However, it has the nasty side effect of limiting how we improve. Whenever I feel like I'm getting into a rut, I will look at popular websites and I'll start to put together a list of features that I want to learn how to build. From that point, I can put a plan together for what concepts I need to learn in order to implement them.

Frustration = skill

One of my favorite illustrations of getting past skill plateaus was made by the calligrapher, Jamin Brown:

Notice in this illustration how the learning process is filled with plateaus? This is a natural component when it comes to improving at any skill.

But also notice that the key to overcoming a plateau is called the Frustration Zone. I think that's a great name for it. Learning complex topics is not easy. As you've probably heard countless times, "if it were easy, everyone would do it".

Becoming a developer can be one of the most rewarding experiences that someone can have. And part of what makes learning how to code so fulfilling is how many challenges you'll need to overcome to succeed.

Best practices

During a phase of the learning cycle when best practices are the focus, students may feel like they are hitting a learning plateau. I remember when I was first learning about test-driven development. The concept seemed counterintuitive. I would spend 2-3 times the amount of time on a feature. And this became incredibly frustrating. It felt like I wasn't learning anything new because my new knowledge wasn't affecting anything on the screen.

However, this phase isn't actually a skill plateau. There are many times where developers need to take a step back and focus on quality over quantity when it comes to building applications.

My advice for going through this phase is to embrace it. Be patient. As soon as you have a firm understanding of how the best practices can be utilized, you'll be able to move onto learning new concepts. The only difference is that now you will be able to leverage your new skills, the result being that you'll be a more refined developer.

Challenging/new tasks

In my experience, the main cause of students hitting a skill plateau is when they stop challenging themselves. If you remember back to when you were first learning development, it seemed like your knowledge was skyrocketing each day.

The reason for this was because each of the concepts you were learning were completely new to you. However, after a certain period of time it seems like it's natural for us to want to become comfortable. Instead of trying to learn something new each day, we simply try to duplicate the work that we've done up to a certain point.

This approach is less taxing mentally. However, it has the nasty side effect of limiting how we improve. Whenever I feel like I'm getting into a rut, I will look at popular websites and I'll start to put together a list of features that I want to learn how to build. From that point, I can put a plan together for what concepts I need to learn in order to implement them.

Frustration = skill

One of my favorite illustrations of getting past skill plateaus was made by the calligrapher, Jamin Brown:

Notice in this illustration how the learning process is filled with plateaus? This is a natural component when it comes to improving at any skill.

But also notice that the key to overcoming a plateau is called the Frustration Zone. I think that's a great name for it. Learning complex topics is not easy. As you've probably heard countless times, "if it were easy, everyone would do it".

Becoming a developer can be one of the most rewarding experiences that someone can have. And part of what makes learning how to code so fulfilling is how many challenges you'll need to overcome to succeed.

Challenging/new tasks

In my experience, the main cause of students hitting a skill plateau is when they stop challenging themselves. If you remember back to when you were first learning development, it seemed like your knowledge was skyrocketing each day.

The reason for this was because each of the concepts you were learning were completely new to you. However, after a certain period of time it seems like it's natural for us to want to become comfortable. Instead of trying to learn something new each day, we simply try to duplicate the work that we've done up to a certain point.

This approach is less taxing mentally. However, it has the nasty side effect of limiting how we improve. Whenever I feel like I'm getting into a rut, I will look at popular websites and I'll start to put together a list of features that I want to learn how to build. From that point, I can put a plan together for what concepts I need to learn in order to implement them.

Frustration = skill

One of my favorite illustrations of getting past skill plateaus was made by the calligrapher, Jamin Brown:

Notice in this illustration how the learning process is filled with plateaus? This is a natural component when it comes to improving at any skill.

But also notice that the key to overcoming a plateau is called the Frustration Zone. I think that's a great name for it. Learning complex topics is not easy. As you've probably heard countless times, "if it were easy, everyone would do it".

Becoming a developer can be one of the most rewarding experiences that someone can have. And part of what makes learning how to code so fulfilling is how many challenges you'll need to overcome to succeed.

Frustration = skill

One of my favorite illustrations of getting past skill plateaus was made by the calligrapher, Jamin Brown:

Notice in this illustration how the learning process is filled with plateaus? This is a natural component when it comes to improving at any skill.

But also notice that the key to overcoming a plateau is called the Frustration Zone. I think that's a great name for it. Learning complex topics is not easy. As you've probably heard countless times, "if it were easy, everyone would do it".

Becoming a developer can be one of the most rewarding experiences that someone can have. And part of what makes learning how to code so fulfilling is how many challenges you'll need to overcome to succeed.

Summary

I hope that this has been a helpful guide and that you now have some practical strategies for getting past skill plateaus. And good luck with the coding.

Chapter 12. Developer Learning Curve – Why Learning How to Code Takes So Long

When it comes to becoming a developer, one of the questions I get asked the most is: why does it take so long to learn how to code? I've discovered the answer can be found in research related to learning curves.

What is the learning curve?

The concept of learning curves has been around since 1885. Typically, the research has been performed in the psychological and cognitive sciences. However, the concept can be clearly utilized when it comes to learning development.

The developer learning curve

The following graph shows the standard learning curve. This was generated by a big data analysis algorithm that analyzed the learning patterns of individuals in a number of industries. The curve is smooth because it takes the average learning process and averages the process.

Later in this chapter, we'll take a look at what a learning curve looks like for a single person. Over the years I've had the privilege of teaching students how to become developers. I've witnessed this learning curve play out again and again. And in this chapter, I want to examine the three stages that all developers go through. Additionally, I'll discuss about how long it takes to traverse from one stage to another. The three stages that I'll discuss are:

Liftoff
The twilight zone
The zone

Liftoff

Let's start off by taking a look at the liftoff stage. This is an exciting time for new students. During this time students are immersed in learning skills that they've never seen before:

Because all the topics that students learn during this stage are new, their expertise skyrockets. I like to call this the liftoff stage because it's easy to visualize a new student's expertise like a rocket ship soaring into the sky into places it has never been before. During this time, a student will learn how to:

Configure a development machine
Learn a programming language
Work with various frameworks
Build functional applications

This stage usually lasts for the first 250-300 hours that a developer is learning how to code. This estimate is based on what I've seen with the DevCamp bootcamp students and equals around 6-8 weeks of intensive learning.

As fun as this stage is, it has drawbacks. One of the key problems is that it can give students false confidence. When they see themselves building applications that actually work, it's natural to believe that they can dive right into building production apps for clients. However, they don't realize that they're about to enter… the twilight zone of learning how to code.

The twilight zone

After the exciting liftoff stage of the developer learning curve, aspiring developers will enter the twilight zone:

This is a challenging time for students and many students decide to quit programming entirely during this stage.

So why is this time so challenging? After seeing countless students go through it, I've discovered that there are a number of contributing factors:

While in this stage, many of the core concepts and commands haven't cemented themselves in a student's long-term memory. This results in them having to constantly look up documentation, query Stack Overflow, and things like that.
During this time, the novelty of simply having an application work has worn off. Now students are asked to perform advanced tasks such as:
- Working with legacy applications
- Debugging defects
- Improving performance
- Building features that they don't have a step-by-step tutorial for
Additionally, while working through the twilight zone, students are expected to start implementing best practices. In the launch stage, the primary goal was to get applications functional.

During this next phase, students start learning how to build applications that can be used in real-world scenarios. This means that a student may spend five times longer to build an application with the identical feature of something they created during the launch stage.

This can be frustrating; however, the increased time spent implementing best practices allow the applications to be scalable and flexible enough to be used in production. This is in stark contrast to the apps created during the launch phase that don't adhere to industry standards.

The zone

There is good news though; if a student persists through the twilight zone of learning they will enter The Zone of the developer learning curve:

This zone is entered usually after around 1,000 hours of study and work. During this stage, developers have a wide range of features they can build without having to look up the documentation.

In this stage, when you visit Stack Overflow you'll be answering as many questions as you ask. And thankfully, learning new concepts will come easier. The reason why learning is easier at this stage is because you will have developed a mental model of development.

For example, I recently started working with the Scala programming language. I've been able to pick up on how to build applications in Scala dramatically faster than when I started learning C or PHP a decade ago. This is because I have a decade of knowledge in the development space that allows me to frame the new concepts. When I read the documentation and see what it says about data types, I don't have to wonder what a data type is. Instead I can skip ahead to learning the syntax.

As you'll notice in the developer learning curve, the growth pattern in this phase is less than the other two stages. As you've heard me say countless times, learning never ends for developers. However, learning does change. During this phase, a developer focuses on learning topics such as:

Incremental performance improvements
Building helper code libraries
Refining how application code flows

A unique journey

Throughout this chapter you may have noticed that the developer learning curve was smooth. However, that's not reality. The reason why the curve was smooth was because it averaged out the learning path of a large number of individuals. When it comes to a single student, the learning curve looks more like the following graph:

There are ups and downs throughout the learning cycle. As a student, you may decide to switch programming languages after a few years (like I did when I switched from PHP to Ruby around 5 years ago).

Even though you don't have to start back from scratch, it will still take time to learn a new language or framework. And throughout your development journey you'll discover plenty of ups and downs. So, don't get discouraged if you aren't satisfied with your skill level, because I have a secret to tell you: good developers never feel like they've arrived and are done learning.

Summary

I hope that this has been a helpful guide to understanding the developer learning curve, and good luck with the coding.

Chapter 13. Slowing Down to Learn How to Code Faster

Nowadays, it seems like everyone wants to do things faster. We want to pay without taking out a credit card or cash. Social media lets us share images and videos from our lives in a split second. And we get frustrated if Netflix takes more than 3 seconds to start streaming our latest TV show series binge. However, if you want to learn how to code faster, I'm going to present an odd idea: go slower.

This may seem like a counterintuitive concept. After all, don't coding bootcamps, even DevCamp where I teach, tell you how you can learn how to code in a few months? Well yes, and research shows that 8 weeks is a powerful number when it comes to learning. The Navy Seal training program specifically chose 8 weeks as its timeframe for conditioning candidates. And if you search the web for the phrase 8 Week Training programs, you'll find courses ranging from running 10ks to speaking Spanish fluently.

So yes, I'm huge believer that individuals can learn an incredible amount of information in a short period of time. But what I'm talking about here is becoming more deliberate when it comes to learning new information.

Learn how to code faster

If you're like me, when you learn a new topic the first thing you'll do is either move onto the next topic or repeat the concept as quickly as humanly possible. For example, when I learn a new Ruby or Scala programming method I'll usually jump right into using it in as many different situations as possible. However, I've discovered that this may not be the best approach because it's very short-sighted.

Our default mind

When it comes to learning how to code, one of the most challenging requirements is moving knowledge from our short-term memory to our long-term memory.

Remember the last time you learned a programming technique. Do you remember how easy it felt when you repeated what the instructor taught? The syntax seemed straightforward and it probably seemed like there was no way you would forget how to implement the feature. But after a few days, if you try to rebuild the component, is it easy or hard?

If you're like me, the concept that seemed incredibly easy only a few days ago now causes you to draw a blank. But don't worry. This doesn't mean that we're incompetent. Instead, it means that this piece of knowledge wasn't given the chance to move from our short-term to our long-term memory.

Hacking the mind

So, if our default mindset is to forget what we've learned after a few days (or a few minutes), how can we learn anything? This is where our brain's default programming comes into play and where we can hack the way that we learn.

I'm currently teaching myself the TypeScript programming language. TypeScript is the language that is recommended for Angular 2 development, so I thought it would be a good next language to learn. However, instead of taking my default approach, which is to slam through training guides and tutorials, I'm taking a more methodical approach.

Slowing it down

Through my learning path, I'm going through a number of books and video series. And as I follow along with the guides, as soon as I learn a new topic I completely stop. I'll stand up. Write the new component on one of my whiteboards. And actually, write the program out by hand.

After that, I type the program out on the keyboard… very slowly. So slowly that I know I could go around 4-5x faster. But by taking this approach I'm forcing my mind to think about the new concept instead of rushing through it. When it comes to working with our long-term memory, this approach is more effective than simply flying through a concept because it forces our minds to think through each keystroke.

Bend it like Beethoven

I didn't learn this technique from another developer. Instead, I heard about how one of the most successful classical music institutions in the world, the Meadowmount School of Music in New York, taught students new music compositions. As a game, the school gives out portions of the sheet music. So, where most schools will give each student the full song, Meadowmount splits the music up into pieces.

From there, it hands each student a single piece for them to focus on. From that point, the student will only learn to place that single piece of music. They will start out very slowly. They won't rush through notes because they don't even know how they fit into the song. This approach teaches them how to concentrate on learning a new song one note at a time.

From that point, the students trade note cards and then focus on learning another piece of the song. They continue with trading cards until each student has been able to work through the entire set of cards.

By forcing the students to break a song into pieces they no longer will have any weak points in a song. Instead, the students will have focused on the notes themselves. From this point, it's trivial for all the students in the class to combine their knowledge and learn how to play the song all the way through.

From classical music to coding

So, can this approach help you learn how to code faster? I think so. The research shows that by slowing down and breaking concepts into small pieces, it's easier for students to transfer information from the short-term to long-term memory.

A practical system

So, the next time you are learning a coding concept, take a step back. Instead of simply copying what the instructor is teaching, write it down on a piece of paper. Walk through exactly what is happening in a program.

If you take this approach, you will discover that you're not longer simply following a teacher's set of steps, but that you'll actually learn how the concepts work. And if you get to the stage of understanding, you will be ready to transfer that knowledge to your long-term memory and remember it for good.

Chapter 14. Mental Models for Learning How to Code and Improve as a Developer

I've talked quite a bit about what it takes to become a great developer. To achieve a level of mastery, I've discussed a number of criteria and in this chapter, I want to add a new pre-requisite to the list.

Let me begin by asking you a question. If I showed you some code, would you be able to tell me in a few seconds if it's good or not? The world of software development is incredibly complex. However, I've discovered over the years that the best developers have the uncanny ability to instantly judge the quality of someone's code.

I spoke to you in Chapter 2, Are Developers Born or Made? – Debunking the Myth of Prodigies about the notion that prodigies and savants are a myth. But if this is the case, how can expert developers analyze programs so quickly? To answer this question, we need to go back to Fake Ancient Greece.

Mental models for the Kouros

I said Fake Ancient Greece because my favorite illustration of mental models was discovered alongside one of the greatest forgeries in modern art history.

In Malcolm Gladwell's book Blink, he tells the story of the Greek Kouros. In 1985, the Getty Museum purchased a Greek statue called the Kouros for over $9 million dollars. Initially, the museum was hesitant to purchase the statue because there was a significant fear that sculpture was a fake. Kouros pieces were so incredibly rare, the chances that a legitimate and well cared for piece had been discovered were slim to none.

However, the museum was willing to take the risk and embarked on a fact-finding mission. They put the statue through every scientific test available at the time. And the Kouros passed with flying colors. After going through the full examination, the museum purchased the Kouros for $9 million dollars.

Art historians from all over the world were flown in for the unveiling of the Kouros. But something went terribly wrong. The moment that these specialists saw the statue they knew the Kouros was a fake. Interestingly enough they couldn't give any actual reason.

They simply knew that something was not quite right. Their suspicions turned out to be correct and the Kouros ended up being proved to be a hoax. But how were these individuals able to do what countless scientific studies could not? It all comes down to mental models.

What are mental models?

In preparation for this chapter, I was discussing the topic of mental models with a friend and was surprised when she looked at me, confused. After informing me that she'd never heard of mental models, I decided to add this section to explain what mental models are. And after that we'll get into how we can build them to learn development.

A mental model is a mental representation of a specific topic or skill. You can't create a mental model overnight or with cram sessions. Mental models are developed through years of repetition and countless hours of honing a craft.

My Dad is a major league hitting coach for the Houston Astros. Throughout my life I've been able to watch him instruct hitters on how they can improve their swings.

And I'll never stop being amazed by the fact that he can watch a new hitter's swing and within a split second pick out multiple ways that the player can improve. I can tell you that he did not develop this skill in a short period of time. He has spent more time watching hitters and film than anyone I know. And over the years he has developed a mental model of what the perfect swing looks like.

Mental models for developers

OK, so we've talked about art historians and baseball coaches, but how can we create mental models as developers? You may or may not like the answer, but it doesn't really matter because it's the truth. Mental models are made through repetition.

However, repetition by itself isn't enough. For example, if you built an identical program every day for 10 years you would get really, really good at building that one application. However, you wouldn't improve as a developer. I've talked before how medical research shows that doctors who have spent years practicing on the same types of patient are less proficient than doctors fresh out of residency. In the same way, as developers we improve when we're stretching ourselves each day.

You can stretch yourself by doing things such as:

Learning a new programming language or framework
Teaching others how to learn programming
Creating an open source code library and allowing other developers to use it

Einstein said it best when he said:

"The only source of knowledge is experience."

Summary

If you dedicate enough time each day improving yourself as a developer, you will be able to truthfully answer yes to the question I posed at the start of this chapter. You will be able to have the ability to look at a piece of code and instantly know if it's good or bad. And you'll know that it's not some type of coding super power; instead, it's a skill that you earned through your constant pursuit of improving as a developer.

Chapter 15. A Developer's Guide for Hacking Procrastination to Achieve Success

There you are. Sitting in front of your computer. Staring at a blank screen. You know you have to work on a code project, but it feels like you're frozen. The task before you is so intimidating that you don't even know where you begin. It feels as if you'd rather be doing anything else in the world besides that task that's staring you in the face.

This scenario is the ugly and all-too-common face of procrastination that programmers are forced to fight constantly. If this situation sounds familiar, you're in good company. But if you want to become a professional developer, you'll need to implement a system for hacking procrastination. And that's what we're going to walk through in this chapter.

As the lead instructor for DevCamp I get asked questions from students from around the world. However, one of the most prevalent inquiries I get from aspiring coders is how to overcome procrastination.

Root causes of procrastination

Before we walk through a system for hacking procrastination, we first need to dive into the root causes for this negative habit. Everyone is unique, but over the years I've seen procrastination is typically caused by three thought patterns:

Perfectionism
Fear of success
Lack of planning

To overcome procrastination and get back on track we'll need to address each one of these issues. Because if you let any of these mindsets control the way your mind operates, you will never be able to reach your potential.

Hacking procrastination

I called this chapter hacking procrastination because I think that hacking is the most appropriate term for what needs to happen to achieve success. Developers hack applications to build features or fix bugs. In the same way, we need to hack our thought patterns so that our brains function properly.

Before we go through the system I want to make one concept clear. As humans, we were made for action. Procrastination is a negative habit that we've learned through fear-driven thought patterns. To be successful at anything in life, whether it's development or business, overcoming procrastination is a requirement.

Hacking perfectionism

Starting off the list of the causes for procrastination is perfectionism. Have you ever watched a baby trying to stand up for the first time? Babies, who haven't learned that failure is a bad thing, will spend countless hours trying to stand up.

Each time they fall down it doesn't seem to faze them in the slightest. But you won't find a baby that lets perfectionism get in the way of achieving their goal. Instead, they will keep trying until they can stand up and eventually walk by themselves.

However, somewhere between the time that we're babies and adults we develop the thought pattern that we're not supposed to fail. So instead of trying and failing until we succeed, we simply try to only perform tasks that we know we can do properly. To hack perfectionism, we have to remove the component in our brain that is afraid of failing.

If you are a developer learning how to build a new feature that you've never worked through before? Let me clear something up. You are going to do it wrong the first time!

And that's 100% fine. If you think that by waiting you are magically going to learn how to perform the task perfectly, you are sadly mistaken. So, step one is: embrace failure and remove the requirement of perfectionism.

Hacking the fear of success

Next on the list is hacking the fear of success. If you're overcome the trap of perfectionism, congratulations. However, I've seen just as many developers get stuck due to the fear of success as the fear of failure.

This concept may seem odd since success doesn't seem like something that you should be scared of. However, I remember when I was first learning development. When I was walking through a coding book I would get so excited when I discovered a new concept. However, then I would freeze. My mind's first response was:

"If you learn this, then what are you going to do?"

For example, when I first learned how to build a connection to a database, I put the book down and didn't pick it up until weeks later. By learning the database concept, it opened up a new and scary new world of all of the new topics I had to learn after that. All of a sudden, I had to understand:

SQL queries
How to build relationships between database tables
SQL injection requirements
And the list seemingly went on infinitely in my mind

To hack the fear of success, we need to quieten our minds. The fear of success is really rooted in the fear of the unknown. So, whenever you're feeling this fear, simply take a step back. Be happy that you have learned a new topic. And then move onto the next feature or topic.

Don't let your mind run wild with all of the potential, unknown concepts that you'll need to learn in the future. Like learning anything else, you need to take it one step at a time.

Hacking the plan

Last on the list for hacking procrastination is creating a practical plan. When I recognize that I'm procrastinating I now tell myself to look at my plan of attack. Usually I'll discover that my plan is too general.

For example, if I'm building a payroll application, I may have an item on my to-do list that says: Build reporting engine. That's a scary feature! That's the type of item that will stick on my to-do list for weeks without me taking any action.

To fix this, I've learned that if I break the requirement into a series of very small tasks I can break the cycle of procrastination. For the reporting engine feature I can create a series of much smaller, more manageable tasks, such as:

Create a page for users to access reports
Implement a database query for pulling the reports from the database
Build a file downloader for reports

When I break a large and scary feature down into small pieces, I instantly feel better. The feature is no longer scary and I no longer feel like putting it off until tomorrow. Instead, I am able to simply follow a set of small tasks each day until the feature is complete.

Hacking perfectionism

Starting off the list of the causes for procrastination is perfectionism. Have you ever watched a baby trying to stand up for the first time? Babies, who haven't learned that failure is a bad thing, will spend countless hours trying to stand up.

Each time they fall down it doesn't seem to faze them in the slightest. But you won't find a baby that lets perfectionism get in the way of achieving their goal. Instead, they will keep trying until they can stand up and eventually walk by themselves.

However, somewhere between the time that we're babies and adults we develop the thought pattern that we're not supposed to fail. So instead of trying and failing until we succeed, we simply try to only perform tasks that we know we can do properly. To hack perfectionism, we have to remove the component in our brain that is afraid of failing.

If you are a developer learning how to build a new feature that you've never worked through before? Let me clear something up. You are going to do it wrong the first time!

And that's 100% fine. If you think that by waiting you are magically going to learn how to perform the task perfectly, you are sadly mistaken. So, step one is: embrace failure and remove the requirement of perfectionism.

Hacking the fear of success

Next on the list is hacking the fear of success. If you're overcome the trap of perfectionism, congratulations. However, I've seen just as many developers get stuck due to the fear of success as the fear of failure.

This concept may seem odd since success doesn't seem like something that you should be scared of. However, I remember when I was first learning development. When I was walking through a coding book I would get so excited when I discovered a new concept. However, then I would freeze. My mind's first response was:

"If you learn this, then what are you going to do?"

For example, when I first learned how to build a connection to a database, I put the book down and didn't pick it up until weeks later. By learning the database concept, it opened up a new and scary new world of all of the new topics I had to learn after that. All of a sudden, I had to understand:

SQL queries
How to build relationships between database tables
SQL injection requirements
And the list seemingly went on infinitely in my mind

To hack the fear of success, we need to quieten our minds. The fear of success is really rooted in the fear of the unknown. So, whenever you're feeling this fear, simply take a step back. Be happy that you have learned a new topic. And then move onto the next feature or topic.

Don't let your mind run wild with all of the potential, unknown concepts that you'll need to learn in the future. Like learning anything else, you need to take it one step at a time.

Hacking the plan

Last on the list for hacking procrastination is creating a practical plan. When I recognize that I'm procrastinating I now tell myself to look at my plan of attack. Usually I'll discover that my plan is too general.

For example, if I'm building a payroll application, I may have an item on my to-do list that says: Build reporting engine. That's a scary feature! That's the type of item that will stick on my to-do list for weeks without me taking any action.

To fix this, I've learned that if I break the requirement into a series of very small tasks I can break the cycle of procrastination. For the reporting engine feature I can create a series of much smaller, more manageable tasks, such as:

Create a page for users to access reports
Implement a database query for pulling the reports from the database
Build a file downloader for reports

When I break a large and scary feature down into small pieces, I instantly feel better. The feature is no longer scary and I no longer feel like putting it off until tomorrow. Instead, I am able to simply follow a set of small tasks each day until the feature is complete.

Hacking the fear of success

Next on the list is hacking the fear of success. If you're overcome the trap of perfectionism, congratulations. However, I've seen just as many developers get stuck due to the fear of success as the fear of failure.

This concept may seem odd since success doesn't seem like something that you should be scared of. However, I remember when I was first learning development. When I was walking through a coding book I would get so excited when I discovered a new concept. However, then I would freeze. My mind's first response was:

"If you learn this, then what are you going to do?"

For example, when I first learned how to build a connection to a database, I put the book down and didn't pick it up until weeks later. By learning the database concept, it opened up a new and scary new world of all of the new topics I had to learn after that. All of a sudden, I had to understand:

SQL queries
How to build relationships between database tables
SQL injection requirements
And the list seemingly went on infinitely in my mind

To hack the fear of success, we need to quieten our minds. The fear of success is really rooted in the fear of the unknown. So, whenever you're feeling this fear, simply take a step back. Be happy that you have learned a new topic. And then move onto the next feature or topic.

Don't let your mind run wild with all of the potential, unknown concepts that you'll need to learn in the future. Like learning anything else, you need to take it one step at a time.

Hacking the plan

Last on the list for hacking procrastination is creating a practical plan. When I recognize that I'm procrastinating I now tell myself to look at my plan of attack. Usually I'll discover that my plan is too general.

For example, if I'm building a payroll application, I may have an item on my to-do list that says: Build reporting engine. That's a scary feature! That's the type of item that will stick on my to-do list for weeks without me taking any action.

To fix this, I've learned that if I break the requirement into a series of very small tasks I can break the cycle of procrastination. For the reporting engine feature I can create a series of much smaller, more manageable tasks, such as:

Create a page for users to access reports
Implement a database query for pulling the reports from the database
Build a file downloader for reports

When I break a large and scary feature down into small pieces, I instantly feel better. The feature is no longer scary and I no longer feel like putting it off until tomorrow. Instead, I am able to simply follow a set of small tasks each day until the feature is complete.

Hacking the plan

Last on the list for hacking procrastination is creating a practical plan. When I recognize that I'm procrastinating I now tell myself to look at my plan of attack. Usually I'll discover that my plan is too general.

For example, if I'm building a payroll application, I may have an item on my to-do list that says: Build reporting engine. That's a scary feature! That's the type of item that will stick on my to-do list for weeks without me taking any action.

To fix this, I've learned that if I break the requirement into a series of very small tasks I can break the cycle of procrastination. For the reporting engine feature I can create a series of much smaller, more manageable tasks, such as:

Create a page for users to access reports
Implement a database query for pulling the reports from the database
Build a file downloader for reports

When I break a large and scary feature down into small pieces, I instantly feel better. The feature is no longer scary and I no longer feel like putting it off until tomorrow. Instead, I am able to simply follow a set of small tasks each day until the feature is complete.

Summary

I hope that this has been a helpful guide for helping you break the cycle of procrastination in your own projects and that you will be able to use it to become a more effective developer. I'll leave you with a quote from the book The Five Elements of Effective Thinking by Edward B. Burger and Michael Starbird:

"Being willing to fail is a liberating attribute of transformative thinking."

So, put yourself out there, create a practical plan, and stop procrastinating and start coding!

Chapter 16. The Problem with Procrastination for Developers

Libraries could be filled to overflowing with books filled on procrastination. Through my life and career, I have gone through self-help books that attempt to explain why people procrastinate along with supplying strategies to help curb procrastination.

And as great as all those books are, no one has been able to describe the true problem with procrastination better in my mind than Steven Pressfield in his book The War of Art.

The problem with procrastination

In The War of Art, Pressfield compares procrastination with being an alcoholic. If you're like me, when I first heard this comparison I was skeptical. I had a hard time connecting myself pushing off writing a blog post until tomorrow with an alcoholic passed out on the sidewalk in front of a bar.

However, I chose to continue reading. Pressfield gave procrastination a name, calling it the resistance. And that was something I could relate to. Whenever I come across a challenging task, it's as if there is a constant voice in my head saying:

"Wouldn't this feel great to push to tomorrow?
You'll be excited to do it tomorrow."

And when I give into the voice, it's as if I took a shot of happy pills. I instantly feels as through a weight has been lifted off my shoulders and I feel happy. However, when tomorrow rolls around I've discovered something… the voice comes right back and it's still encouraging me to push the task off again.

Instant gratification

After going through this cycle of procrastination for years I finally did recognize the pattern. And Pressfield was right, procrastinating on tasks has the same root cause as being an alcoholic. Alcoholics are willing to trade long-term joy for short-term happiness. By this I mean that an alcoholic will risk their health, career, and family, all for the sake of the feeling that a drink will give them at that moment.

This pattern is played out in the mind of all of us when we procrastinate. When we continually put off tasks for tomorrow, we are trading long-term success for short-term convenience.

Baby steps to knock out procrastination

I've already presented my system for hacking procrastination. However, I don't want to describe a problem without giving a solution. Therefore, I will conclude by saying that the best way I've discovered to fight procrastination is by taking baby steps.

In his book Mini Habits, Stephen Guise made the concept of performing one push up a day famous. Guise was a self-proclaimed procrastinator who despised going to the gym or working out. However, one day he decided he was going to create the mini goal for himself to perform a single push up every single day. By following this approach, he realized that the idea of working out was no longer a scary concept. And therefore wasn't something to procrastinate.

Of course, doing one push up a day would have limited health benefits. But what Guise discovered was that after performing the push up he was usually in the mood for doing more pushups. And eventually, his daily habit morphed into a full daily fitness regime.

Baby coding steps

I've discovered the same approach works with learning and development. When there is a task that I feel like pushing off, I tell myself that I only have to work on it for thirty minutes.

By giving myself a doable goal, the task is far less intimidating and therefore, I don't feel the same resistance and desire to push it off. And typically, I'll discover that I want to work longer than 30 minutes on the task. The end result being that I get much more done and I no longer fear my daily to-do list.

Chapter 17. Practical Ways to Use the Pomodoro Technique as a Developer

As we continue to work through ways to hack the developer's mind, the focus of this chapter is going to be on increasing productivity. Specifically, we're going to analyze practical ways to use the Pomodoro Technique.

I'm constantly researching new ways to improve my personal productivity. And through my journey as a developer, a popular approach that I've discovered is the Pomodoro Technique. This is a process that I've utilized and I credit it with allowing me to focus on a large number of tasks each day.

Don't let the weird name scare you away. The Pomodoro Technique is a dead simple productivity system that focuses on splitting tasks into timed intervals throughout the day.

Practical ways to use the Pomodoro Technique

One of the greatest strengths of the Pomodoro Technique is how easy it is to implement. The process that I follow is:

Each morning I pick out the tasks that I want to accomplish that day.
I then decide how long each task will take. The Pomodoro Technique works on point system. Each time you work through a 25-minute task you earn a point.
Typically, I try to earn 10 Pomodoro points each day. This means that if I have 3 tasks that I know will take an hour each, I will earn 6 points for those tasks. And it means that I have 4 additional 25-minute slots available for the rest of the day.

Taking a break

Did you notice how I kept saying 25-minute time slots? There is a reason for the odd number. The Pomodoro Technique places a high priority on taking scheduled breaks. After completing each 25-minute task, you take a 5-minute break. During this free time, you can do anything you want. You can get on social media, you can take a walk around the block, or anything that you want to do. Just make sure that your break does not exceed 5 minutes.

Also, after you've completed 4 tasks it's recommended that you take a 15-minute break. However, you can tailor your breaks and intervals to what works best with your schedule. By planning breaks throughout the day, you will decrease your chances of burn out. And I've noticed that I no longer feel bad about doing things such as checking my Instagram account or Hacker News throughout the day, because I can fit my guilty pleasures into my scheduled free time.

This is one of the aspects that I truly love about the Pomodoro Technique. Many of the other productivity systems I've tried in the past tend to lead individuals towards burning out. However, the Pomodoro approach allows you to have a sense of balance.

Lifestyle versus fads

Have you ever tried dieting before? When I was younger I struggled with my weight and to help fix it, I tried a number of intense diets. This included nutrition strategies such as dramatically decreasing calories, or killing off carbs. However, I noticed that I'd stay true to the diet for a few weeks or even a few months, but eventually I would fall back into poor eating habits.

Once I recognized this trend I moved to having a balanced approach to eating. I stopped trying nutritional fads and I transitioned my focus into eating in a way I felt I could eat for the rest of my life.

I made this change in my nutritional approach a few years ago and it's completely stopped my roller coaster dieting and weight loss and weight gain.

A lifestyle of productivity

In the same way when I was younger I fell into the same pattern with working on tasks. I'd get excited about working on a project or learning a new programming language. And I would spend countless hours working on what I wanted to accomplish.

However, this approach inevitably led to burning out and large stretches of time where I didn't want to work at all. I look at the Pomodoro Technique in the same way that I look at having a balanced diet. By limiting the number of tasks that I work on each day and by implementing planned breaks between each task, I no longer burn myself out.

Additionally, after I have finished my work for the day and have earned my 10 Pomodoro points, I feel a sense of accomplishment that I never felt before. And after work, I don't feel guilty spending time with my family and friends, because I know that I completed every task that I set out to work on that day.

Practical implementation

So how can you implement the program? There are a few ways. To start off, you can simply use the timer on your phone and then count up each of the tasks/points that you achieved each day. That's how I started off working with the Pomodoro Technique.

Additionally, there are a number of smartphone apps that have Pomodoro timers and even allow for creating a task list that you can use as a pick list for your tasks each day. I like these types of apps because they also give you historical analytics so you can see how many tasks you've completed each day. The Pomodoro focus app (https://itunes.apple.com/us/app/pomodoro-time-focus-timer/id973134470?mt=12) is my personal favorite (and it's free).

Chapter 18. The Power of Making Mistakes – Learning by Failing

Let's take a step back in time back to my first semester of Computer Science grad school. Stepping into my first class I was filled with nervous excitement. The class was taught by Dr. Gelfond, one of the most respected individuals in the artificial intelligence sector.

As class progressed I witnessed a disturbing trend. Instead of simply lecturing us like our other professors, Dr. Gelfond constantly called students up front to write programs on the chalkboard or to describe a concept he discussed. This wouldn't be a big deal, except that he made a habit of calling us up front specifically when it was clear that we did not understand the concept. Was he cruel? Did he want to make us look ignorant in front of the entire class?

The secret weapon to mastery – making mistakes

Actually, the opposite was true. Instead, Dr. Gelfond cared enough about us that he imparted to us the secret weapon to mastery: making mistakes. Wait, making mistakes is the opposite of what our mind tells us to do, right? Making mistakes is embarrassing. Mistakes tell the world that we don't understand a concept. However, making mistakes also provides a number of powerful tools that anyone interested in learning should be aware of.

Making mistakes – memory steroids

First and foremost, when you make mistakes, especially publicly, you're going to feel like you're taking memory steroids. How so? When I think back to Dr. Gelfond's class I still remember every mistake I made when I was called in front of the class. The memories generated by making mistakes are so vivid that they can be recalled, even years later like mine. Now obviously simply remembering the mistakes by themselves would be pointless.

However, in addition to remembering what I did wrong, more importantly I remember what I had to do to correct my mistake. It's been over three years since I took that class, but I can still remember each of the key concepts that he taught us. And I can tell you from experience that I cannot say the same thing about all of the classes I've taken.

Mistakes force learning

Another benefit to making mistakes is that they force you to learn. No one likes being wrong. So, assuming that you have a passion for knowledge, you can use the memory of making mistakes to help motivate you to learn a concept properly.

If Dr. Gelfond would have simply stood in front of the class and lectured for the entire semester, I most likely would have studied enough to do well on the tests and leave it at that. However, because I constantly had the thought in the back of my mind that I may have to be called up in front of the class to write a program or describe a concept, it forced me to study harder than I would have for a test. This healthy fear took me from simply being able to remember a concept to truly mastering it.

Mistakes kill pride

Lastly, making mistakes helps to kill pride. Proverbs 16:18 says:

"Pride goes before destruction, a haughty spirit before a fall."

One of the largest obstacles to learning is pride. Anyone puffed up with pride will find that their learning progress will come to a halt. When someone is filled with pride they can't see beyond their own limited knowledge. Thankfully, if you embrace the process of learning by making mistakes, pride will never be able to stake a claim in you. By their very nature mistakes force you to realize that you don't know everything, and that you have more to learn… which we all do.

Summary

So, whether you are just learning to code from scratch or if you're a seasoned developer, never be afraid to make mistakes. Mistakes reveal that you're traversing into new territory that you've never been before, which is what you need to do to go from mediocrity to mastery.

Chapter 19. Learn How to Code – The Guide to Memorization

During a recent bootcamp teaching session where I was walking through a number of frontend development techniques, a student asked a great question. Referencing the CSS styles, she asked:

"What is the best way to remember all of the specific style names and properties?"

This is a vital question to answer, especially for new students. For example, if you look at the CSS documentation you'll find thousands of potential style options. If you're learning these styles for the first time that list can be pretty intimidating. And that doesn't even bring in the idea of learning how the styles work together with applications as a whole!

Obviously, this issue does not only apply to CSS styles. When it comes to learning development, whether it's a programming language or framework, you will be greeted with a large amount of information that you'll need to memorize, or at least know where to reference it.

The guide to memorization

At first glance, this may seem like a daunting task. And many aspiring developers have given up on their learning journey because it seems like an insurmountable challenge.

However, I'm here to tell you that it's completely realistic for you to learn how to work with a large number of complex concepts. And if you follow the system I outline in this chapter, you'll be amazed at how quickly you pick up on memorizing more information than you ever thought possible.

Repetition

Before I go into the memorization system I have used over the years, it's important to say that repetition is the key to memorizing large amounts of information. None of the techniques I will give you are going to help if you don't take the time to work through them consistently.

Smarter, not harder

With that being said, it's important to know that, by itself, repetition is a slow and naive memory training technique. As a development student, imagine that I had a list of a few hundred method names and tell you to memorize them. If you were to simply stare at the sheet of paper and try to memorize the names, how do you think you'd do? If you're like me and the majority of the world, probably not very well.

The reason why dry repetition isn't a great way to memorize names is because it doesn't give you a frame of reference for the names.

Visual mental mapping

In the first memory technique, we're going to walk through visual mental mapping. Our minds are incredible at memorization. However, at the same time, our minds are also picky with how they store information. Let's run a quick test. If I show you 15 random digits, such as:

234
348532
984
234523
34534
35234
234
25345
234
985
553
37434
740
423
9812

And I give you 5 seconds to look at each number. How many of the numbers will you repeat back to me? Unless your name is Dustin Hoffman, you probably won't be able to name very many!

However, what if I showed you the pictures of 15 celebrities? Now if I give you the same test as with the numbers, do you think you'd do a better job remembering the list of celebrities or the random numbers? Assuming you know who the celebrities are, you'd be able to repeat back a significantly larger number of celebrities than numbers.

The reason for this difference is because you have a frame of reference for the celebrities and in this exercise, you had a visual reference. By combining these two things your brain was fully prepared to recite back a larger number of items from the second list.

With this knowledge in mind we can apply the same principles for memorizing anything.

Short-term versus long-term memory

Because our brains are efficient machines they naturally sort information based on priority. You are most likely aware that you have short-term and long-term memory. This concept is the reason why you can instantly remember your second-grade teacher's name decades later, but may forget a new acquaintance's name 30 seconds after hearing it.

Typically, the brain doesn't log knowledge into our long-term memory bank unless it thinks we're going to need it in the future. This is kind of like how a computer works. If you add text to a document and save the file on the hard drive, that's like storing information in the mind's long-term memory.

However, if you run a calculation in the terminal the computer processes the information in memory and then discards it, which is like how our short-term memory system works.

Implementing visual mental mapping

So, when it comes to implementing the visual mental mapping technique, we're essentially tricking our brain into thinking that it needs to move a piece of information into long-term memory. In this process, we associate a visual image with the term that we want to memorize. A key prerequisite for this to work is that the visualization needs to be relevant to the term (or the behavior of the term).

Getting back to the developer's initial question. Let's see how we can use visual mental mapping to memorize a CSS style. I'm going to use the text-decoration property as a case study. In the world of CSS, the text-decoration element allows you to add or remove an underline style to a piece of text. With this in mind, I would create an image in my mind that would look something like this:

So, in this example I have an image filled with decorations. And on top of the image, I have some text that is underlined. And it's sitting on the decorated fireplace mantle. By creating this visual image, I've mapped:

Decoration to underlined text
A familiar image to something abstract

And with this mental image in place, I don't have to think about the term text-decoration, instead I will think of a decorated fireplace with underlined text sitting on the mantle. This visual is much easier for my brain to accept into long term memory because it has a direct frame of reference.

The text-decoration word is no longer a foreign element trying to invade my memory. Instead, it's catching a ride on an image that already has a home in my long-term memory.

Taking a real-world example

Sticking with our celebrity theme. Imagine that you wanted to go to a private, VIP party in Hollywood. If you just try to show up the bouncer at the door most likely won't let you in. However, if you're friends with Brad Pitt and you walk in together, you won't have any issues attending the party.

Visual mental mapping follows the same principle. Our brains guard our long-term memory to ensure that our mind doesn't get cluttered with useless information. For example, what if you logged every piece of information that you come across each day into your long-term memory?

As you drive down the street to work your brain captures millions of data points, such as street signs and people walking, etc. If your brain didn't guard against useless information entering your long-term memory bank, all of this information would be treated with the same priority as your parent's names. Obviously, this wouldn't be a good idea!

So, our brains are like the guard in the VIP Hollywood party. And when we attach a new piece of information to something already logged in long term memory, it's like we're having Brad Pitt escort us into the party.

Finding patterns

So visual mental mapping seems like a great idea. However, the idea of creating thousands of visualizations isn't very practical, which is why, when I'm learning a new programming language, I also focus on picking up on patterns.

Returning to our case study of memorizing CSS elements, let's take a look at the border attributes available in CSS3:

border
border-bottom
border-bottom-color
border-bottom-style
border-bottom-width
border-color
border-left
border-left-color
border-left-style
border-left-width
border-radius
border-right
border-right-color
border-right-style
border-right-width
border-style
border-top
border-top-color
border-top-style
border-top-width
border-width

As you can see, there are 21 available attributes. And that's just for managing border styles on a webpage! As you can imagine, it would be pretty intimidating to memorize this list, especially when you realize that it's only a very small percentage of the available CSS styles needed for development.

However, if you start to analyze the list you'll notice a number of trends. For example, there are a number of styles that simply reference: top, bottom, left, and right. These styles are simply ways for giving a border style to a specific side of an element.

Additionally, you may also notice that each side also has a set of options for color, style, and width. So practically, if you know that these elements are all available to the border set of elements, this list can be shrunk down to 5 items:

border
border-color
border-radius
border-style
border-width

This is more manageable.

Copy and paste is the enemy

In addition to creating visual mental maps and using patterns, I'm going to finish off the list of memorization techniques with the recommendation to not copy and paste new concepts that you're trying to learn.

I first heard this advice from Zed A. Shaw, the author of the Learn Hard programming book series. He instructs his readers to not even look at the book at the same time that they're implementing the code. He postulates that by forcing yourself to type in the code without referencing the documentation while typing, it forces the mind to actually think through each keystroke.

In my personal experience as a developer and with teaching, I've discovered a significant difference between the students that copied and pasted code or simply followed along with a tutorial, compared with the students that attempted (even unsuccessfully) to implement the code by themselves.

Not everything has to be memorized

On a final note, I want to dispel a common fallacy. As a developer, you don't have to memorize every class and method to build a project.

Even professional programmers constantly look up documentation on a regular basis. Instead of feeling like you have to memorize everything, focus on memorizing the terms that you use the most. This will make the memorization process more practical and natural.

Chapter 20. A System for Learning a New Programming Language

In this chapter, I'm going to discuss how to learn a new programming language. I'll walk you through the five steps that I use whenever I'm learning a new language or framework.

Over the years, I've been hired by organizations such as Learn.co and AppDev to write programming curriculums for:

Ruby on Rails
Ruby programming
Python
Java
Several JavaScript frameworks

The only language that I really build applications in is Ruby, which means that I've been forced to become proficient in a number of language that I really didn't have much experience working with, sometimes in a very short period of time. And over the years I've developed a system for learning a new language or framework, and that's what I'm going to walk through in this chapter.

When I'm learning a new programming language I follow these steps:

Watch a full tutorial series on the language. When I'm watching I don't try to follow along, I simply watch what the instructor does in the demos so I can get a high-level view of the language syntax and flow.
Create a hello world application. I'll incorporate a few basics, such as running a loop, creating and instantiating a class, and any other high-level concepts I remember from the tutorial.
Pick out a sorting algorithm and implement it in the language. It's fine if the sorting algorithm is a basic one such as selection or bubble sort. Sorting algorithms force you to use data structures, loops, variables, and functions. Combining each of these elements will give you a good handle on how the language works.
Go through an advanced tutorial on the language and this time follow along and build the programs with the instructor.
Go through coding interview questions for the language. Being able to confidently answer these questions will give you a good idea if you have a solid understanding of the language.

I've used these five steps for a number of languages and I can also tell you, once you've become proficient in a single language you'll find it's much easier to pick up new programming languages since most of them have quite a bit of shared processes, and all you'll need to do is learn the difference in syntax.

I hope these tips will help you learn a new programming language. Please feel free to write to me with any other methods that you've found helpful when learning, and good luck with the coding!

Chapter 21. Development Study Tips – Reverse Note-Taking

In this chapter, we're going to go back in time and walk through when I developed the system of reverse note-taking. A quick Google search will show that I have coined the term; however, I did not invent the process.

Back when I started computer science grad school at Texas Tech I was struggling with one of my classes. It had been about a decade since I had been in a classroom environment and I was having a difficult time paying attention to the 1.5-hour lectures.

The problem with traditional note-taking

During this time, I spent quite a bit of time meeting with Dr. Richard Watson. And during one of our meetings I brought up the issues I was having. His first question was based around how I was taking notes for the course.

I showed him my notes and he instantly told me that I was taking notes completely wrong. He pointed out multiple places in my notes where I had missed key concepts that were unifying elements. And without noting these items, I wouldn't understand the topics at all.

In reviewing the notes, I realized he was completely right. I spent my time writing down facts and what I thought were key terms. However, I regularly failed to articulate how everything worked together.

For example, for my notes on tree data structures I outlined each of the key elements of binary search trees and B-Trees. But I failed to describe the innate differences between the tree components from a behavior perspective.

This is similar to taking notes in a history class and writing down the names, dates, and locations for Napoleon's loss at the battle of Waterloo without describing the critical differences between his old armies with the one he lost with.

Reverse note-taking

Finding out that I was taking notes wrong was great. But it wouldn't have been too useful without learning an alternative approach. So, Dr. Watson asked me to try a different type of note-taking technique.

He said to put my pen and paper away during class. And instead of taking notes during class, he recommended that I simply listen to the lecture. He instructed that as soon as the lecture was over I should find a quiet place and then write down all the topics that I remembered from the discussion.

Initially, I was skeptical of this approach, mainly because I was afraid that the important concepts would go in one ear and out the other. He added that I should tape record the lecture so that I could use the recording as a safety net for the topics that I failed to remember.

Despite my negative perspective on the approach, I decided to give it a try. (Obviously, my natural note-taking approach wasn't effective, so I didn't have much to lose). I followed Dr. Watson's advice to the letter. And I was pleasantly surprised to discover that I remembered much more information using this reverse note-taking approach compared with simply trying to write down concepts during the lecture.

Benefits of reverse note-taking

I started following this reverse note-taking process years ago and I still use it today. Through this time, I've noticed a number of key benefits to this approach.

Narrowed focus

First and foremost, by having the knowledge that I will have to recite back the key components of the lecture forces me to have an increased level of focus. This is opposite to how I used to take notes. My old way of taking notes would many times distract me from the concepts being discussed. I would hear a concept that I felt was important and I would take my focus away from the speaker and focus on writing down the topic.

Many times, this would inadvertently result steal my focus away from another important concept, or a description of how the topic I was writing down worked at a high level.

Additionally, as a naturally competitive person I would make a game of how much I could remember from each lecture. If I could remember enough to write down two pages of notes on Monday, I would try to write down two and a half pages on Tuesday. By making a game of the practice it forced me to narrow my focus even more on the content.

Story-based mindset

Another benefit of reverse note-taking is that it forced me to think of the lecture as a unified story instead of a series of facts. Let's go back to our illustration of Napoleon's battle at Waterloo. If you listen to a lecture about the battle and take notes during the class, you'd probably do things like write down the following:

General names
Cities where battles took place
Dates

However, if you simply listen intently to the lecture and recite it back afterwards you won't repeat dates and locations. Instead you will naturally remember the battle in story form. You'll discuss the struggles that the Duke of Wellington had to overcome to lead the charge against the French army. And because it's a story, your retention of the topics will be considerably higher compared with attempting to memorize facts and figures.

If I were to ask you to remember a high school history class and a movie you saw in high school, would you have a better chance of remembering the plot of the movie or the history lecture?

So, getting back to my computer science grad school experience, by leveraging the reverse note-taking strategy I forced myself to think of the topics discussed during the lecture as a story as opposed to a bunch of theories and math equations.

Forced repetition

Lastly, the reverse note-taking approach made it easier to review the lecture material compared with my old style of note-taking. Before that I would rarely listen to a lecture recording. Even if I had the intention to listen to the recording, other priorities always seemed to override the task. I mainly attribute this failure to the fact that I, for some reason, trusted my notes.

However, when I started reverse note-taking I would always listen to the lecture a second time to fill in any items that I missed during my post note-writing session. I discovered this single benefit to be critical to my success since it became an automatic habit to reinforce my knowledge. In contrast to my old approach where I trusted my untrustworthy notes, with reverse note-taking I didn't trust my memory, so I knew I had to reinforce my memory. And the consequence was that I always would listen to a lecture twice, with the final result being a dramatic increase in retention.

Summary

This approach is not for everyone. I know students who excel with a more traditional note-taking strategy. However, if you find yourself in a situation like mine, I highly recommend you giving reverse note-taking a chance. You may be surprised how effective it can be.