Pack Your Bags For A Learning Journey

Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter “How to program if you cannot.” - Edsger Dijkstra, a super-famous computer scientist in his essay “On the cruelty of really teaching computing science”

When I got serious about coding, I often found myself frustrated beyond belief. I would spend h-o-u-r-s trying to figure out why my code didn’t work. Then I would realize I was missing a semicolon in my JavaScript. Worse yet, I would realize there had been a message in the browser’s JavaScript console, telling me about the error the entire time. The error message even said what line of code the bug was on! If only I had looked earlier! I had just lost hours of precious coding time! FUUUUU-

Learning how to code is hard.

Go ahead and recognize that… and be proud of yourself for attempting a hard thing!

Unless and until you give up, you have not failed in your mission to become an employed coder.

If you ever feel down after a day with seemingly no progress, remember Jake the Dog’s old aphorism in Adventure Time: “Sucking at something is the first step towards being sort of good at something.”

The Way

Over time and with dedicated practice, coding gets easier.

You develop systemic approaches for architecting your software projects and then coding and debugging them (Note: debugging = coding). You get better at reading documentation. You peruse blog posts, books, and coder forums like StackOverflow.com. You learn how the industry’s intellectual leaders think about code. You dig into the source code of open-source software.

Most importantly, you write a lot of code. Every coder has ten thousand lines of Very Bad Code in them. The faster you get yours out, the faster you are done with them.

After enough practice, it all snowballs. You begin to feel more confident. You begin to recognize patterns. Your coding vocabulary gets bigger. You begin to look at your favorite webpages as just a bunch of HTML boxes, holding content.

You can and will get to this place. You will feel your attitude shift: You may not immediately know how to solve any particular software task, but you are not worried, because you know how to slice the task up into smaller, more manageable pieces.

So… how can we speed up this process?

How can we go from frustration to confidence more quickly?

Learning How To Learn

Consider this quote from John Dewey, the great 20th century educator, philosopher, and psychologist:

Perhaps the greatest of all pedagogical fallacies is the notion that a person learns only the particular thing he is studying at the time. Collateral learning in the way of formation of enduring attitudes… may be and often is much more important than the spelling lesson or lesson in geography or history that is learned. For these attitudes are fundamentally what count in the future.

What Dr. Dewey is saying here is: The most important thing you are ever learning is not what you learn, but how you learn. For example, in the chapters on HTML, the most important thing you are learning is not HTML. You are learning how to most effectively study HTML. This enables you to go on and learn even more about HTML on your own. This enables you to learn about HTML faster.

Pay attention to what are the most effective learning strategies for yourself. This will help you learn more, faster. Optimizing for and investing in learning always pays for itself - in money, time, and energy - over and over and over. This is what they mean when they say coding is “knowledge work”.

This book incorporates many learning strategies that I have found effective. The upcoming chapter Tips For Success also specifies some strategies for optimizing your learning experiences.

Craftsmanship

Many great programmers have said that they consider software development to be a craft that they practice. In this spirit, many software teams hold weekly retrospective meetings – discussions of what the team can do to ship more/better software the following week. They ask: What did we do that worked well this week? What did we do that didn’t? Then they try to do more of what worked and less of what didn’t.

Do not think of software as some discrete body of knowledge that can be memorized. Think of it as a craft. The main requirement for practicing a craft is is that the craftsperson thinks about the craft they are making - before, during, and after they make it. Thus the goal is not just to write as many lines of code as possible, but to think about them as your are pounding them out on your keyboard.

Find Your Zen

It is impossible to learn everything about software. Give up now.

Think of software as a craft that you practice.

Write a lot of bad code to start writing good code.

Getting better at learning is more valuable than learning any one individual fact.

Do more of what works. Do less of what doesn’t.