[Thinking inside a large box];

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.

I wanted to write this blog post for well over half a year. I don’t believe Uber will be a successful business. I’ve been making my points in individual conversations over and over again - with this post I’m creating a writeup of my arguments that I can share in future.

Since I’ve had a lot of discussions about Uber in person, it makes the most sense to write this piece in the platonic dialogue form.

TL;DR: In order to learn more about how Thread Sanitizer’s data race detection works I’ve implemented a very simple version in Swift. You can find it on GitHub. We all know concurrency is hard. It’s easy to make mistakes when attempting to synchronize access to shared resources and the resulting issues are often extremely hard to reproduce and debug. So I was very excited when I learned about data race detection in LLVM’s Thread Sanitizer in this year’s WWDC Session 412. Read More...