It|was|after|11 PM and an invite for a mandatory team meeting popped up on my phone, from the director, for 9 AM the following morning. This cannot be good, I thought . My fears were confirmed during the meeting: the product that my team had developed from the ground up over 6 years was being migrated to a group overseas. My job was being eliminated.

Management offered me a role in another business unit, but it was to provide developer support - for the product that I had invested 6 years of my life building. My reaction: dismay and anger. I'm a full stack engineer. Support, I thought, was a waste of my skills. I found the offer offensive.

But in the interest of family stability, I took the job. I could do this for a short while at least, I thought. Five 5 years later, I am happy I did. I am grateful that circumstances pushed me to take a job I did not want. Because it made me a better software engineer.

The support role helped me to see that I was living in a developer's bubble, and that I didn't truly understand the end customer of my work. Had I never taken the support role, I might never have.

My career has continued to evolve since that transition, but the lessons I learned from my time in support have stayed with me. Here are the big ones:

Know your customer(s)

The software you are building may serve more than one customer persona. For example, if the product exposes APIs, the persona of the API user is almost certainly different than the persona of the consumer user of the product. Knowing each persona, by knowing their needs and challenges, allows developers to design each piece of the product accordingly.

Also, don't forget to write persona-specific documentation. Your customers and your support team will find it extremely helpful.

Don't assume expertise

Developers often believe that the consumers of their software and APIs are experts in the technology, process, or business relevant to the product. Most of the time, they are not. When I was providing API support, I found that most customers fell into two categories: They were either expert in the product, but new to development because of the change in their job role; or they were contracted developers who knew how to code but didn't understand the product and technology, or the business. So in the product itself and in the documentation, you must use terms that are clear to a novice user. When writing documentation, define industry-specific words. Spell out all acronyms. Explain the features and APIs as if the user is brand new to the technology.

Appreciate the customer's environment

A customer's environment is nothing like the developer's testing environment. Customers will push the limits of what is supported. Some will go way beyond what your company considers the bounds of support. The customer environment is also typically complex and comprised of numerous products integrated together. Developers tend to test products in the simplest supported environment due to hardware and budgetary constraints.

Customers have control

"That's not supported." Those were my favorite words as a developer because that meant we didn't need to handle those scenarios. When I became a support engineer I learned that my favorite words were meaningless. If the product does not actively restrict the customers from what is unsupported, the customer is likely to use it in just that way and still expect full support when it doesn't work. When a high-profile customer does this, what was originally unsupported might need to be supported ASAP. Which means developers will have to drop everything to make it happen.

Look at the big picture

When software is developed, features and APIs are split amongst several groups of developers and are worked on in parallel. This is a reasonable tactic for getting complex software written, but developers that are focused on their individual deliverables can fail to understand the customer's end-to-end use cases and flow. We can assume the customer will take a certain path, but assumptions rarely match reality. By understanding the customer's use cases and flows, developers (and project managers) can cover all possible combinations and paths. This is primarily a challenge of internal team communication and coordination.

Doing support was more valuable than I expected

To my surprise, being a developer support engineer ended up being very rewarding. I've always taken pride in the software that I develop. It was fulfilling to see it being used by large and reputable companies, and to talk to the people who were using it. . I learned a lot about the customers, and gained empathy for their struggles. I am a better software engineer than I was before. I can now recommend doing support -at least for a short period of time - to any developer.

See Cisco DevNet's Coding Learning Labs!

Come meet me at Cisco Live in Las Vegas, June 13 to 16. I'll be in the DevNet zone, running a Python Advanced workshop - among other activities. Sign up today!

Join our daily livestream from the DevNet Zone during Cisco Live!

Stay Informed!
Sign up for theDevNet Zone Cisco Live Email Newsand be the first to know about special sessions and surprises whether you are attending in person or will engage with us online.

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel