I've written quite a few books now, and one questions that I get from time to time is what tools I use to write them. I've developed a pretty nifty tool-chain - at least for my purposes - over the years, so here's my notion of how it all hangs together.

It's only just over a year since I got my first ebook reader. Now I only buy paper books when I really have to. I wrote my last book thinking of it primarily as a paper book, but that will be the last time, in the future electronic forms will be at the front of my mind. These changes will completely alter the landscape of books, but other than that, the next steps aren't that clear.

I've spent a lot of my writing energy writing patterns. From time to time I get asked questions about why I do that and what makes a good pattern. This is a brief article about how I look at patterns with my suggestions for people who are interested in writing patterns themselves.

My IEEE column on the valuable contributions that patterns can make to understanding software design.

For quite a while now, I've been doing most of my writing using XML - even to the point of writing my last book in XML. As I've mentioned this to people they've asked me a number of questions about my experiences, and that's been enough to prompt this little article on the whole thing.

An experienced technical author explores using ChatGPT to assist with a number of writing projects. He finds ChatGPT can provide time-savings through drafts and prompting for additional content, but lacks accuracy and depth - as well as suffering from bubbly optimism. Overall it is useful if you work iteratively, asking for small chunks with well-crafted prompts.

How I use, and render, footnotes

The things I do to make Twitter useful and avoid the time-traps

With the current uncertainty over Twitter, I'm starting to explore using Mastodon

One of the frustrations of the software development field it's hard to choose between different techniques and tools. Often when someone talks about this they are asked for 'hard data' that the technique or tool is better than alternatives. It's an understandable request, but in the end it's a doomed one. For a start we CannotMeasureProductivity.

Andrew Koenig first coined the term “antipattern” in an article in JOOP, which is sadly not available on the internet. The essential idea (as I remember it ) was that an antipattern was something that seems like a good idea when you begin, but leads you into trouble. Since then the term has often been used just to indicate any bad idea, but I think the original focus is more useful.

Every so often I get someone who not just disagrees with something I've said, but is also alarmed that I've said it. “When a guru like you says something, lots of people will blindly do exactly what you say”.

Making and editing video used to be an expensive exercise, but now cameras and editing software are cheap. As a result many loud-mouths like me have got into making videos to help spread their ideas. There's many reasons to do this, it's a medium with lots of possibilities, it suits people like me who talk well on stage, and there's good evidence that people will pay for video - which is good both for one's income and as evidence that people take it seriously. Despite these reasons, so far I've not taken the plunge.

I don't not write much production code these days, but I still spend quite a few hours writing code. This code is a particular form of code, meant for explaining ideas in books. Book code isn't quite like real code, there are some different forces to consider when writing it.

I write about design, and it's my view that even when you are discussing somewhat abstract design patterns it's useful to provide source code examples. Of course this can lead to people thinking that the code example is the pattern, but I think that risk is outweighed by the precision that code provides. Several times I'm not quite sure about an idea but a code example helps to clarify it for me. So in my writing on design I always try to provide code examples.

One of the most striking things about the Manifesto for Agile Software Development is the format of its values “we favor x over y“. I don't remember who came up with that idea, or how it arose. It probably just bubbled up as we tossed around ideas. But it's distinctive format has led a few people to try using that format again.

Last week I got the newest book in my signature series: xUnit Test Patterns by Gerard Meszaros. I've been working with Gerard with it on and off for a couple of years, so I'm fairly familiar with its contents, but somehow seeing the physical copy gave me quite a shock. Somehow it hadn't dawned on me how big the book was - 883 pages, easily the biggest book in my series.

When I was starting out on my writing career, I began with writing articles for technical magazines. Now, when I write article length pieces, they are all written for the web. Paper magazines still exist, but they are a shrinking minority, probably doomed to extinction. Yet despite the withering of paper magazines, many of the assumptions of paper magazines still exact a hold on writers and publishers. This has particularly risen up in some recent conversations with people working on articles I want to publish on my site.

One of the problems with growing our understanding of software systems is that we don't see enough examples. In many professional disciplines, people learn by looking at what's already been done. Examples serve as inspiration, a source of good ideas, and warnings of difficulties. For a long time it's been much harder to learn about software this way.

Over the weekend I heard the sad news that John Vlissides died after a long battle with cancer. John is best known as one of the “Gang of Four” who produced probably the best book written on software design.

As a writer and speaker on software development, I dish out a huge amount of general advice about our profession. Whether it's as specific as saying how a DecoratedCommand works, or as philosophical as how to think about your SoftwareDevelopmentAttitude, there's no end to the noise I make. Furthermore I'm only one of a large community of general advice givers: authors, analyst companies, journalists, there's more of it than anyone can read.

As someone who uses version control all the time, I think it's something that can grow into more areas of computer use. Other than software developers, few computer users use version control. Yet as software developers know, version control is a great mechanism for collaborative work, allowing multiple people to work together on a single software system. What would be the benefits of version control being more widely used?

As I've been using slides again as a visual channel in my talks, I've been making use of animation with diagrams to help communicate my points. The major presentation programs (Keynote and Powerpoint) have long supported animation, but I've been inclinded to look for motion grahics tools that are more powerful and easier to use.

All of this site is written in simple XML documents and transformed to HTML. I find this works really well, and means I never have to worry about dealing with HTML formats. (Not that fancy layout is my style, as you can tell.) I've even written a whole book that way.

A couple of years ago I changed an important aspect of my working life. Before then I tried to work on only one computer (or more strictly only one hard drive). All my working files were kept on my laptop hard drive. If I used a desktop machine I used those files through file sharing facilities.

Neologism:

1: a new word, usage, or expression.
2: a meaningless word coined by a psychotic.

-- Merriam-Webster

If you read much of my writing you'll quickly notice that I am a compulsive neologiser. I'm always looking to come up with new words and phrases, indeed this bliki is designed around this habit.

Microsoft have released a new community resource called PatternShare. The idea is to bring together pattern summaries from many pattern authors and provide a platform for discussion and further exploration of the interconnections between them. Much of the work was led by Ward Cunningham, whose pattern lineage is second to none. You'll find patterns there from myself, GOF, POSA, Hohpe/Woolf, Evans, and Microsoft.

A common complaint about patterns books is that they have nothing new to tell experienced developers. (I've had a few of these recently in amazon reviews and on The Server Side, so perhaps I'm feeling sensitive at the moment.) Not just is this true, but it's the whole point of patterns.

One of the side-effects of my success as a writer is that I've become a minor geek celebrity. It is very minor, usually only taking effect in geek conferences (although I have had people wander up to me in a restaurent a couple of times in San Francisco.) Before it happened I really didn't think much about it, other than a mild hankering after fame. Now it's happened I'm more aware of it - and all in all I hate it.

I have the habit of creating Neologisms to describe the things I see in software development. It's a common habit amongst writers in this field, for software development still lacks much useful jargon. One of the problems with building a jargon is that terms are vulnerable to losing their meaning, in a process of semantic diffusion - to use yet another potential addition to our jargon.

From time to time people ask about how you get a book into my signature series. There are lots of book series out there and each series has its own way of deciding what to accept. Here's how I decide

From time to time I run into people who want to get a smalltalk and give it a spin to see what the fuss is about. My old favorite introductory smalltalk book went out of print, but I just discovered you can now download it from here together with lots of other smalltalk related material. The material is hosted by Stéphane Ducasse, who was a co-author on an excellent book on reengineering patterns.

I wasn't cool enough to be in the first wave of invitations, but I have now got onto Google+, the Maybe Next Big Thing in social networks. It seems somewhat appropriate to mark this Momentous Event by writing a little bit about how I've used social networks so far, and some uninformed speculation about the impact of Google+

If you read many standards documents, apart from the need for excessive amounts of coffee, you'll also need to be wary of the overloaded meaning of some words.

It's one thing to idle away your productive hours reading this blog, but some people like to translate it too. So I'd like to welcome a Thai translation which is being done by a team of people led by Wee Witthawaskul. About fifteen years ago I visited Thailand as a typical backpacker western tourist. I have fond memories of the river buses in Bangkok, hiking near Pai, snorkelling at Ko Pi Pi, and some great food. I first met Wee while he was working with Ralph Johnson, he's now joined me at Thoughtworks.

In the summer of 2006 I did a major chunk of work on UI patterns. Since then they've been very much on ice as my primary writing focus has shifted (although not very visibly) to DomainSpecificLanguages. On this page I'll keep a note of links to writings I've liked that are connected with that work.

XML has been around for a while now, and it's used a lot - indeed a lot more than it should be. Like most tools XML is good for some things and not for others