Editor's note: This book is in its early, early alpha stage. It began as a list of projects to demonstrate the variety of uses for programming. I then started including tutorials on basic concepts and have kept wavering on how to make everything stick together. It's now a quagmire in that I spend more time exploring tangents and ideas than actually finishing the writing. So this first release is just meant as a milestone to keep on track. Everything in this book is subject to revision, correction, and complete overhauling.

Programming is for Anyone

Two phrases make the point of this book:

"If you count something you find interesting, you will learn something interesting."

Better: A Surgeon's Notes on Performance - Dr. Atul Gawande

1 + 1 = 2 - The minimum level of math skill needed for an interesting program

Counting, according to Dr. Gawande, is one way a doctor can be more than "just a white-coated cog in a machine." While he was a medical resident, Gawande didn't have a research grant or laboratory but he decided to count the times that surgical instruments were forgotten inside of patients. These mistakes, which could cause serious damage, happened about once for every 15,000 operations.

But when Gawande refined his counting to track the circumstances of the accidents, he found a deeper, more meaningful story: most of these mistakes occurred when an operation took a drastic turn, like when an appendectomy reveals a cancerous tumor:

The numbers began to make sense. If nurses have to track fifty sponges and a couple of hundred instruments during an operation – already a tricky thing to do –it is understandably much harder under urgent circumstances or when unexpected changes require bringing in lots more equipment. Our usual approach of punishing people for failures wasn’t going to eliminate the problem, I realized. Only a technological solution would—and I soon found myself working with some colleagues to come up with a device that could automate the tracking of sponges and instruments.

The Bastards Book is not about Ruby – Ruby just happens to be one of several popular and accessible programming languages to choose from. But this book is also not just about programming. Programming just happens to be one of the best ways to do the kind of counting – and the exploration, analysis, and critical thinking associated with it – so that you can be, as Gawande puts it, "a scientist in this world."

The math behind counting is simple. But the process is hard and tedious and so we often settle and accept generalized numbers, reports and press releases because we just don't have the time or ability to look any deeper. So programming becomes an increasingly necessary skill as the world becomes more digitized and its information more accessible.

It's hard to think of a purpose more broad than counting. Or simply, information. This book aims to demonstrate the diverse and practical uses of programming and how if you have any kind of interest in anything, you'll find a use for programming. And the math involved won't have to be more complicated than 1 + 1.

The state of self-taught programming If you're not a programmer now, you might have dabbled in it or even studied it in college before deciding it was too esoteric and abstract to be of use for whatever you do in your life today. I felt the exact same way and only learned programming because it was part of my degree's curriculum. And at the time, I would've never recommended it to anyone who didn't want a career in programming. I was wrong then, but I would be especially wrong now. In even just the last few years, the amount of resources and tools available to learning programmers – and more importantly, the number of things to do with programming – have increased by a staggering degree. Programming languages are more human-friendly.

Early computer languages were optimized for early computers. With today's processors, languages can have far more built-in features that drastically reduce the physical tedium and memorized minutiae needed to write powerful programs. Because programming languages don't need to be as efficient for machines to process, they've become much more efficient for humans to work with.

Early computer languages were optimized for early computers. With today's processors, languages can have far more built-in features that drastically reduce the physical tedium and memorized minutiae needed to write powerful programs. Because programming languages don't need to be as efficient for machines to process, they've become much more efficient for humans to work with. The amount of data and possible applications is much more diverse and plentiful.

Nearly every piece of vital information is digitized – and even if when it isn't, there's an app for that. Anyone who deals with any kind of information today will find a reason to program.

Nearly every piece of vital information is digitized – and even if when it isn't, there's an app for that. Anyone who deals with any kind of information today will find a reason to program. The tools are still free. And they keep getting better.

No other field exists like programming, in how a determined beginner can immediately do the things that master programmers worked for years to hammer out – because those programmers then gave out their work for others to reuse. The code I've written for this book uses the most basic parts of the language, yet I'm able to demonstrate tasks as complex as web-scraping, facial-recognition, and data-visualization, thanks to the hard work of other programmers. In the music industry, you have to get your own instrument and you can be sued for reusing even just two seconds of another song. In programming, the best tools are free (and are constantly improved upon). And using thousands of lines verbatim from someone else's code is not just legal, but a best practice.

The community keeps growing

Just as they give away their code, programmers are generous in helping and teaching others. Entire books are posted online for free. In forums like StackOverflow, expert users practically compete with each other to help out even the most novice programmer. There is almost no question too obscure or basic that can't be found through Google. But despite the wealth of incentives and resources, I won't bullshit you: programming will still be the most involved and demanding of any thing you've ever learned to do on a computer. But, even if the path might be long and difficult, it is neither lonely nor narrow.

Ideals and pragmatism Five years ago as a frustrated programmer, I would have never encouraged anyone to go into programming, let alone try to teach it. So it's amazing to me that 15 years ago, Steve Jobs – who was not really a programmer – said this about computer science: In my perspective ... science and computer science is a liberal art, it's something everyone should know how to use, at least, and harness in their life. It's not something that should be relegated to 5 percent of the population over in the corner. It's something that everybody should be exposed to and everyone should have mastery of to some extent, and that's how we viewed computation and these computation devices. Steve Jobs, NPR/Fresh Air interview, 1996 Jobs advocated computer science well before the Internet became ubiquitous and unavoidable. And so his belief that programming was important and enlightening for everyone is far more real today. But as much as I'd like to also tout the high-minded virtues of programming, it wouldn't be very honest of me. Because I haven't stuck with programming out of abstract ideals of understanding the world around me. I just think it's depressing and dull to have to use computers without programming. And I'm someone who quit computer engineering because I wanted to get away from computers. It's assumed that programmers must love computers. But consider how an average person uses a computer for work: mindlessly following a chain of tedious tasks learned at a training session years ago that involve navigating a seemingly random sequence of pop-up menus and buttons from mouse-click to mouse-click, interrupted only by inexplicable error messages and frequent calls to the help desk. A routine chore might include clicking through a 30-page online database and copying parts of it into a spreadsheet. By hand, this repetitive task might take an hour. As a mediocre programmer, you might spend 59 minutes – not all of them at your keyboard – to design and program a web-scraper that does that same task today and for every other day. But even if you never look at that program again, here's the key advantage: For 57 of those minutes (the other two minutes being used to actually type the code), you were actively thinking, researching, and learning how to solve a problem. You may never reuse that exact code. But you've become a better programmer and thinker. The next program might take just 5 minutes to think about and write. Whereas if you had spent that hour just copying-and-pasting, dragging, clicking, redoing the times that you didn't properly drag-and-click, you've only gotten better at...just copying-and-pasting. Until you get carpal tunnel syndrome. I don't know if programmers necessarily love computers more than the average user. We might just have fewer reasons to hate them.

The importance of being interested Most of my professional career has been non-technical jobs but I still found ways to practice coding. As a newspaper reporter, I occasionally filled in on the night cops desk. This consisted mostly of chatting with the dispatchers and taking the radio scanner to dinner so that if something big happened, you could scramble and get the story before the paper went to press. Many nights were pretty slow though. With the court system closed for the day and people going about their evening activities, there wasn't much to report on if those evening activities didn't include a major crime. However, the county jail's website did provide an up-to-the-minute log of everyone booked in the last 24 hours. In theory, it could be another source for late-night news. But in practice, the site's interface made it nearly unusable for that purpose. It presented the user with a simple list of inmates' names, the time they checked in, and a link to more details of the arrest. My enthusiasm quickly waned after clicking through to the tenth booking record in a row that involved only an outstanding warrant or DUI. So during a couple quiet shifts, I wrote a simple script to crawl the jail website. After hitting "Run" and going to get a coffee, I'd have a spreadsheet of every new visitor to the county jail, listed in a way most useful to me: each inmate side-by-side with his or her alleged deeds so that I could skim for "assault", "murder", "aggravated," and so forth. And since it was a spreadsheet, I could easily sort the entire inmate population by age, bail amount, and even weight. Not being a full-time cops reporter, I didn't have a good grasp of the bail schedule. But now I could easily make comparisons and see how an alleged armed robber might have to put up $20,000. But someone else might have her bail set at $1,000,000 for a non-violent offense. Since bail is a consideration of both current charges, past criminal history, and flight risk, it's possible there were arrestees with interesting circumstances who didn't strike an information officer as being newsy enough to announce. Was creating this spreadsheet impossible without programming? No. But I didn't have a group of interns to order around. And if I had outsourced the work, I would have missed an even bigger story. One of the less-heralded effects of programming is that even its tedious steps are valuable. They force you to slow down and notice the details that are easily looked over for seeming irrelevant. When all I knew was mouse-clicking to view the jail records and manually copy them, I only looked at names and crimes because that was what I thought was interesting. When I took the time to write a web-scraper, I noticed what could be interesting. In particular, the jail records included a reference number for each inmate. That number was a unique identifier that was used also by the county's court system to track not just when an inmate would have her day in court, but all of her past court appearances and resolutions, too. I had ignored the reference number because it was extra work to write down. But it was trivial to collect with an automated web-scraper – along with every other data field. And now I instantly had a key into an entirely new source of data. With a little more programming, my scraper automatically could visit the court system's website and collect past criminal histories. What started out as a tool for trivial breaking news was now something that explored a much bigger picture of the justice system, potentially shedding light on issues of recidivism and other outcomes of sentencing practices. When non-programmers hear of such seemingly expansive analysis, they think that the programmer must be a genius. But it's not genius as much as a natural revelation that comes from being used to seeing the logical big picture, nevermind the details and minutiae. Programming is an art that sparks curiosity in its practitioner and, as a (huge) bonus, also provides an efficient way to investigate and satisfy that curiosity. So what did I do with this mine of criminal justice data? Virtually nothing. I checked in occasionally to see if anyone had any giant bail amounts or simply to find out who was the heaviest or oldest person in jail. Crime wasn't my main beat and so this was just a programming exercise for me. In a chapter of this book, I demonstrate how to scrape another jail system. But I draw only superficial conclusions about the data, because I know even less about that jurisdiction. The collage of inmate facial expressions above, which I stitched together with a Ruby script, is the peak of my creativity. When it comes to making meaningful interpretations, pure programming skill can't make up for lack of institutional knowledge or passion about a subject. A programmer may have the tools and data easily in hand, but that doesn't mean he or she will know what to look for. And non-programmers can have the insight and instinct for investigation. But the inability to even conceive of the tools leaves them just as blind. The problem with being just a non-programmer with an interest – or a programmer without an interest – is that it's not enough to know what you don't know, hoping that you can just hire someone to fill the gap. Because you still won't even know what you don't know, and more often than not, neither will your partner. As programming is increasingly more relevant to our everyday lives, I think everyone should learn it to some degree, though I can't say that everyone should study it in-depth, because it's still a intellectually-demanding pursuit that requires patience and devotion. But I also think there are many out there who have so far avoided programming for the wrong reasons, thinking that it was too narrow and difficult for their purposes. If they could only see how it might relate to their passion, and how it would vastly improve their work and their ability to make an impact, they would gladly make the leap to learn programming.