If you’re feeling stuck in a coding rut, consider this: traditional schooling may not have adequately prepared you for the world of software development.
Below guest writer Ken Mazaika, the CTO and Co-founder at The Firehose Project, describes how schooling fails to prepare us for what it takes to become a developer. Because, unlike in school, failing and cheating are okay in the world of programming. So is never knowing it all, and instead focusing on big picture concepts rather than the intricacies.
Take it away, Ken!
Traditional schooling conditioned you to struggle at programming. It’s not fair to put the blame on your kind elementary, high school, and college teachers. They probably didn’t know. But pretty much everything that they taught you back then has made it difficult for you to learn to code today.
![red-school-blur-factory](jpg/red-school-blur-factory-1024x683.jpg)
Let’s talk about how school works.
Schools generally push you to learn various topics, then take an exam without the aid of the materials you used to learn the topic being tested. The test happens on a certain date and you need to learn the material before that date. Before the exam, your teacher will provide all the resources you need to learn everything on the test. Theoretically, if you learn the material perfectly, you should receive 100% on an exam. If you receive a failing grade on an exam, it’s generally because of a lack of effort or preparation.
It doesn’t matter at all if you learn the material after the date of the exam. If you failed the exam, then mastered the material a day after it happened, it wouldn’t make a difference in the world. You didn’t know the material when you needed to, so you’ll probably have a tough time passing the class.
The system works. Kind of. In the United States, most people learn to read, write and do simple math, like algebra. But there’s a big problem.
Compare the way you’re expected to learn in school with the way developers learn to program in the real world. You’ll find that the two methods are exact opposites.
There are a few reasons why.
School has taught us that failure is bad.
Let’s assume that failure is a bad thing and that preparation can prevent failure. In this case, you may think that adequate preparation can prevent mistakes, errors, and the things that are bad from happening. But with programming, the opposite is true.
Instead, failure is an opportunity.
You will see error messages while learning to code. And you will see error messages after you learn to code, too. You need to develop a single skill on your path to becoming a self-sufficient developer.
You need to be able to see an error message, read what it says, investigate your code, and resolve the problem. This involves acting rationally. However, for some people, seeing problems in code can make them feel emotional. It shouldn’t.
A computer’s job is to take a sequence of instructions and run them as instructed. Given a certain configuration of code files, the computer will produce a certain outcome. If your code has an error, it just means that the way your code was written at this specific moment in time causes the particular error. Nothing more.
Problems in your code do not mean you are a bad programmer.
For the most part, there’s no such thing as a bug-free app. That means errors in your code indicate that something isn’t configured properly. It doesn’t mean that you’re stupid. And it doesn’t mean that you’re bad at programming. It just means that the program you’ve written doesn’t do what you think it should. What most beginners don’t realize is that this is actually a good thing.
Each failure is an opportunity to learn.
If you think your code should be working, and it is not, it indicates that there’s a disconnect (likely a very small one) between what you think your code is doing and what it should be doing.
However, working with problems you already know and are comfortable solving doesn’t help you grow as a programmer.
That’s where the real learning happens in programming. There will be small disconnects between how you think the computer will interpret your code and how it actually does interpret your code. And that’s ok.
The error message is the computer telling you that something is off. The awesome thing is that it also gives you hints letting you know what the problem is and how you might be able to fix it.
Problems with code are fundamentally different than problems that exist elsewhere.
Problems with code can be fixed for free. If you assemble a car with a broken transmission or a bridge with faulty materials, it will cost major time and money to fix down the line. But if you assemble some broken code, figure out what’s wrong with it, and fix it at a later date, it doesn’t have the same ramifications.
This means that you have the freedom to, as Mark Zuckerberg says, “move fast and break things.”
Don’t treat an error message like the computer is giving you an “F Grade” on an exam.
This isn’t school, where the time comes and goes and you’re a screw-up for not knowing better. Instead, an error message means that the computer is simply telling you:
“Hey friend! I believe there’s a small disconnect between how you think the application works and how it actually works. Here are some hints!”
School has taught us that it’s bad to cheat.
A big part of programming is learning how to cheat. Programmers do not learn by memorizing a bunch of things upfront and typing on a keyboard like a maniac.
http://i.imgur.com/lz7hOlC.gif
Instead, they learn by tapping into resources that contain answers to their questions. They look at code they’ve written previously. They review code that other people have written. They perform google searches, find blog posts, and document what they’ve learned. Programmers don’t memorize. They recognize patterns cheat when they need help.
There’s a legitimate reason why startup offices have ping pong and foosball tables. It’s because there are better ways to solve problems than just sitting down and typing code for multiple hours at a time. This allows you to reorient your thoughts and think about problems from a different perspective. Coding isn’t all about producing a seamless stream of code.
![foozball](jpg/foozball-1-1024x576.jpg)
There’s a reason why the fake O’Reilly book “The Essential Guide to Copying and Pasting from Stack Overflow” went viral. It’s because there’s a lot of truth in the title. In programming, it doesn’t matter if you learn all the material before a critical time moment. The only thing you need to learn is how to figure it out.
Being able to figure things out is what makes you ready for a job. Your superiors will simply expect you to learn and grow.
School taught us that knowing stuff is important.
Honestly, it’s not. Most of the details generally don’t matter.
Take the analogy of a perfectly dark room, which represents a brand new topic. Any light that appears in the dark room represents your knowledge of said topic. In school, you were probably taught to think that if you do enough of something, the room will suddenly fill up with light. You were probably also taught that the most important skill was figuring out how to completely fill the room up with light.
But that’s not how programming works. You’re never going to be able to fully illuminate the room, and that’s not the skill that actually matters. Instead, to be good at programming, you need to figure out how to wander around in the dark room with a flashlight and get things done. The skill that actually matters is your ability to navigate the dark room with the limited amount of light and tools at your disposal.
New programming technologies are always coming out. Computers and technology are changing at an incomparable rate. One of the alumni from the Firehose program recently pointed out these facts during one of our office hours sessions:
- The wheel was invented in approximately 3000 BC
- The Industrial Revolution happened between 1760-1840 (almost 5,000 years later)
- The Wright Brothers made their first flight in 1903 (60 years later)
- Soviets put a satellite in space in 1957 (50 years later)
- Neil Armstrong lands on the moon in 1969 (another 12 years later)
And to bring it home, the Apollo Guidance Computer could process 41.6 instructions/second. An iPhone 6 processes about 3.36 billion instructions/second. This means that the technology in your pocket has the computing power to guide 120 million Apollo rockets to the moon at the same time in 1969.
Technology is evolving so quickly that it’s physically impossible to learn everything.
There’s just too much to learn and there aren’t enough hours in the day. So don’t worry about mastering something. Instead, focus on the skill of learning how to learn. That’s what really matters. The actual “thing” is far less important than your understanding the skills needed to develop it.
Once you learn one way to solve problems with programming languages or frameworks, the other ways will come easier. So don’t worry about memorizing a bunch of stuff. Instead, focus on grasping the big picture ideas.
Learning how to learn how to code matters much more than the actual code that you learn. It’s why many engineers land jobs that ask them to use technologies they don’t know…yet. It’s because being an in-demand developer is very different than what most people think.
Start coding now
Stop waiting and start learning! Get my 10 tips on teaching yourself how to code.
You master the art of programming when you master the ability to work with the unknown.
This phenomenon is remarkably common and things that “will never happen” sometimes happen. Nobody would ever start out building a desk and end up with a baseball bat. But the equivalent happens in software all the time. For example, Flickr started out as a game. It later evolved into a photo sharing site.
This is what makes programming so engaging, challenging, and fun. It requires you to fail, to cheat, and to focus on the big picture concepts that actually matter.
Remember these three core principles and let go of how you were taught to think during school. If you do, you’ll be well on your way to becoming an awesome programmer.
About the Author
Ken Mazaika is the CTO and Co-founder at The Firehose Project, where he spends time helping people make their ideas become a reality. Previously, he was tech lead at Where.com and a member of the PayPal/EBay development team in Boston. In a former life, he turned a health insurance quote generator from a $400/day web application into a $40,000/day business.
Interested in reading more code-related articles? Check out The Firehose Blog here.