This is Part 2 of a 5 part series:
Part 1
Part 3
Part 4
Part 5
Developing a Growth Mindset to Learn Software Engineering
Growth Mindset Overview
Let’s dig into the meat of this piece (or the potatoes, for you veggies out there!) The question is, why should you develop a growth mindset? And what does it have to do with becoming a software engineer?
I’m so glad you asked! It has everything to do with it. I don’t know if I have ever spent more than 2 hours programming in a given day without needing to Google something. I have to do it constantly. I am often stuck, or forget something, or I have a typo somewhere and miss it because I didn’t get enough sleep the night before.
I choose to not get down on myself for not knowing things. That’s because I have cultivated a growth mindset.
A growth mindset is the belief that you are not a fixed person. Your skills, abilities, and passions can develop over time. Many, and I mean MANY of us have a fixed belief when it comes to either technology or math. People often say, “I’m just not good at math, never have been.”
This is baloney. What this actually means is that you don’t like to struggle on math problems you don’t understand. Or using technology makes you feel stupid. Especially, when you don’t understand it easily. Guess what? Most of us don’t. This is learned behavior and not innate.
As a kid I enjoyed messing with the VCR to program things. The reward of a taped episode of the Simpsons during basketball practice made it worthwhile to me. I also failed to record things. I would come home and find a blank tape, or a tape that was still recording and had written over the show. Whoops!
Did I find this frustrating? Sure I did. But did I give up? Did I break the VCR in a fit of rage, chucking it out the window into our snowy back yard? No. Maybe I wanted to once or twice but in general, I didn’t care. I never mad at myself for this, I was upset at the choices by the machine’s designers.
I had fun trying to program it. I enjoyed seeing if it could work overnight, or what would happen with Daylight Savings Time. I cultivated a sense of play when it came to remote controls. This lead to me doing something similar with computers as I grew older.
What would have happened if my dad had yelled at me for failing to record a show? Or if he’d grounded me? Or punished me? I would not have enjoyed the process, rather I would have cared too much about getting it right and stopped finding joy in messing around.
This happens to lots of us in many different areas of life. We develop fear in an area and are no longer willing to play and fail. When it comes to coding, discarding this attitude is a must.
You have to enjoy failing and being wrong. Why? Because you have a different mental model than the random people who made your computer, wrote the languages and libraries you’re using. Do you know who designed the internet as a whole? What their motivations were? The constraints at that point in time? I certainly don’t.
Does that mean you’re wrong or bad? No! As a consequence, they had a different model of how things should work than you do. There’s a logical reason, based on your experience in the world, for you to believe your code will work. It just happens to be different than the people who originally created the technology.
This is okay. We all have this. Your goal is to attempt to understand why they made the decisions they did. It will build empathy instead of self-loathing. It will encourage you to have fun and play with code. And you’ll find that you can learn a lot faster this way.
This is the core idea behind developing a growth mindset. The correct answer is never important. The process you use to learn about and adapt to a misperception is the focus. In a nutshell, effort trumps talent!
Struggle Mode
One of the core models we teach students is known as the optimal area of struggle. You have a certain amount of knowledge in a given field. Imagine this is a circle. To increase your knowledge, you need to grow this circle by 10% to 25%.
When you make something in this larger circle you’ll be able to bridge the gap between your current understanding and your desired outcome. This is a fun struggle! The goal is to spend as much time as possible in this struggle zone. We’ll refer to it as the Green Zone going forward.
On the other hand, let’s say you attempt to make something that’s dramatically outside your current knowledge or comfort zone. What if I gave you 3 days to write a better algorithm than Google’s search. Yikes! You’d panic. Sweaty palms and anxiety ensue.
This is the Red Zone. You wouldn’t know where to begin. You’d likely find complete dead ends on your first few attempts and have no clue what to do next. The Red Zone is what we want to avoid when learning.
Time spent in the Red Zone without help can lead to burn out. It’s a big part of why people struggle to learn software engineering. There are a lot of topics and it’s difficult to find a roadmap — what happens when you’re completely stuck?
I want you to spend as much time in the Green Zone as you can. The important thing to remember is that it should be a struggle.
That means not only solving problems you are confident in your ability to solve. It means that with each project you should learn one or two new things. It means you should have to spend time Googling and asking for help on each project. This is more than okay, it’s good!
I’ll remind you about this again later but seek the Green Zone. Learn to be aware when you’re in the Red Zone. This doesn’t mean giving up when something is a challenge — instead, identify appropriate challenges for your current skill level.
How to Practice Software Engineering
This is the section where I suggest how you actually study. The common path is to either read a whole book or watch an entire tutorial, then try it yourself. Almost as common path is to follow along with the book or tutorial — writing the code you are told to write without fully understanding it.
Both of these are poor uses of your time. You only have so many hours! Use them wisely. Instead of using either of those two strategies, here’s a new one to try out:
Attempt to build something or complete a task, for at least 15–30 minutes.More if you end up on a roll. Feel free to look at the technical documentation, or use a reference or cheat sheet you find on Google. Both are fine. The goal is for you to start the task you want to learn until you get stuck.
Once you get stuck (having spent 20–30 minutes without progress) it’s time to get help. Find the section of the book or the part of the tutorial that explains what you’re stuck on.
You usually get stuck when your mental model of the technology is different than the people who created the tech. This is ok, your goal in reading or watching is to make a new mental model.
Remember — your goal is not to just type the things that someone else wants you to type. It is to understand why they want you to type those things. When you understand the why, you’ll be unstuck!
Sometimes you won’t find the answer in the book or videos. This is OK. Do not panic. There are two reasons that this can happen and they both have solutions:
- The resource is outdated and the technology has changed. This happens a lot. Check the dates and check the versions to see if they are similar — if not, look for a newer resource.
- The technology you are attempting to learn is built on multiple concepts that you don’t understand yet.
Imagine I ask you to make a complex pasta dish with noodles, shrimp, crab, veggies, and a white wine sauce. You don’t know how to make any of these on their own. Pulling each piece together will be hard and you’ll likely fail along the way. Even if you succeed, you won’t understand why you did certain actions. I would recommend you learn how to make shrimp first, or properly sauté vegetables, then advance to the whole dish.
Software development works the same way. If you are tackling something that’s too far outside where you are now there are two options: scale back to something easier, or get serious help from a mentor or friend who is further along. This is OK! I still ask for help all the time and I encourage you to as well. The person you go to for help might even have an idea of a better project for you.
Find a Mentor and Community
My last chunk of advice in this section is two-fold.
First, find someone you can go to when you get stuck. Often this is someone you know well who is already working in the industry, such as a friend or relative. They don’t have to be your daily resource for help, rather someone to talk to when you’re feeling low or need guidance on what to do next.
A large part of my goal in creating this guide is to provide a resource to help students get a sense of all the things to do (and what order to do them in).
Second, you should find at least one other person to learn with. This is important for a huge number of reasons. Coding all day on your own, or job hunting without anyone to talk to is hard. Humans are social creatures.
Additionally, it can be rewarding to learn from and teach to a peer. The best way to check that you understand something is to teach it to another person— this is hard.
It will also give you practice in technical communication, one of the critical job seeking skills. In a nutshell, this is your ability to talk about code and technology using correct language. This is a large factor in how others will determine your competency.
You should practice this skill every chance you get. Whenever you attempt to explain a technical concept and use words like “it”, “thing”, or “thingy”, this is a warning flag. Take a minute to learn the correct terms. When you speak with more experienced developers you will seem more competent.
Coding with others can be a blast too! My favorite times are still working on a project with friends.
Common Pitfalls (and how to avoid them)
- Coding alone too much. For the reasons I have given above, it is important to find others to code with. I suggest using meetup.org, asking friends or family, or looking for an online community. In person is the best option, but either way, it’s critical to find others to learn with.
- Take breaks! This is often overlooked, especially by beginners. Sleep and walks are when your brain actually does the learning. Your process should look like this. Struggle > Take a Walk Break to Relax > Struggle > Walk > Struggle > Sleep. This gives your brain time to switch between modes and time to heal.
- Your brain has two modes: focused and diffuse. You are in focused mode when reading or coding. You are in diffuse mode when in the shower or taking a walk —whenever you get that feeling of daydreaming. You need to switch between the two modes to solve problems. Sleep is where you take information from short-term memory and add it to long-term. It also gives your brain a chance to heal.
- Below I’m going to give you some resources to learn more about mindset and how to approach learning. These have the potential to help you grow exponentially — I can’t recommend them enough.
- Everyone gets impostor syndrome. This is that moment where you doubt yourself and think I can’t do this, why am I even here? At some point or other, you will probably question your ability. Even after making an app, you may look back and feel you just got lucky. This is OK. Acknowledge it, then move on.
- Don’t let the feeling change your actions — the goal is to realize that you’re feeling this way. Tell a friend or a loved one. Make sure to take a break and reward your awareness of this thought process. You’re not an impostor. Everyone can learn to do this — it just takes time and commitment.
Resources
After each section, I am going to list the resources I have mentioned or think are relevant.
I don’t want to overwhelm you — work through them as you can, they largely build off each other. If you feel you have mastered a concept in any given section, move on to the next resource. Be honest with yourself though. All of these high-level concepts are important to your job search. But you don’t need to work through every resource to learn them — it’s about active practice.
- Carol Dweck’s book, Mindset.
- Learning How To Learn course on Coursera. There’s a companion book if you want to dig deeper.
- Mark Manson’s book. I think this can help during the actual job search when you’re dealing with a lot of rejection.
That’s all for part 2. In the next section we’ll dig into the steps you should follow for learning fullstack JavaScript. It also covers all of the technical abilities you’ll need for that first job and how to study them.
Stay tuned! Check out Part 3 here.
Leave a Reply