Books and articles educate us that APIs as well as other artefacts should be seen as products (“API Product Management”). That’s a good thing, because it turns our focus away from purely technological approach. However, product-centric thinking leaves the customer with lesser attention compared to developer-centric approach (“Manage customer-centric innovation-systematically”).

Developer-centric is in literature seen primarily related to internal developer culture and tools. Close to DevOps. Satisfy your own developers and your productivity and employee satisfaction rises. IDEs are essentially developer-centric, meaning that their primary user experience focuses on the individual developer. Different view point presented here is externally oriented developer-centric approach == developer experience 2.0.

As API provider you should understand that your API as a product is not the center of the universe. It’s probably just a little piece in the puzzle. Considering the application developers environment there are other influencing elements. According to Booch and Brown, coding is very cooperative process and involves “organizing their working space and process, representing and communicating design decisions and ideas, and communicating and negotiating with various stakeholders”. “Static analysis of event-driven Node. js JavaScript applications”

On the left side you’ll find influencing elements which are not related to your APIs. That is the life of application developer you should know and understand. You should understand the pains and gains in developer’s environment as you do in API development given that you use API Model Canvas tool. The items on the left influence how your API is adopted, perceived and how well it fits in architecture. Items on the left are things you have little or no control at all. Dispite of that you need to be aware of those.

Your APIs business model is also relevant since the overall development and maintenance costs of the application possibly limit the options of application developer.

Team and skills

Most of the professional developers work in teams. The composition and group dynamics of the team affect the application developer as well. If the team works well together, they help each other. In those cases single application developer can expect help and support from team members if he is confronted with difficulties regarding your API.

Support can also come from broader “teams” which are known as communities. One helpfull wellknown community is Stack Overflow. In there developer can find questions and answers related to programming. If the problem has not been discussed in forum yet, the developer can pose a question to Stack OVerflow community and get help in the form of responses.

Skills and experience of single developer influence how your API is adopted. More experienced developer might not let first problems to stop their work, but less commited and skilled devs might just frustrate and quit working on the subject/task.

Quality

Low quality level of some components in node.js ecosystem is said to be one of the cons of node.js in general. There are even cases in which malicious code has been injected to node components. Those incidents have lowered the trust for the ecosystem and component quality. If included components contain security risks or harmfull functions, those will decrease the overall quality of the application.

Quality requirements for the application such as response time, put requirements for your API as well. Curiosity is that response time and reliability are not part of the SLA documents in API economy, but those are used internally. More about SLAs later in this book.

If your APIs performance is low, developer will most likely change to different API or build a workaround (with extra code). The latter will increase the complexity of the application and thus inreases the risks. Thus changing API is primary option and workaround is implemented only if nothing else can be done.

Selected framework

Development frameworks and runtime environments play a huge role in all application development, API economy is no exception.

As an API provider the framework topic might seem a bit far-fetched, but it’s not. Some of the successful API-first companies have selected not to push direct API sales. Instead they have selected strategy in which APIs are consumed via packages or components. The components can be easily added to development frameworks from command-line or by edition project configuration file. These packages are sometimes called SDKs (Software Development Kit). Not all agree that SDK is the right term to use here, because it has originally meant toolkit for application development on top of specific operating system such as iOS and Android. Nevertheless, package build for specific framework can be seen as SDK eventhough the original meaning is a bit different.

Put aside the semantics discussion, packages build in these environments is a variation of multichannel customer experience familiar from reasons why APIs are used in building end-user customer experience.

Web application frameworks and runtime environment such as Node.js, Ruby on Rails and Django can be used for consuming, developing and running APIs. Focus here is in consuming APIs, since the book is about devleopers as customers in API economy.

Tools always comes with pros and cons. Most of the web application framework enable easy API consuming with either build-in functions or libraries. Differences can be found though. Some of the frameworks are easier to adopt and build application faster. Popular node.js is not a framework and thus comparing it for example with ruby on rails would not make sense. Selecting “right” framework or runtime environment for the job at hand is important. Some of the tools have larger talent pool than others. Thus picking framework with less developers might cause issues the future if and when more developers are needed.

Some of the tools are optimized for performance while others provide better business process build-in support. For example javascript driven node.js is optimal for real-time websites with push capability, since it uses non-blocking, event-driven I/O paradigm[15], [16]. For example, if developer builds node.js driven application, it is likely that traditional request-response REST APIs force developer to create extra polling logic in the app. If you would provide API with hooks, any changes in data would be pushed to application.

Ruby on Rails has robust support for business process handling and can not scale as easily as Node.js. One of the cons of node.js is the lack of ability to perform CPU intense operations. Python is also one of the most loved programming languages. Python driven frameworks such as Django are said to promise fast results and be beginner-friendly.

Selected framework also affects your APIs supportive tools. If the developer is using node.js, he is not likely to be interested about your python based tools or components. It might be the best possible tool or library in the world, but it’s irrelevat for the developer. Thus you should be aware of the frameworks used by your target audience. Sounds tricky but you could start with the most used frameworks and runtime environments.

Most used web appplication frameworks of the professional developers according to Stack Overflow Developer Survey 2018 are:

  1. Node.js (49,9%),
  2. Angular (37,6%),
  3. React (28,3%),
  4. .NET Core (27,2%),
  5. Spring (17,8%) and
  6. Django (12,8%).

Note that the three first are javascript driven. That indicates the strong foothold of javascript inside the professional developer community.

APIs on the right

On the right side you’ll find the things you can partially control. Some of the APIs developer is using is just given (“by mandate”). Those are either mandated by architect/lead developer or even customer. Customer might be using some system and then you have no choice but to use what ever you get your hands on to. Mandated APIs might effect also selection of the rest of the APIs and SDKs.

Some of the APIs are selected by the developer (“by choice”). Selection might be done by the lead developer but based on suggestion of the developer. In some cases developer is free to choose what ever she wants given that the selection follows given principles. This is the sweetspot your API might be trying to hit. Convince the developer that your API has the best value proposition and they will rememberr you when to time comes. Developers test tools and APIs even on their freetime and based on the experiences might suggest them to a bigger project in their company.

Some of the APIs are “just APIs”. Some have libraries which make the utilization more simple occasionally. Some have SDKs. Libraries were discussed in details previously in “#7 - Technical strategy options of Developer eXperience driven growth”

Holy Grail - quest for the flow

Developer is in the middle and every day trying to get into the “flow”. Flow is claimed to increase productivity and thus it is desired state of mind. What is flow?

It’s a moment when time is irrelevant, minutes can feel like hours and hours feel like passing in minutes. Csikszentmihaly uses the term “optimal experience” as synonym for flow state. During those moments we feel a sense of exhilaration, a deep sense of enjoyment, we are active, body or mind is stretched to its limits in a voluntary effort to accomplish something that is difficult or worthwhile. In the book Peopleware: Productive Projects and Teams DeMarco and Lister describe flow as “a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria”.

The task might be undertaken for other reasons but the activity soon becomes intrinsically rewarding. Getting to the flow becomes one of the most influencal intrinsic motivation factors.

In the flow state person feels enjoyment and pleasure. Those in turn increase the quality of life. It’s not far fetched to say that flow state can become addictive thus making it something that a person seeks to accomplish again and again. A friend of mine and one of the developer advisory board members of the book “Build for Developers” compared flow state to git commits:

Interestingly achieving flow state does not work like a switch, it takes time. According to Demarco and Lister it takes about 15 minutes or more to get into the flow. Before achieving the flow, person is extremely sensitive to noises and disruptions and those can make it impossible to achieve. Once you’re in the flow, the state can be broken by something that is focused on you. According to research that state is also broken easily by internal interruptions.

According to research external distractions are felt to be more influencal than internal, but results indicate the opposite. The internal interruptions aka self-interruptions break the flow. Most common (30%) self-interruption is being blocked on a task (e.g. tool obstacles, technical issues). That is more common than getting sidetracked to other tasks (23%) or lack of technical information for example documentation (16%).

Don’t become destroyer of flow states

Lack of technical documentation is at least one of the flow-killer reasons any API provider can and should avoid. As API provider you should make sure that your API is not causing blocks or does not have insufficient or hard to read and understand documentation. In worst case your API might be the flow-stopper. Nobody likes flow-killers. In those cases you could change your slogan to be “Now we have become Death, the destroyer of flows.” In fact you should always develop ands document your APIs as if the guy who ends up consuming your API will be a violent psychopath who knows where you live .

Great industry top 1% APIs enable the developer to enter flow state and stay there, not hinder it.

Some more to read from 100 Days DX