So I wrote a book

I’ve been pretty quiet on the old blog front as of late. This is largely attributable to me being busy with other things. The most interesting of which, in my mind, is that I wrote a book .  It isn’t a very long book and it isn’t a very exciting book but I’m still proud of having written the little guy. This post is less about the book itself and more about what it was like to write a book.

First off it is a lot of work. Far more work than I was originally expecting. I’ve written lengthy things before, most notably about 100 pages during my masters. This was different because I didn’t feel like I knew the content as well as I did for the masters paper. Having restrictions on the length of the chapters was the most difficult part. Due to some confusion about the margins for a page I started by writing the equivalent of 15 pages for a 10 page chapter. I did this for 4 chapters before my editor caught it. I agreed to cut the content down and get back on track in accordance with the outline.

This was a mistake. It was really hard to cut content to that degree. A few words here or there was easy enough but what amounted to a third of the chapter content? Tough. Later in the project I realized that keeping within the outline pages was not nearly as important as I had been lead to believe. After throwing the limits out the window the writing process became much easier.

In order to treat writing a book with the same agile approach one might use for developing software it seems crucial to not involve page counts at all. A page count is a poor metric and I have no idea why one would optimize for it. Obviously there should be some rough guidelines for the whole thing you don’t want to end up with a 1000 page book when you only set out to write 200 nor do you want 200 pages when you set out to write 1000. But writing to within 50% of the target length is reasonable.

To put too much emphasis on length is to lose sight of the goals of the book. These are much more along the lines of education or entertainment or something like that. The goal isn’t to kill X trees.

Are books still relevant?

Umm, <mumble> <mumble>. I don’t know to be honest. I don’t read many programming books these days, I spend my time reading blogs and tutorials instead. I think there is still a space for paper form technical books even in a fast moving world like computer programming. There is certainly a place for books about techniques or styles or about the craft of programming in general. I have some well thumbed copies of Code Complete and The Pragmatic Programmer and even Clean Code. I do not, however, think there is a place for technology specific paper books. That target moves too quickly.

The long form technical document is not dead it just needs to remain spry. If you’re going to publish a longer book style document then publishing it in a form which can be changed and updated easily is key. This is where wikis and services like leanpub come into their own. As an author you need to keep updating the book or open it to a community which will do updates for you.

Would I do it again?

Not at the moment. Not through a traditional publisher. Not on my own.

I’ve had enough of writing books for now. I’m going to take a break from that, likely a long break. I might come back to it in a year or two but no sooner. I think I can understand why authors frequently have long breaks between their books. It is an exhausting slog, a death march really.

There was nothing wrong, per say, with Packt publishing. They did pretty good work and I liked my editor or editors or many many editors… I’m not sure how many edits we had on some chapters. Frequently it would be edited by person X and then those edits reversed by person Y. There didn’t seem to be an overall guiding hand which was responsible for ensuring a quality product. Good editing has to be the selling feature for publishers, the way they attract both authors and purchasers. It is the only thing which sets them apart from self publishers.

Self publishing and micro-printing is coming into its own now. By micro-printing I mean being able to produce small runs of books economically rather than printing in very small text. If I were to do it again I would take this route. I would also hire a top notch editor who would stay with the project the whole time, somebody like @SocksOnBackward(she would tell me that top notch should be top-notch).

I would also like to work with somebody. Writing alone is difficult because there is nobody off of whom you can bounce ideas. I certainly could have reached out to random people I know in the community but it is a lot to ask of them. I would be much happier having somebody who could share the whole endeavour with me.

I guess watch this spot to see if I end up writing another book.

GeoGuessr as an Interview Question

Today somebody (it might have been an xkcd comic) pointed me to the addictive game GeoGuessr. I didn’t link it because if you click on it you’ll never come back to finish reading this blog post. The idea of the game is that they drop you into street view somewhere on the planet and you have to guess where you are. The closer you are to being right the more points you get. It is a very simple concept for a game but at the same time real good fun. I was playing it when somebody came into my office and asked about it. We spent 5 minutes dissecting a series of photos using logic and best guesses to figure out where we were. The whole exercise got me thinking about how I’m going to use this game as an interview tool the next time I interview somebody.

What?

Stay with me on this one. One of the more popular interview techniques for tech companies is to present a puzzle and have people solve it. A lot of people look down on puzzle interviews because it is such a gotcha style of interview. If you’ve seen the puzzle before or you guess the trick then you can get it quickly and you win the interview. I don’t mind puzzle interview questions. It isn’t because I think being able to figure out the puzzle is important it is because it gives me some insight into how well the interviewee will approach a problem. We’ve all worked with that developer who gives up in the face of a difficult problem. Throwing ideas against the wall and seeing what sticks is a hallmark of good programming problem solving. I don’t expect people to have the answers to difficult problems right away but I do expect them to puzzle out the problem.

I think that playing a round or two of GeoGuessr (I linked it there because you got this far and deserve a reward) during the interview would allow for a quick evaluation of how the programmer thinks. Just have them puzzle out loud or play with their potential team mates. In the brief time I played with somebody we said things like

“Well look, they’re driving on the left side of the road so that eliminates a lot of places. The language on the signs seems to be English.  So UK, South Africa or Australia. Seems pretty arid, perhaps Australia?”

and

“Right, there is a truck. A dodge truck so North America is pretty much for sure. There is a highway marker for an in-state highway 45. So we know US for sure. I bet most states have a highway 45, it is a good number 45. No mountains so that cuts out a few places. There is a train, looks like it has grain cars – a lot of grain cars. Bread basket somewhere? Hey, hey look! A sign for interstate 69. Google it! It goes North/South through Arkansas and Kentucky. Let’s try Kentucky.”

This demonstrates that we’re working though a difficult problem and that we’re doing it as a team. Also this sort of thing is a great ice breaker during an interview. If you try this out before me drop me a line and let me know how it works.