This issue is about recycling, whether computers, computer software, or yourself. Recently I came across a great item in the Help Kids Code news wire, The Myth of I Can’t Code. If you don’t know, the news wire is a curated collection of 110+ sources of news about computer science and computing from teachers, coders, creatives, vendors, organizations, schools, and magazines. The news wire captures some of the more interesting bits of news and ideas about computing that float along the internet any given day.

This article comes from the Flatiron School in New York City, a 12 week intensive program designed to turn you into a web developer. Written by Stephanie Oh, a Flatiron student halfway through their program, she writes:

For the first few weeks, I thought surely that I had slipped through the admissions cracks; that I had duped everyone and somehow "impostored" my way into Flatiron. I felt this way due to a number of reasons, none of which were actually reasonable: I wasn't good at programming yet (of course I wasn't "” I'd never programmed in my life and I was here to learn!), I hadn't majored in Comp Sci in college (barely anyone else in the program had, either), I didn't know many, if ANY, keyboard shortcuts upon entering the program (because knowing keyboard shortcuts automatically makes one a good programmer"¦?), and I was/am a woman. Once again, being unreasonable with myself was largely responsible for my struggling.

The imposter feeling is common not only in coding but in any human activity where you learn how to do new things. Especially if you’re surrounded by others. Why? People learn at different speeds. It’s easy, as Stephanie points out, to think you’re an imposter if you can point to others who learn more quickly. Or you think they learn more quickly.

The imposter experience also is key to recycling yourself successfully. If you want to do almost anything new, you’ll be a newbie. You will fail. You will fall behind. But if you hang in, learn from many or most of your mistakes, likely you will have some success. And if you hang in longer, those successes add up. Or you realize your achievements are enough and move on to other projects.

But the key is no one is an imposter. It’s a false conclusion. We are simply new to a topic or not. We’re learning or not. We persist or we walk away.

Put another way, it might take you 12 weeks to become a web developer while it takes me a year. You have to decide if 12 weeks works for you and I have to decide if a year works for me. But it’s silly for me to say I’m somehow less capable, or an imposter, simply because it takes me longer to learn to be a web developer.

Stephanie Oh’s piece also highlights another key point: should everyone learn to code? What is the purpose of learning to code? Yes, we could live in a world full of people fluent in programming. But would it be like Vitamin C, useful only in small doses but not required if you already eat oranges? If you can use a smartphone and software apps, do you also need to learn to code?

While people estimate there will be a million unfilled coding jobs by 2020, and we currently have more coding jobs than computer science college graduates, the past fifty years have undergone equally dramatic technology shifts and survived fine. Could we have done better with more Lisp programmers? More Ada and C# coders? Probably. But we did pretty well as a society. On balance, technology has helped us more than hurt us. And problems like government surveillance and online privacy can be addressed and balanced out. Coder shortages also help keep wages liveable and avoid turning coders into the digital equivalent of low-wage burger flippers. In addition, many coders do not have computer science degrees so the 2020 shortage may be much less.

So the need for everyone to learn to code should not be based on fear of having too few programmers in the future. We’ve already lived that future for almost fifty years.

There are other better reasons to learn to code. And learning to code is not all we need to learn.

We should teach coding the way we teach Vietnamese or German. As noted in an article in this issue, the Go programming language was created to solve problems with how to manage data in massive databases on computers with multiple processors stored in multiple data centers. This is a problem PHP and Python languages did not face and, therefore, did not address when they were created years before Go. In a perfect world, people would learn not only how to code in Go, PHP, and/or Python; they also would learn how each language happened, what problems they were created to solve, what trade-offs resulted, and how they compare with other languages.

When you learn Vietnamese, for example, you learn more than words, phrases, and sentence structures. You also learn Vietnamese history, stories, and ways of thinking. Every language is a door to access the lives of millions of people. Learning to code should work the same way.

In addition, there also are ways to teach computer science without computers, something I plan to cover in future issues of this magazine.

It’s also true teaching everyone how to code fails to teach people how to manage technology for their benefit and the benefit of society. While we’re told technology progress is unstoppable, the truth is agreeing to that idea is a choice. We could choose, for example, to set minimum prices for ebooks to ensure publishers and authors can make a living. If you think that’s crazy, since the late 1800s the Germans have done something similar with printed books. As a result, they have more authors, small bookstores, books, and publishing houses than in the US.

The point is not to say one policy is better than another. Instead, we always have choices with technology. Teaching everyone to code should include teaching people how to create and balance our options and then make choices. We must teach the social impact of technology and our responsibility to manage technology to benefit everyone. The alternative is to make it easy for people to game the system for their benefit, in some cases, at the expense of many other people.

I also found Stephanie’s piece gets at what is special about coding. It’s not the drudgery of learning a language to make it work. What really is coding? In my experience, coding is debugging. It’s researching. It’s trial and error. It’s ripping up code to start over when you learn better ways to do things. It’s a puzzle. It’s fun. Coding teaches persistence, creativity, flexibility, openness. For the right person, programming can be as intense and insightful experience as learning anything non-technical. I often find myself as engrossed and engaged with coding as when I read favorite novels or poems.

Which leads to another point about learning to code: we definitely should teach how to work in groups to define, design, code, test, and launch software applications. For me, one of the joys of programming has been working with clients and other people to complete projects.

And, finally, as Stephanie points out later in her essay, coding definitely should be taught as fun. People can create neat things with software, if only to amuse themselves, the same way they might tell a joke, read a book, or learn to play a piano sonata.

Halfway into my time at Flatiron (and just a short minute into a much longer lifetime of programming), I know how to use both git and github to maximize not only my individual workflow, but a group workflow; I feel weird if I'm ever using my GUI instead of living and breathing in my Terminal; I've scraped various websites including Netflix.com and RottenTomatoes.com for fun projects like a command-line game that I helped present at a NYC Rails Meetup; I know the difference between SQL, Sequel, and Sqlite and that both the Sinatra and Rails frameworks are built on top of Rack; I can build a basic Sinatra application and convert all the code into a Rails version of the application; I have a much better intuition about project directory structures and can thus guess where to find specific files better "” i.e I was able to further customize this blog template today by downloading and adding social media icons. Did I mention that I pushed my first gem to rubygems.org this afternoon?

And this is where she ends:

These are my reflections on the first six weeks. They were hard as hell.

And I can't wait for the next six.

One thing is certain: whether or not Stephanie becomes a professional programmer, she has the right attitude to tackle anything that interests her. She is not an imposter. Neither are you, or anyone else.

Learn More

The Myth of ‘I Can’t Code’

http://stephaniehoh.github.io/blog/2013/11/06/the-myth-of-i-cant-code/
http://blog.flatironschool.com/post/66383520349/the-myth-of-i-cant-code

Language of the Month: Go

https://kidscodecs.com/go/

Help Kids Code News Wire

https://kidscodecs.com/wire/
https://kidscodecs.com/wire/people/
https://kidscodecs.com/wire/sources/
https://kidscodecs.com/wire/date-archives/