Becoming a Better Engineer by Doing Support

For many developers, support is perceived as a chore that’s not as exciting a task as writing new features is, but I have a different take on it: Spending time working on support has made me a better engineer. More specifically, being able to unblock other developers has taught me that everything is possible. By doing support, I’ve been exposed to use cases I hadn’t anticipated and scenarios I didn’t think were possible.

At PSPDFKit, we believe it’s always about people — that’s why we do what we do. This philosophy is one of our core values; it’s deeply entrenched in how we operate as a company and as individuals, and it is reflected in how we go about building relationships with everyone around us.

Our company occupies an interesting position in the software world, because we build products that are used by other people to build their own products. As such, offering world-class support is as important to us as our SDK itself.

In this blog post, I’d like to share how being part of organization-wide effort to keep our customers moving as fast as they can when integrating PSPDFKit into their products has impacted me and is helping me become a better engineer.

Support Is an Engineer’s Job

PSPDFKit is comprised almost entirely of people working on the SDKs in one way or another, and we do not have a dedicated support team, which is something that many other companies do have. We decided against a separate support team because it is important for us to “get our hands dirty” and have real exposure to the issues our customers are facing.

What this means is that, with PSPDFKit, if you’re using our Android SDK, someone building the Android SDK will be there to assist you with any questions you may have. This is beneficial not only for the customer, but also for us as a team that’s always trying to improve.

Building and supporting an SDK is a huge challenge. As an engineer on our iOS SDK, my task is to design APIs and components for other developers to use, which in it of itself is super tricky to get right. If the company had a dedicated support team, I would not have the direct feedback loop of learning firsthand what our customers are trying to do, thus hindering my ability to actually understand what makes a good API and product for our customers.

Being on the frontline supporting our customers also gives me the chance to make sure our documentation is always updated. If a customer reaches out with a question, my first instinct is to see if we have the answer already documented, and then, depending upon whether it is or not, I can either make sure the existing document is up to date or is updated to add any additional details that might’ve been omitted, or create a new document that explains the issue at hand in detail.

In contrast, when the people interacting with the users are not the same people actually building the product, there’s a huge separation of interests that can lead to a less than ideal relationship.

Increasing Empathy

Before this job, the idea of doing support at a company always struck me as a burden, or as something not as interesting as actually building a product.

However, through being exposed to the comments, questions, frustrations, and overall feedback from people using APIs and modules that I’ve worked on to build their own businesses, I’ve gained more empathy for our customers. I also have a better attitude about trying to solve issues now that I know how our customers use our products, because I get to see how our decisions directly affect them.

Truth be told, it can be both daunting and taxing to read bug reports, investigate them, and come up with solutions that both solve the issue at hand and improve the SDK. But in spite of that, when I go back to building PSPDFKit, I have an increased understanding of what people will look for, what they’ll expect, and how I can serve them better. It’s, plain and simple, a win-win situation.

What’s more is that being on support duty has also made me better at reporting issues to other people and companies — which is something that we as engineers also have to deal with on a regular basis.

Edge Cases of the Edge Cases

When deep into feature work, it’s really easy to get lost in my own head, making assumptions about how what I’m working on will be used and in which scenarios.

Since working on support, I’ve learned that any expectations I have about the use of an API or an environment should be thrown out the window. I’m fortunate enough to be working on a product that’s widely used across many different types of applications trying to solve an amazing number of diverse problems, and so it’s natural that I’ll encounter edge cases I wouldn’t have thought of myself.

There’s a misconception that as engineers, we must know everything there is to know about a system and the environment in which it will be used. But the fact is that we’re all humans, and there’s stuff that we’ll either miss or not know about. And naturally, those gaps are made more obvious when you’re faced with helping a customer get unblocked.

Since being exposed to the breadth of possibilities out there, I now take a humbler approach to solving issues and make an extra effort to put myself in the customer’s shoes to think beyond what I thought was possible.

Be One Step Ahead

In case it didn’t come across in the previous sections of this post, let me make it clear: I enjoy doing support for our products. However, ironically enough, the more I’m helping with supporting our customers, the more chances PSPDFKit (the company) gets to reduce actual support work.

By being involved in supporting our customers directly, I gain the ability to learn from our previous mistakes, see into the future, and take preventive action so that, eventually, our customers will only want to reach out to say thank you.

Conclusion

After riding a roller coaster of emotions that started with me rolling my eyes back at the idea of handling support requests, to it being one of the aspects I enjoy the most about my day-to-day job, I can confidently say that support should be something every engineer has to do at least once, for it is as important as the product itself.

When the people building the product are also the ones exposed to learning how it is being used in the real world, the engineers stand to grow in both knowledge and empathy, and as a result, the product itself can only get better.