During the early stage of my career, I had very less interaction among the team members, and the only person I had to listen to or interact with more was my mentor. But over the years I understood, I had to listen to the voice of my customers (or other developers who use my APIs) to improve the overall experience of our products and APIs we share. These views are based on my experience working as a backend developer during my early career to my current role and most of the time the teams I worked with are small more like Startup. Most of the time some of the team members had to wear multiple hats and work.

Listening to Other Developers

Not all the teams have rich experienced developers; sometimes many developers in our team may be fresh or will be having very little experience. They can't forecast every problem which will come in the future.

API Integration Engineer Experience

Once I was tasked to publish API details for another remote team member. I simply made changes in our server and shared the API details with another developer in the mail (later learned about Swagger). Many times the same API is shared with many other developers. Every time there will be minor mistakes done by developers or the mail I forward to the developers. After checking how to improve this I understood the best way is to write a proper Swagger Document and also to release SDK on most commonly used languages (Java, Javascript, and so on..).

Frontend Engineer Experience

I worked as a backend developer for most of my career. My job is to mostly publish API and optimize backend systems (memory optimization, optimizing/introducing schedulers, introducing backend caching, and so on). I try to re-use and optimize backend components but when I work on API one of the important things I often forgot is minimizing the size of bytes transferred across the backend server to various clients. My colleague shared a post on Facebook 2G Tuesday

Listening to Other Sub Team Members

I got an opportunity to lead a small team for a particular feature launch; during that time I got more chances to work with the Marketer for our feature. My colleague from the Marketing team was so kind enough to share what are the various process they will be doing on feature release, what are the various help document they will be creating along with the content team. From their interaction, I understood sometimes these people in Marketing & Content team are our zeroth customers. After those interactions, I used to share the feature document with them to help their to create content faster and to understand what are the various thought process we have put on creating the feature.

Listening to Customers

Customer sessions are one of the most important learning sessions we can get. Some of my friends used to tell me, once they join their company they will be in customer sessions for the first 1 month which helped them to learn more about the product and various use cases how the product is used. More use cases mean more problems, more opportunities to learn.

To conclude this post, as a developer we should have lot of patience and have to listen to all our members who are around us. They will be constantly sharing the inputs which will help at some point of time.