Hi, I’m Sam.

Recently, I spit in a plastic tube and mailed it to California. While that sounds like a fun prank, it was to get my DNA tested by 23andMe. The first few minutes of this video show the unboxing/spitting.

23andMe is a really neat company that has been around since 2007. They process your DNA and tell you what it means. It's only $99 to get yours tested.

Here's the highlights from my results.

Traits

The most fascinating part was the traits. Here are a few of the interesting ones:

It's crazy how all of them were right on. Fascinating.

Disease Risk

It also shows tons of diseases and your risk for them. Here are a few that are below for me.

Of the ones that had increased risk, none of them were too scary thankfully. Before they tell you a few of them, they present a ton of information and you have to click I understand before they tell you the result (Alzheimer's for one). Thankfully, I have a lower risk for all of those.

Ancestory

I knew my mother's side was British before coming to America in the colonies. Seeing a tad of Native American and African in there makes sense. I knew there was some Cherokee in there, so it was cool to see the results matched that. You can really drill down on this graph. Here's the overview though:

This wasn't as interesting to me as the health/traits stuff, but still pretty cool.

See My Genome

I posted my genome on GitHub: github.com/soffes/dna. You can download it and look through my source code. Pretty fascinating.

Pull requests welcome.

For iOS development, I don't use Interface Builder. I haven't willfully used a NIB (when I say NIB, I mean Interface Builder file, not the specific format) since iOS 2.0. In the past, I've worked with a few folks that really liked using Interface Builder. This is an argument I've had over and over.

Instead of mindlessly arguing on one side or the other of this, here's my go to points when I'm trying to win someone over.

Choosing Explicit over Implicit

Choosing to be explicit is my number one reason to do things in code instead. If someone new to the team opens up a view or view controller, they can see right away where everything is and not have to wonder if this file has a NIB.

I have spent countless hours searching for the source of a bug only to discover it's some checkbox in one of the half dozen inspectors in Interface Builder. If it was in code, it's simple to glance at the view code and see the source of the problem much quicker.

Tight Coupling

It is much harder to use Interface Builder for reusable views. I constantly create little views and reuse them all over the place. That's kind of the point of working in an object-oriented environment. If you use Interface Builder and have outlets and forget to connect the outlet in the second place you use it, you crash at runtime. This is terrible. This introduces a whole new class of bugs.

Now we have this thing that crashes simply because we're using Interface Builder instead of using code. If it was the exact same thing in code, it wouldn't crash. Even worse, the compiler can check this for you.

Not to mention, if you use lots of custom views, your NIBs will just be a bunch of invisible boxes. So now you have this tight coupling that is even harder to work with if you were to just lay it out in code.

Have you ever sat staring at some code wondering why it's not working on to realize you didn't connect the outlet or action? I hate that.

Working With Others

Have you ever had a merge conflict in a NIB. It's the worst. (Granted the XIB format has helped, but it's just awful instead of impossible now.) If you're working in a large application with several developers, you will waste an enormous amount of time dealing wit this issue.

The worst part is if it gets automatically merged wrong, you might not notice until runtime. With code, you can read the diff and understand what's happening. NIBs (in either format) are not human readable. This also makes looking at the history of a file useless. If it was code, it's just Objective-C. We're good at that.

It's Part of Xcode

This used to be more of an issue, but I think it's still worth mentioning. To put it lightly, Xcode is not the most stable piece of software in the world. The text editing part works pretty well. Every time I get a crash while editing a NIB, I grumble to myself and wish it was code even more.

The less I have to use Xcode for more than anything except a text editor with completion and a compiler, the happier I am.

Location, Location, Location

Layout code is not hard. Auto-layout is a bit more code than traditional layout, but it's still not bad. Trying to work with auto-layout in Interface Builder is maddening. Setting outlets to control built-in constraints is just silliness.

It's so simple to just override layoutSubviews and do your thing. Personally, I find this much easier to work with than auto-layout for most things.

I think this is a lot of people's biggest fear is working with layouts in code. Once you get the hang of it, it's so simple. Making your app universal becomes much more tribal than making separate NIBs for iPhone and iPad. You can simply reuse your code instead of create this tight coupling.

Bottom Line

Interface Builder itself is not bad. It does encourage bad practices, prevent reusability, make working with others more difficult, and slow your workflow. Personally, I avoid using Interface Builder (including storyboards) as much as possible. All of the projects I've worked on since 2009 haven't had NIBs unless it was out of my control.

I think you should save yourself some time, learn a few things, and start moving to code. We are programmers after all.

As a developer, designing is a big challenge. My process is a lot different than "normal designers." I design much like I code: trial and error.

When I'm programming, it's constantly running the tests to see what failed, trying a fix, repeat. It's finding a bug, try a fix, repeat. You get the idea. That's how I work. It's constantly iterating on ideas to see if they work.

When I was first starting out, I'd find myself reading entire source files to try to understand everything that was happening and only running the code very rarely. It's no surprise that were lots of bugs in this code. Letting the computer do the work for you is like the whole point. Anyway, this is how I design.

Sketching

Sometimes I start by sketching on paper or on an iPad. I only do this if I have no idea what I'm trying to do. If I can't picture what I'm trying to make in my head, I sketch. There's something about sketching that really helps me visualize the end result. Scribbling down idea after idea is where most of the actual "designing" takes place for me. Again, it's an iterative process.

So once I have a rough idea of the structure and layout, I jump into code. I don't use Interface Builder at all (on iOS anyway—Mac is a different story). I haven't used Interface Builder since my very first application (unless it was removing other people's NIBs). We'll save the why for another time.

Prototype Early

On iOS, it's so easy to just get something you can use. Just through together some UINavigationControllers, etc. A lot of developer confuse "design" with "visual design." They think it's only pretty pixels. The flow is the most important part. If your app is super pretty but no one can use it, it's pretty useless.

I like to just get something I can use on my phone with all system controls. If things feel good, then I move onto designing pixel. Most of the time, my first take is terrible and I go back to sketching. Iteration.

Pixel Time

For pixels, I work the same way. Once I have the layout, it dictates what needs some extra love. If I can't picture what I'm doing, I'll open Photoshop and mess around until I see something I like. A lot of the time, I don't save my PSDs. They are just pixel sketches. Once I know what I'm doing, I start implementing in code.

I often try to implement as much as I can in code instead of using images, but sometimes it's a lot easier to just use an image asset. I have an "asset farm" PSD with all of the assets I need. I keep this one around for when I inevitably change something.

Go

So there's no secret to getting into design. Just do it. Go get a piece of paper and start scribbling down your ideas. If you want to get better as a designer, go browser Dribbble or the App Store for inspiration. All you need is inspiration and iteration.