What My First Year in Software Work Actually Changed

My first professional software role began at Samuel Sekuritas Indonesia in April 2021. I had finished an intensive Full Stack JavaScript program, but professional work expanded the definition of "done."

This reflection avoids reconstructed dialogue and dramatic incidents that I cannot verify. The useful lessons are ordinary, repeatable, and still relevant.

Code is one part of a running product

In learning projects, a feature often ends when it works in a local demonstration. At work, the feature enters a system with users, operations, release constraints, and older decisions.

I worked across Next.js and NestJS web applications, an Android application written in Java, iOS code in Objective-C, and Linux infrastructure behind NGINX. The variety made one point clear: a product is not identical to its newest codebase.

Before changing something, I learned to ask:

• Which users depend on this behavior?
• Where does the data originate?
• Which older client still calls this contract?
• How is failure observed?
• How can the change be reversed?

The questions often mattered more than typing quickly.

Existing code deserves curiosity

It is easy for a new developer to label unfamiliar code as bad. Some code is genuinely difficult and should be improved. But a strange pattern can also be evidence of a compatibility constraint, a past incident, or a platform limitation.

The responsible sequence is:

1. Reproduce the current behavior.
2. Read nearby tests and history.
3. Ask what constraint produced the shape.
4. Make the smallest useful change.
5. Record why the new decision is safer.

This approach does not excuse permanent complexity. It makes refactoring evidence-based.

Communication is part of correctness

A technically correct change can still fail if nobody understands its impact. I had to become more explicit about status, assumptions, and uncertainty.

A useful update is short:

Current behavior:
Expected behavior:
What I checked:
What remains uncertain:
Next decision needed:

This gives a teammate something concrete to review. It also exposes when I am relying on a guess.

Mobile and web age differently

Server and web deployments can often be updated centrally. Mobile clients remain installed in the wild. Older versions may continue calling a service after the newest application ships.

Working across Android, iOS, and web made backward compatibility a product concern rather than a theoretical topic. Removing a field or changing an assumption can affect users who have not updated.

The safer habits are gradual migrations, version-aware contracts, observability, and a defined removal date.

Infrastructure is product work

Configuring a Linux server or NGINX initially felt separate from feature development. It was not. Routing, process health, certificates, environment configuration, logs, and rollback determine whether the feature can be used.

The lesson was not that every developer must become an infrastructure specialist. It was that deployment should be understood well enough to diagnose a failure and ask the right person the right question.

Skill grows through reviewable work

Large changes can feel impressive, but small changes are easier to verify and teach. A reviewable unit has a clear reason, bounded impact, and evidence that the intended behavior holds.

This became even more important when I later taught at Hacktiv8. The habits learned as a junior developer influenced how I gave feedback to students:

• Explain the reason, not only the preferred syntax.
• Separate correctness from style.
• Give one achievable next step.
• Keep the learner responsible for the final decision.

What I would tell my earlier self

Do not rush to appear certain. Trace the system. Ask before the assumption becomes code. Make the change small enough to review. Learn how the product is released and observed. Leave a note that helps the next person.

The first year did not complete my transition into an engineer. It changed the unit of attention from a piece of code to the people and systems around it.

Sources

• LinkedIn public profile
• GitHub public profile