Knowing and No'ing

1 comment:

The delicate art of saying "no" to people when they are looking for technical help, especially at parties.

The thing is, I'm pretty smart. I'm no Einstein but I can hold my own when it comes to math, science, computers and most nerdy things. I have a physics BS from a not-too-shabby school (UC Irvine) and I've been using computers since the Apple IIe first came out. (That's like, 25 years).

It's pretty cool to know all the stuff I know. It's useful. I can Do Stuff.
The thing that gets me down, though, is that when people realize how much I know, then they want my help. Usually they want my help fixing their computer. Now, this is something I used to do 15 years ago. But it is unreasonable for a conversation to turn, as if on a dime, from something fun that we are both enjoying to what basically boils down to getting grilled on all manner of technical matters.

Generally, I like helping people, and I like explaining how things work. But not all the time, and not on demand, and certainly not in the kind of detail that people seem to want, and not at a social event.

One bitter irony is that even if I suck it up and try to answer the question, whatever information I give them will soon be forgotten, and their problem won't actually be fixed. The bottom line is that they are not getting the help that they need, nor am I getting to enjoy myself.

This is something I don't understand. Upon finding out that someone is a hairdresser, do you start asking them for advice about your hair? Or if a person is a lawyer, for advice on a case you're involved in? Or a doctor about your ailments? Why is it then so acceptable, in a social situation, to start asking a programmer about computers?

The bottom line is that it isn't acceptable. If you really want my help with something, you can hire me to fix your problem, and it will get fixed (assuming it's in scope of what I do, which is custom software, not computer repair). I'll even be happy to explain what I did, why, and the technologies behind the solution, much like a good doctor would. But what I will not do is talk about work at a social event to satisfy idle curiosity.

There are two exceptions to this: first, if you are yourself an experienced geek wanting to debate  some esoteric idea, and if I'm in the mood for the discussion, great. Second, if you are not a geek but want to debate about either the philosophy or politics of technology, then that's cool, too. But I do not want to discuss why you can't sign into your AOL account or how your Dell laptop has gotten slower over time and do you have a virus and how do you clean it off and will it require a reformat of the hard-drive.

Publishing an ebook on Amazon - 2010 edition

No comments:
A friend asked me to publish an ebook for him. I agreed.

In initial Google search turned up a lot of (expensive, in terms of wasted time) dead-ends:
  1. Askville - where Steve Weber (who writes books and a blog on self-publishing) tells you you need an ISBN block, a mobi-pocket account, and the mobi-pocket software. circa 2006? NO LONGER ACCURATE
  2. Fonerbooks - where someone very nicely lays out the ISBN landscape, and how to deal with the Bowker monopoly, and the connection to "Books in Print". crica 2005 (but apparently still valid). Bowker reminds me strongly of ARIN!
  3. LighteningSource - which is really a dead-end for me because I don't want print-on-demand.
Could it really be this hard to self-publish?! Not too terribly surprised, but a little disappointed, I set to work following the steps described in #1. Block of 10 ISBNs, $250, check. I dutifully downloaded the (Windows-only) mobi-pocket creator - which looks like it hasn't been touched since Windows 95 was hot stuff.

The manuscript was in a combination of (custom) InDesign and EPS - which I (imperfectly, I'm sure) converted to PDF. I dutifully added some meta data, generated the file, and then tried to publish via the Creator interface. I waited expectantly...

...to find out that mobi-pocket accounts are deprecated, and the entire process has been stream-lined and simplified.

It's called the Amazon Digital Text Platform and you don't need an ISBN (it's optional), you don't need to download conversion software, and you can use your existing Amazon user account. (Granted you have to add some data, like your Social Security number and a mailing address for royalty checks, but still...)

I had to fill out some metadata again, but it only took about 15 minutes to setup the account and upload the PDF of the manuscript. Amazon now says that the book is "in review" and theoretically you'll be able to buy it on Kindle any time now.

[Update: the book is published]

An Application Programmers Appeal

No comments:
My fellow application programmers,

Have you ever noticed how sometimes you learn on the run, slapping together code from working examples, and other times you take your time, really study the technology, savoring it and understanding its complexity? Have you noticed that there are some things which are far more amenable to one than to the other?

What if all learning starts out as "on the run" learning? You pull something into a project to make your life easier, to abstract away something that you don't want to do. You don't want to become an expert. If you can adapt an example its a good sign: you are playing to the libraries strengths, and don't really need to learn much about it for it to be useful. JodaTime might be a good example, or any of the Apache Commons.

Sometimes you pull something in and it works, but it leaves you feeling a little uncomfortable. There's just too much about it that you don't understand. It's a nagging itch that you want to scratch: what exactly is going on in there? Personally, I had this feeling with log4j - a deceptively simple little library with a surprising amount of depth. (And actually I'm still not entirely clear how commons logging, java.util.logging, and log4j all mesh together, even though I'm pretty sure we're talking about like 20 small classes).

Over time there are these "idea" technologies which just don't make sense unless you know the idea behind them. Spring is perhaps the best example of this. Learning the control flow of a Spring app without prior knowledge would be like learning French from a French dictionary. It seems like there are lots of idea tools out there, and more every day. Most of them are NOT amenable to quick uptake.

It would seem like most library authors would enjoy having you become an expert in their library, to become passionate about it, to understand it's delicate intricacies - especially the idea-driven tools. But often this just doesn't happen. Why not? Because when it does it is by persistent necessity rather than inclination. Consider Spring: people learn it because they use it for project after project. It is a persistent feature of the application landscape. It pays to learn it, and to learn it very well. But Sax? Or Java IO? Or Swing? You might need it occasionally, but there's no reason to dig in. Ignoring these libraries is a smart play.

The technology that seems to do the best are those rare gems which are both easy to adopt when you're in a hurry, which are broadly useful across a lot of projects, and which reward the student as they get deeper into it.

These observations drive a few conclusions. First, for an application programmer, be kind to yourself and recognize when you're running and gunning, and when you're taking your time to savor the moment. We will always experience a combination of both modes, and neither mode is better than the other, so don't berate yourself for not taking the time to learn that library better or using it to it's full potential. You didn't have time, and 99% of the other users didn't have time either. Second, for the library author, recognize and embrace those two modes because they are both important. Too often you make it difficult for us to use your libraries, expecting us to know magic incantations (class casts, method chains, constants) to accomplish straight-forward tasks. I have no doubt that the complexity is necessary to handle edge cases: but that's not why I'm using the library! I'm using it for the core case. Give me a utility class and mark it clearly as such (oh boy, nothing slows people down like trying to figure out dueling utility classes, abstractions on top of abstractions done with different idioms within the same project, and finding out that they were just facades over the *real* library). For God's sake use package level JavaDocs liberally to explain how the pieces go together with simple example code, and make some reference to applicable utility class in the lower level classes.

It's not easy being a Java programmer, and it never will be. Our language's expressivity is inherently (and intentionally) limited in the hopes that the compiler and other programmer tools can make our programs more error free. This trade-off between safety and freedom makes it all the more important that our libraries be incredibly well-designed, because we just don't have the linguistic freedom to mold your library to our liking.

Sincerely,
(Java)Josh