Lazy, impatient & overly-proud: Building great experiences for great developers

From ‘’how do I do this’’ to ‘’hello world’’ in a blink of an eye.

A few weeks back, we wrote about the importance (and struggles) of designing software developer kits (SDKs) our end users can seamlessly interact with.

But a topic that rarely comes up in this space is that of developer experience (DX). People seem to forget that developers enjoy simple, engaging experiences as much as the last person in front of the screen. 

The difference is, if a developer gets stuck or confused trying to integrate an SDK into their app, even the most functional, delightful component will never see the light of day.

Here at Microblink, we are doing all we can to avoid this from happening. 

We know that the developers browsing our scanning solutions want to get up and running with one of our SDKs without having to reinvent the wheel and that, once integrated, they expect it to work flawlessly inside their own app. 

So how do we go about creating such an experience?

By embracing their laziness 

Larry Wall, the creator of Perl, was the first to coin three tongue-in-cheek virtues that set good developers apart: laziness, impatience and hubris. He described laziness as ‘’a quality that makes you go to great effort to reduce overall energy expenditure.’’ (1)

We’ll agree with that. Developers have a lot of work to get done and if there’s a low-effort solution that will help them get it done faster, they’ll come up with it. 

That’s why we don’t force them to spend hours doing work that can only take minutes. Yes, the technology behind our SDKs can get quite complex, but the integration rarely involves more than a few lines of code. 

Also, we are keeping our ears to the ground trying to figure out the next best feature our developers will need. When we release a new version of our SDK, that feature is usually already there.

Another thing we avoid doing when writing our SDKs is bombarding developers with features, methods or variable names they’re unfamiliar with. 

This should feel like a natural extension of their apps, which is why we’re sticking to naming conventions and syntax they’re used to. 

For example, on Android, it’s onActivityResult that returns scanned results whereas on iOS, the same method is called via a view controller and a delegate.  For developers working with a single codebase, we’ve wrapped a good chunk of our SDKs into plugins for the most popular cross-platform frameworks out there. 

Everything we do, we do in an aim to do as much heavy lifting for developers as we possibly can. When they’ve got less code to deal with and fewer things to worry about, our SDKs stand a better chance of finding their ‘happily ever after’ in a real app.

By saving them time

In the same way patience can be a weakness, impatience can be a virtue. If developers weren’t impatient by nature, you’d be seeing Apple’s spinning beach ball of death much more often.

Developers exploring our products get intrigued by the idea of having their app scan ID documents, credit cards, boarding passes and anything else in a fraction of a second. Often, they’re itching to get something working quickly, without having to license the SDK straight away.

We understand that. To mitigate their impatience, we let them clone and run sample apps relevant to their use case so that they don’t have to dig too far into our documentation. 

And if even that’s too much work, they can just download the Microblink Vision app for iOS or Android to see our SDKs in action.

By letting them have the last word 

As is the case with any other craft, app development carries a dose of hubris — or excessive pride — alongside it. And that’s okay. To a developer, the feeling of shipping an app may not be much different to that a sculptor gets from having an exhibition on. 

That’s why we’re letting developers have the final say in how our SDKs will function or look like inside their app. If laziness takes a backseat to hubris and they believe they can implement scanning better than us, nobody is stopping them. 

A developer can use our built-in scanning flow out of the box, customize or make a new UX from scratch and even take control of the in-app camera management.

We allow them to get their hands dirty and go full custom, knowing we would be stuck working with dated languages and frameworks forever were it not for overly-confident developers saying ‘’Meh, I could make this work or look better.’’

Remember: developers are users, too

While laziness, impatience and hubris may not come in handy when you’ve got a pile of dishes soaking in the sink, they can be a powerful driving force of efficiency and innovation when developing applications. 

Because, at their core, what they really are is a disguised desire for efficiency. Developers just want to get their job done faster and better. And that means less meaningless code, less unfamiliar terminology and more time spent on creating instead of onboarding.

When building our SDKs, we need to be mindful of these things and strive for a developer experience that’s so intuitive it barely gets noticed. The sort of experience we rush to deliver to our end users but often forget to recreate for our developers.

Our intelligent scanning solutions are built with developer experience in mind. Try them inside your app for free.