Developers are developers. But, developers are also users. And like any users, they need appropriate tools that match and augment their abilities, too.

IDEs are supposed to do just that. They are supposed to bring together into one coherent interface all tools related to development. This is what "I" stands for.

But, let’s look at it: all IDEs I know have in forefront the text editor. And there are some powerful editors out there. Those editors are particularly good at creating code, but are terrible at understanding code. Why terrible? Well, imagine having to optimize the traffic in a city, and only be given a magnifier glass as a tool. The editor is exactly that: a magnifier that shows with great details every line of code. Clearly, the design of the IDE does not favor the big picture.

And that’s not all. Let’s look at search: how do you search for concrete annotations in your IDE, such as quickly finding all Java methods annotated with @Interesting(“with specifics”)? Given that annotations are more and more pervasive, should it not follow that the IDE makes it possible to quickly find them without involving regex file search? Or let’s consider inspecting objects: when you inspect a dictionary, why do you see a tree? Should it not be more appropriate to see a table instead? Should the IDE not make it possible to offer presentations that are better suited based on the context at hand? And why are pictures not pervasive in our world?

These are just some examples. The “I” is not that integrated. We can do better. We have to do better. We have to put the developer experience in the forefront.

Designing an interface starts from understanding the needs. In this talk, we take a systematic look at how a developer experience could look like and what an environment for developers could be made of. We exemplify the message with live demos of the Glamorous Toolkit (http://gt.moosetechnology.org), a project aiming to reinvent the IDE.