My Best Advice as a Software Engineer

Source: Dev.to

Introduction

I previously wrote about my experience as an entry‑level (junior) software engineer, sharing highlights and lessons from my day‑to‑day job. Since then I’ve taken on many different responsibilities, and I’ve learned something I didn’t realize when I first wrote that post.

I started my job a year and a half ago. Everyone on the team was far more experienced, and it was my first professional role at a cybersecurity startup. The environment was fast‑moving, and I had to wrap my head around a domain I knew little about.

Over time I learned the basics of the domain. My familiarity with C# and .NET gave me spare capacity to ask colleagues about concepts that were initially mysterious.

In startups, code is constantly being prepared and shipped, unlike large corporations where change is slower. For big features, seniors discuss architecture with the architect and stakeholders. I began pushing myself into those meetings just to listen, and that became a turning point for my growth.

Don’t just ask “What should I do?”

This is my best advice, literally. Hear me out.

During a discussion, the Product Requirements Document and design mockups were being laid out. I didn’t know the best solution, but I wanted to take a large part of the feature. I reached out to the team, took ownership of the feature, and, because it wasn’t high‑priority, I had time to explore.

I researched possible solutions, sketched ideas on paper, and created simple flows with FigJam. After settling on a solution, I pitched it to the team. It was approved, and I began implementation. The feature succeeded; a few minor bugs appeared, which I resolved easily.

In another feature, I repeated the process: I approached the problem by brainstorming solutions, documenting them, and then pitching my idea. Instead of asking “What should I do?” or “What should I work on?”, I asked:

• How would I solve this?
• What works and what doesn’t?
• What are the trade‑offs of this approach versus another?

Looking back, owning an entire feature—from initial solution drafting to production—was the best decision for my growth and learning.

Moral of the story

If you want to level up, don’t limit yourself to merely executing tasks. Ask questions, explore, and ponder how to solve problems. When you stop asking “What should I work on?” and start asking “How can I solve this?”, you open your mind to new ideas and approaches. You become a problem solver who sees multiple options and can choose the best one.

I hope this experience benefits you, even in the slightest.

Thanks for reading.