I’m about two months into learning how to develop iOS applications, and I think I’ve located the key to consumer software engineering (not that I am even close to being good at it, mind you).

It’s not mathematics. In fact, unless you are developing a brand-new machine learning algorithm, math seems to have very little use in commercial software development.

It’s not facility with complex systems, although an ability to visualize interdependent relationships between components helps when laying out models and tracking down bugs.

It’s reading. Competent software engineering ultimately boils down to reading.

I should be thrilled by this realization, because I’m good at reading. I can plow through any kind of fiction at warp speed, and I’m handy with expository material too, whether journalistic or academic in flavor. I’ve been a professional researcher of one form or another for a long time.

Unfortunately, this isn’t the kind of reading I’m used to. This is technical reading. And it’s freaking difficult.

By way of explanation, good consumer software engineering seems to boil down to these three requirements, in order of importance:

  1. Build a product that works as intended,
  2. And will continue to work indefinitely,
  3. As quickly and cheaply as possible.

Notice what’s not on the list.

Build something that works flawlessly at release? Always nice if you can do it, but not likely and not really expected, either. Build everything yourself from scratch? That takes way too long. Build additional features on top of what’s strictly required? Not unless you come in early and under budget. Find a new, more elegant way to solve a problem someone else has already solved? Fixing stuff that isn’t broken is a cardinal sin.

Consumer software engineering is the art of determining which preexisting components you need, locating them, and then combining them in the right wayAnd from what I’ve seen so far, there are many, many excellent components out there just waiting for someone to grab them off the shelf and reassemble them into a billion-dollar product.

Other engineers, computer scientists, coders and tinkerers have been spitting out solutions to difficult problems for decades, both commercially and in the Open Source community. One excellent example I’m learning about right now is Parse, which is a pretty damn solid cloud database solution you can plug right into and start using for free. Someone could very easily use it to build the next Facebook or Instagram in about a week… provided they had the idea for the next Facebook or Instagram (which is an entirely different kettle of fish).

The point is that these building blocks effectively form layers of abstraction that should eliminate entire classes of problem from an engineer’s purview. But again, in order for you to gain access to these amazing shortcuts, you’ve got to know what you’re looking for. Then you’ve got to find it. Then you’ve got to figure out how the hell it works!

And that’s where all the reading–and a fair amount of writing–comes in. Now that I’ve gotten through the nuts and bolts of Objective-C and the basic iOS components, and I’m moving into building real products, I’m spending about 30% of my time on Google and Stack Overflow merely trying to describe the problems I’m trying to solve, in order find the right off-the-shelf tool.  And once I find those tools, another 40% of my time is going to reading documentation and forum posts to try to flatten my learning curve. I spend the remaining 30% trying various things in code.

This is nasty, frustrating, smash-mouth research, conducted in a technical vernacular that I barely understand. The sources are written by people who, to put it charitably, do not necessarily specialize in communication and may not be very sympathetic to beginners. Effective examples are few and far between.

So it’s pretty weird to find myself enjoying it.

Weirdly, I don’t seem to mind banging away on a single small problem for hours at a time, rooting through manuals and bugging people on forums. Because when the damn thing finally works, it’s like I’ve found the Philosopher’s Stone, and I get to enjoy that feeling for five minutes until it’s time to move on to the next intractable issue.

I’ll tell you this much, though. If I ever get to the point where I’m designing my own tools and components for others to use, I’m going to make sure a fourth-grader can read my documentation.