Newbie Journey - Entering the Real Developer World

Context

I am a self-taught career switcher who entered frontend development. This post summarizes what the first few months felt like and what challenges are worth preparing for in advance.

Some of these issues are still difficult for me today, but knowing where to look and what to strengthen can save a lot of exploration time.

Key Dimensions

Technical

• New tools and libraries are normal for everyone, even experienced engineers changing jobs.
• Understand Git collaboration flow (main branches, hotfix branches, plus commands like rebase and stash).
• Learn test/staging vs production environments and release coordination with backend teams.
• Practice reading existing code and locating the correct file quickly when fixing bugs.
• Learn team conventions and project standards, even if they feel overwhelming at first.
• Ask clear questions: goal -> assumption -> attempts -> where it failed.

At first, I spent a lot of time just finding the right file. A practical trick: make a tiny visual code change to confirm you are editing the correct page before deeper work.

When implementing new features, common beginner confusion includes:

• which existing file should I copy from?
• which parts should stay or be removed?
• is this pattern current or legacy?

Also, personal side projects usually do not train environment awareness enough. In real teams, test and production can have different data. Without this concept, reproducing bugs gets hard quickly.

Business Logic / Domain Understanding

• Be able to explain what the company does, who the customers are, and what problem is being solved.
• If domain knowledge is unclear, PM requirements will feel vague.
• In B2B products, admin/backend users may include both internal staff and client-side operators.

I often practiced explaining my company’s product in casual conversations with friends.
Because most friends are not in tech, this forced me to simplify language and improve clarity.

Domain documents are important, but reading them alone is often not enough. It helps to connect them to user stories: what pain point is the user facing, and what action solves it?

”I am slow, I do not understand people, am I really an engineer?”

• Get used to workplace shorthand and jargon.
• Convert abstract requirements into concrete screens + data flow.
• Break tasks down until you can visualize:
  • what appears on this page?
  • what data is required?
  • what conditions must be checked?
  • what should be stored/sent?
  • what is the navigation order?

As this mental model becomes clearer, your response speed improves naturally.

Lessons Learned

Mindset

• Do not over-limit yourself because you are junior.
• If something helps your work, ask.
• Stay open to feedback and actively request it.
• Accept current gaps; slow reaction at the beginning is normal.

Many juniors self-censor: “Should I avoid asking? Should seniors always speak first?”
In my experience, this slows growth. Participating more helps both team integration and learning speed.

A memorable example: before a team lead left, I asked for feedback. I also told him engineering can feel low on explicit positive feedback because “no bug” often means silence.
His advice was great: proactively demo your work to PMs and ask for feedback directly.

Comparing yourself with others is unavoidable, but if you accept that every skill takes time, negative emotion becomes easier to manage.

How This Differs from My Previous Work

• Process-oriented vs goal-oriented
  In many traditional roles, SOP is fixed. In engineering, the target is fixed more than the path, and even targets can evolve.

• “Get it right in one shot” vs iterative optimization
  Coding is usually: define problem -> simplify -> attempt -> fix.
  Trying to make every line perfect before typing can block progress.

• Joining a changing team
  Product, people, and processes can all change at once. Psychological flexibility matters.

• Value the process, not only output
  Reading code for hours without writing lines can still be essential progress.
  Debug paths that “did not work” still narrow search space and lead to the actual fix.

Thanks for Reading

Career transition has been one of the most special experiences in my life.
I hope these notes can reduce panic and increase clarity for people with similar backgrounds.

If you have thoughts, feel free to reach out on LinkedIn.