Why everyone should learn to program (and where to start)
I’ve previously said that the problem with attracting new programmers is not in explaining how to program, it’s in helping people understand why to program.
So why learn to program, aside from the life lessons mentioned in the last post? A lot of reasons, actually.
It really is a form of “digital literacy”. Even if you decide programming isn’t how you’ll make a living, having these skills is like knowing how your car is put together: you will often know how to fix problems yourself, but even when you have to take it to the mechanic, you’re more likely to be taken seriously.
You’ll run a better business. If you have an entrepreneurial bone in your body, learning to program is going to return rewards to you many times over when starting your own company. I’ve seen many startups fail because of poor technical leadership by founders, and many succeed due to good communication between management and engineering.
You’re uniquely set up to succeed. Whether your background is as a writer or a pizza maker, it will likely help bring a completely different perspective to programming, which benefits everyone, including you.
Don’t let your subconscious lie to you
One life-impacting lesson I’ve learned recently from Paul Graham is that we too often let our subconscious make the decision to steer away from things that seem difficult. We mentally file it under “impossible” and let our conscious mind plan our goals around the perceived roadblocks.
Let’s run through some of those:
“But doesn’t programming require a formal education?” No. Next question.
“Isn’t it hard?” Yes. But not in the way you’re thinking. It’s hard in the way that playing an instrument is hard, in that it is merely a matter of practice. In fact, learning to play a musical instrument is the most direct parallel to programming of which I’m aware.
“Isn’t it just for antisocial, nerdy guys?” Oh dear, let’s dive into that one.
First off, it’s time to let go of the programmer stereotype from the 1980s, because it’s not useful and no longer accurate. We have a whole new crop of stereotypes for you to choose from.
Most distressing is the fact that most women have had a lifetime of exposure to the idea that “programming is for boys”, and from a young age, mentally wall that area off. This costs us in software quite dearly, both in sheer numbers and in the diversity of perspective that smart women bring to the activity.
Don’t let a lifetime of people trying to intimidate you (even subconsciously) prevent you from realizing that you have all the capability they do.
Programming is a special ability, akin to a superpower. It transforms you from a consumer into a maker. But it’s not for special people.
Some programmers feel otherwise, that programming is something you need special skills for. Instead of punching them in the face, just remember that a few hundred years ago, these are the types who thought reading and writing should be reserved for clergy. Learn and make all you can, so that these code hipsters can someday complain that they were programming before it went all mainstream.
Starting on your own path
Learning to program isn’t as hard as it sounds if you’re working with people who know how to ramp up the difficulty properly (and speak English instead of jargon). The Learn to Program (Ruby) book I used is a tried-and-true introduction to programming concepts, and I recommend it highly.
Plus, with those languages, there are communities of people who are knowledgeable and generally helpful. There’s simply no substitute for personal, interactive feedback with experienced mentors. Even as a brand-new programmer, I found the pattern of showing up to local Ruby User Groups and following the attendees on Twitter to be incredibly valuable. It helped me create a support network of people who could answer questions or buoy me up when I felt like I was underwater.
Finding a local User Group, following helpful people on Twitter, joining related IRC channels (I use the fantastic IRCCloud service for this), and generally trying to grab the attention of people who do this for a living are all good ways to help luck start to fall in your favor.
Later this year, my understanding is that Mendicant University will be holding classes for newer programmers, and that may be a great time to start. If your local programming groups don’t offer workshops for new programmers, I bet they’d be open to the suggestion.
If you’re interested in learning to program, find me on Twitter and I’ll do my best either to help you or line you up with people who can.
If you knew half of the doors it’d open for you, you’d be starting one of these books or tools tonight and beating down the door of your local programming community leaders to build an initiative for new programmers. If you give learning to code half a chance, I can promise that in some significant way, opening your mind to it will have an impact on the course of your life.
In the last post, I talked about how I learned to program. This process has had a profound impact on the way I think, the way I approach problems, and my outlook on life in general. Here are just of the few of the lessons this process has taught me:
Unknowns are not bad. I used to work from a place of fear. If I didn’t know how we’d solve a problem, the risk was unacceptable and we’d abandon the effort. Programmers almost never know exactly how they’ll solve a problem, only that historically, they’ve been able to solve them. This is a much better place from which to start thinking if you want to change the world.
Breaking problems down is my job. Along with the last point, if a problem looked too complex, it was easy to get overwhelmed. But programmers know they’re the last line of defense: the enzymes whose job it is to break complexity down to manageable chunks. This is the key mindset difference that makes programmers so damn special.
Sharing is good. Previous jobs, Marketing in particular, taught me each and every idea is a trade secret and must be protected. Programming leads the way in thinking that “none of us is as smart as all of us,” which is part of why software is moving humanity forward at an astounding pace.
Black boxes are stupid and harmful. I used to think that if I didn’t understand how something worked, I probably never would. Programmers don’t allow “black boxes”: they have to tear everything apart to know how it works. It’s okay to not care how something works precisely, as long as you have a general idea of what’s going on. My friend Dave Brady calls it “Leaver’s Law”: “Anything that a system does for you, it also does to you.”
Sleep is amazing. Programming has taught me that your brain will chew on things for you and often bring you the answer after a good night’s sleep (or even a long walk). Letting your subconscious process things for you is a gift and a curse: I’ve had horrible code nightmares where I couldn’t solve a problem. But more often, I’ve awoken to find last night’s unsolveable problem quite easy to untangle.
You’re a free agent. I used to feel chained to my employer, completely subject to the ups and downs of the company. I felt if I lost my job, I might just die. Programmers tend to think in projects, and an employment contract is just that: a contract that needs to be mutually beneficial, or they’ll find somewhere better to spend their time.
Develop, then trust, your intuition. Programming is a surprisingly intuitive process. Things that just “feel wrong” or “feel right” typically are. You can then find the principles that define and back up these intuitive feelings.
People get paid to do this? If you don’t marvel at that from time to time, chances are your work isn’t aligned with your passion. Even on rough days, programmers generally have a sense of how fortunate they are.
Don’t give in to the overwhelming temptation to quit. The highs are high, but prepare for soul-crushing, ego-obliterating lows. It’s important to build a network of people who know exactly how you feel.
They’re not going to eat you. You will embarrass yourself. You will write hideous code. You will ask stupid questions. But all the embarrassment you’re conditioned to feel is unwarranted, because 99% of the time, sharing things you make with other makers is a safe thing to do.
It’s not as hard as it looks. There are a number of reasons that programming looks hard from an outsider’s perspective, but it’s only hard work (there’s a big difference). Things that appear to be a cliff to newbies actually have a gentler slope on the other side. It’s still a hike, but it’s doable.
Feeling dumb is normal. We’re trained like seals to bark the right answers back at teachers, bosses, etc., and to feel awful with anything less. Programmers get really comfy with not having any answers upfront, and finding fulfillment in the discovery process.
Your capabilities are limitless… eventually. Programmers are special because they tend to look at ignorance on a topic as a passing phase. Because they have to re-learn their own profession as it’s reinvented every few years, they know that given sufficient time and attention, you could become an expert on anything you want.
Show me the code. Years ago, I figured I had to try to play political games to get ahead. I even tried to learn to golf to get in my boss’s good graces (shudder). Not so with programming. Coders either deliver a result, or they don’t. Next to sales, it’s difficult to imagine a more results-driven culture. It’s basically impossible to BS your way through, because you either make things or you don’t.
Feedback is feedback. It’s better to move forward on the wrong information or without permission than to sit still and wait for the perfect opportunity. Being proven wrong is always an acceptable outcome, because it means you’re moving, and the “perfect opportunity” seems to prefer a moving target.
It’s about the journey. This is probably the lesson that’s had the biggest impact on my life. It’s too easy to become so focused on chasing some big reward while missing all the wonderful experiences in between. If you can’t enjoy the journey you’re taking, you probably won’t love the destination either.
Above all this, I’m generally a much happier, more patient person. I’m infinitely grateful to all the people who taught me these lessons and encouraged me to keep pressing forward.
Learning to program has changed my life in vastly more ways than listed here, and it’s why I’m so passionate about making the onramp less steep for new people. In the next post, I’ll talk about why you should learn to program and how you can get started.
Quite often, when I tell people I left a career in marketing to teach myself to program and develop software, they react with surprise or even amazement. As much as my ego wants it to be, it’s really not all that special, and it’s something I believe anyone can do, and many should.
Here’s how I learned to program, how it changed my perspective, and how you can do the same without falling into some of the same pitfalls I did.
The spark of interest
After spending nearly 5 years learning online marketing for the startup I worked at, I had become profoundly unhappy in my job. The only path forward I saw for myself was “marketing guru” (ugh), and I was constantly depressed.
Several people, including my dad, suggested that I pick up programming, and that I might enjoy that more than my present career. I perceived it as a serious affront to my abilities as a marketer and fumed at the advice.
But eventually, I decided to take a few minutes to talk with our lead developer and brought the idea up. His response surprised me and sidestepped all my concerns: “Everyone should know how to program. It’s a part of living in modern society. It’s like knowing how to change your oil or change a tire.”
We talked late into the night, and he wanted to show me how amazing programming was. He wrote a little program in Ruby that would create different animals, give them stats, let them fight, and see who would win.
I watched the strange symbols dance around the screen and was totally fascinated and thoroughly confused.
He handed me Learn to Program by Chris Pine and suggested that I start reading it. He said that I’d know whether I had any interest within two weeks, and my response would be either “this isn’t for me,” or “people get paid to do this?”
Learning to program
I started in on the next night, and asked the second question within hours. Captivated, I spent every night for the next few weeks working through the exercises in the book.
Each day I’d run into the developers’ room to talk about concepts, check my code, or get help on the tougher exercises (looking back, a recursive algorithm for parsing an array of arrays is a bit much for beginners).
Clearly, it was a stroke of luck that I worked with wonderful, knowledgeable people who were too happy to help me along the path.
From there, the books thing was working so well that I kept rolling with it. I picked up several advanced books that started to take me off track. Somewhere between Design Patterns in Ruby and Test-Driven Development, I started to feel like I’d gotten in over my head.
I confided in my friend and admitted that I’d failed as a programmer. I couldn’t do it all at once, and there didn’t seem to be a way to break it up. He told me, “That’s enough, your problem is too many books. You need to write some code and go from there.”
My first projects
My friend was right: it was time to just start making things. I got tiny assignments from the dev team: small copy or functionality changes, or bite-size features that were low-risk if I failed.
The things I built were embarrassingly elementary, but it’s an amazing feeling to ship code, and I felt back on track.
I tried and failed at a few more side projects. I was wholly unprepared to build the square-foot-gardening app I wanted to make, having underestimated its difficulty.
It was about this time that the company started to go under and I was shown the door. I suddenly lost my support network, and it became more difficult to practice my coding skills.
Luckily, just a few months later, I discovered Ruby Mendicant University. Started by Gregory Brown, it’s a free online school for intermediate programmers with a strong focus on building stuff for real-life situations.
After completing the core Mendicant University course, my projects became slightly more ambitious: A video upload site that limits you to 1 minute (a terrible idea, if you’re considering it), then a lunch-voting app, ToDoGroove, and now Hashbadges, which is mostly under wraps for the time being.
Even with all that, I still had a mental block about becoming a full-time programmer. I was more comfortable hanging back a bit and helping manage programmers than trying to write code that would actually be used in the business.
Luckily, I had a friend call me out on this and tell me that it was do-or-die time. I either needed to start coding and stop making excuses, or be happy with a non-technical role. We spent the next week pair programming, and I realized that I really am capable of programming full-time.
That week, I moved my desk into the programmers’ area and decided to become a full-time developer. (Kudos to my employer for not firing me for that one.)
I’ve only been a full-time programmer for about 5 months, but it’s been the most fun and interesting few months of my career thus far.
I have no idea where the future is taking me, because I’m having so much fun with what I’m doing now. No matter what I decide to do next, the act of learning to program has taught me lessons that completely altered the course of my life.
Lately, I’ve discovered that processes are not the key to successful projects. But good metaphors lead you to communication shortcuts that sometimes are keys to success.
Specifically, I’ve drawn a lot of value from the story of Stone Soup.
For the unfamiliar, it’s a very old story of a tramp who travels to a town in search of some food. Hungry and destitute, he knows better than to ask the townfolk for a handout. Instead, he offers the villagers the best soup they’ve ever had, “Stone Soup.”
Having intrigued the villagers, he drops his “soup stone” in a large pot and brings it a boil. He tastes it, adding that it just needs a bit of barley and salt to be complete. Then, the story goes, he gradually asks other villagers for more ingredients to make it “just right”: chicken stock, celery, flour, and so on. Everyone shares in the soup, and the stone is extracted, ready to earn a free meal for its owner in the next town.
Starting with nothing
Most projects (especially software projects) are astonishingly like this story.
If you’re building software for a customer or group of customers, you must start with only a stone and a promise of soup to come. That’s probably a familiar feeling to many developers.
Unless you’re writing software to an exact set of specs (in which case, you’re doomed, sorry to say), your customers don’t know exactly what they want. They also don’t want to provide you with the tools, data, and requirements you literally can’t move forward without.
Making matters worse, their expectations are that you’ll magically appear with the project, after reading their minds, overcoming all obstacles, and satisfying all dependencies.
Stone soup is how you show them some of this magic.
Some see the tramp in this story as a charlatan, but I am going to use the term “instigator”: the guy or gal with the guts to set up a pot of boiling water and throw in the stone. The instigator goes out on a limb to make things happen.
Here’s how you can start making some soup:
Find your stone
You are now the keeper of the stone. You’re the instigator. Why you? Because you are probably the only person that knows there’s even supposed to be a stone.
In my experience, throwing the stone into the pot involves skipping a lengthy requirements phase and taking that risky first stab at the product.
There are arguments for building low-fi mockups and some for high-fi, functioning prototypes. As I’ve gotten better at building products, I’ve found high-fidelity prototypes to extract more valuable feedback.
I’ve also heard this called a “straw man”. The point is to start the conversation by putting something in a customer’s hands to either love or hate.
Projects often grind to a halt when people fail to deliver on their part of the bargain. This is where I’ve watched projects languish and then die.
Momentum is everything in this phase. No, you won’t get all the ingredients you think you need for your soup. But you do need ingredients of some kind or the boil dies down, interest is lost, and everyone goes home with empty stomachs.
So if one person or group isn’t delivering and is holding things up, it’s time to get creative. What can you put in that would move the conversation forward? Can you get data from a different source that would still be valuable? Can you show a reasonable facsimile of this feature using only the tools you have on hand?
This ingenuity both helps solidify the product and creates a vacuum for the actual item you need, pointing a spotlight on the reason it’s being held up.
The finished product
Actually, that’s kind of a misnomer. The product is never finished.
But after a few iterations on the original concept, you have something worth sharing, even if it’s not perfect. You may never have all the ingredients you’d planned on, but just getting the wheels unstuck generated an outcome that would never have existed otherwise.
At a micro level, the instigator never knew how the soup was going to turn out. The ingredients and tools on hand vary wildly. But at a macro level, he or she knew enough about the process to guide the participants to a shared goal: making something great.
Want to change the world? Be an instigator.
To be successful as an instigator, you must have a decent mental picture of how the soup gets made. If it’s a software project, you’d better have a working knowledge of the parts of the process, from servers, to data, to code.
Once armed with this knowledge, developing a habit of making stone soup is what sets leaders apart from those who are led. It gives you the ability to know that you’ll be able to deliver a result, even without a sure knowledge of exactly how you’ll do it.
Most people aren’t wired to want to be instigators. It’s scary and the risk of failure or embarrassment seems high. But it’s a skill that can be learned, and whether you’re a coder, a manager, or an entrepreneur, it’s required if you want to help lead successful projects and create great products.