Four Things I Wish Someone Told Me as a Junior Engineer

This week marks my second year at UnifyApps. Usually, I just post a quick tweet with my GitHub graph and move on. But this time, it felt right to sit down and write something longer. Not dramatic life lessons, just a few reflections.

Working in a startup is strange. Every week feels like a month, every month feels like a year, and somehow two years pass all at once. The features you built a few months ago already feel ancient.

When I joined UnifyApps, I was the most junior. Not by a little, but by a lot. My first task was to build the typography component for our UI library. Because really, what can you build in frontend without showing text on the screen? It seemed simple enough. I'd written similar things before. But there's a world of difference between adding a piece to an existing system and writing something into an empty codebase. At Lyearn, everything was already established. There was a "way" things were done. At UnifyApps, there was no history to lean on. It was a blank canvas.

And writing on a blank canvas is much harder than coloring inside someone else's lines. I remember feeling the weight of that first component. Not because the code was complex, but because it was the first pull request of the entire codebase. There's something quietly exciting and heavy about that.

Over time, I learned what "escape velocity" means for a startup. Every early company needs momentum to break free from zero users to meaningful traction. As an engineer, you contribute through consistent building, refining, iterating until your work creates real thrust.

That rhythm clicked around our first product demo. We worked late not from pressure, but from energy—the kind where you forget time because something genuine is being built. I wasn't just keeping up anymore. I was helping us reach orbit.

In startups, agency matters. Every decision counts. Here's what I think creates value when individual initiative drives collective success.

Communicate Even When You Think You Don't Need To#

One thing I've seen again and again, in myself and others, is the tendency to go quiet and try to figure everything out alone. It doesn't look dramatic. It looks like "let me think this through first." Actually, it is important to think things through first. But going quiet and not keeping your team updated on your progress can lead to confusion and unnecessary rework.

I would recommend keeping your manager updated on what you're working on, what you're learning, and what you're unsure about. It gives them context on who you are and what kind of work to trust you with.

When you're new, you don't always know which decisions matter and which don't. Sometimes you take a clever-looking detour, only to realize later that it moved you further away from the goal. The mistake isn't always in the code. Sometimes it's in the assumption.

So communication isn't just "keep your team updated." It's about sharing what's happening in your head. What you're trying, what you've tried, what you're uncertain about.

Being a good communicator isn't about being loud. It's about making your thinking visible.

It keeps everyone aligned, and it saves you from unnecessary wandering. Especially in a startup, where direction shifts fast and clarity is currency, communicating what you're doing is part of the work, not something you do after.

Be Diligent Because The Last Commit Is Always the One#

There's a certain overconfidence that creeps in when something feels almost done. I once pushed a final commit after a PR was approved. Just a "small improvement." And it broke the entire feature.

My manager told me something that stuck:

"I always know it's the last commit that breaks the PR."

He wasn't blaming me. He was right.

That moment taught me how easy it is to rush at the finish line. Writing code is easy. Closing code is where discipline lives. Taking ten extra minutes to test, to re-read, to let your mind settle saves hours of debugging later.

Always self-review your pull requests. Be critical of yourself. Diligence looks slow from the outside, but it's what makes you dependable.

Take Initiative and Look for What Isn't Assigned#

At startups, no one has time to point out every small thing that needs fixing. People are busy moving big rocks. The small ones get ignored, not because they don't matter, but because there's no time to notice them.

Some of my most valuable growth came from simply using the product we were building. Clicking around, spotting rough edges, and fixing them without waiting for a ticket. These weren't glamorous tasks, but they built understanding. Not just of the code, but of the feel of the product. That understanding compounds. It changes how you think and how you architect.

Taking initiative isn't about being heroic. It's about being curious.

Be Willing to Be Uncomfortable#

The latest memory I have of this is when we were optimizing evaluation performance in our no-code engine. Computations were taking about six milliseconds, and my instinctive thought was, "Six milliseconds is already fast. Why touch it?" But the same logic written directly in code would take around 0.1 milliseconds. This meant we were actually slow because of our meta-programming architecture, even though the number looked small. That's when I learned that discomfort often hides behind assumptions that sound reasonable.

Sometimes that discomfort looks like diving into something you've never touched. Maybe building a video chat application, working with video streams, or debugging a rendering pipeline. You don't learn those things to get a job. You learn them because you want to build something that challenges how you think.

For me, the discomfort wasn't in doing the optimization itself. It was in realizing I'd limited my thinking by assuming "this is already good enough." Pushing yourself into discomfort, failing multiple times, and then finally succeeding is what makes you a better engineer. For me, the breakthrough came when I discovered that reusing compiled function results was dramatically faster than re-creating functions each time.

Being uncomfortable is how you expand your mind. Comfort flattens your perspective.

Conclusion#

Even after all this advice, I still make mistakes. I still miscommunicate. I still ship faster than I should. The difference now is awareness. And that awareness was earned slowly.

None of these improvements happen overnight. They build quietly, almost invisibly, until one day you realize you're not the same person who started. Growth in engineering isn't dramatic. It's gradual. But it compounds.

If any of this helps even one person starting out, this note has done what I hoped it would.

And to anyone reading this from Microsoft, I'm sure you have your own lessons. Feel free to schedule a meeting to share them. I believe your next available slot is in Q3.

Thanks for reading.

(This blog was heavily AI-assisted. Don't worry, I still write the bugs myself.)