[Thinking inside a large box];

I recently got asked a lot about book recommendations for engineering leaders. Here are the five books that I’ve found most helpful so far.

Many engineers and managers focus too much on process and overlook much more important aspects of a successful engineering team.

Here’s a quick reminder about what really matters and what engineering managers should spend their time and energy on.

What is like to be an engineering manager vs. an individual contributor? Should engineering managers code? What do engineering managers actually do? The correct, yet unhelpful answer is: “it depends”.

The (software) engineering management role comes in many flavors. This means that the day-to-day work can be vastly different. If you’re trying to learn from engineering manager peers or are considering getting into engineering management, these differences are important to understand.

I’m currently reading a great book on designing data intensive applications. In the earlier chapters of the book the author (one of the main contributors to Apache Kafka) discusses the history of database models and tradeoffs between document, relational and graph databases.

He touches on interesting trend: Some of the most popular database systems such as PostgreSQL and SQlite now offer APIs to store and query JSON documents, making them multi-paradigm and bringing a lot of the benefits of document based database systems to traditionally relational ones.

Coincidentally I’m currently working on a feature that requires me to model a one-to-many relationship in SQlite, which lead me to try it’s JSON support.

It’s almost the end of July and I’ve tried to keep up a schedule of blogging at least once a month. So I decided to pull a topic from the long pile of potential blog posts I’ve accumulated: prototyping.

This posts focuses on using prototypes to validate technical ideas, not on creating prototypes for user testing.

Working with closed source APIs sometimes requires us to use advanced debugging techniques to track down issues that cannot be explained by our application code alone.

This week I had an interesting debugging session in which I learned more about the behavior of apps with multiple UIWindows. These kind of posts are mostly useful for me as an attempt to retain some knowledge. But I hope this story is entertaining and useful to you too!

NSUndoManager is a powerful API, but it is geared towards Objective-C code and relies on runtime features. This post demonstrates a simpler alternative that is better suitable for idiomatic Swift code.

This is a cross post of a piece that original appeared on the PlanGrid R&D blog

Short version: When profiling code that should run on multiple cores in parallel, CPU utilization of multiple cores isn’t a good indicator as a single thread might utilize multiple cores at (almost) the same time.

At PlanGrid we started adopting Swift prior to the 1.0 release. Despite the tooling problems you’re probably familiar with, we’re still excited Swift users and have written almost all new code since the summer of 2014 in Swift. We are doing that within a large legacy codebase so more than 50% of our application code is still in Objective-C. As in many projects Swift and Objective-C need to co-exist.