How to create an interactive environment for developers Hyper Dev

If we resort to analogy, the frog, thrown into boiling water, jumps out. But if you put it in a slowly heated water, it will not feel the danger and cooked.
Web developers are like these serene frogs. Every day, plunging into code and services, we do not notice changes in the level of complexity. But look at the industry from the side - like those who are just studying programming - and you will understand how much a person is loaded before writing the first line of code. What language should I start from? Which libraries to use? Which IDE is better? SQL or not just SQL? Merge or move? And what the hell is a dynamometer? This article caught our attention by the fact that the story contained in it can be useful not only for developers, but also for everyone who is trying to create products that simplify the lives of customers . We hope the information will be useful to you!

It was the complexity that prompted us at Fog Creek to create Hyper Dev - an interactive environment for quickly creating complex web applications. It removes all the preparation, but because you are only writing code. Just once we realized that for 15 years, when creating web applications used by millions of people (for example, Stack Overflow or Trello), we stopped noticing difficulties.
')
As long as there is web development, we are watching the rapid growth in the number of services, languages, libraries and environments designed to simplify this process. But now, in order to get at least “Hello World”, we need to configure the server, run shell commands, compile files, organize pipeline processing and control the version control system.

As a result, just starting to learn programming, you encounter a chasm of materials that have no relation to the subject, which can distract you from the basic principles of work and confuse. And you will spend time , which you already have not so much, on shaving a well-known yak and solving such problems that will not give you knowledge.

The more we engaged in the study of the user audience - talking with beginners - the more often phrases such as "I am stupid" or "I feel like an idiot" would pop up. But this should not be surprising. If even such a leader in his field and an experienced developer like Ron Jeffreys - the father of extreme programming - spends whole days trying to launch a simple application, then what about the rest?

Partial simplification of web development

Therefore, we decided to deal with this problem. At first, it was necessary to determine what question we would be tackling. Web development is a very complex area with a number of problems, and you should not even dream of solving them all.

We started with Creek Week, that is, we abandoned our daily activities for a week and focused on studying the problem. The task at Creek Week was this: “to highlight boring, difficult to learn aspects of development” and come up with something that allows people to “create applications and move them to the URL without all this fussing.”

A little more specifics - and we managed to exclude many things. First of all, we “isolated”, but not deleted. And we did not try to simplify the programming itself, did not create the Logo anew.

This task also helped us focus our research. We considered existing solutions in this area that did not eliminate the problem (IaaS, PaaS, Rapid Application Development, and online code editors). So we understood a lot, including what approaches we should avoid - for example, attempts to completely abandon coding by creating visual software. This is a beaten track, on which no one has yet succeeded. We wanted to preserve the power and flexibility of programming, simply by simplifying and speeding up the preparation for it.

During Creek Week we created a working concept. It was used to get approval from our organization and the right to further study the problem. We also developed several models:



Original editor model



Project creation field model

Here you see such components as the “save and send” button, the “main” branch and the “tests” tab. We just did not know what technologies we would use to influence the problem.

Principles of the created product

As with the work on Trello, we have reduced our reasoning to several principles. They were an attempt to outline our approach and find the best way. Here they are:

• It should be the fastest and easiest way to get your own web application and start working with it.
• Editing the application, you should immediately receive direct feedback.
• Making changes should be safe so that you can test your ideas without fear for the project.
• The editor should be fun, fast and accessible.

All this helped us clarify our ideas.

For example, having overestimated the model “Fields of project creation” taking into account these principles, we noticed: at the initial stage, users will have to make many complex technical solutions. That is, instead of creating something, you will go to find out how the proposed options differ from each other. This clearly violated the first principle - the fastest possible transition to the case.

These statements also required to abandon the "save and send" button. She not only implied that you know what “to save” is and where to “send”, but also blocked immediate feedback. Moreover, after conversations with testers, it turned out that version control is a source of perpetual anxiety and confusion, because most people use only a small fraction of Git's capabilities.

Yes, the flexibility and control provided by access to the command line is useful. But they put in front of users a problem of the environment, which gives almost no new knowledge, which may take hours to solve. However, if we want to achieve "simplicity", we need to be based on existing methods of using code. Therefore, the answer copied from Stack Overflow should work the same as on your local machine.

Armed with these principles, we realized that we have an adequate idea of ​​how to create a product with minimal functionality (MVP). Now we wanted to see how these ideas would work in practice.

MVP creation

The next few months consisted of developing, conducting internal user tests and every 2 weeks of control meetings of the team with the founders. Such conversations helped to obtain data from those who were not busy with everyday issues of the project. They forced us to think non-routinely and did not allow us to focus on trifles .

To finish the job, we needed to go beyond our own organization. And we went for help at the Recurse Center and Flat Iron School. There we talked about our product, received feedback and conducted many individual product tests to get an even better response.



Fragment Insertion Field
These tests turned out to be useful: it became clear which aspects of the product, even those that corresponded to the principles, did not work in practice. For example, to simplify the implementation of common tasks, we made it possible to search and insert previously created code fragments. In theory, this made sense, but on tests, users, even after receiving a description of this function, did not apply it. In addition, she created many questions, for example, where would these snippets come from? Who will write and store them? And is it necessary to add software packages to projects if this is implied by a fragment?



Prompt language selection

Another feature that has been preserved for months in the preliminary version is the prompt selection of a language for files. Theoretically, this made it easy to experiment with languages ​​and served as a contextual way to show users which languages ​​we currently support. To ensure this, we needed to create a multitude of libraries that helped to somewhat abstract away from the stereotypical code required by existing environments and languages.

This fit in perfectly with our principles, but in fact, the testees were uncomfortable , unable to see their initialization code. They were not ready for this, and this made it difficult to understand how the product works. And we made it more transparent.

What we did

The final step was to obtain usage data and conclusions about the product, and we opened the beta version for everyone. What have we achieved in terms of a common intention - to save web development from difficulties?

If you go to hyperdev.com, a new project will be automatically launched, containing a welcome application. It has its own URL and is always available to you and all those with whom you share it. And this is a real web application, with code for both server and client side.

You can edit it or open a new project and create any real and full-fledged application on the Node.js platform. But what you do not have to do:

• Create an account.
• Configure and configure a web server.
• Register on the server and wait for the name resolution to make changes.
• Install OS, LAMP, Node, etc.
• Save, compile, or move code.

The applications you create are constantly active and already hosted on the host. The changes you make begin to take effect immediately, because they move as you type them. No preparation - setting up the environment, organizing pipelining, learning Git, or manually moving updates. And you can invite teammates to collaborate on the code and see all the changes in real time.

You can mix existing publicly available projects. Each of your creations will have its own URL, allowing you to share them.

We have come a long way, but these are only the first steps to eliminate the difficulties in web development.

PS We recommend another useful article on the topic - 10 questions for an interview with a candidate for an IT position .

The author of the translation is Vyacheslav Davidenko, the founder of the TESTutor company.