Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

A Coder Interview With Mike Ash

0.00/5 (No votes)
22 Feb 2012 1  
Welcome to our continuing series of Code Project interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Mac and iOS developer Mike Ash

Welcome to our continuing series of Code Project interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Mac and iOS developer Mike Ash.

Who are you?

My name is Mike Ash, or more commonly known in the programming community as simply mikeash. I live in Alexandria, a suburb of Washington, DC, and am a software engineer with Plausible Labs, a worker-owned cooperative based in New York and San Francisco.

Since the next question after I say that is always to ask what exactly a cooperative is in this context, it means that we have essentially no hierarchy, we largely govern by consensus, and everybody has a say in corporate decisions. I’m pretty new to PL, but so far it seems to work out really well.

What do you do?

I spend most of my time at PL these days working on a mobile app simply called Comics, which we develop for comiXology. They are the premier distributor of digital comics, including all the big names like Marvel and DC, and the Comics app is their digital purchasing and reading platform on iOS and Android, including the Kindle Fire.

I’ve spent a good chunk of time working on both versions, mainly on backend stuff like the download and storage systems. I’m good at manipulating bits and bytes, but not so good at human factors, so the more hidden areas are my specialty. I’m fortunate to work with extremely talented designers and UI programmers at PL so we have all the bases covered.

Before joining PL in the summer of 2011, I worked at Rogue Amoeba. They’re a small, independent company concentrating on consumer-level Mac audio software, including software for recording, editing, and broadcasting audio. Again, I tended to concentrate more on backend stuff, including audio processing code and networking code, and I’m happy to say that I had some part in pretty much every product they make. They’re a great group and great products, and worth checking out.

I’ve also worked on a fairly extensive set of open source libraries for Mac and iOS development. Once again, my code tends toward low-level backend stuff. No custom buttons here! My most popular libraries are probably MAObjCRuntime, an object-oriented wrapper around the various introspection facilities of the Objective-C runtime, and MAZeroingWeakRef, which adds zeroing weak reference support to Objective-C. (Objective-C has zeroing weak references built in now with ARC, but only on the most recent OS release, and only when using ARC. My library has neither of those limitations, and so can come in handy when targeting older stuff.) My libraries are available in my GitHub repo.

What is your development environment?

My main work computer is a 2008 Mac Pro, an 8-core 2.66GHz Xeon machine with 16GB of RAM and a 256GB SSD as the primary boot drive. It’s beautifully fast and can generally take anything I throw at it. I have two 23" monitors connected to it, generally using one for code and the other for documentation, auxiliary code, chats, etc., but I’m not too consistent about it.

For Mac and iOS work, I spend my time in Xcode. I am not a fan of Xcode, and I especially think that Xcode 4 was a major step backwards in terms of UI and stability, but there aren’t a lot of other choices out there. I’m interested in trying out JetBrains AppCode, but haven’t had a chance to really give it a shot just yet.

For Android work, I use IntelliJ. It’s not a very Mac-like app, but after getting used to it I’ve found it to be pretty decent. I previously used Eclipse for Android development, but it was slower and more finicky in terms of getting it to talk to my Android devices.

I do some Python on the side as well, mostly to maintain my web site and for a few hobby projects. For that, and for little ObjC programs, I use SubEthaEdit, a lightweight plain text editor for the Mac that’s mainly known for its realtime collaborative editing feature. I’ve almost never used the collaborative editing feature, which makes me a little sad, but it’s a decent simple text editor.

Of course I also need test hardware for these mobile apps. I have a fairly crazy collection of several iPads, a Kindle Fire, a Galaxy Tab, and two iPhones.

What new tools, languages or frameworks interest you?

IntelliJ, Java, and the whole Android environment are still pretty new to me. I only really started doing Android stuff seriously a few months ago. It’s an interesting mixed bag compared to iOS development. On one hand, it’s really nice to have modern language features like garbage collection, namespaces, etc. On the other hand, the lack of lambdas is a serious pain, and Java’s overall verbosity can be a little wearing.

On a completely different note of new tools, I’ve also started playing around some with Arduino. That kind of small-scale hardware-ish work is really fun. Unfortunately, I have a little trouble coming up with interesting things to actually build with it, but so far I’ve built a hardware CPU load monitor, using a line of LEDs as a realtime graph, and an automatic audio switch, which switches a set of speakers between two input ports depending on which one is playing audio at any given time.

What is your coding pet peeve?

I’m not sure that I have a coding pet peeve. In general, I try to be flexible, use whatever techniques are needed to get the job done, and try to fit in with the team and code base I’m working with.

I suppose that if I had a coding pet peeve, it would be people who concentrate so hard on their pet techniques and procedures that they lose sight of the job. Spending half an hour arguing where to put the asterisk is not productive! Any competent programmer should be able to adapt to minor differences in style or technique, and who knows, you might even learn something new if you try things the other guy’s way.

That said, although I don’t much care how you achieve it, your code MUST be clear. I have no mercy for the (thankfully rare) people who think indentation in general is unnecessary, variable names can be named after characters from their favorite TV shows, etc. I’m not going to say that you must format code my way, but you had better at least do it some way.

How did you get started programming?

My programming history is fairly long and boring. I started out doing BASIC on the Commodore 64. I never got too far with it, but it was my first taste of things.

I then graduated to an Apple IIGS, initially doing BASIC there, then Pascal. Still didn’t get too far, but I did make a couple of simple games and other toys.

After that, I got a Mac, and started doing Pascal on that, then moved up (down?) to C. I made the jump to Mac OS X and Objective-C around the initial release of OS X, and went from there.

How has the developer community influenced your coding?

The developer community has taught me so much. Official documentation and examples will only take you so far, and pure solo exploration has its limits too. I’ve learned interesting, devious, and incredibly useful techniques from my peers.

I mainly use Twitter, GitHub, IRC, and my own blog for that sort of thing. I’m lucky to have a group of extremely intelligent and high-signal commenters on my blog.

On the bad side, the iOS community at least is overall far more loving of Apple than I think is justified. Apple’s relationship with the iOS developer community has been highly contentious, from the Jobs’s original “sweet solution” of having everyone do web apps to painful and inane App Store review processes. And yet, in all of these cases, there are inevitably loud voices defending, even praising, Apple for moves which directly hurt us.

I think that too many iOS developers treat Apple like it was their hometown sports team, seeing Apple’s successes as their own, and Apple’s failures as their own, and their self-image inextricably tied to the mothership. Overall, I think this attitude lets Apple exert far more control over their ecosystem than they otherwise would, and far more than is truly healthy for independent third-party developers.

What advice would you offer to an up-and-coming programmer?

For up-and-coming programmers, my advice would be to never stop exploring, never be afraid to try things, and read, read, read. Far too often, I see people establish a small zone of comfort and then never leave it. It’s an easy trap to fall into, but you’ll miss out on a ton of opportunities to do interesting stuff if you do.

When confronted with something mysterious, figure it out! People hit a mysterious crash inside Apple’s code, for example, see an assembly dump in the debugger, and throw up their hands and stop trying. Don’t! There’s nothing magic about assembly. You can learn the basics in an afternoon, and that knowledge will serve you for life. Obviously, registers and conditional jumps and raw memory access are a far cry from the softer object-oriented worlds most of us spend our time in, but it’s not any harder, just different!

The same goes for code in unfamiliar languages, for unfamiliar algorithms, unfamiliar data structures, you name it. Every time you encounter one, it’s an opportunity to grow, to learn, and to become more excellent at what you do. Some things may still go over your head or be beyond your level of knowledge, but don’t just assume that’s the case because something is strange.

Finally, don’t be afraid to try things. Programming may well be the most forgiving creative endeavor ever to exist. If you screw something up, generally nothing happens. Nobody dies, no equipment gets destroyed, no volatile chemicals get released. You don’t even waste any materials! Can you imagine an architect testing out a design technique by building a test house with it and seeing if the result is any good? The amount of time and money involved would be prohibitive, and if it really goes badly somebody could even get hurt or killed. But to do the equivalent as a programmer is practical and routine.

Many people will spend hours doing research on a question that would take 20 minutes to test. Reading is great, but you reach a point of diminishing returns, and experimentation can teach you so much. Failure is cheap, so take advantage!

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here