12 Dec

WatchKit Tutorial: Send data to parent iOS app

WatchKit beta 2 was just released as a part of the iOS 8.2 developer seed. One of the best new additions to the SDK is the ability to communicate back to the iOS parent app from the WatchKit extension. This allows us to essentially “close the loop” and pass information from the watch to the watch extension and to the iOS parent app that supports it.

I created a simple counter app for the watch which saves its count values back to a simple iOS table view app when the user hits a Save button. This tutorial will demonstrate how to transfer data to the parent iOS app from the watch extension. See the finished project on GitHub.


Now before you jump into this tutorial, I highly recommend that you read Natasha’s Hello World WatchKit tutorial first. This tutorial will assume that you’re already a little bit familiar with WatchKit (and iOS development in general).

Read More

10 Dec

Easy iOS Device Projector Demos

I recently did a talk where I live demoed some OCR functionality that I built. Essentially, I had to show what was happening on my device screen while I took a picture of a piece of paper. The main issue with this for screen reflector apps is that the refresh rate isn’t nearly as fast as the native iOS camera app – especially in web conference meetings, so you end up getting horizontal black lines all over your camera view.

Looks something like this:

Camera lines

Luckily, I found an simple and free solution for it that also makes iOS demos on a Mac computer screen much easier. You can now do demos with the new Quicktime Yosemite movie recording feature.

QuickTime shows your connected device’s screen live on your own computer screen. It makes it really easy to show whatever you are demoing your device in a much larger format. This can be very useful for presentations or meetings, rather than having a bunch of people crowd around your tiny screen or using third-party software like Reflector.

The best part is that it’s straightforward to set up. Here are the steps:

  1. Open QuickTime
  2. Connect your iOS mobile device to you computer using the lightning cable
  3. Right-click on the QuickTime icon and choose New Movie Recording
  4. At this point it’ll probably pop up with a live stream of your face since it connects to the web cam by default.
  5. Now, click on the down arrow button next to be big red recording button.
  6. Find your device name listed in the Camera section and click it. It should now show your device’s screen instead.

That’s it! At this point you can interact with your device like normal.

Just in case that wasn’t clear enough, here’s a quick video of how to do it:

The only thing that’s not as good as some of the third party apps is that this technique doesn’t show where the user is tapping on the screen. Most of the time, you’re able to just talk through where you’re tapping while you’re demoing so it shouldn’t pose too much of an issue.

26 Sep

It’s not my job to care what the product looks like, or is it?

Well it doesn’t look pretty, but we’re not designers anyway…it’s not our job.

-Software engineer intern

I overheard one of the interns earlier this summer talking about the project he was working on when he was updating his mentor on his progress. He was working as a client-side iOS engineer for the summer and didn’t seem to think it was his job to make things pretty, just functional.

While there’s a certain truth to the fact that engineers don’t have to come up with good UI/interaction designs for their products (at least at large software companies where there’s dedicated designers for this purpose), this doesn’t necessarily mean that they should turn a blind eye to their “ugly” but functional work.

For front-end/client-side engineers, there are two things that I’ve observed that the best engineers do:

Work hand in hand with their designers to come up with the best experience but DON’T hinder the designer to think big.

In general, the ideal workflow goes something like this:

  1. Based on the requirements, designer and engineering team brainstorm different ideas for the product
  2. Designer takes an initial stab at the designs (alone) with the brainstorming feedback from the team
  3. Designer sits down with engineering team to do a first pass over the user interface and user interaction mockups
  4. Designer takes team feedback and iterates on his mockups
  5. The engineering team does another pass over the new designs
  6. Steps 4 & 5 repeat until both sides are happy

As someone that’s taken a stab at being an interaction designer from an engineering background, step 2 is a particularly important step. This is what is necessary to allow a designer to dream big and not get their ideas immediately shut down by the engineering team. Engineers are generally limited by what they think is technically possible. However, I often see instances where an engineer will tell a designer “It can’t be done” and come back later and say “Wait, I think I figured it out.” They just needed a little bit of time to think (or Google around for an answer) and a bit of inspiration from the design itself.

That being said, the rest of the steps are to bring the designer back down to earth and find a common ground between the design and engineering teams. Sometimes things actually aren’t technically feasible, or there’s just not enough time to implement everything the designer wants.

Push back against designs that just aren’t good enough.

Even though your designer is probably great at his job, he doesn’t always have the right answers to everything. If there’s something that just doesn’t sit right with you as an engineer, say something, even if you don’t necessarily have a solution for the issue. Likely, others on the team will agree with you and then together, the team can find a better way of doing things than sticking with the original idea.

When both the engineers and the designers have a say in the UI, everyone will be much more invested in building a great product. Otherwise, if the product doesn’t turn out quite the way everyone envisioned it, you may have a case of the blame game on your hands – “The designer just didn’t do a great job with the interactions” or “The engineers didn’t understand me and built something completely different.”

Building great and beautiful products is definitely a team responsibility. While everyone has their own roles on the team, that doesn’t mean that as an engineer, you shouldn’t get any say in the design (if you want it). The best designs are not “thrown over the fence” and given to the engineers to implement. The best designs are iterated on, pushed and prodded, fiddled and tinkered with until it just works…for everyone.

25 Jul

How to be a speaker if you don’t have any experience

I recently did a presentation for the Intuit Girls Who Code class – it was the first of many presentations I hope to give throughout my career. Some people seem to feel that public speaking is one of those fears that is even greater than death. I’m not a big fan of being put on the spot either, but with enough preparation (and maybe a friendly starting audience), it can actually be a pretty enjoyable experience. Now, I don’t claim to know it all from just one presentation, but these were the things I used to get started.

The Start

In the beginning, the first two hurdles I saw were:

  1. Opportunity
  2. Topic

Opportunities are actually a lot easier to come by than most people think. Presentations aren’t necessarily shown to hundreds of people at a time. In fact, that’s probably the worst way to get started as a speaker. There are plenty of opportunities around in unexpected places. Here’s some examples:

  • You have a new coworker that doesn’t know how to use Git. Create a presentation and teach them all about the wonders of this versioning tool. (1 on 1)
  • You have a group of summer interns that need to come up to speed on the best coding standards for your team. Grab all that information and create a presentation that’s way more interesting than the boring wiki you normally tell new team members to read. (1 on 5)
  • Worked with some interesting new technology that not everyone on your team knows about? Present all your findings during a lunchtime/staff meeting. (1 on 10-20)
  • Go back to your alma mater and teach your 21 year old self how to do something that’s not pulling all-nighters and partying too hard. (1 on 50-100+)

You can scale your talks accordingly. Start small with friendly people that will give you great feedback…then work your way up to a larger and more intimidating audience. Once you master the few, working your way up won’t seem too bad.

Topics on the other hand…this is one that I struggled with more than finding opportunities. Especially when you’re early in your career, sometimes it’s hard to figure out what would be an interesting topic to teach others about. Topics can be too basic, too complex, too narrow, too generic…the list goes on and there’s extremes at either end.

This one is more personal – what works for some may not work for others. I took some advice from Zach Holman, who has an amazing resource on speaking. In particular, he states that anyone can be an expert on most things if they focus and narrow in on something that they’re passionate about. Even if you’re not a complete expert in that particular area, it’s really about “making your audience reconsider their own perspectives. You don’t have to be smarter than them or even be more correct than them to do that.”

Generally, chosen topics are about something that you have done or experienced personally. However,  another way to think about it is that the best way to learn something is to teach it. If there’s a particular area that you’re interested in learning more about, the best way to thoroughly understand that area is to teach it to someone else. You can’t teach what you don’t know.

Read More

16 May

Are you a bad (software) engineer if you don’t do side projects?

This is a question that recently came up on Quora and something that I’ve personally struggled with during and after college. It’s been especially hard for me ever since I started doing recruiting for Intuit, as one of the things that we look out for in promising candidates (at least at a university recruiting level) is that these students are self starters that have side projects listed on their resume. When students ask me what they can improve about their resume, one of the first things I recommend is that they work on a meaningful side project or get involved in extracurriculars to help bulk up their resume.

For me though, I feel a bit like a hypocrite because spending time on side projects is not something I do on my own time. Working as a full time iOS engineer fulfills my need to build, create, problem solve…etc. – I prefer to spend my time engaged in other meaningful learnings that aren’t as explored in my day job.

That being said, there’s definitely other ways that you can gain knowledge and continue learning without having to do side projects – they can even be your day job! I have a very similar perspective to Tracy Chou’s opinion on the matter – snippet below:

I don’t do side projects and I don’t identify as a hacker, but I do read technical documentation, articles, and books; I do attend (and give) technical talks; and perhaps most importantly, I pick my day job based on learning and growth opportunities: which company I’m working at, which team I’m on, and which projects I take on. I stumbled onto this a little bit by accident, but I discovered that responsibilities in your day job that require you to learn are a great forcing function for learning. 

Aside from these things, I’d also recommend joining Meetup groups and attending technical events/conferences. There’s nothing better than learning first hand from experts on the subject matter, and being able to discuss it with them (networking isn’t a bad idea either). What matters most is that you find what you’re passionate about and make sure that the world knows about it, side projects or not.

****One caveat to this though is that if you are currently a student, side projects are definitely one of the easiest ways to make yourself stand out among the rest of the candidates. I’ll add though, I personally didn’t do that many large side projects in school. I did, however, participate in hackathons and was greatly involved in student leadership. These were the things that made me stand out.

13 Aug

Don’t underestimate the power of passion

A person can succeed at almost anything for which they have unlimited enthusiasm.

Charles M. Schwab

I had the good fortune of being selected as one of the engineers to go to the 2012 Grace Hopper conference on behalf of Intuit. It’s really quite strange being on the other side of the table after having been a college student for five years. Suddenly, everything everyone ever told me made perfect sense. Now that recruiting season is almost upon us again, I wanted to bring up something that I noticed at last year’s conference.

After speaking with the endless amount of amazing talent at GHC, it became clear to me one thing that seemed to be lacking in even some of the most qualified candidates. Aside from the general advice everyone gives to technical candidates (study your data structures, brush up on those algorithms…etc.), there’s one specific thing that can make even the most inexperienced person someone that every company wants.

Are you ready for it?

Really ready for it?

Ok. Here it goes.


It’s as simple as that.

The best candidates are the ones that can barely hold back a wide grin when they talk about their favorite classes or the awesome project that they worked on. They’re the ones with the spark in their eyes when they describe what it was like to be involved in a student organization. They’re the ones with the delight in their voice as they describe the first time they wrote a simple mobile app that, by all means, isn’t the most technologically advanced thing most engineers will ever see, but it’ll sound like they’re describing how they discovered the cure for cancer. Those are the memorable ones.

Technical skills can always be developed. There’s no question about that. But, if the passion for problem solving and delivering something that can potentially revolutionize the world isn’t there, then it’ll never be there. That’s something that can’t be taught. You can fill your resume with amazing projects and a ridiculous number of technical skills that would make any recruiter drool, but if you don’t have any passion for the things you worked on, then people won’t be excited about you and what you can bring to the team. You’ll fade into the background, lost in the endless sea of resumes that get collected at these conferences and career fairs. Trust me, that’s the last thing you want to do.