Real Experience Working with a Large Enterprise and What to Take Away

I used to work mainly on projects that easily fit on my laptop. I would run the code, set up the database in Docker, check everything locally, and then deploy. At worst, it took ten minutes to start, but I was completely autonomous.

Then I encountered a real enterprise.

The project is written in Java, consists of over a dozen modules, and weighs tens of gigabytes. This doesn't include the database needed for testing and debugging. Running all this on my "travel" MacBook Air is unlikely. Even a powerful desktop PC doesn't always handle it.

Therefore, all work is done through test environments. And here the nuances begin:

• if someone starts a build, the environment is blocked for others for at least half an hour;

• before deploying, you need to inform colleagues and ensure no one else is building the project;

• any minor error turns into an hour of lost time.

At first, it was unusual. It seemed like development turned into constant waiting. But over time, I developed several rules that make the process more manageable.

1. Mini-environments locally

You can't fully launch the project, but you can set up a micro-environment: only the necessary modules plus stubs for external services. This allows you to check basic logic "on the fly."

2. Tests are not optional, but necessary

I used to treat unit tests as a "useful addition." Now I understand that each test saves half an hour of downtime. Sometimes it's easier to write a small integration test to check a hypothesis than to spend time building.

3. Small changes

If you can break a task into several small pull requests, you should. The smaller the code piece, the lower the risk and the faster the review.

4. Code review as a filter

Cross-review with colleagues is a mandatory step. Often a second pair of eyes catches what one might miss. Errors are caught before the build, saving hours.

5. Deployment planning

Running on the environment is a resource, and it needs to be managed. We have an unspoken rule: arrange your "window" in advance to not interfere with others.

Enterprise taught me to approach development differently. There's no room for the philosophy of "I'll do it first, then fix it." Every change requires preparation and verification. In return, you get cleaner and more reliable code, and you begin to respect colleagues' time and value discipline.

In essence, such conditions form a completely different mindset: you learn to write in a way that makes it as difficult as possible to make mistakes even before the first deployment.