Earlier this year I was asked if some engineers from our team could help build a newly prioritized project. Doing so meant putting our team’s current work at substantial risk of failure. I knew canceling our project was the right thing to do because the incoming request was more important and because continuing our current work meant spreading our team too thin. Our team had put in a lot of time so I wanted to share the news empathetically, but delivering and receiving difficult news is never easy.

I started by talking to my product manager. They quickly understood and helped me plan how we would deliver the news to our team. We drafted a list of points to communicate. Having a list was important because we didn’t want to leave out part of the message when speaking in different places or with different people. We detailed what was changing, why, what would happen next, and honestly that...

Some time back my team was asked to take up a critical project on short notice. My product manager and I found out about the project on Monday evening and we were told it needed to ship on Friday the same week to 3 client platforms with a small team. We had just four days to make this happen and the date couldn’t move so we had to work with the other two project levers: changing the amount of work we would deliver, and putting more people on the project. The latter famously only helps so much. I want to share how we got many people on the same page and kept them there by managing their expectations.

What are expectations?
Expectations are things people believe will happen in the future. Unmet expectations can lead to unfortunate outcomes like duplicate effort, missed opportunities, or worse. Managing expectations is the act of making promises you intend to keep, making sure other people...

The other day I was chatting with a friend who is both very competent and early in their software engineering career. They had noticed it sometimes took others less time to solve problems than it took them, and when they’d ask for help, these folks knew the answer or could often point them in the right direction right away. It felt like magic.

Thinking this is normal, but it’s not magic. When people come back with an answer quickly it’s because they’re aware of the problem, already understand how a system works, or because they’re pattern matching against previous experiences and happened to guess the issue. But if you’ve ever handed off a difficult bug only to have a peer come back the next day with what seems like a simple fix, it can trigger negative feelings.

A couple of years ago I was trying to understand a strange bug in my company’s app that broke the theming system with a new...

People have different value systems. Someone may value very expensive headphones, or cameras and you may value sneakers. Someone may value working really hard, and you may value having time to live and travel. It’s best to not push your value system onto others, because it can harm relationships. It’s okay and good that people value different things.

Related to value systems — how does one’s value system affect how they weigh tradeoffs? Is this refactor more or less important than shipping? Internationalization? Accessibility? Polish? What stage is your company at? What’s the right thing to do? How does one’s value system help define “right”? Can you think of a way to acknowledge a peer’s values and leverage strengths in a way that helps your team succeed and makes them happy?

Value systems also affect motivations, which vary from person to person. Some people are motivated by public...

Note: I wrote the following note over a year ago, but only recently decided to send it to my newsletter. I’m not sure why I sat on it so long. Your [respectful] thoughts are welcome on Twitter.

Empathy doesn’t always come easy, but it goes a very long way toward building trust with those around you. I’ve seen many well-intentioned people lose the trust of their peers because they fail to communicate with empathy. Perhaps they rush when replying to a message, or they fail to set aside frustration with a decision they believe should have gone a different way. In many cases this is a matter of differently weighed trade offs or a misunderstanding about who is empowered to make a decision. It turns out these things are sometimes unclear.

It’s important to take a step back in moments like these to get a broader view of the situation: try to understand the position the other person is in...

Did you know the swift-llbuild project contains a debugging tool called llbuild-ui that can find dependency cycles in your iOS build? To try it:

1. Enable the New Build System (In Xcode it’s under File, Workspace Settings)
2. Build your project
3. Open the Derived Data directory on your machine and find the build.db file generated by the build system. This will be in a path similar to /Users/<yourUsername>/Library/Developer/Xcode/DerivedData/iOS-<someIdentifier>/Build/Intermediates.noindex/XCBuildData/build.db. Take note of this path as you will need it later.
4. Follow the instructions here to install llbuild UI. You’ll need to have Python (and probably some dependencies) installed on your system.

5. Start llbuild UI by running the command shown on the Github page linked in step 4 above in terminal.

   FLASK_APP=llbuildui.app venv/bin/python -m flask run

6. Visit http://127.0.0.1:5000/ in your...

Xcode 9 includes a new build system that can substantially improve build times. The new build system is more strict about build issues, but some of its diagnostic output can be difficult to reason about. One difficult to debug error is “Dependency cycle between targets,” which may appear during incremental builds where you may not have an explicit circular build dependency between targets. Let’s talk about how these types of cycles are introduced and how to troubleshoot and fix them.

There is more than one way to cause this sort of target dependency cycle without adding an explicit target dependency. The behavior of the legacy build system is to continue to (re)build instead of failing. This can increase incremental build times for your project, but the build ultimately succeeds and you may not know there’s a problem. The new build system fails instead, which helps you better maintain...

Last year I started offering mock interviews for iOS developers. It’s been a learning experience for me and, I think, others. I’d like to share a bit about what me and the 10 folks I’ve interviewed so far have experienced and what’s next.

Through the wonder of the internet, I’ve met (and hopefully helped) folks from all over the world. Once a week I interview an iOS developer from anywhere in the world during my lunch hour. I’ve interviewed people from the US, Canada, Italy, Australia, and more. I currently have another 8 interviews lined up with folks from Greece, Singapore, and Brazil to name a few.

Interviews start with about 15 minutes of iOS knowledge questions that cover a wide range of categories from user interface basics to concurrency. I tell candidates that real interviews will go much deeper on each of these topics. This helps them figure out the sort of things they may be...

Home automation is still an early adopter’s game. The landscape is fragmented and there are competing standards like Insteon, Z-Wave, zigbee, Wi-Fi based devices like Nest and Philips Hue, and Apple HomeKit. And most of these things don’t work together out of the box. ?

So what should you buy? Will it work with iOS via HomeKit or do you have to use a bunch of apps?

I have experience with Insteon, Z-Wave, and Apple HomeKit so I’ll share what I know about those standards here. But first, let’s get some basics out of the way. Setting up Home Automation requires a controller and a responder. (I’ll call responders devices here.)

Controllers
There are many controllers out there. First party controllers generally work with one standard. For instance, Insteon’s hub only talks to Insteon devices. And Samsung’s SmartThings hub talks to Z-Wave devices. I should point out that Z-Wave is not...