small medium large xlarge

21 Dec 2010, 05:26
Larry Jones (89 posts)

As I was writing tonight, I began wondering, “Am I drifting too far afield from my original concept?”

When I began writing, I had an idea of how I wanted to approach my topic. As I considered how I have actually spent my time “words,” I have not spent them in the direction I originally envisioned.

Although I am pleased with my progress (the number of words I write each night), I wonder if it is more “pragmatic” to: - Re-write my current “chapter” in my originally direction - Press on since I’d like to get a proposal submitted (similar to persevering in your major when you decide, as a senior, you really don’t want to pursue this degree) - Spawn a “branch” of my current “chapter” in my original direction (preferred direction to be decided later)


21 Dec 2010, 14:23
Raymond Yee (47 posts)

If, for the moment, you didn’t have to worry about the effort required to write up your “original concept” vs the direction you ended up going, which concept do you prefer? Can you give us more specific details?

22 Dec 2010, 02:57
Larry Jones (89 posts)

Thanks for the questions, Raymond.

I had originally planned to focus on the use of the IPython shell for exploratory development. (I used this shell when I originally developed some of the ideas I plan to develop in the book.) However, other posts reminded me of the need for unit testing. So I began adding unit tests and explaining the details of the “red/green/refactor” cycle in development process.

As a consequence, I’ve written many words illustrating how the red/green/refactor cycle works and how to use its feedback to diagnose issues and to improve your code. Although I’ve read about the cycle, I’ve seen few examples about actually applying this cycle in development.

I’m not certain which I prefer. The focus on the red/green/refactor cycle seems more mainstream - but may be covered elsewhere. Emphasizing exploratory development within the interpreter is something that many authors hint at, but few seem to illustrate effective ways to practice it. Since many languages now are offering an interpreter, I thought this approach would be more unique in the marketplace.

Confusing enough?

22 Dec 2010, 16:57
Raymond Yee (47 posts)


Are you planning to submit a proposal to PragPro? If so, Susannah might be open to some preliminary discussions about what are promising topics. I think it might be easy for her to tell you whether a given topic is promising enough to proceed before putting too much effort.

My guess is that a book on using IPython for exploratory development might be too narrow of a topic for a book and the audience is too small, and there might be more interest in “red/green/refactor” unit testing (which I don’t know anything about). A key question is assessing the size of a potential audience.

But a core question is also what you want to write about. It won’t be easy to put a lot of energy and time into a topic that you don’t care about either.

Hope this helps, -Raymond

23 Dec 2010, 04:47
Travis Swicegood (117 posts)

Hey Larry;

I agree with Raymond here. My hunch is that iPython as an exploratory tool might be too laser focused, but what about a book on iPython? There’s so much about it. I just saw a presentation at the Austin Python User’s Group this past month on using it in an HPC environment for massively parallel computing in the medical field. I had no clue iPython had that under the hood. All of the things you can do with it are pretty amazing.

As far as what direction to head, go with where the writing seems to be. This latest book is the first one where I’ve written it and its turned out sorta kinda where I envisioned it. The first two were a bit all over the place as I figured out where they were going. Sections got changed and rearranged; some chapters got yanked, others repurposed. Don’t be afraid to experiment. If you’re afraid you’re chasing rabbits down holes where they have stop watches and queens wear clothing with card suites on them, time box yourself. Give yourself two or three days to see where it goes. That’s the beauty of version control, if you don’t like it, revert out the changes and they’re always there if you need to go back to them. You are using version control… right?

On an interesting side note, I read this article the other day on the creative process and tools like version control. For most of us in this forum, it probably borders on hilarious the novelty that the author treats version control, but sometimes we have blinders and forget that the common place for us is still the esoteric for others. Something we should keep in mind when writing books too. :-)


28 Dec 2010, 05:35
Larry Jones (89 posts)


Thanks for the note.

I am planning to submit a proposal to Pragmatic Programmers. Talking to Susannah is a great idea.

I do not think I effectively communicated my topic. Although I had thought about using IPython, it is a technology that provides effective feedback. You have an idea of how something does or ought to work. Although you can begin by writing production style code, the feedback telling you if you are right is a long way off. (Unit testing helps, but changes feedback from seconds to minutes.) Interactive experimenting - like we did when we were kids trying to figure out “how this works” - is great way for feedback in seconds. And IPython provides an environment supporting that “learn by doing” skill we learned as children.

Thinking of potential audience size is a great idea. My problem is finding a balance. Trying to talk to all developers targets a very large audience, but this can result in either a very large book or a book that doesn’t say enough to an “expert.” I would say my target audience is # Developers # Who want to try unit testing # But who want to limit the risk of spending too much time writing unit tests So I help them to focus on effective testing by using feedback.

Sorry for the rambling response, but I’m still learning myself.

28 Dec 2010, 05:51
Larry Jones (89 posts)


Thanks for the good ideas. I like the idea of a book on IPython. I think it has hidden potential that Erlang programmers would say is obvious but Python programmers, especially those, like myself, coming from a C/C++/Java/C# background and day job, miss. As I mentioned in my reply to Raymond, it supports a “tinkering” approach to software which is very different from the business “mainstream”, but which, I think, succeeds better when one is just “trying things out.” Although I used IPython to support this style of programming, I’ve been away from it for awhile, and I was very pleasantly surprised at the changes (and breadth of features) when I downloaded the latest version. I have much more work to do to catch up, but I think it might be worthwhile for my second book. (Aren’t I Pollyannish today?)

Thanks for the advice on “going where the writing is heading.” This advice is similar to the idea of feedback that I plan to explore in this book. I think I’ll be able to incorporate both unit test feedback (once a person “knows” what they are doing) and IPython (when how things actually work is still unclear). And the idea of a two- or three-day time box is great for avoiding rabbit holes!

Finally, I am using version control. Over twelve years ago, I looked at my “home projects” and said to myself, “I use version control at work. Why don’t I use at it home?” I began with CVS, but have since used SVN, Git and Mercurial (Hg). As I’m sure someone before me has said, “Source control means never having to say your sorry” (with apologies to Erich Segal).

You must be logged in to comment