How It All Began

I joined a startup during my final semester of college full of dreams, excitement, and absolutely zero clue what was coming.

They called it an "internship." On Day 1, I walked in expecting some hand holding, maybe a slow ramp-up, a buddy to show me around. Instead, I got a quick KT (knowledge transfer) session and a task: "Create a new API endpoint on the existing codebase."

Sounds simple, right? Then I opened the codebase.

It wasn't a codebase. It was a monster. Files everywhere. Folders nested inside folders. Functions calling other functions calling things I couldn't even find. I sat there staring at my screen thinking, "What even is this?"

I walked over to my senior and asked, "Hey, is there any documentation I can refer to?"

He smiled and said, "I am the documentation."

That was the moment I realized I wasn't just learning code. I was learning survival.

I pulled out a notebook and a pen yes, actual paper and started writing down every file path, every function name, every weird quirk I discovered. Because in a codebase that big, your memory is a liar. By lunchtime, you've already forgotten where that one config file lived.

That notebook saved me. And honestly, it taught me my first lesson before I even shipped a single line of code: in a startup, you are your own documentation.

four years later, I'm still at this startup. I've shipped features, broken production, fixed production, mentored interns, and made every mistake you can think of (and probably a few new ones). Here's everything I've learned along the way.

Communication Is the Real Skill

I used to think being a good engineer meant writing clean code. It doesn't. It means being able to explain what you're doing, why you're doing it, and what could go wrong clearly and early.

If you can't communicate:

• You can't ask for help when you're stuck (and you will get stuck).
• Your manager doesn't know what you're working on.
• Other teams build things that conflict with your work.
• You become invisible which sounds fine until promotion time.

Over-communicate. Always. Send that update message. Ask that "dumb" question. Confirm that ambiguous requirement. The five minutes you spend writing a clear Slack message saves hours of cleanup later.

Even today, before making a major change, I try to communicate:

• what I am changing,
• why I am changing it,
• possible risks,
• rollback plans,
• and expected behavior.

That habit alone prevents many problems.

Understand the Product Before Understanding the Code

This is one of the biggest lessons I learned.

When joining a startup, many developers immediately try to understand the architecture, framework, or folder structure.

But in reality:

the codebase is only a reflection of the business.

If you do not understand the product, the code will never fully make sense.

Without understanding the real business flow, many parts of the code look “weird.”

Later you realize: the code is not weird, the business itself is complicated.

Once I started understanding:

• why users use the product,
• how customers think,
• what business problems exist,
• and how operations work,

reading the code became much easier.

Because then every endpoint started telling a story instead of looking like random logic.

Respect Legacy Code

One mistake many developers make they underestimate old code.

As engineers, we continuously improve. We learn cleaner patterns, better architecture, and new technologies.

So when we see old code, our first reaction is often:

“Why did they write it like this?”

But startup experience taught me something important:

old code usually contains old pain.

That “ugly” logic may exist because:

• some customer workflow breaks without it,
• an external API behaves unpredictably,
• or production once failed in a very specific edge case.

Never rewrite legacy code until you fully understand:

• the business logic,
• dependencies,
• edge cases,
• and historical reasons behind it.

Sometimes the dangerous code is not the messy looking code.

Sometimes the dangerous code is the “clean refactor” done by someone who didn’t understand the system deeply enough.

The rule I follow now: if you're not 100% confident why a piece of legacy code exists, don't touch it. Ask someone. Read the git blame. Check the original ticket. Then decide. because I breaked production few times by refactoring the old code (:sweatsmile)

If You Do Something More Than Twice, Automate It

This mindset saved me a lot of time.In startups, repetitive manual work slowly drains energy.

For example, in my case: every time I wanted to deploy to a test server, I had to:

• open GitHub Actions,
• select branch names,
• choose environments,
• and manually trigger workflows.

It sounds small.But small friction repeated daily becomes expensive.So I wrote a simple CLI script to automate the process.

That small automation improved:

• speed,
• focus,
• and consistency.

After that, I started automating many repetitive tasks.

One thing startup life teaches quickly:

engineers should not repeatedly do work that machines can do reliably.

Self-Review Prevents Embarrassing Bugs

One habit that helped me a lot reviewing my own PR before others review it.

Earlier, after finishing a feature, I immediately created a PR.

Later I realized many mistakes become obvious if you step away for a few minutes and review calmly.

Things like:

• forgotten logs,
• wrong variable names,
• debug code,
• edge cases,
• null checks,
• deployment risks,
• and typo mistakes.

Now before pushing, I usually ask:

“If I was reviewing someone else’s code, what problems would I point out?”

That simple mindset catches many issues early.

Learn to Say “No”

In startups, there is always more work.

At first, I tried saying “yes” to everything.

Eventually I learned: saying yes to everything usually means:

• context switching,
• rushed work,
• burnout,
• and lower quality.

Good engineers are not people who accept everything blindly.

Good engineers understand priorities.

Sometimes saying:

“This needs more time.”

or

“This may break existing flows.”

or

“We should not rush this deployment.”

is actually responsible engineering.

Track Your Mistakes

One underrated thing I started doing was tracking mistakes I made.

Not to feel bad.But to avoid repeating them.

For example:

• deployment mistakes,
• debugging assumptions,
• poor estimates,
• missing edge cases,
• communication gaps,
• production incidents.

Over time, patterns start appearing. You realize your biggest enemy is not lack of intelligence.It is repeated carelessness.

Tracking mistakes improves self-awareness very quickly.

I also tracked wins:

• successful releases,
• difficult bugs solved,
• systems improved,
• automation built,
• and customer issues resolved.

Because during difficult periods, those reminders help you see growth.

Build Good Relationships With Fellow Developers

One thing that helped me a lot during my startup journey was building good relationships with other developers.

In startups especially, every developer usually has different strengths:

• someone is good at debugging,
• someone understands infrastructure deeply,
• someone writes clean architecture,
• someone knows the business logic well,
• someone stays calm during production issues,
• and someone can explain complex things simply.

If you maintain good communication and healthy relationships with teammates, you naturally learn from each other every day.

Many things cannot be learned from documentation alone.

For example:

• hidden deployment tricks,
• production debugging approaches,
• business edge cases,
• architecture decisions,
• and lessons from past failures.

A strong team culture makes learning much faster because people openly share knowledge instead of protecting it.

I also learned that helping others is one of the fastest ways to grow yourself.

Sometimes while explaining a bug or teaching a junior developer, you realize gaps in your own understanding. Teaching forces clarity.

And during difficult production issues, good relationships matter even more.

When systems break at midnight, people work better with teammates they trust and communicate comfortably with.

• the people they learned from,
• the teammates who helped during difficult releases,
• the debugging sessions,
• and the feeling of building something together.

Prioritize Product Value Over Perfect Code

The perfect engineering is not always the highest priority.

As developers, we naturally love:

• clean architecture,
• optimized code,One lesson I learned in startups is that
• perfect abstractions,
• and elegant systems.

But startup reality is different.

Our CTO used to say something like:

“Having highly efficient code without customers is useless.”

At first, I didn’t fully understand that statement. Later I realized what he meant.

A startup survives only if it solves customer problems fast enough.

Sometimes that means:

• shipping a simpler solution,
• compromising on perfect architecture,
• delaying optimization,
• or writing code that is “good enough for now.”

That does NOT mean writing bad code carelessly. It means understanding business priorities.

In startups, timing matters a lot.Many engineers make the mistake of overengineering too early:

• building complex abstractions,
• designing for massive scale before users exist,
• or spending weeks optimizing systems nobody is using heavily yet.

Good startup engineering is often about balance.

You need to ask:

• Does this optimization actually matter now?
• Is this complexity solving a real business problem?
• Are we building for current reality or imaginary future scale?

Over time, I learned:

perfect code is valuable,

but solving real customer problems is what keeps the company alive long enough to improve the code later.

Sometimes “done and useful” is more valuable than “perfect but delayed.”

The important thing is knowing:

• where compromises are acceptable,
• and where they become dangerous technical debt.

That judgment only comes with experience.

Final Thoughts

When I joined as an intern, I thought software engineering was mainly about writing code.

• communication,
• decision making,
• understanding systems,
• reducing chaos,
• and helping teams move forward safely.

The code is only one part of it.

And honestly, I’m still learning.

• Every production issue,
• every failed deployment,
• every weird bug,
• every legacy system,
• every difficult release teaches something new.

That’s the beautiful thing about startups.

They force you to grow faster than you expected.

Sometimes painfully. But meaningfully.