Isolated Development Environments (IDE)

I was captivated by several aspects of this story on the coming software apocalypse. After reading the story, I am learning more about the temporal logic of actions, and how I can apply it as part of my work on algorithmic observability using APIs. Another layer of this story I found interesting was around a hallmark tool in many developer’s life, the integrated development environment (IDE). The IDE is a layer of my API research, and something I’ve been advocating the delivery of API documentation, and other resources to help developers build better applications using the growing number of API resources. In a developers world, many roads lead into our IDEs, and I have been looking to feed the distributed resources that are available out their into the place where we work each day.

This post has me rethinking our IDE reality. I’ve struggled to find the right IDE for my API-driven world, and settled in on Github’s Atom editor, which has been a pretty light-weight IDE (until recently), and allows me to get the basics of what I need done, without too much of the bulk I’ve seen in other environments. I feel like that is evolving with this release, but for now I’m staying put. One of the reasons I believe in APIs so much is that they force us IT and developer folks to pick up our heads from time to time, and work with external actors, whether it is consumers of our APIs, or the providers of the APIs we are consuming. There is more opportunity to bridge us to the real world. The external world. Something us developers and IT groups are so resistant to in our daily lives. APIs don’t open the doors, windows, and blinds all by themselves, but there is a greater chance some sunlight will be let in with them, then without them.

In my IDE it is easy to tune out the world and be alone with my code. My programming language dictionary is there. My library of code snippets are there. It is where I put my blinders on and make the magic happen. Or, this is what I tell myself at least. I rarely have, where I write stories, open at the same time I have Atom open, writing code. However, as the API Evangelist, there are times where these worlds do overlap, where I’m looking for some code, or a JSON snippet for use in a story. My storytelling brain, and my coding brain do not often get along, and they tend to not think along the same lines. My storytelling brain wants to speak to people. It wants to listen to stories, and retell them to people. My coding brain wants to be left alone. I cannot be bothered with what others have to say, I have to solve this problem. The code will speak for itself.

Atom is my isolated development environment (IDE), and is my inclusive storytelling environment. I do not think about other people in my IDE, and all I do in my storytelling world is think about people. As I was writing this piece I tried to apply an acronym to my inclusive storytelling environment, but I couldn’t. Acronyms are about exclusion, and have no place in describing what I do as a storyteller. All of this is why I consider storytelling the most important tool in an API providers and evangelists toolbox. Without stories about what you are doing, the value delivered, and the human impact being realized, none of this matters. If you can’t articulate why your API matters to other humans, you shouldn’t be doing your API. It might have all made sense in your isolated development environment, but in the real world it will dissolve, dissipate, and become vapor when touched by sunlight.

Isolation is on my mind lately. Rural isolation. Algorithmic isolation. Development environment isolation. Why do we isolate ourselves? How comfortable isolation can be. When someone interrupts me while I’m immersed in my IDE, I react like someone pulled up the blinds and let the sunshine in. It is disorienting. There is a reason for this. There is a danger to this. It is something I’ll keep exploring and thinking about. I’m going to be paying attention more to how I use my IDE, and how it impacts how I engage with people. I’m going to think more about how it railroads me. How it feeds me what I need and keeps me serving my master. Codifying our reality, and increasingly the reality of others through the algorithms we are crafting. Like the inputs and outputs of an algorithm, how are our IDEs determining what gets in and what comes out?