Skip navigation

I want to flesh out the picture I’ve been painting of Gandhi by pointing out that, although he urges Satyagrahis not to resist arrest – this does not mean that they are not to show any form of resistance when dealing with the police. Naturally, he urges people to resist harassment and brutality by not complying with whatever it is the police are trying to get them to do. For example, during the salt protest of 1930, the police often attempted to seize contraband salt forcefully from the protesters, and Gandhi praised them for sitting on the ground and clinging to their bags of salt with four limbs as the police tried to take them away. That Gandhi urges resistance in this situation and not during an arrest, is that, in his belief, making arrests is a civil, responsible way to enforce a law while attacking or making threats is a form of what he calls “Goonda Raj,” i.e, rule by thugs. This distinction makes perfect sense to me.

Sadly, this once again leads me to wonder: what can people today do similarly, when faced with injustices? I have only seen little of the Occupy Wall Street protests, my immediate modern example, and it seems that they responded quite well to the police. That’s not really an issue: the protests were/are non-violent in action (though perhaps violent in word and thought – though I’m not going to get into that now). The problem once again is: what is it that they were not participating in? I feel that’s the issue. Non-violent confrontation cannot go anywhere without demands. OWS made an attempt to put together demands, but it was handled more like an after-thought than the core of the protests. I feel that such things need to occur before anyone stands on the pavement, otherwise either the cause is lost or it will erupt into violence.


One quick note this time. There is a lot to absorb in Satyagraha, but I am taking it in slowly (around 2 chapters per day), and the ideas are beginning to stick a little bit.

1. Revisiting a point I made in my last post about Gandhi, it still impresses me how often Gandhi says that non-violence is something a practitioner should die for. The process does not work if you are not laying your life on the line. Otherwise it cannot be taken seriously, and you are not truly committed.

This also applies to arrests and imprisonment. According to Gandhi, a Satyagrahi is not to complain or resist arrest in any way. This seems entirely counter-intuitive to our current conception of non-violent resistance – which seems to largely consist of provoking people until the police arrive, so you can “resist” the police. That’s not what Gandhi’s idea of resistance is about. What a Satyagrahi resists is participation in an unjust system: you are supposed to be demonstrating that you would rather make large sacrifices than cooperate in a government or other organization that uses violence to enforce an unjust set of circumstances. For example, unfair taxation; an occupation of an entire nation by a colonial power; slavery; things like that. You demonstrate your non-participation by giving things up: your privileges, honors, posts and – scary thought these days – your jobs, to convince the offenders that you will not submit to any system that does not fit your morals.

This is not how Occupy Wall Street is (was? is it still going?) operating – or really any modern protest I’ve seen recently, including the protests against SOPA/PIPA. Interestingly, Maddox, of “The Best Page in the Universe” and “Alphabet of Manliness” fame, has offered a plan for action against SOPA that seems to be the closest to Gandhi’s principles. It’s not quite there, as he is essentially suggesting that corporations that support SOPA/PIPA should be punished with boycotts – and punishment is explicitly excluded from Satyagraha – but he is the only person I have yet heard who has insisted that protests are meaningless without personal sacrifice. If there are more, please comment and let me know.

This brings up the question: what kinds of non-violent sacrifices can we make that would really change how our government and society at large work?

So here is where I begin to report the little lessons I learn while studying to be a programmer.

This first post is not so fresh in my mind – I’m describing something I worked on roughly a month ago as an exercise in Zelle’s book. But my notes are pretty clear.

The project was pretty simple: choose a card game, design a program in python for playing it, use a simple gui (I used a modification of Tkinter supplied by Zelle), include a splash screen. It was an extensive practice in object-oriented design – so the point was to make good use of classes. (For those who don’t know, OOD is essentially writing chunks of code that can be recalled by a name so you can play around with sticking big chunks of code together like legos instead of writing line after line of the same little details over and over.)

And I did make good use of classes. With one big mistake.

So for those familiar with Blackjack, you have a few actions you can choose from each turn. Mostly, that’s going to be hitting (getting a new card) or standing (ending your turn). Most of blackjack consists of these two things. Because most of the game is these two things, I wrote the program around them. I thought about the other options for only a second. I only thought about doubling down, which is a special kind of hitting and standing that effects your wager, and nothing else. So, no problem.

Except there’s this other important aspect of the game: splitting. I thought I could just “cram it in” like doubling down. No need to spend too much time figuring it out.

This was the mistake. You see, splitting requires you to play with two hands (at least four cards). I had enough forsight to leave enough room in the gui for two hands. So that worked out. There is a minor problem there, because sometimes you can split a split hand (depending on house rules), which means I would need to set up for three hands. I decided it was not worth thinking about. This was just an exercise in a textbook, it needed to be very good, with a lot of effort put in, but not perfect. I decided this house would allow only one split. Fine.

The problem was in coding. It became a nightmare, figuring out how to redesign the program to get input from the user when it was a split. I won’t go into the details. I will say that I spent about 8 hours working on this, and at least 4 of them were trying to get splits to work.

What was the problem? I discounted splits because they are not normal. They occur maybe 5% of the time, at most. I made the mistake of thinking that, since this happened 5% of the time, it warranted 5% of my attention. It warranted more, and it got its attention with a vengeance.

How could I have done better? Spent time mapping out options and observing patterns. I thought that, since I understand blackjack pretty well, and I even coded a primitive version of the same thing a few weeks prior, I could just breeze through. What I didn’t realize was how object oriented programming requires you to step up your planning efforts. You need to spend the time figuring out just what is an object – just what are the essential components of the program – and exactly how everything fits together.

If I had planned this game out, taken the time to map everything in a flow chart or something similar, I would have realized that it would have been easier to make a “normal” hand a simpler version of a “split” hand than it was to make a “split” hand a more complicated version of a “normal” hand. I should have expanded my definition of what a hand is to include a split hand. What I was doing was kind of looking at a split hand as an afterthought – a particular tweaking of a normal hand – and therefore not worth thinking about too much until I got to it.

A more general definition of a hand, based on a more careful perspective, would have allowed me to include the shared characteristics of both normal and split hands, saving me the step of redesigning everything towards the end of the process and making the whole process faster and easier.

You’re probably detecting a kind of moral lesson out of this. And I think there definitely is one. In any situation, it’s better to accept all cases and account for them – whether its at home, in politics, in your day to day affairs of life – than it is to marginalize. If you want to see beauty and some kind of order in your life, you have to make sure you are making relevant distinctions. If not, you risk either rejecting something valuable or neglecting something significant.

See, programming has a lot to teach. More to come.

I want to begin recording my thoughts and misadventures as I go about teaching myself how to program. I would like to share my curriculum of self-study, once it’s finished. Every day, it seems, I’m getting more and more ideas about what to put into it to make it function. It’s a lot. I’m going to divide my time between general programming languages, web development, math pertinent to the topic (especially algorithm design), operating systems (mostly Linux), network and server administration and finally – which is an entire subject unto itself – electronics and basics of computer engineering. This is, perhaps, a lifetime curriculum. Maybe it will take multiple lifetimes. We’ll see.

But right now, going at my steady tortoise-pace (which I hope will help me across the finish line) I’m studying two languages: Python and C++. I probably won’t be talking about C++ for a while, because I’m studying it as part of a college course which is going relatively slow for me.

My main text right now is Zed A. Shaw’s book, Learn Python the Hard Way.  From one perspective, beginning this book after finishing Zelle’s Python Programming was a step backward. I’ve been reading lessons about many of the things I’ve learned before – all the basic stuff, like printing, loops, decision structures and classes. There are a few functions and concepts that Shaw introduces that simply don’t appear in Zelle’s book, such as argument variables. If that were the only advantage, it would not have been a good use of my type. I’m finding it invaluable, though, for two important reasons:

1. Zelle’s book uses Python 3, Shaw uses Python 2. The two are different enough for starting over to be helpful for me to learn the differences.

2. Shaw is an outstanding teacher. Sure, he has a different aim than Zelle – Zelle is an academic who is committed to developing a very thorough, solid introduction to the concepts of computer science, where Zed is trying to provide a quick, practical guide to the realities of programming.

But it’s more than that. Shaw has helped me learn how to learn. And this is coming from somebody who dropped out of high school and attended a bizarre liberal arts college because he cynically believed (and still tends to believe) that nobody knows how to teach anything. Zed helps me in two ways.

First is the way the book is structured and the scope of the exercises, divided between daily lessons and week-long “missions” (my term, not his), where he asks you to devote yourself, single-mindedly to one purpose, whether its to design a program, memorize symbols or expressions, or spend time exploring the internet to read code. Everything weaves together nicely; he obviously took care to decide what is important to simply practice, what is important to simply gloss over and what is necessary to etch into your skull with a diamond pen.

This leads into the second great thing about the book: Shaw’s tone, his comments, his attitude. Though a bit cynical (I can often feel a restrained anger toward the missteps of his predecessors and peers), it is infinitely helpful. In the process of steering the reader away from unhelpful trends out there in the forum of computer science, he provides an example to the reader of how to be wary and circumspect about the different opinions out there – an attitude that will help anyone to be more focused, to be more skilled, to be excellent. As an illustration, in Exercise 34, he warns readers not to bother reading about Edsger Dijkstra’s opinions on cardinality – essentially saying that this topic is not worth the time of a beginning programmer (also, that Dijkstra’s opinion is not worth very much, but I have no way of judging that). Not that I was about to go out and read anything by Dijkstra, but it’s good to hear from an instructor what is worth my time for now and what isn’t.

In the end, I like this book, because I feel confident that I am being guided toward proficiency. None of the particular points and warnings are, if taken generally, anything new to me (how to be circumspect, how to avoid pointless arguments, how to memorize a list of symbols), but this book fits them all together in a beautiful whole.

I’m just over halfway finished, currently working on a week-long mission project. The assignment was to write a simple text adventure. For some reason, I’ve decided to go overboard: I’ve created a function that has the text print across the screen, character-by-character instead of string by string; and I’ve added a whole slew of Nintendo-era sound effects to a graphics-less game. Perhaps this game will become the subject of a future article on “feature-creep,” but, for the time being, I’m having fun.

As a final note, Shaw has created a site called Learn Code the Hard Way, as a follow up to the success of the Python book. As far as I know, only the Python and Ruby versions are complete; he’s working on a handful more and is now offering online courses. I’m curious to see how his teaching endeavors will develop. But, for the time being, back to the Python mines.

Wherever man adheres to being something or doing something, there his roots remain in the human, and out of his roots he can become whole, and in whatever he engages himself, in knowledge or in the word, in beauty or in joy, in death or in eternal honor, he can be saved through himself and can himself establish his life. But where man adheres to the illusion of possessing something, there he tears up his roots out of the human; they no longer draw up healing to him from out of the human earth, and I know no help for him.


— Martin Buber (after Rabbi Nachman of Bratzlav), “The Master of Prayer”

I dream of becoming a homesteader. I’m not very close to that – yet – as far as I know – but I still like thinking about it. Before I even begin writing about how to make that happen, I want to record my thoughts on why it’s important. Here’s the first I’ve come up with.

1. We must spend so much time taking care of our homes, vehicles, gardens, tools, electronics and toys anyway.

We spend a lot of time, work and energy taking care of our things – and it’s horribly draining. Why not channel all this effort into a means of living? It would do two things: first, it would lessen the pressure for us to find work in order to live; second, it would take an amount of work we already find ourselves engaged in and make it infinitely more meaningful. Doing work that you know is not returning very much value is draining. Good work makes you feel good. In my experience, it makes me feel stronger, more solid; where doing what I consider to be pointless toil leaves me feeling empty, weak, empty, devoid of substance.  I find myself less solid than the world around me, less able to stand up to it and do what needs to get done.

So there would be a very definite and direct kind of fulfillment, to gradually shift to providing directly for myself, without the intermediary of an economy.

I’m currently reading Dover Press’s printing of an old collection of Gandhi’s newspapers articles. It’s titled “Non-violent Resistance (Satyagraha)”, and you can find it here.

Anyway, rather than treat this as a book review, I thought I’d periodically share my notes on what I’m learning from the book.

I began reading the book largely because of the Occupy Wall Street Protests. I wanted to learn for myself, from a respected practitioner, what non-violent protests are truly supposed to be about. Granted that, until I finish the book, the contents of these notes are not to be taken as any kind of prescription for modern times. I am merely going to set down ideas that strike me as being particularly insightful or essential. It will be equal parts for my own personal clarification and memory and to share with all of you out there. So I begin.

0. Satyagraha means “grasping the truth.” Taking this as symbolic for all of Gandhi’s teachings on non-violence, it means the focus is not on attacking or disrupting the unjust directly but on holding on to what is true. It is something positive, rather than negative.

1. Gandhi does not advocate non-violence in all situations. In what I have read so far, he insists that using violence for political gains is ineffective and unjust. He explicitly writes that using violence for self-defense in emergency situations (he describes an assassination attempt) is perfectly acceptable. I have not read his opinion on war; my assumption is that he is against it.

2. Gandhi makes a distinction between non-violent protest and passive-resistance. He believes that passive-resistance refers to concession; to being non-violent because any attempt at violence would be defeated. He considers this to be participating in the violence by fearing it. He conceives of non-violent protest as something active – something planned and executed to gain something; not as a means of avoiding the offending party’s violence.

3. Everywhere is the word discipline. Discipline, discipline, discipline. He writes that actions of non-violent resistance that are not grounded in strict discipline and disorganization are mere criminal acts. He believes that non-payment of taxes is, theoretically, an acceptable and helpful tool in resisting an unjust government, but at one point he dissuades people from using it, because he does not feel that the people of India are sufficiently trained in the discipline of non-violence to not join it too easily.  He rather urges political leaders to spend more time planning and training their people than to rush into actions with severe consequences.

4. Non-violence must be total and completely thorough to be effective. Violence is not just physical violence, but also hateful speech, implicit participation in power structures that support violence or injustice, and any kind of punitive behavior. On the latter: he points out that staging boycotts against one party (e.g., the British Empire) is punitive rather than productive and therefore has no part in non-violent protest. Simply to reject is harmful. One must take up residence in what is true and helpful for one’s self. The protest, the resistance, is the rejection of any attempt to deny them that.

5. The most obviously “non-violent” part of non-violent resistance has to do with police action. Gandhi insists that non-violent protesters must not resist or complain about police action, arrest or imprisonment. It is a much bolder statement to willingly and cordially go to prison as the result of not-participating in unjust circumstances than it is to complain about the police. This could mean accepting injury and death as a consequence.

6. Gandhi says a non-violent protester must be willing to sacrifice his or her life for the cause.

7. Over and over gain, Gandhi writes that government is not anything bad in itself; it is only bad when it acts unjustly. To me, this portrays government more than ever as a machine that must be made to serve its people – not as a fundamental bugbear or source of strife. Part of keeping the machine running well is making sure that the people could live without it – at least for a short while – if they needed it. It would be good to think of it as an essential convenience in human life – a simple machine like a hammer, a wheel, a rope. Though you could live without one if, somehow, it became too much of a problem for you – it would probably be very stressful to do so for a long time.

That’ll be it for now. More to come.

I’ve been experimenting with all kinds of life_hack, GTD, workflow things since earlier this year. It’s been an ongoing process, as I’ve tried different methods, read various articles (and one book) on the subject, and experimented with different programs and apps. I’d like to begin sharing my experiences with others in an attempt to track my progress, learn from my mistakes and add to the general body of knowledge on the subject.

Today I attempted task batching. It’s a pretty common phrase – you can google it and bring up any number of articles. It means doing tasks of a similar type in one group or ‘batch.’ I have more advanced systems for long-term projects, but for my daily ToDo list, I use a piece of scrap paper and a pen. I generally write tasks out in a logical, chronological sequence, which I generally follow. But I allow myself to pick and choose, and now and then.

Once the idea of batching entered my mind, I began to realize how wasteful it is to change gears. It seems to be a natural fact: doing work makes me want to do work; relaxing makes me want to relax. There is a lot of wriggle room in these behavioral shackles of cause-and-effect – enough to make you think otherwise, in fact – but the fact remains that there is always a little tug. My theory is: maybe it’s all the little tugs that build up into massive resistance later on. Maybe switching between different types of tasks costs a lot more energy than I realize and lowers my sense of flow.

So I wrote up a list last night, before bed. It looked like this [comments in brackets]s:

-eat fish [a small breakfast]

-start making stock [a cooking project for the day]

-2 lessons python studies

-15 minutes of linux command reviews

-2 vim training lessons

-sit zazen

-do kettlebell exercises

-do yoga

-go running

-eat breakfast

-read 40 pages of ‘Twilight in Italy’

-basic cleaning [a group of little chores I do everyday as the bare minimum maintenance]

-process daily workflow [a topic unto itself. I use]


-write a private blog entry [a different blog I use for more journal-like posts]

-write a wordpress article [self-referential]

So here are some notes about how this went down:

What Worked Well:

Batching all my physical exercises together felt really natural. Doing all the floor exercises before running sent me out there with a lot of relaxed energy. Perfect. Sitting zazen at the beginning helped put me in a focused frame of mind, as well. I’m going to at least keep this task batch in my repertoire, if nothing else.

Batching in the morning gives me a very good feeling in the afternoon. I have not completed my list (and I probably won’t get everything done), but I feel like I spent the day with a lot of focus. I’m definitely going to be doing this again.

That being said, there were some problems and mistakes:

Problem: I woke up about an hour later than I planned [it was the snooze alarm that did me in]. Though this was an extreme example (I usually get up about 20 minutes after the alarm goes off), it’s something I need to work on.

Possible Solution: Keep alarm clock away from the bed. Sleep better [I have a few techniques up my sleeve.]

Problem: My vim training website was down when I was ready to begin my practice. I hesitated for a few moments before moving on to the next thing, which was, unfortunately, in the next batch of tasks.

Possible Solution: Though it’s a bad idea to let the batches get mixed up, I think a little leniency is definitely in order. It would be better to make a quick decision and just move on to the next thing, rather than spend any time hesitating. It’s not ideal, but it’s the most acceptable stop-gap.

Problem: My vim training lesson (whose website began working again after zazen), was structured in a confusing way that forced me to figure out how to navigate certain websites and certain directories in my system folder in order to complete it. Although this was educational in itself, it took up way more time that I had planned.

Possible Solution: Take a little more time to A. Set time limits on possibly open-ended tasks and B. Pay attention to any materials I might be using to make sure they fit within those parameters. Also, getting frustrated by this took some time. Once again, it would have been better to simply continue, rather than worry about the flow being disrupted.

Problem: Some tasks involved going outside – where I might get waylaid by neighbors who, thankfully, like me and want to talk to me, but who might take up time. Feeling uncomfortable about this prevented me from doing my outside chores for a while.

Possible Solution: I’m noticing a theme, where, in retrospect, allowing the interruption to happen is always a better decision than trying to prevent it. Though it might take some deeper work into how I relate to people, I think it would be very simple to just remind myself to do what I need to do and talk to the people I like, not look at myself as I total machine. It’s the anxiety and fogginess in my mind that eats up my time, not valuable time spent with friends. I can always clearly and kindly say that I’m busy, if I want to. It doesn’t have to be a big deal.

Problem: This list takes up most of my day.

Possible Solution: Another problem I really just need to not worry about. It’s better in the long run if I try batching and see if it works. Organizing my time this way puts everything I plan to do in the clearest perspective possible; if I get better at doing things this way, I’ll be all the more clearer about what to keep and what not to.

So I feel pretty good about this. I probably won’t have time to complete a full load of task batching until the new year, but I’m excited about trying it again: this could possibly be the most productive I’ve felt since I began studying all of this time management stuff. Go batching.

(Note: this review refers to the Second Edition of the book.)

Last July I decided to study computing in earnest, and I wanted to find a good textbook to serve as a good, solid introduction to the fundamentals of the science. But I wanted to also learn some practical skills while learning more abstract concepts. Google searches on the subject led me to the blog Programming Zen, whose author wrote an article about how to get into computing. He said that beginners should make their entry with the Python language, and that John Zelle’s book, Python Programming: An Introduction to Computer Science, was the best way to start.

I looked it up on amazon, read reader reviews, looked at a few pages and, after careful deliberation, decided it was a good choice. So I ordered it and began working through it. I’ve just finished it now, having taken a large, nearly two-month break in the middle. Accounting for that, I completed the text and its exercises in about 10 weeks, with considerable time spent (often more than 4 hours per day).

I’ve put a lot of time and effort into working through the course of the book, and so I have a lot of strong feelings about the book. There is a lot that is, frankly, quite brilliant and well done. Some things not so much, but, even then, there are some qualifications. In the end, I’d say it’s a wonderful production. It feels strange saying that, after all the frustration I’ve experienced at the hands of the text, but, a few days past it, I can really see how valuable it was. It really shines in comparison to other textbooks that I have gotten know since finishing Zelle’s.

But let’s get into the details, shall we?

1. The Name

Let’s get this out of the way. The name is problematic. Zelle states clearly in his introduction that this is not a book about Python; rather, it’s an introduction to basic concepts in computing, serving as an introductory course to computer science – using Python as an excellent way to start. Zelle is essentially using the fluidity of Python as a playground or laboratory for the archetypal, essential elements of programming he really wants to teach. In the process, you do learn a bit about Python. Enough to make significantly complicated, useful programs, in fact. But that’s almost a side effect of the actual stated goal of the book, which is to impart a deeper understanding of computing concepts. In the end, this focus on core programming concepts makes the book actually very helpful in learning how to program in all languages, including Python. Just in an immediate, “master this in 3 days” kind of way. But that’s not a very valuable way to learn anything anyway.

So I’m left calling the name problematic, instead of outright misleading. Also, you’ll notice that the blog post that led me to the book insisted this was a good way to learn Python, and I’m not criticising that statement, either. It’s a little bit of a gray area: I can see some people saying that, no, this book does not in fact teach Python. And they would be right from a technical standpoint. I happen to be someone who values core concepts and looks at them as an essential part to studying anything I truly wish to understand, so I tend to look at what Zelle is doing here as learning how to program. It’s not quite as direct as other methods, but I think it goes far deeper.

2. Structure and Topics

The thirteen chapters of the book essentially divide into three sections. The first 8 chapters, plus chapter 11, are about basic elements of computer programming: expressions, variables, functions, arrays, strings and string methods, loops and the like. Chapters 9, 10 and 12 focus on design, starting with simple simulations and moving to more complex programs and introducing object oriented design. Chapter 13 is about Algorithm Design, including recursion, and, as such, is the only chapter exclusively devoted to concepts of computer science. Sure, the rest of the book is tempered by a perspective of computer science, but the last chapter is the only one featuring any CS “meat.”

This also presents a problem in defining the scope of the book. When talking about the name, I pointed out how this is supposed to be a book about computer science that uses Python programming as a method to that end. Really, the book is getting you up to speed on programming as an art and science, rather than discussing computer science directly. That doesn’t disqualify it as a computer science textbook, but it makes the focus of the book seem even less clear.

This seems to open up another gray area, as the title did. Is a book really about computer science if it spends most of its text discussing the art of computer programming? Barely. But does spending so much time on design make it a good introduction to the science? There is no better way to introduce a science than
to lead your student to direct experience in the environment that the science works with. As I will explain in the next section, this book will provide you with hundreds of hours worth of practice experience. Practical experience is really the best route to understanding, that is, a full grasp of the concept, as opposed to knowledge.

Many tech authors decide that the best way to teach everything is to, well, teach everything. Their books become massive, monolithic braindumps that provide thorough documentation on their subject, but very little in the way of imparting wisdom or understanding. Zelle excels in this latter method, making his book a true guidebook. A nice contrast from some of the other choices available.

3. Exercises

Wow. Massive. And subtly so: the actual quantity of exercises is not that incredible. But pay close attention (and you will, if you’re trying to go through all of them), and you’ll see that many of these projects are full-scale projects. The book was intended to be a classroom textbook, so perhaps the exercise sections were designed to be picked through by an instructor, shortening the time to complete them. I read this book for self-study, however, and I soon found that the 4 hours per day I had given myself for practicing Python was not enough to complete both the chapter reading and the exercises; then it became a matter of only getting a few exercises done per day; then it got to the point where I was taking multiple days to complete one project. Toward the end, I had entered into an Ahab-like state of obsession, putting all of myself into finishing all of the exercises and coming up with something good at the end. I finished, and it was a spectacular feeling.

Now, that’s just good education. When a teacher gets you to put so much effort into something that it becomes an intense point of focus like that, he’s really throwing you into the task. For a few days at the end, my life was coding. I got to feel what it was like to commit myself to coding. This also ending up being one of those experiences, where I gain insight into myself and how I do work.

Of course, I don’t think that this intense kind of experience was Zelle’s intention – at least not directly. What I credit him for is setting me, the reader, up with a swan dive into the material. This is an excellent balance and a good model for other textbook writers: though the pace of the text is slow, steady and thorough, the exercises can be fierce enough to really challenge you and get you to a high level of real understanding.

Here are some examples of exercises I liked: everything in chapter 4, which introduces graphical concepts at a relatively early stage for a textbook, having you design programs that draw faces and houses at the click of the mouse, for example; the decoding exercises from chapter 5; the bouncing ball animation from chapter 7 (exercise 17); the greyscale conversion (exercise 14) and photo negative (exercise 15) programs from chapter 8; most of chapters 9, 10 and 12 were fun. The end of chapter 12 is really a list of massive projects, where you’re asked to create games that simulate dice, card and board games. Chapter 13 had you working out some pretty funky algorithms, but, in the end, it was too short a treatment of the subject for your projects to get all that advanced. Though it is nice to come away with a script that solves the weekly jumble.

I’d also like to point out that all the exercises are fair. I’ve looked at a few tech texts so far that pull what I would consider a rookie mistake: carelessly creating exercise lists that, while they have to do with the topic at hand, rely on understanding concepts that weren’t directly discussed in the lesson. While this might seem like a small error – I find that for me, and other people I’ve observed, this can be a huge break in the “flow” of the text that throws off the learning experience. I’ll leave it at that, though, just to say that Zelle does not make this mistake.

I want to note that there was a single exercise I didn’t complete. This was chapter 12, exercise 6, which asks you to learn the rules of contract bridge and write a program that sets up the first hand. I’m sorry, I’m not going to spend my programming time learning how to play a game I have no interest in. I know, as a coder I might be tasked in dealing with things I’m not interested in. I’d be glad to. For money.

Not to end this section on a low note, but I must mention the “Review Questions” that come at the end of each chapter, before the exercises. The discussion questions were great – but I wish there had been a lot more of them and that they were more challenging. The true/false and multiple choice exercises were so short and easy they might just as well have not been included. Some drill-like exercises would have been nice in their stead.

4. Conclusion

This was a fantastic read. A true education in the subject, any gray areas its confusing title and structure might evoke for you are really insignificant compared to the insight into programming you are going to come away with. The text is 100% ideal for absolute beginners. I would call myself an advanced beginner – someone who programmed a lot as a kid, but who is just getting back to it after a decade or two – and the level of the text was still excellent for me. There was a lot of review, but it was very constructive – I feel I have a firm grasp on these concepts now. This book is not for more advanced programmers – but they’re not going to be reading any introductions to computer science any time soon. An intermediate programmer wouldn’t get anything out of the lessons earlier, but someone who is short of complete mastery of the subject, I think, will still be able to enjoy the exercises. The easy ones won’t take much time at all – but the later ones make a nice challenge.

This one is going to stay on my shelf a while – if not for myself, then to pass on to other beginners as a strongly recommended introduction.

I am currently working toward a more solid workflow design in my life, that is, a way to manage all of my projects and get myself ready to begin working and studying again. Although the blog is temporarily suffering from that, this blog is actually part of that plan, and I will be getting back to it in due time.

My current goal is to finish a workflow design according to David Allen’s Getting Things Done program. I’m most of the way finished with the book (which, sadly, I started in August), but I am taking a very long time going through every single one of my possessions, including computer files, to make sure there is a place for everything. Naturally, this is taking a lot of time and energy, but I am pushing to complete it as soon as possible, so I should be ready to move on to something else before long.