Thinking Like a Cocoa Programmer

Being a great Mac or iPhone programmer means more than just knowing Objective-C and the Cocoa, it means thinking in a different way about designing and writing software. Understanding how experienced Cocoa programmers look at things will help you get closer to becoming an expert.

First and most importantly, the Cocoa programmer's focus is always the end result for the user, not the academic sophistication of the code. Start with the simpler, lower-tech solution and switch to a more complex one only if there's a clear reason to do so. This ain't no science fair. The only person you need to impress is the user.

How To Make Great Software

Avoid overdesign — Don't sit down to design big, sweeping architectures that try to address every case that could ever exist. Instead, start by targeting scenarios that actually exist right now using the tools available now. Come up with a solution for one part of the equation, learn what you can, then move onto the next iteration.

Avoid underdesign — Don't blindly implement specs. See the spec as a starting point, and then continually ask the question "does it really make sense to do it this way?" We're making software for a human, after all, not a piece of paper.

Overdesigning for fun — Mac programmers experiment with over-engineering solutions for the sheer joy of doing so. In those cases, they're trying to impress each other, but only in the spirit of having fun and challenging each other to do better work, and only when it doesn't compromise the overall quality or ship date of the product.

Optimization — It's counter-productive to optimize before you know what you're actually building. Get something working, then rearrange it into a reasonably clean design, and optimize for performance after that. Do start with streamlined implementations of things you know you'll need, but the key is streamlined, not obsessively optimized.

Experts write less code — Experienced Cocoa programmers start by assuming the frameworks do the right thing, and look for ways to tweak the built-in classes before resorting to writing custom implementations from scratch. Custom code has to be maintained, so use built-in code whenever possible.

Frameworks and API — When creating a reusable framework, it's far better to solve a practical problem in an end-user application before trying to generalize the code into an API. If you try to create API by guessing, you'll probably end up with the wrong design.

Experience, Inside and Out

It's everywhere — Cocoa programmers think about user experience at every step. Novices think user experience is just on-screen graphics, but it includes things as subtle as the capitalization of text in a preferences window, the name and location of data files, and even the phrasing of messages in the console.

Users aren't stupid, they just have other things to do — Don't assume the user is an expert, but don't talk down to them either. Non-experts are usually intelligent people who don't spend as much time thinking about software as engineers do. Assist the novice user to whatever degree you can without making the software a chore to use for experts.

Code counts too — The developer's experience of reading the code is significant. The developer is you for the moment, but it may be a future version of you, another developer, or a mob of developers if the project is later open sourced. The need to ship software may override the desire for beautiful code, but at least try to arrange things so they can be cleaned up later.

How To Make Great Software Better

Be an advocate for the user — Experts vigorously scrutinize their software as a painter would scrutinize a painting, looking for any reasonable opportunity to improve it without holding up the project as a whole. You're not doing this to impress co-workers, you're doing it to be an advocate for the end user's experience.

See the forest — When scrutinizing software, true experts don't look at it purely as a collection of individual parts. The user sees the final result as a whole, and a great piece of software is as much art as it is science. The highest-level goal is satisfaction, and that may involve doing some really illogical, counter-intuitive things at times.

Feedback — Experienced developers don't let critical feedback get them down. Welcome and thank someone who volunteers insights about your software because it's incredibly valuable information. Don't take it personally because anyone who criticizes too harshly likely hasn't attempted the same kind of work.

Knowing what to not implement — Experts can identify well-intentioned feedback which doesn't really apply to what the software is trying to accomplish. It's not helpful to implement every feature that is requested. A big part of making a successful product is knowing which features to not implement so that the most important ones can shine.

We Make the Rules, We Can Break Them

Any of these rules above can be bent or broken in pursuit of the first rule — making something great for the user. Remember to enjoy what you do because it will reflect in your work.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.