Tuesday, December 21, 2010

Non-Deterministic Problems aka Finding Talent

As programmers, we usually deal with deterministic systems. To state it simplistically, deterministic systems are systems where the same inputs always results in the same output. Unless we intentionally introduce randomness¹ or have a relatively rare kind of bug in our code, the same inputs to our programs will always yield the same output. It could very well be the wrong result if our algorithm is bad, but it should be the same wrong result every time, which is a trait we rely on heavily.

In the real world, most things we encounter are non-deterministic. There are always factors we can't control or measure, and most systems have a human element. We are at the mercy of whim and emotion, and that's hard for a lot of programmers to deal with. Our fellow humans's decisions are decidedly non-deterministic and hard to predict, as are ours (though we usually don't notice this trait quite as much in ourselves).

You may have noticed that I haven't had much time to write lately. I've been exceedingly busy of late, even by my own standards. Although a lot of my time is being spent writing and debugging software, I've also been involved with some very non-deterministic problems as a result of my involvement with some large, complex development projects.

Probably the biggest non-programming problem that I've had to deal with lately, which most of my industry peers and nearly all of our clients are dealing with also, is finding good, experienced, reliable developers to staff projects. In short, there aren't enough experienced mobile software developers to go around. There simply aren't as many developers with multiple successful projects under their belt as there are companies who need the services of such people. I know of one large company that currently has ten open requisitions for mobile developers - five iOS and five Android - and no viable prospects at the moment. I helped one client recently bring aboard a good iOS developer, which took several months, and then I very quickly regretted it, because MartianCraft could really use that developer's services now.

Yet, on the other hand, whenever I blog about just how much work there is right now, I inevitably get several e-mails or comments from developers wanting to know how to find all this work. I make it sound like it's raining work, and they're not getting wet.

Given that, I thought it worth a few minutes to write about both sides of the equation: how to find developers, and how to find work as a developer. This isn't an exhaustive treatment, just a summary of recent observations.

For Developers: Finding Work



Unfortunately, I've got no silver bullet for aspiring developers. Overnight success is often indistinguishable from years of hard work. There are countless issues around getting that are not mobile development-specific that I'm not going to touch, such as a willingness to relocate ("go where the work is").

As with any industry, a large part of finding work is establishing a reputation and getting to know as many people in the industry as you can. Though it's expensive, you really need to go to WWDC, and probably a couple other conferences as well. About half, maybe even more, of MartianCraft work has come directly or indirectly as a result of one of us attending a conference. Conferences are where we meet our peers and where we develop and maintain our relationships with them. You should also attend CocoaHeads and/or NSCoder Night if you have one near you. This is where you can meet and get to know local iOS and Mac developers. On the Android side, there are similar meet-ups that you can attend.

When going to hire or subcontract a developer, most people I know will automatically prefer someone they've met, talked with, and maybe shared a drink with over a stranger, no matter how good the stranger's resume looks. Confidence in someone's ability to get a job done comes more rapidly from personal interaction. Resumes are sterile, but sitting down and working through a tough bug with somebody gives you a real feel for the other person's character and technical chops in a way you can never get from a resume.

At conferences, don't worry about going to every session. Everybody tries to at their first DubDub, but don't. Really. Pace yourself so you can socialize in the evenings. That may sound like bad, or even frivolous advice - as if I'm telling you to play hooky, but the information in the sessions can be found again. Most conferences videotape their sessions, and usually some of the attendees do joint note-taking using SubEthaEdit and make those notes available. But socializing with industry peers is vital if you want to do this full time, especially as an Indie. These are the people who can give you work (and accept work when you're too busy to take on new work yourself), and they are the people who can help you when you're stuck on a gnarly technical problem. These are the people who can give you a different perspective on something you've been staring at for far too long and are the people who can help you become a smarter, better developer.

Though not perfect, the iOS and Mac developer community is incredibly giving and helpful. It's not uncommon for direct competitors to help each other out and consider each other friends. Most of us realize that it's not a zero-sum game, and helping out others in our community usually comes back with interest. Scratch that. Not usually. Always.

Getting ongoing work requires more than being liked by other developers, however. You have to give people a reason to have confidence in your abilities. Creating or contributing to open source projects can show huge (if not immediate) returns. In the early days of iOS, before Core Data was available, my SQLitePersistentObjects project brought me nearly as much recognition as having my name on the cover of iPhone programming books.

Regular blogging is also a huge opportunity. Not only does it give people an idea of the depth of your knowledge, it gives you a chance to learn and improve. I don't think I've posted more than a couple technical blog posts where there wasn't either a correction or improvement sent to me by a reader, and often there were many. Just remember not to get defensive or depressed when it happens. You don't stop making mistakes until you stop living, but if you keep learning, you can avoid making the same mistake too many times. Readers who care enough to point out your mistakes are valuable beyond belief. Tame your ego and cherish them. Nobody's going to think less of you as a developer for occasional mistakes or less-than-perfect code.

But, no matter how much of the above you do, there is one absolute prerequisite to getting work on an ongoing basis: you have to have the technical chops. This is probably the hardest thing to figure out. I've met many great developers who lacked confidence in their abilities and I've met some who've had far too much confidence in them. It's really hard to gauge your own ability and it's almost always sobering to revisit older code you've written. No matter how good you get, there's always room to get better and if you're doing it right, you will. As developers, we're paid as much for our ability to quickly assimilate new knowledge as we are for the things we already know.

Don't worry too much about your whether you have a specific degree, or a college degree at all. You don't have to have a computer science or computer engineering degree to be a good programmer. There are many, many great programmers (including inside Apple) without those degrees and, in fact, without degrees at all. College is one way to get the information and some of the experience you need to be a good programmer, but it's not the only way, and it's possible (though probably not common) to get through school with a CS or CE degree and completely suck. Some of the worst iOS programmers I've encountered have both degrees and programming experience. Objective-C is a bit of a weird beast, and overconfidence is a big problem for experienced developers coming from C++, Java, and C# background. They look at Objective-C, see familiar aspects, and think they know what they're doing, sometimes completely oblivious to the differences between a static, strongly-typed language and a dynamic, weakly-typed one or the differences between a garbage-collected language and a reference-counted one.

In a perfect world, nobody would ever be able to offer their services as an iOS developer without perfectly understanding the rules around memory management. I'm not suggesting you should, but everything else, you could learn on the job, but you have to really grok the way retain counting and memory management work to be a professional iOS developer. You can really fuck up a code base trying to fix EXC_BAD_ACCESS bugs if you don't know what you're doing and can create an awful lot of work for somebody else in the process. You can also get away with an awful lot of leaks if you're developing on the simulator that will cause significant problems later. The stakes get much higher when you're working on the same code at the same time other developers are.

One thing to seriously consider, even if you have a few apps under your belt, is to take a class or workshop. There are some excellent ones out there, including (but certainly not limited to) the Big Nerd Ranch and the Pragmatic Studio. A few thousand dollars may seem like a lot of money, but it's a hell of an investment given the work opportunities available right now. A good workshop will beat into your head the important stuff. They'll strap a firehose of information onto your face and open the spout. They will make your brain hurt, but you will come out knowing memory management and the fundamentals, and that will put you in the running.

Another key skill is debugging. Being able to fix your bugs and those you find in other people's code is vital. Plus, the more bugs you encounter, the more things you know not to do in the future. Want to test yourself? Try downloading this. It's an Xcode project — a modified version of one of the Beginning iPhone 3 Development projects — that has a number of common bugs introduced into it. You should be able to get this to compile clean (no errors or warnings), then be able to navigate into every view in the application without it crashing and with something being displayed on every view. Once you've done that, you should then be able to fix any leaks in the app using Instruments. How long it takes is going to depend on a lot of factors, but I'd say that a typical, experienced, professional iOS developer should be able to fix this in between a half hour and an hour and a half. Regardless of how long it takes, if you can fix them all without help, you've gone a long way down the path to becoming a great developer.

Don't worry if you can't find them all that quickly. The first time you encounter a particular class of bug, it takes more time. Persistence is as important as speed, and debugging this project is a good exercise. Once you see a type of bug once, it's much easier to find and fix it when you encounter it again.

If I find time over the holiday, I might do a screencast showing how to find and fix all the bugs in the project. I can't promise I'll find the time to do that given my current workload, but if I can, I will.

Lastly, if you're looking for full-time iOS or Android employment, or for contract development work, send me your resume. MartianCraft isn't hiring full-time employees at the moment, but we do often need subs, and I know of many, many open requisitions for full-time jobs and I'm always happy to pass resumes along to hiring managers.

For Companies: Finding Mobile Developers



The other side of the equation is, how do you staff a mobile development project right now? Many experienced mobile developers were attracted to the space because it offered them the ability to make a living creating what they want to create. Mobile, and especially iOS development offer opportunities for small teams without a lot of funding to make a decent living. Many of those indie developers are doing exactly what they want to be doing and it's going to be hard, if not impossible, to attract them away from that life, if they're good at what they do.

Hell, many contract developers have app ideas they'd love to be working on themselves. A friend of mine who owns a development shop stated the problem fairly succinctly recently by saying: "We've got several app ideas we'd like to build, but clients keep throwing money at us."

I don't know exactly how many contract iOS developers there are with Objective-C experience that pre-dates the release of the iPhone SDK and/or who have several successful projects under their belt, but it's less than are needed. Big businesses are finally catching on to the importance of mobile and that's making a shallow talent pool even shallower. The situation for Android is similar. Though there are more people who already know the underlying language (Java), the platform has only relatively recently hit critical mass, so there aren't a lot of people who have been involved with successful Android software projects yet compared to the work available, and even less who have successfully shipped multiple Android projects.

In all reality, you're either going to need to offer crazy rates to lure the cream of the crop to your project (and that is no guarantee you're going to get the cream) or you're going to need to invest time and money into developing internal talent. I would advise at least having one really good, experienced tech lead on any decent size project, though. As many App Store success stories can attest, it is absolutely possible to ship good software using only inexperienced developers. But, doing so increases your risk substantially. Having at least one mentor who can guide and help and solve the really icky problems is gold.

In most places, you can train developers more cheaply and more quickly than you can find existing ones, at least if you're looking for full-time employees. It's not a perfect plan - your newly trained people will be learning on the job and making mistakes and may, at times, hit problems that are beyond their ken. But, with the proper training and support, they can handle the bulk of the work, and over time, will gain the experience to handle anything. Of course, you'll have to take steps to keep them from leaving. Arming an employee with a highly marketable skill always incurs a risk of losing that employee.

You can deal with that using contract terms requiring payback of training expenses or other similar ideas, but it's far more effective (albeit harder) to create an environment where people want to work. Job satisfaction is a bigger motivator for many developers than the size of their paycheck, assuming they're making enough to be comfortable and to feel valued. We're one of the few growth industries in this economy, and there's always another paycheck somewhere if you have these skills, so if you're create a hostile environment, no amount of money is going to keep the good people around long term.

There's another option you might be considering: offshoring. Go ahead. I mean, anything I say against the practice is going to seem biased given what I do for a living, and it's true that you can get considerably lower rates by doing it. I've seen shops in other countries offering iOS development services for about what you can make working at Burger King here in the states. And there are actually success stories from offshoring to cheap development body shops. Unfortunately, there are even more horror stories. In the few cases where I've been brought in to fix² projects of this nature, it's always been a waste of time and we ended up just throwing out the old code and starting over. Let me tell you, "start over" is a suggestion that strikes fear into the hearts of project managers.

To put it as fairly as possible: Offshoring increases risk. If you're comfortable with more risk, then it might be a good choice for you. There's a chance you'll come in way under budget and be a hero. Just recognize that there's a larger chance you'll end up six months down the line starting over completely. Any way you cut it, you're likely to have language barriers, cultural differences, and a hard time enforcing accountability. The simple fact of the matter is, even in countries with considerably lower cost of living, opportunities for good mobile developers are legion, so the only way those shops can maintain those excessively low rates is with a constant stream of new, inexperienced bodies. Call me crazy, but it seems to me, that if you're going to have inexperienced bodies working on your project, you'd be better off with ones closer to home that you can train and guide and have some idea of what they're doing.

I'll be blunt. If you're looking to build a team of iOS or Android developers in-house, you've got a tough road ahead of you at the moment. At some point, we'll hit equilibrium and it will get easier, but right now, it's hard. Just as I suggested to aspiring developers, I'd encourage you to get involved with the community. Send somebody, preferably somebody with some authority to hire developers and whose day-to-day job is working with the technology, to conferences, CocoaHeads meetings, and NSCoder Nights, or the Android equivalents (Meetup.com is a good place to find both iOS and Android groups in your area).

I'm always happy to hear from companies that need iOS or Android development resources. I'm thrilled to refer potential employees your way if you're looking for in-house talent, and MartianCraft is always open to talking with with you about your development needs, whether it's for a little strategic consulting and guidance, or to fully staff a development project. And if MartianCraft isn't a good fit for your situation or doesn't have the resources available to do a great job, there's a pretty good chance we know somebody who is and does. If we do, we'll connect you with them.



1 Technically speaking, without external input of some sort, computers are not capable of true randomness, and using a pseudorandom function doesn't make a computer non-deterministic. Pseudorandomness does make the computer pretend to be non-deterministic, though, and you will appear to get different output from the same input on successive runs of the program.
2 The term that we professionals in the industry use to refer to this process is "unfucking". Surprisingly, most dictionaries have not picked up this term yet.



23 comments:

Joe said...

Thanks so much for the insightful article Jeff. As someone who has recently started getting into the mobile space, this was really helpful. I find these types of articles to be just as helpful as the technical ones.

bignerdbrian said...

Great post, as usual, Jeff.

Thanks for the Big Nerd Ranch shout-out!

Don said...

Good article.

I'm a full time C#/SQL developer who will start a full time iOS job come January 3rd. To get there, I studied in my off-hours, worked on an iOS app in-house, created a simple app for the App Store, attended CocoaHeads meetings, read books (such as Beginning iPhone Development on Safari), followed blogs such as yours and iOS developers on Twitter.

In short, you have to know your goals and have a plan to get there. Along the way, you have to be humble enough to know that you need to work hard to understand things even if they may seem simple or come easily. You may not yet know enough to recognize that you do not fully understand a topic.

Basically the same thing you'd need to do for any endeavor.

To fill the positions, the company I'll be working for started with a phone screen, then a programming test and 4 hours of discussions with the existing team. That was followed by a 2 hour resume-based interview. Companies are looking hard for this talent, so opportunities do exist.

I'm really looking forward to trying to debug the sample project. I could use the practice and confidence before showing up next Monday. Thanks, Jeff, for continuing to help and support others.

Adam Eberbach said...

If you're a developer and looking for an iPhone position, here is my tip for you - DON'T package up a sample program from Jeff's book (or anyone else's) and submit it as a sample of your own work. It's so obvious!

We're hiring (Melbourne, Australia) and are just not getting responses. So if you're looking...

Andrew said...

Great post - enjoyed the project too! 20 mins =]

Carlo said...

Great post Jeff. Nice to play with "DebugMe", 20 minutes to fix all bugs, last exercise before going to sleep.

As far as the path to become a good developer, I suggest reading a lot, looking at wonderful WWDC videos, studying open-source code, installing and try to mimic a lot of good apps (mimic some other app behaviour is a good challenge) and of course code. Besides never work alone, but have someone that evalute your app and accept all reports these testers may do on your app. I started by developing 50 USD apps on freelance websites and now my minimum request for an app is 1000 USD, so use your time to invest on it.

Here in Italy we have similar issues in looking for good developers, but for developers we have enough flexibility. Everyone wants to code in Obj-C only and nobody plans the possibility to switch to hmtl, or perl, or php because the app needs to do so (for any task), while we are looking people having the possibility to switch from Obj-C to Perl to PHP to SQL (we don't need great experts for all this languages, we just need flexibility).

As far as our methodology to evaluate a developer: we just provide him a real task. Sometime we do a pre-screening by just asking them to make a small iPhone project called "FontViewer" whose purpose is: show all the fonts available in the iPhone, display them and allow to dynamically change their size (essentially a grouped table view with label font set to the iOS font: many people stuck on this simple project!)

Evgeny said...

I really loved the "DebugMe" app. Where can I find more debugging exercises?

Jeff LaMarche said...

Evgeny:

I have no idea. I made this one for a class I used to teach. I am not aware of any other similar ones.

Sorry,
Jeff

Benjamin Egelund-Müller said...

Thank you for a very informative post!

I noticed throughout the code in DebugMe, that you almost always call [super viewDidLoad] at the end of viewDidLoad, and not at beginning. Are there any specific reasons for this? I've always followed the rule: call super first for creation, and last for destruction. Am I wrong — or does it really not matter which order things are done?

Thank you!

Dad said...

Oooh, just read this closely and found the programming challenge! Nice Christmas present - thanks Jeff!

To make this more challenging for experienced iOS developers - try finding and fixing all the problems just by reading the source and looking at the xibs (if any). No compiling and no using Instruments. Then go use the compiler & Instruments to see how you did! :-)

Dad said...

Wow! Finding everything just by reading the source and looking at the xib files was harder than I'd thought it would be (!). Without giving away the problems, I missed 4 typos, one missing nil, one infinite loop (duh), and I forgot to look over the xib files (duh - tired). Fixed most if it though.

Quite quick to find the last few with the compiler and debugger though. Trying it without them first makes me appreciate good compiler messages (!) and a source code debugger (RIP Macsbug).

Fun! Thanks Jeff :)

zack said...

This is great - The challenge is awesome. I started sitting down with it tonight but am totally stuck on a gross crash when pushing a PresidentDetailController onto the stack. Bah! Will let the brain rest and give it another go tomorrow. Thanks again!

abackus said...

"Tame your ego and cherish them. Nobody's going to think less of you as a developer for occasional mistakes or less-than-perfect code."

I think this is one of the most important things in the software field. Some times, you are fortunate to have testers. Otherwise, without peer reviewers, you are flying blind. If someone is willing to spend the time to give you feedback, they have already made a commitment to you and are a valuable ally to improving your code.

Thanks for the project! 43 minutes :)

-Abe

Steve said...

Nice recursion on the rowImage property. That one threw me for a loop. 2000+ stack frames and I knew there was something terribly wrong.

Rob Pearson said...

Thanks for the project.
Got it all working during my lunch break.

Strange, but Instruments is not showing me any leaks but I can see code not being released?

Rob Pearson said...

Hi Jeff,

Just thought I'd share a couple other bugs that catch me out more times than I'd like to admit.

BOOL iAmNotAString = YES;
NSLog(@"iAmNotAString:%@", iAmNotAString);

The second took me all of Tuesday this week to track down:

Placing [super dealloc]; at the beginning of a dealloc method, rather than at the end. I'm not quite sure how to reproduce it (it was one of a dozen classes I had wrong) but I was getting EXC_BAD_ACCESS at random times during draining of the auto release pool. Backtrace just showed the auto-release stuff (i.e. none of my code) and enabling NSZombieEnabled didn't even help.

kevin said...

im coming from a different perspective, Not seeking a developers job but would like to contribute to a small team working on the next awesome, stunningly successful iphones game. Who wouldnt ? See my site for what i can bring to a team, art and ideas - go-ideas.org
cheers

yan said...

thank you, Jeff.
I was worry and unable to see my future as a ios beginner developer.
I found your article really inspiring and helpful.
thank you so much!

Hire iphone developer said...

Hello,
Today, iPhone 4 apps development is a glorious service that is widely used for the business purpose.
karan

Cheapsocceruniforms said...

There are many brand from France, also including herve leger, and most of womens stars love wearing herve leger dress when they join in some important party. Now polo ralph lauren is very popular with youthful people, everyone want to get ralph lauren polo shirts, there are lots of online shop which are ralph lauren polo outlet, true religion jeans outlet, it will be convenient for us.

Hire iphone developer said...

Hello,
The programmer developer you are checking out should be able to work for you on the part time as well as full time basis, like on hourly, weekly or monthly basis, which would be as per your business requirements.

Hire iphone developer

Srijeet said...

For iphone 3g and 4g issues check out the following link http://miesterdisplay.com/iphone-applications-development.html

Srijeet said...

For Iphone 3g and 4g issues check out http://miesterdisplay.com/iphone-applications-development.html