When I get a requirement, I don’t start coding

For me, software engineering is not about choosing Java, Spring Boot, or any other technology first.

I think the important part is understanding what you are actually trying to solve. The code comes after that.

At work and in projects, you often see requirements like: “It’s Java, Spring Boot, and we need a system like this.”

But that’s not really the problem. That’s just the technology being used.

The real questions come next.

• What should the system actually do?
• How does this process work in real life?
• What rules are involved?
• What can be changed, and what cannot?
• What should happen if something goes wrong?

Because if you start coding before understanding these things, you can write very clean code and still end up solving the wrong problem.

A requirement is more than just a ticket

A ticket often describes what we see on the screen: a button, a form, a list, a new endpoint, and so on.

But behind all of that, there is usually a business process.

For example, if some data needs to be changed, simply writing an update is not enough. First, you need to understand:

• Who is allowed to change it?
• Under what conditions can it be changed?
• Why does the previous value matter?
• What should happen if the operation fails?
• Can this change affect other processes?

Sometimes none of this is written in the ticket. But these details are exactly what determine whether the system works correctly.

That’s why when I receive a requirement, I try not to open my IDE and start coding immediately. I first try to understand the process.

The stack comes later

I like working with Java and Spring Boot. They make it possible to express business rules clearly in code and test them properly.

But technology itself is not the goal for me.

If frontend is needed, we build the frontend. If AI makes sense, we use AI. If another technology is a better fit, then we should consider it.

The important thing is that the technology you choose should help solve the actual problem.

You notice this even more when working with banking systems. A small mistake may not remain just a “bug”. A wrong amount, wrong status, or incorrect business rule can have a real impact.

But this is not something that applies only to banking.

Any system needs to be reliable.

What does a good software engineer do?

For me, a good software engineer is not simply someone who makes the code work.

They understand the problem, identify the business rules, implement them correctly, and think about whether the system will still behave correctly when they are no longer in the room.

Code is obviously important.

But even well-written code can be the wrong solution if the requirement was misunderstood.

So for me, the process is quite simple:

• Understand the problem first.
• Then understand the rules.
• Then choose the technology and write the code.

I think this is where software engineering really starts.