Photo: Iman Moradi

Every few weeks I seem to see clusters of discussions about "young people" and technology. Typically, it starts off as I notice someone doing a news story or just spouting off in a restaurant about how amazing it is that "kids today" are growing up with computers/cellphones/iPods and how amazed they are by how adept and sophisticated they are in using those devices.

Nearly always, within 1-2 days, I see another article or just happen to see an incident that points to just how wrong that generalization is. From computers ripe with thousands of viruses and bits of spyware to reports of college professors citing how poorly students grasp the very concept of citing sources and the simple basics of research, examples seem to point to a much more complicated picture.

It's clear to me that there seems to be a segment inside EVERY age group that seems to just "get" technology. Many of the sharpest technologists I know are in their 50's or 60's and some of the most clueless are 16-25. Of course, the plural of anecdote isn't data, but there certainly seems to be enough indication that the full spectrum from tech novice to tech genius exists in nearly all of the age brackets.

One of the criticisms leveled at the non-savvy portion of the younger brackets is how often they will pretty much stop at the first level of Wikipedia when researching a topic. It's so common that many colleges and Universities have had to put actual bans on citing Wikipedia in academic papers.

Given that I was told that the encyclopedia stopped being a valid primary source at some time in 8th grade, this troubles me like it does many others. Wikipedia and Google are starting points for exploring or researching a topic.

I've mentioned before how often I've been asked how/why I know something. That's been followed more than a few times by people asking how I manage to learn as much as I do about the topics that sparked the discussion in the first place.

As I recently used my "normal" process just recently on a topic, I took note of how I dig into a topic and I thought I'd share. This isn't an approach to writing a formal paper/thesis/dissertation. Rather, it's an approach to to satisfying curiosity, getting acquainted with a topic, and getting a dedicated hobbiest level of knowledge in a given topic.

Read the rest of this entry »

Photo: guldfisken

Yesterday, I was listening to Dave Slusher talk about his incredulity at people wondering how he'd fill 50 years without a "job". He, like me, has such a long list of books he'd like to read.

I'm guessing that he, like me, finds the very idea of being "bored" or having "nothing" to do completely foreign.

At any rate, I felt prompted to take inventory of the books I've got lying around that I haven't read yet.

So, last night, I tried to tidy up my office bookshelves and group together the books that I haven't read yet, those that I want to revisit, etc. In doing so, I noticed some distinct patterns in the type of books that I'm drawn to.

They tend to be the kind of books that let me exercise my generalist/liberal arts orientation by tapping into a wide variety of fields. They're mostly non-fiction (about 7 or 8:1) and many are scientific or philosophical. They are, however, the kind of book that is written for people outside of the field to grok.

Jason Kottke recently called them "science and idea books", which is a category I think I like better than what I've heard the publishing industry call them: popular science. I like them because they tend to fire WAY more of those synapses in my brain that make connections between things.

When I read these books, I tend to feel those sparks of insight flashing back and forth in ways that much of the online equivalent doesn't cause. I'm not sure if it's just the longer form, the context in which I read them or the form factor that contributes to that.

However, I don't really care as the effect is obvious to me after years of self-observation.

Kottke's post linked to a nice list of the best of these kinds of books that includes some intriguing title.s

I really like the end of the year for producing lists like this. They serve a handy purpose in aggregating and filtering the total list of books published in a year into a manageable list that lets me read really good books without spending a lot of time finding them.

What was disappointing was that the list itself only included the titles and authors. I didn't want to have to click each title in turn and look at them all individually.

Fortunately (at least for this particular problem), I've spent the last 2 months DEEP in the bowels of the Amazon E-Commerce API and knew that I could quickly spit out a better copy of the list.

Sure enough, it just took a quick bit of C# and I had a much better format. I uploaded a PDF of my exported list, including the editorial reviews and New/Used pricing so I can look over the whole list much more easily than looking up each of the books. You can download it too if you want. The PDF itself was generated using the techniques I mentioned earlier this week.

Photo: lui

[[FYI, this has been sitting in my writing queue for a while. I took a quick look at it and am shoving it out the door. Let me know if it's deficient and I'll fix it. Consider this version 1.0 of the article.]]

Ever since I spent my time in the technical writing trenches right out of college, I've been interested in doing my writing in a single format, generating whatever target formats from that.

At different points over the ensuing years, I've been drawn to Docbook as that single format. It's SGML/XML, first of all, which makes it relatively easy to write in a text editor. It uses XSLT to transform to other formats. It has pre-built toolchains for outputting HTML, PDF, etc. Also, it is easily versioned using Subversion.

As an additional vote of confidence for using Docbook is the fact that O'Reilly has been using it for many of their recent books. They're actually also storing their content in an Atom Publishing Protocol repository. That's another vote for where my intuition about a personal publishing stack has been leading. When written content is stored in a robust container (DocBook or Atom, etc.), you can repurpose it.

Technical documentation doesn't always work in every format (which is why many of the single source experiments in that space failed). However, for things that *do* work in multiple formats, the technology for producing those formats gets in the way. Not so with DocBook.

Now, while I've looked into it at several different points, I've never really dug into it well enough to get much done with it. I set out over the last couple of weeks to actually get completely up and running with Docbook. This time I powered through and got it working. I suspect that the motivations were more concrete this time

Along the way, I discovered that there wasn't a tutorial that matched what I was looking for. I also found tutorials that had non-functional code. However, despite that, I was able to get a basic Docbook book up and running and figured out a much simpler way to get started with Docbook, so I figured I'd share.
Read the rest of this entry »

For the past few years, I've been making a concerted effort to question my own assumptions and the assumptions that our culture makes and presents to me. In so many places in life, when you directly examine the "conventional wisdom" about a given subject, it just doesn't stand up to scrutiny.

Over the last couple of weeks, this particular theme has been popping up (which is to say that I've just been noticing it where I've been looking) a lot. In many places, we seem to rely on what we *think* is true rather than actually investigating and determining what actually *is* true.

In many cases, this is because the conventional wisdom is something we're attached to. Take for instance, the idea of creativity. This old article on the myths of creativity (linked from Lifehack.org a couple of weeks ago) lists as #3 in their list the idea that creativity thrives under pressure.

I've heard that hundreds of times from all sorts of people, that they just do "better" work when their scrambling at the last minute. Heck, for a long time, I believed this one myself. The thing is that when you actually study creative output, it just isn't true.

Similarly, Marc Andreessen pointed out an analysis of the concept of "brainstorming" as a group. Again, if you analyze it rationally, having everyone in separate rooms coming up with ideas results in not only more ideas, but better ones as well than having everyone in a room.

On this one, I suspect that the "feeling" of brainstorming as a group gives the impression of higher productivity. It's probably also linked to the fact that in most offices, if you ask people to go to their desks and come up with ideas, they usually get bogged down in unrelated work. That doesn't change the facts, though. It just points to needing to handle brainstorming sessions in a more intelligent way.

Have everyone spend half of the meeting spread out coming up with their own ideas and then bringing them all together later. Don't send them back to their desks to get distracted. Just keep them on task, but brainstorming as individuals.

Some other conventional wisdom comes out and becomes pervasive because it's what we want to believe. A recent book, Myths of Innovation looks at one such area. We all (especially the press and blogs) want to believe in the idea of all innovation coming in that garage-in-the-wild-west, burning-the-midnight-oil, eureka-moment version of innovation. The truth is much less sexy. I'm not done reading this book yet, and have only been able to listen to a few minutes of this podcast interview with the author. However, all of it keeps resonating this same chord with me.

I'm definitely digging this trend, even if it's just that I'm finally noticing it. This stuff is striking me the way that Stumbling on Happiness did. It gets me in a mindset to think through my habits and the things that I take for granted. It makes me question my beliefs about practical matters like happiness, creativity, productivity, morality, work, etc. I like that.

It all feeds into the general approach to life that I've been taking lately which is that many of these issues require that you quit relying on the lower/older portions of your brain to make decisions and plan, instead using the top. That's mostly a debate between snap judgments and rationally examining a situation. It's clear to me how much of life comes down to the battle between the top and bottom of my brain.

For years I've been using O'Reilly's Safari service. Most of the books from not just O'Reilly, but lots of other publishers are right there, online. I like it because books tend to address issues in more depth than most quick articles do on the Internet. Yet, being online, I get: full-text search, copy and paste from code samples, etc.

I tend to use Google, MSDN et al when I'm looking for an answer to a specific question. However, when I'm looking to improve my architectural approach or a cohesive look at a technology, I often turn to books. I do buy my fair share of books, but tend to like to get used copies (the whole half price thing works for me). Unfortunately, used book sellers don't always want to coordinate with my deadlines.

Enter Safari. Instead of hoping that the boxy white truck delivers your book before you need to deliver the code, you add it to your Safari bookshelf and get to work. For most of that time, I was on their "10 books at a time" plan. You get up to 10 books on your bookshelf to juggle between. Once you add a book, it stays on the shelf for 30 days.

Most of the time, that was fine. However, as I moved into shorter projects, that became more and more cramped. I was constantly trying to figure out which books to ditch, only to need them 2 weeks later.

Fortunately, I recently discovered that O'Reilly has an unlimited plan (called Safari Library), which is very cool if you do fulltime development. For $40 a month (intro rate), you get ALL of the books in their catalog. Instead of a "bookshelf", you just have "favorites". When combined with their bookmark system and a few PDF downloads of chapters, you've got a pretty comprehensive reference library.

Sure, it's not free, but it runs about what a new book would each month (if you had to go to the brick and mortar store and buy it), and it's instantaneous and flexible. I can now just grab the exact information I need instead of trying to shuffle and plan.

When your week at contains a list of technologies like this: SQLServer 2005 Reporting Services Architecture, ASP.NET SOAP services, MySQL performance tuning, PHP web stats analysis, blending recursive SQLServer datasets of accounting data in C# for embedding into Reporting services and conflicting VPN configurations on wireless connections - and your home project list includes a list like: Linux remote desktop, HTPC configuration, Powershell scripting, building a RESTful blogging engine and client, Mono/C#, setting up a Linux firewall/router, etc. . . . that kind of flexibility and wide range of information is really useful.

Because, sometimes the solution can't just be put into a 2 page article that you find on Digg.