What is a (simple definition of) a development environment?

If you write software you necessarily have a development environment. It might help or hinder you as you work. A development environment consists of some set of tools that you use to develop the program. The tools might be integrated into a single framework (an IDE) or not, but you have some sort of environment.

The tools include at least

1. one or more editors to create files of various kinds, text and otherwise.

2. one or more compilers to translate your program files into machine code for one or more machine architectures

3. one or more run-time-environments in which you can execute your code, either on the target architecture or in a simulator

Additional tools that are usually needed are (not a complete list but will do for a start)

1. a test framework so that you can effectively write both unit tests (the code does what I think it does and doesn't break as I change things) and acceptance tests (the code does what the owner/customer really wants done - irrespective of my understanding).

2. automated error checkers to trace back exceptions and race conditions (among other issues)

3. a debugger that lets you interact directly with the target code as an aid in finding and repairing errors.

4. a design framework in which it is easy (or at least possible) to create design documents, which may be textual or graphical. They might be integrated with code generation or not.

5. a code repository and version control system so that old versions can be maintained and errors can be backed out of

6. a team-support system that helps a group of developers work on the same project. These tools may include simple communication tools (email...) or provide things like distributed pair programming.

7. a database system to hold necessary data used by the program. Sometimes a database is also used to store fragments of the program(s) themselves. The database might also contain required test data to assure the correct thing is built. Likewise it might contain information about the success or failure of test runs

8. a documentation system that can be used for either or both of program documentation of use by the team and user documentation that gives instructions to the end-user on effective use of the system

9. a way to make interaction with the file system easy and efficient, such as directory listings that let you easily open/save/close files

10. a way to maintain various "configuration files" so that the system can be tailored for its various uses

11. a way to keep all of the tools updated easily

12. automatic error checkers and style checkers beyond those provided by the compiler

13. For some kinds of software a sophisticated emulation environment to check the interaction of various components. Mobile apps often need servers and some way test the interactions, for example.

An Integrated Development Environment (say Eclipse or NetBeans) will integrate all of this into a single program that may use one or more multi-pane windows to provide a visual representation of all of the tools. A good one is tailorable by language and by need without cluttering up the workspace. A less integrated system (Emacs, say) provides all of these things through (possibly cryptic) user commands. An IDE requires a learning process itself, but it pays dividends if it is flexible and not restricted to a single language or architecture.

But even a simple text editor, a compiler, and a run-time for testing is a development environment and for many years was all that was available. Way back, the "text-editor" was just a card punch.

Note that not all files in a project are necessarily just text. Some projects require, for example, graphical files to show design.

I don't claim I have a complete list here. There are many other possibilities. Each person's development environment is personal. It is good if it makes them more productive and less frustrated. Is is subject to update and modification at any time that you learn of a new tool or technique.

Also note that not all of these are needed in every project and you don't need to be proficient in many of them to get started. But issues that arise as you work may help you see the need to expand your personal set.