A Successful Programmer: Reading

I’ve been thinking a long while about some of the things that have made me a successful programmer. One in particular is reading. I have read and continue to read many books. The books I read vary in topic and not all are technical. I will just to focus on technical books for now.

Even though I work professionally as an iOS developer. I keep my eyes open for useful or emerging technologies. There is something to learn from every field, technology, or language. When I find a useful technique, I adopt it into my current practices. Recently I’ve been incorporating more functional programming techniques. The idea of limiting mutable state greatly simplifies debugging later.

One of my favorite publishers is The Pragmatic Bookshelf. They publish books for programmers authored by programmers. They have books on almost any topic and at varying levels of expertise. Additionally their publications are easily affordable. They offer physical books, ebooks, and screencasts. Updated digital publications can be automatically synced with Dropbox. When I want to pick up a new technology and be assured I’m learning best practice, this is my first source. At the time of this writing, I own 31 of their books.

I also read many older books. There is much to learn from the past. One book I often reference is Design Patterns: Elements of Reusable Object-Oriented Software. Knowing good code design is fundamental to writing maintainable code. I love Don Norman’s Design of Everyday Things to better understand building usable apps. Fred Brook’s The Mythical Man Month is great for avoiding common pitfalls in managing technical projects. There are countless other classics I could mention, but these books are among my favorites.

I’ve often heard as a rule of thumb that every programmer should learn a new language every year. This is certainly not enough time to master the language. It is, however, sufficiently long to learn the unique features of the language. I personally try to read several books per year, both related and unrelated to my current work. Lately I have been studying distributed computing and Erlang/Elixir. I love parallel processing, and big data is one of the next big problems that needs to be solved. Though these studies are not directly related to iOS development, it helps me in building scalable web backends to service iOS apps.

Everyone has different learning patterns. If reading books doesn’t suit you, find other ways to learn new technologies and techniques.

As a disclaimer, I am not receiving any compensation from any publishers or authors. I have found the mentioned books useful and believe that they will benefit others.

iOS Recipes Review

Here’s a book I couldn’t recommend more. iOS Recipes by Paul Warren and Matt Drance has done more to improve my code than any other book.

Summary

iOS Recipes gives 40 code samples to improve common or useful iOS code. The recipes are grouped into five categories: UI, Table/Scroll Views, Graphics, Networking, and Runtime. The book is organized so you can read it in whatever order suits your needs. The wide range of recipes guarantees there is something that will benefit you.

Pros

iOS Recipes includes many code samples that can be dropped into any project and will just work without any extra modification. Any project could benefit from using at least one of the included recipes. For example, the common table view cell production/customization process typically takes 20+ lines of code. I now write the same code in 3 lines of code and it is fully Interface Builder customizable.

The greatest value of this book, however, is the explanation of how these recipes were designed. Warren and Drance explain exactly why they, for example, chose blocks over delegation or vice versa. By applying their same reasoning to other code, you can create your own quality recipes. This is further encouraged by not giving recipes that do everything. Some extensions are left as an exercise to the reader.

Cons

There’s nothing I can say against this book. It really is a great book.

Recommendation

Every experienced iOS developer should own this book. By following the principles taught in iOS Recipes, your code will increase in quality. I also recommend this book to any daring, young developers who are interested in gaining a deeper understanding of the full power of Objective-C and designing quality code.

Driving Technical Change Review

One particular book that caught my eye some time ago is Driving Technical Change by Terrence Ryan. In his book, Ryan teaches the skills necessary to convince others to adopt your ideas. Though the book focuses around technical fields, most of the skills taught apply to other disciplines.

Summary
Ryan begins his book by classifying different types of people, such as the Cynic, the Uniformed, and the Irrational. From there he progresses to the skills needed to use on the different categories including delivering your message, gaining trust, and getting publicity. Ryan then concludes with how to strategically employ the needed skills.

Pros
The book is written in a way that it can in whatever order fits your needs. Once you have identified the category (or categories) of people you are working with, you can jump straight to the recommended skills and techniques. The chapters are short and easy to read. Every skeptic category and rhetoric technique includes short examples to illustrate the ideas.

Most of the ideas covered seem common sense. Yet there are some examples that I had never thought of employing. For example, Ryan suggests one way to get coworkers to accept a framework you've built is to open source it. If many people start using it, or even contributing to it, then your coworkers will be much more open to using your framework.

Cons
Ryan tends to dodge confronting the Irrational. It is true that little can be done to convince an irrational person. However, he doesn't offer many suggestions besides avoid them and/or have management mandate a policy. Management mandate may be the silver bullet, but what about the situation when management is irrational? Perhaps the best solution at that point is to find a new job.

Before reading this book, I was expecting Ryan to go into more detail on leadership skills. However, many skills such as gaining trust are left with few examples or explanation of how to gain trust. I do like the succinctness of Ryan's writing, but sometimes I'm left wanting more concrete examples.

Recommendation
If you are one of the many that feel your voice isn't heard, this book likely has some skills you haven't tried yet. Ryan shares his secret to leadership: "you can be promoted to management, but no one appoints you a leader." Driving Technical Change can help you take initiative and become a leader.

You can purchase Driving Technical Change here from The Pragmatic Bookshelf.

Designed For Use Review

I've been anticipating the release of Designed for Use: Create Usable Interfaces for Applications and the Web for a while now. I was a little disappointed that it was delayed by almost a week from its original release date. Nevertheless, I bought it and finished it right away.

Summary
Lukas Mathis breaks the design process into three distinct parts: research, design, and implementation. Each category is subdivided into smaller steps classified as either idea-based or skill-based. The progression is logical, but also is written in a way that steps can be skipped or read out of order according to the needs of the product.

Pros
When I first saw the book, I expected a focus strictly on what Mathis terms the "design phase" (Part 2 of 3). Design to me, before reading this book, meant wireframes, prototypes, and usability testing. The book gives much more. Mathis shows that the design process extends throughout the entire development cycle.

Designed for Use includes countless links to other resources. Mathis cites many prominent UX and Design blogs, books, videos, etc. Most are web based, so they are freely and widely available.

Many great techniques are suggested that I never thought of as part of "design." Mathis includes mock press releases, job shadowing, and feature sorting. Not only does he teach several techniques, but he also gives low-budget suggestions. He removes any excuse for not following certain steps such as usability testing.

Cons
Overall the book seems to have a bias towards desktop and web applications. There are several references to developing mobile applications, but there are few resources mentioned. I was expecting to see services such as Flurry and TestFlight included in the sections on user feedback and testing. Nevertheless, the ideas and techniques still apply.

Recommendation
In general product development I often see two areas that lack: design and documentation. Mathis hits on both topics. Every step of the design process is covered succinctly and thoroughly making it quick and easy to read yet includes many references for further indulgence. I would highly recommend this book to both young and experienced developers. Designed for Use can be purchased here on pragprog.com.