Think Like a Programmer

I used to write software. I confess, it has been a long time. There are parts about doing so that I loved (problem solving, being creative) and parts I didn’t enjoy (solving problems that I didn’t find interesting, over and over and over again). This book concentrates on the parts I enjoyed most.

Think Like a Programmer came out earlier in 2012. It was published by No Starch Press, which consistently puts out books that impress me. It is one of the more consistent computer-related publishers and when I’m researching a specific topic, I generally look at any they offer, along with O’Reilly, before looking at other publishers’ offerings. I should probably disclose that back in 2009 I talked with No Starch about writing a book about Ubuntu. That didn’t work out and shortly afterward I ended up taking over the Ubuntu Unleashed title for SAMS when the previous author team didn’t want to continue with it, but my email conversations with the head honcho (or as their website says, the “Big Fish”), Bill Pollock, left me with a favorable impression of the company.

This is not a “how to program” book that concentrates on learning the syntax, vocabulary, and grammar of a specific programming language. You will need to learn that elsewhere. In fact, you probably want to learn basic C++ before you read this book. While the concepts in this book will apply across programming languages, examples are given using C++. Those who already know Java or C# and who are flexible will probably be okay, but will need to be experienced enough to translate.

This is a “how to program” book that focuses on figuring out how and when to use the various concepts and tools within a language to creatively solve problems. I have never read another book that covers this topic. The idea is that learning the basics of a language helps you understand what the tools do, but it is usually experience that helps you understand and create strategies for using them. You may know what a pointer is and the mechanics of using one, but seeing when using pointers is most effective only happens after seeing them at work in context. Context is what this book tries to give. The author, V. Anton Spraul, calls the missing skill problem solving, “the ability to take a given problem description and write an original program to solve it.” The cool thing is that the book teaches the sort of problem solving skills that usually require years of experience in a systematic, logical way.

The book starts with a discussion about strategies. Problems almost always have constraints, things that limit the paths you have available for solving them. Good problem solving finds a way to do what must be done while not violating any of these boundaries. This involves creative thinking. This 20-some page discussion is the foundation for the rest of the book.

As the book continues, you will meet up with all your conceptual friends you learned about in your programming class or book. Only this time, the discussion is not about mechanics, but strategy. Why is tracking state important? When should I use scalar variables vs arrays vs multidimensional arrays? What problems are better solved using pointers and dynamic memory? How do I create meaningful classes and objects (and not just “arbitrary bags of leftovers”)? Since C++ is flexible, it affords a nice discussion of when a procedural and when an object-oriented approach may be most suitable. Sequential or recursive? If using recursion, head or tail? What about reusing code?

The book ends with a useful chapter on thinking like a programmer. Yes, that is the topic of the entire book, but whereas each chapter focuses on discrete parts, this chapter brings all the parts together to help the reader learn to synthesize a master plan when solving specific problems.

Bottom line: you probably need a year or two of experience for this book to be really useful. This is because once you have struggled with some of the issues the book discusses you are going to be much better equipped to see how useful the book is. The bare minimum is to either have studied C++ or to have spent enough time programming in another language or two so that you understand what the C++ discussions and samples are illustrating. If you fit here, the book is highly recommended.

Disclosure: I was given my copy of this book by the publisher as a review copy.

The Insider’s Guide to Technical Writing

I love technical writing. Sincerely. When I say that to most people, they look at me oddly, squint a little, maybe cock their head sideways, and walk away. I think that is because most people don’t really understand what this job entails. To be sure, most people realize that technical writers are the ones who write those manuals that come with their favorite electronic toys and mechanical gadgets. We get credit for making sure mechanics have quality, accurate information before they lay a wrench on your car or adjust the hydraulic systems on the airplane you flew in to visit your grandmother. What most people don’t realize is that this process is actually a lot of fun. This book communicates that beautifully.

The Insider’s Guide to Technical Writing came out earlier in 2012. It was published by XML Press, which specializes on content for technical communicators (also known as technical writers, technical documentation specialists, and so on). The author, Krista Van Laan, has the experience to be credible and authoritative. She also proves her mettle with her clear writing and thorough coverage of the field.

As I read the book, I played a game. You see, I am also an experienced technical writer, and I have read some books on the topic that I would not recommend at all. My game consisted of trying to find the holes in the book. I watched carefully for the missed aspects of the job or the incomplete descriptions of a task. I scrutinized the text to see if I could find the sort of poor writing style or uninteresting examples that plague some parts of our field–ever read a manual and thought to yourself that you could write a better one? So have I. So has Van Laan, and she uses this example as one reason why you might be a good candidate to become a technical writer.

My game was an utter failure. The book is a resounding success. Everything I love is in here. Everything I do (including those bits I don’t love quite so much) is in here. The book is not only written clearly, but with a style that is enjoyable to read. Examples are interesting and ring true to life. If you have ever wondered whether you might want to become a technical writer, wondered what a technical writer does, or you are a technical writer who knows there are gaps in your knowledge, buy and read this book.

The Insider’s Guide to Technical Writing covers all the bases. It begins with a high-level description of what a technical writer does and how to determine whether or not you have the right stuff to be a success. This is not a discouraging section, but rather a deeply encouraging one that highlights the personality and intellectual traits necessary to learn and enjoy using the skills that a technical writer needs. It covers how to pursue the career and how to get a job in the field. Then, we get to the really fun parts.

I’m convinced that technical writing is about 15% writing. The rest of my time is spent doing research, being one of the very first people to test a product or an application, interviewing subject matter experts, learning about my audience, planning and coordinating my activities so that I can deliver the requested materials on time, presenting drafts for technical review, and accepting and incorporating correction and feedback from others who also want us to deliver excellent and accurate documentation. When I’m not doing these things, I might be organizing or reorganizing information, playing around with how it is expressed, working on a style guide to ensure that everything is consistent in its look and feel, or learning about design or a new technology for delivering documentation. Good writing skills are vital, but technical writers also need good organizational skills, interpersonal communication skills, the ability to learn new technologies quickly and completely, and adaptability.

Everything in the previous paragraph is in the book. In fact, that paragraph only scratches the surface of the book’s content. You will also learn about managing your career, working remotely, translation and localization, how to keep your writer’s skills and toolkit up to date, and constantly growing.

Seriously, if any of this sounds interesting to you, buy this book and read it.

Disclosure: I was given my copy of this book by the publisher as a review copy.

The Manga Guide to Linear Algebra

It has again been a while since I have reviewed a manga book. This is one of several atypical educational books that use graphic art to help teach difficult concepts or illustrate the action and another wonderful entry in the “Manga Guide to…” series that I have been reviewing.  I keep requesting review copies of each title in the series as they come out, and I have yet to be disappointed. This is an impressive series that consistently makes very difficult academic topics more interesting and a little easier for students. I would not consider these a replacement for a textbook, and neither would the publishers of the series, but every book that I have reviewed from the series would make an excellent supplement, especially for the struggling student.

The Manga Guide to Linear Algebra follows the actions of a Reiji, who wants a black belt in Karate and to gain the interest of the girl of his dreams, Misa. She happens to be the younger sister of the captain of the university Karate club, and although her brother is intimidating, he offers to give Reiji lessons in exchange for Reiji tutoring Misa. You will have to read the book to see how that turns out.

The book starts with an introduction to the characters, then an introduction to linear algebra. I admit, it has been many years since I studied the topic and I was interested to see how quickly I would pick it back up. The book made it easier than I anticipated, partially because it gives context for each concept presented. Knowing why something is important and how it fits into a greater scheme makes it much easier to understand and remember.

Topics covered in the book include fundamentals like number systems, implication and equivalence, set theory, functions, combinations and permutations. We then transition into matrices with a “what is a matrix?” section, calculations, special matrices and lots more. Once matrices are covered in depth, vectors are introduced along with calculations, geometric interpretations, linear independence, bases, dimensions, and coordinates. Once we move into linear transformations and spend some time trying to get a handle on this difficult topic, the presentation turns to an interesting discussion of the relationship between linear transformations and matrices–again, this helps provide some useful context to a difficult idea to grasp. Finally, the book discussed Eigenvalues and Eigenvectors, including how to calculate them, multiplicity, and diagonalization. Then, the storyline surrounding the mathmatical topic is brought to a close.

Studying linear algebra? This won’t replace your textbook and doing your homework, but it may help you figure out the context for and gain a deeper understanding of what you are doing. That alone makes the book valuable and earns it my recommendation as a quality introduction to the topic.

Disclosure: I was given my copy of this book by the publisher as a review copy.

Seven Databases in Seven Weeks

I’ve spent some of my free time over the last couple of months researching different databases for a chapter in one of my books. I have some limited experience using some NoSQL options, but must confess that I am not as familiar with many of the newer databases as I would like. As a part of my research, I read this book.

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Eric Redmond and Jim R. Wilson came out earlier in 2012. It is published by The Pragmatic Programmers, as a part of their Pragmatic Bookshelf, which is an impressive and deservedly well-respected series.

My goal in reading this book was to get a better sense of the landscape, to learn the basics of several of the new databases out that have been receiving the lion’s share of the buzz in the computer press. The book did not disappoint, in fact it exceeded my expectations.

All a reader absolutely must know before reading this book is what a database is, but after saying that, I will follow with a quick disclaimer that this is not intended for newbies. The book is written for experienced developers, people who understand software, who know their concepts and how to apply them, but who are interested in the latest developments. The book does not cover things like installation or systems/database administration. Instead, it gives information that surveys the strengths and weaknesses of the new databases to help the experienced developer better understand when, why, and how he or she might find a specific one useful. We have discussions of features, contexts, and pragmatic looks at usefulness. I appreciated the author’s willingness to state not only how specific products could benefit, but also mention when specific products may be unsuitable for a specific project.

Databases covered are these, listed in the order in which you will find them in the book:

  • PostgreSQL
  • Riak
  • HBase
  • MongoDB
  • CouchDB
  • Neo4J
  • Redis

You will notice that there is a nice variety in the types of databases listed. Represented are a standard relational database (PostgreSQL), key-value stores (Riak, Redis), a columnar database (HBase), some document-oriented databases (MongoDB, CouchDB), and even a graph database (Neo4J). The survey is clear, deep, and packed with useful data that makes comparing these vastly different, but often lumped together as “NoSQL” databases, easier.

If you have any reason to use or consider using anything other than a more traditional relational database, and aren’t sure which one to try out of the exploding number of new options, this book will help you make sense of the field and better evaluate your options against your current needs. I recommend it.

Disclosure: I was given my copy of this book by the publisher as a review copy.

More reviews coming soon

I moved house recently, and I got behind. I have several books in a pile waiting to be read and reviewed, and now that the dust has settled from the move, I’m ready to get back to it. I don’t have a time frame, but in the queue are books on databases, technical writing, and another entry in the Manga Guide series, this one on linear algebra. I’ve read enough of these to be certain they will be worth mentioning, but I also have several more that I haven’t even opened, so there may even be more than those three in the coming weeks.

Confluence, Tech Comm, Chocolate

As I mentioned in an earlier review of writing-related books, I am a writer. I write for a living. I write technical documentation, books, occasional articles for magazines and websites, and more. This review covers a book that has been helpful to me primarily in technical writing.

Wikis are wonderful. There, I said it right at the beginning. I’m biased. I’ve written documentation using everything from word processors like Microsoft Word and LibreOffice to XML variants like DocBook. I’ve hand-written entire suites of documentation using HTML and XHTML. I’ve also used various wikis, such as MediaWiki, MoinMoin, and the topic of the book in this review, Confluence.

Confluence, Tech Comm, Chocolate: A wiki as platform extraordinaire for technical communication came out earlier in 2012. It was published by XML Press, which specializes on content for technical communicators (also known as technical writers, technical documentation specialists, and so on). The author, Sarah Maddox, works as a technical writer for Atlassian, the creator of Confluence and other software tools.

This book fits a useful niche between marketing materials that are more useful in an early product evaluation stage and technical documentation that is most useful during the implementation stage. Planning your documentation comes in between these two stages and is a vital step that is often poorly documented, especially in terms of planning and creating technical documentation on a wiki. This book gives a wealth of practical advice for this stage.

In addition, Sarah Maddox includes in the book all the information that a complete novice requires. Topics like what is a wiki or how is a wiki used on a day to day basis for technical communication are covered and covered well. The reader receives specific instruction on useful topics like creating content for reuse, using Confluence as your single source for output to other formats, creating templates and styling, importing content from other formats, creating documentation as a team, using a wiki within an Agile context, and performing content reviews on the wiki itself.

I’ve used Confluence to create technical documentation from scratch in previous projects. The best practice guidelines and tips in this book ring true to me from my experiences. My current project uses Confluence as one tool among many. I will be sharing the book with my colleagues to see how we can use it even more effectively.

If you are a technical communicator and are considering Confluence as a medium for documentation, take a look at this book before you do anything. In addition, I believe the book would be useful to share with both technical collaborators like software engineers as well as less technical collaborators like program managers or sales staff. The latter generally have more direct communication with customers, either through software requirements or personal interaction, and the book will help each understand and determine whether Confluence is a good fit for your technical communication, for your company workflow, and also for your sales and bottom line.

Disclosure: I was given my copy of this book by the publisher as a review copy.

Style Guides

As many of you reading this already know, I am a writer. I write for a living. I write technical documentation, books, occasional articles for magazines and websites, and more. The books in this post have been helpful to me primarily in technical writing.

Style guides exist to help writers reduce the number of decisions they must make as they write. This simplifies the complex task of writing technical documentation, at least a little, by eliminating many of the questions that a good writer must ask. Should my directions use the word “click” or “open” when referring to using the mouse to start a program? Should menu options be set off in sentences using italics or bold text? For many of these sorts of questions, there is no right or wrong answer, there is rather a strong need to choose a form and use it consistently. For other questions, there are strong reasons to choose one format or expression over another, but these are not always easy to remember. This is where style guides help.

The first style guide I used, and which still sits on my desk, is The Chicago Manual of Style, which has been around since the late 1800s. Published by the University of Chicago Press, this manual has been a consistent and well respected guide to good writing for decades. While there is a newer edition available, both in print and online, I still have the 15th Edition sitting on my desk, and it has served me well. However, this is a general-purpose style guide, and most of what I write lately is focused on computer software, which uses terminology not covered by The Chicago Manual of Style. I needed to look further.

The rest of this post will focus on three style guides intended for the computer industry. Each of them cover the vital information a technical writer will need when covering topics related to computers, both hardware and software. These include writing mechanics, formatting, style, procedural directions, writing for an international audience, and so on. They differ primarily in the choices made and the manner in which they themselves are written.

Read Me First! A Style Guide for the Computer Industry, 3rd Edition came out in 2010. It was published by Sun Technical Publications, which was part of Sun Microsystems. The style is easy to read and clear, not too dry and never frivolous. The book gives clear examples and labels them “correct” and “incorrect” to help the reader. I have used this book for about 18 months and it has served me well. Some unique topics in this book include legal guidelines for protecting copyrights and trademarks, and a description of different types of technical documentation. This is a very good style guide, but I wonder about its future, since Oracle’s purchase of Sun Microsystems was completed a few months after this edition was published.

The IBM Style Guide: Conventions for Writers and Editors came out in 2012. This is the first edition of the book, but it seems safe to assume IBM has had an internal style guide for decades. IBM documentation is always clear, well written, and consistent. This book is formal, always appropriate in tone and style, and gives many examples to show the “correct” and “incorrect” way to express content. This is a style guide worthy of use by anyone who wants to produce professional documentation.

Microsoft Manual of Style, 4th Edition came out in 2012. This style guide surprised me, in several good ways. First, the layout uses more white space, a clearer typeface, and is slightly easier to read than most style guides. It isn’t that the others are bad, but that this one is better. I also like that Microsoft does not label their examples as “correct” or “incorrect,” but instead uses the terms “Microsoft Style” and “Not Microsoft Style.” While it should be understood that this is the ultimate meaning of “correct” and “incorrect” in the books from IBM and Sun, Microsoft comes across as both authoritative and humble at the same time–an impressive feat. Unique topics include writing with accessibility in mind, for content reuse in ways that allow those with non-traditional needs to be able to use the information.

Bottom line

The Chicago Manual of Style is a writer’s standard, but does not explicitly cover the needs of technical writers creating documentation for computer hardware and software. Each of the other three books mentioned here is a quality guide to creating useful documentation that is clear, useful, and appropriately standardized. They all cover the most important topics, but some of them have information not covered by the other two. Using any of the style guides listed here will benefit the technical writer, especially if no style guide is currently being used. If I was starting a new project, I would probably choose the Microsoft style guide, but I want to be clear that all of them are adequate to the task and worth a look if you are seeking guidance.

Disclosure: I was given my copies of Read Me First!, The IBM Style Guide, and Microsoft Manual of Style by the publishers as review copies. I bought my copy of The Chicago Manual of Style years ago when I first got started.

Reading up on HTML5 and CSS3

Everyone is talking about HTML5 and CSS3. If you believe the hype, they will change how web development is done while feeding the world and creating new opportunities for people everywhere to enjoy a new era of peace, love, and rainbow-emitting unicorns. Obviously, I’ve been around long enough to be a skeptic.

That said, I do want to keep up on standards and trends, if only to keep my work from causing me embarrassment and to prevent having to do more work than necessary (by having to perform updates soon after code is written). With this in mind, I picked up two books on HTML5 and CSS3.

First, I read Pragmatic Programmer’s HTML5 and CSS3: Develop with Tomorrow’s Standards Today by Brian P. Hogan.

I liked this book. It was easy to read and understand. I liked that the book avoids hype and marketing speak and sticks to a clear description of HTML5 as a platform and as a specification. The author respects his intended audience, presumably people who are currently involved in web design and development and who don’t need their hands held with very basic descriptions of JavaScript, jQuery, or basic HTML and CSS from past versions. This book focuses on the new features that are most likely to be useful and exciting to developers: new structural tags and attributes, improved methods for creating web forms, making better interfaces, improving accessibility, and, of course, eye and ear candy in the form of canvas and media embedding.

Next, I read Sitepoint’s HTML5 & CSS3 For The Real World by Alexis Goldstein, Louis Lazaris, and Estelle Weyl.

This book is also intended for people with experience using HTML and CSS. The basics are often assumed and not covered in great depth. This means that most of the book is dedicated to things the target audience does not already know. In addition, this book also avoids the hype and unicorns and focuses on specific aspects of HTML5 and CSS3 that will be most useful to real world developers. The book includes a real world style example that is used to introduce the similarities and differences in the new versions of HTML and CSS that will make it easy for people familiar with the technology to jump in and do something practical.

HTML5 & CSS3 For The Real World covers all the same basic material as HTML5 and CSS3: Develop with Tomorrow’s Standards Today, but with some very useful and appreciated additions. Here we have coverage of Modernizer, a JavaScript library that can test for individual HTML5 features in a browser rather than simply checking what browser is being used, WAI-ARIA for making websites accessible more easily, and the Microdata Specification that allows machine-readable data to be embedded in HTML documents. Cool stuff!

Bottom line: both books are good, but HTML5 & CSS3 For The Real World covers more features and does so using better examples. I’ll give it a 5/5 and rate HTML5 and CSS3: Develop with Tomorrow’s Standards Today a very close second at 4/5.

Disclosure: I was given my copy of each of these books by the publishers as review copies.

The Official Ubuntu Book, sixth edition

I had the privilege to lead the team that updated The Official Ubuntu Book for this sixth edition. The book continues to serve as a quality introduction for newcomers to Ubuntu, both the software and the community that surrounds it.

ISBN-13: 978-0132748506

Link to the Amazon.com page for the book.