Skill Up: A Software Developer's Guide to Life and Career

4 (3 reviews total)
By Jordan Hudgens
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. I. Coder Skills

About this book

This is an all-purpose toolkit for your programming career. It has been built by Jordan Hudgens over a lifetime of coding and teaching coding. It helps you identify the key questions and stumbling blocks that programmers encounter, and gives you the answers to them! It is a comprehensive guide containing more than 50 insights that you can use to improve your work, and to give advice in your career.

The book is split up into three topic areas: Coder Skills, Freelancer Skills, and Career Skills, each containing a wealth of practical advice. Coder Skills contains advice for people starting out, or those who are already working in a programming role but want to improve their skills. It includes such subjects as: how to study and understand complex topics, and getting past skill plateaus when learning new languages. Freelancer Skills contains advice for developers working as freelancers or with freelancers. It includes such subjects as: knowing when to fire a client, and tips for taking over legacy applications. Career Skills contains advice for building a successful career as a developer. It includes such subjects as: how to improve your programming techniques, and interview guides and developer salary negotiation strategies.

Publication date:
July 2017
Publisher
Packt
Pages
302
ISBN
9781787287037

   

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.

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:

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

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."

 

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.

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.

 

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:

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.

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 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 A smarter approach

So, instead
 

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.

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:

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.

 

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

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.

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 Additional negative effects

How is
 

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.

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:

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.

 

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.

  1. 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.
  2. 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.
  3. 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.

 

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:

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.

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.

 

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:

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.

 

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.

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

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.

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.

 

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

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.

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

Proper information/resources

When a
Best practices

During a
Challenging/new tasks

In my
Frustration = skill

One of
 

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

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:

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.

 

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.

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.

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.

 

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.

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.

 

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.

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.

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:

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:

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 perfectionism

Starting off

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:

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:

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 fear of success

Next on
Hacking the plan

Last on
 

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.

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:

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.

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.

 

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.

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

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.

 

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?

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.

 

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:

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.

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.

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.

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:

Implementing visual mental mapping

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:

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.

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:

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:

This is more manageable.

 

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:

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:

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!

 

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.

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.

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.

About the Author

  • Jordan Hudgens

    Jordan Hudgens is a full stack developer and the founder of DevCamp.com and the Bottega Code School. As a developer for over the past 15 years, he specializes in Ruby on Rails, React, Vue JS, and TypeScript with a focus on API development. He has built applications for a wide variety of organizations, including Eventbrite and Quip. He has published and maintains multiple open source NPM modules that help individuals automate the development process for JavaScript and TypeScript applications. Additionally, he has published over 30 courses, taught 42,000 students globally, and written several programming books.

    Browse publications by this author

Latest Reviews

(3 reviews total)
Not a genius book, but useful, interesting and easy to read
Chapters are too short (1 or 2 pages each). Tens of extra white pages, so the actual number of text pages is way smaller than the published number of pages. Great book though.
Easy to read Points made by the author are concise and make sense

Recommended For You

Book Title
Access this book, plus 7,500 other titles for FREE
Access now