When summer of 2017 arrived, I transitioned to a project which allowed me to contribute remotely. After 25 years of working in technology across eight different employers, I was finally able to determine if working 100% remotely would lead to productivity gains … or losses.

Just under 3 years before the pandemic arrived, I discovered I was twice as productive as before – simply by reviewing my commit history from in-office time periods where I was doing similar work. I also felt like the quality of my work improved, largely because of the ability to place myself in focus mode, devoid of any unexpected distractions.

I also realized which tooling dependencies I leaned on to help me to become more productive. Aside from the IntelliJ IDEA integrated development environment (IDE), Postman was a critical tool that helped me become successful as a service developer and architect.

In a bit of a personal retrospective, I wanted to talk about how Postman has helped me to build thriving APIs and to succeed while working in a 100% remote environment.

About Postman

Postman started as a side project of software engineer Abhinav Asthana, with a goal to simplify the API testing process. At the time I started using Postman, it was a free plugin that I could use within my Chrome browser. 

Here’s an example of what Postman looked like back then:

Fast-forward to today where Postman is a standalone client used by over 25 million developers globally and half a million companies, including Box, LinkedIn, Paylocity, Paypal, Sling, Twilio, Twitter/X, and WhatsApp. Incredibly, 98% of today’s Fortune 500 companies are using Postman.

If you are interested in the evolution of Postman, check out The New Postman API Platform: Redefining API Management for the API-First World.

My Original Use Case

When I started using Postman in 2014, I was in dire need of a better way to exercise my APIs. Using a cURL command from my Windows-based developer machine was painful to say the least, relying heavily on copying and pasting from a Notepad document I kept on my desktop.

Just recapping that time of my life sends chills down my spine.

With the Postman app installed in Chrome, I was able to onboard quickly by importing those cURL commands from my Notepad document. As a result of the simple-but-effective user interface, my requests were presented in a better light and easily cloned to further exercise my services.

As I gained experience using Postman, I added environments and variables to my requests and started grouping them in collections that were much easier to reference. This approach allowed me to write a given request one time and be able to use the same request in every application environment — from local to development and even production.

Leveraging Postman for API Services

Today, as a service developer, I see Postman’s in multiple places during the API life cycle.

API-First

With the success of the API in the early 2000s by companies like Salesforce and eBay, the concept of API-first — defining your API specification before any coding begins — did not become mainstream until about five years later.

My first entry point into using API-first was for the RESTful API I built for a fitness-based service I created with my sister-in-law. As part of that effort, I was building both the client and the service, using Angular and Spring Boot, respectively. I used Postman to define my API specification.

The benefit of using API-first for the project allowed me to work on both aspects at the same time. So I could work on the service for a period of time, then switch over and work on the client to keep things fresh. The API-first specification served as a contract that I could rely on, and I was even able to create a mock server in Postman. This allowed me to make client calls to a service which wasn’t actually ready for use yet.

Test Generation

For every request in Postman, a Tests tab provides auto-created code stubs which allow API requests to be executed programmatically using JavaScript. Not familiar with how to write tests? A Postbot provides AI-like interactivity to help with the test script creation process. Once ready, these requests can be executed at the collection level, giving developers the ability to test an entire API.

Currently in beta, Postman collections include a “Generate tests” feature that will also create tests that can be created without the need to use JavaScript. I recently used this feature for a collection I created to validate that my APIs were running as expected in multiple regions across the United States.

CI Pipelines

Postman integrates with continuous integration (CI) pipelines, allowing tests to be executed during the CI life cycle via the Postman command-line interface (CLI). What this means is that builds can fail in cases where expectations established in Postman are not being met.

Let’s take a second to understand what this means.

APIs created using an API-first specification, created in Postman, can be later validated by tests that were created in Postman. This is in comparison to integration and regression tests that are often created via a secondary development life cycle — at great risk of becoming out of sync with the underlying API specification.

Where Postman Soars — Distributed Developers

The biggest challenge I faced after becoming 100% remote was the inability to roll my chair over to another software engineer’s workspace for instant feedback or validation. This effort, while disruptive to the target of my questions, did help me personally — but at the cost of the gained knowledge not residing anywhere else but inside my mind.

With my closest team member now a little over 1,100 miles from me, sliding my chair to his desk is not a reasonable quest I am willing to make. However, with Postman, I no longer have that need.

Shared Workspaces and Collections

Postman allows engineers to establish workspaces and collections that can be stored in a central location.

Think of collections as groups of related items. For Postman, this is more than a simple HTTP request, as shown below:

A workspace in Postman contains one or more collections to make the engineer’s life easier. I’ve often established a workspace for my team and a collection for each service that we support.

The cool thing about Postman workspaces is that they can even be made public for anyone to use. In fact, when I was writing a series of articles about Salesforce, I leveraged a publicly-available workspace to understand their APIs better.

Salesforce Platform APIs

Next-Gen Engineering

One change that I have seen proliferate recently is the elimination of the quality engineer role. As a result, quality engineering tasks have become part of the software engineering role.

This honestly makes sense to me, because often the quality engineer was left to support the features created by multiple software engineers, leading to an abundance of work being placed onto the quality engineer before features could be released. With this transformation, engineers become responsible for adding the expected level of quality coverage within each feature.

Postman provides this ability via JavaScript-based tests and automated test generation that can be integrated into the CI pipeline, as noted above.

Peeking Into Enterprise Essentials

For larger teams, Postman also offers an Enterprise Essentials solution that provides the following benefits:

• Real-time collaboration with change tracking and notification

• Workspace templates to reduce duplicate efforts shared by every project

• API development that allows producers and consumers to work together, making it a shared initiative

Especially as I think about the remote work aspect of being a service developer (or any kind of software developer, for that matter), the Enterprise Essentials features around workspaces and collections make the most sense to me. Collaboration is so key to the scale of what we do. When working with multiple teams across multiple services and APIs, these tools and features make all the difference.

At this enterprise level, Postman can accelerate time to market and identify challenges faster — potentially before the first line of code is written.

Conclusion

My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional:

“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”

- J. Vester

To say that Postman adheres to my personal mission statement is a bit of an understatement. Instead, I would go as far to say that Postman has been a key to my personal success as a software engineer for the past eight years.

No joke.

Postman was there where I needed to be saved from executing painful cURL commands on my Windows-based computer, and it has helped me write APIs that have scaled both vertically and horizontally, building upon an API-first strategy.

Postman has eased any challenges associated with team members being located in remote locations around the world — sharing workspaces and collections, plus using the Postman CLI to execute API tests as part of the CI pipeline.

Postman has allowed my team to focus on building services which help extend the intellectual property of our current priority.

As I close out this personal retrospective, I ask that if you are looking for a way to boost the productivity of your team, consider exploring what Postman has to offer.

Have a really great day!