Forem: Rich Park

What It Really Feels Like to Work as a Software Engineer

Rich Park — Mon, 01 Sep 2025 15:11:12 +0000

An honest take on the day-to-day reality of working as a software engineer: the routine, the mindset, and the lessons that actually matter.

My earlier posts shared anecdotes with a few lessons sprinkled in. This one is more direct. After a few years in the field, here’s what I’ve actually observed about being a software engineer.

If you’re learning programming, halfway there, or already technical but wondering what the job feels like day-to-day, this is what I wish someone had told me.

Day-to-day reality

Before I started, I imagined engineering as constant problem-solving and building. I thought I’d always be shipping features, surrounded by brilliant people who knew exactly what they were doing.

The reality is different.

Most of the job is routine. Some weeks I barely write code. Instead, I:

test
push PRs through pipelines
wait for reviews
deploy
attend meetings
update Jira

It’s not glamorous. Engineering is less about constant creation, more about maintaining and connecting things so they keep moving.

Why survival matters

I’ve seen plenty of smart engineers laid off. Not because they were bad, just because that’s how the industry works.

Meanwhile, staying put gave me something that’s hard to replace: context. Knowing how systems really work builds value over time.

That survival is where value starts to build.

Context is the real currency

Companies rarely build from scratch. They stack systems and frameworks together in ways tutorials never cover.

The real skill is understanding how things connect, where they break, and how to fix them.

That’s what people end up relying on you for.

Mindset that keeps me moving

When things don’t work, some engineers blame the tool, the setup, or the environment.

My instinct is different: I assume I’m missing something and dig deeper.

Instead of staying blocked, I:

mock responses
try workarounds
keep pushing forward

That ownership mindset has carried me further than any framework or theory.

And yes, luck

I’d be lying if I said it’s all skill. A lot of survival comes down to luck: timing, projects, layoffs.

You can’t control that. But you can control persistence, mindset, and whether you’re still standing when luck matters.

What’s helped me so far

Accepting that boredom is part of the job
Staying long enough to build context
Owning tasks instead of waiting for perfect conditions
Doubting the tool less, doubting myself just enough to keep learning
Recognizing luck plays a role, and focusing on what I can control

This isn’t a universal truth. It’s just what being a software engineer has felt like to me and what’s helped me get through it so far.

Self-Taught, No Bootcamp, First Dev Job: Exactly What I Did

Rich Park — Sat, 02 Aug 2025 17:34:02 +0000

My previous posts were about life after I landed the job; this one is about how I landed it, how long it took and what it took.

I didn’t do a bootcamp. I couldn’t afford it, and my English wasn’t good enough to follow one anyway. So I learned on trains and after work: docs, blogs, a few courses, Discord servers, whatever I could stick in my head without it sliding out.

I did all of this while working full-time at a small mom-and-pop shop, studying on the train and after my shift.

For the first six months, my brain rejected everything. I’d read MDN for an hour and remember three words. Somewhere around month six, it stopped hurting. A “hello world” turned into a todo app, then a simple site. Tiny dopamine hits kept me going.

Then I tried to get a job.

Hundreds of applications. Silence. Not even rejections. Silence.

I learned what no tutorial tells you: most companies don’t want to train brand-new devs, especially without a degree. Projects on GitHub? Good for learning, almost invisible for hiring.

So I made a decision I’m not proud of, but I’m not going to pretend didn’t happen: I padded my résumé, framed my self-study as “experience,” listed tools I knew but hadn’t used at scale. It was a risk. It got me callbacks.

Then I bombed the calls. I didn’t speak recruiter. I didn’t speak “team.”

I fixed that. Short answers. Business context. “Here’s what I built, why it mattered, and what I’d do differently.” I kept a notebook of phrases that worked and stole the ones that sounded like a grown engineer.

Technical rounds hit next. Algorithms. Data structures. Timers. Dry mouth.

I drilled patterns with a pen before I touched the IDE: sliding window, two pointers, BFS/DFS, binary search. I failed again and again. Call it around forty interviews before I started recognizing the shapes of questions and my own panic patterns.

Almost two years in, I got my first offer.

No magic moment. Just volume, adjustments, and not quitting on the worst days.

The Parts No One Says Out Loud

Projects rarely get you hired.

They teach you. They rarely convince them. Don’t stop building, just know what it’s for.

“Entry-level” often means “already did this somewhere else.”

Companies want risk reduced. If you’re truly new, you have to make them feel safe: clarity, communication, pattern fluency.

Padding your résumé is a gamble.

It might get you in the room. It might nuke your trust. I own my choice. It’s not advice.

Interviews are pattern recognition, not genius.

You don’t have to be special. You have to be steady.

What Actually Moved the Needle

I leaned on Dev.to and freeCodeCamp blogs, plus a few Coursera modules. I mixed in Udemy and Zero To Mastery (Andrei Neagoie), Traversy Media and Joshua Fluke on YouTube, and debugged with Google, StackOverflow, Reddit, and Discord communities while drilling LeetCode with a pen-and-notebook.

Reading over random tutorials. Docs and longform posts trained my brain to sit and absorb. Videos were supplements, not the main meal.
Two or three small but finished apps. Not ten half-done clones. Finished, with a README that explains trade-offs.
Notebook before IDE. If I couldn’t write the idea without code, I didn’t understand it.
Daily DSA reps (30–45 minutes). Not marathons. Patterns over perfection.
Recruiter language. Impact → tools → trade-offs → what I’d change. That loop got me past screens.
Focused waves of applications. Adjust résumé and keywords every two weeks instead of blasting identical submissions.
Discord over solo despair. Someone telling me “yeah, that error is normal” saved me hours and my sanity.

Scenes I Still Remember

The train at 11 p.m. Reading the same paragraph three times until it finally made sense.
The first phone screen. My voice shook. I talked in circles. Dead silence after.
The first solved LeetCode without hints. Not hard, just clean. I wrote the solution twice to burn it in.
The nearly-offer that became a rejection. I went for a walk and didn’t quit.
The actual offer. No confetti. Just a call. I said “yes,” hung up, and sat quietly for five minutes.

If You’re Where I Was

This isn’t a checklist. It’s a handful of rules that didn’t lie to me.

Read daily. Thirty minutes. Docs count.
Build small, finish, write it up. What, why, trade-offs.
Drill patterns, not ego. Two questions a day beats a weekend binge.
Record yourself answering “Tell me about a project.” Fix the ramble.
If a tool confuses you, write a one-page explainer in your own words.
Apply in batches, then adjust. Don’t keep doing what isn’t working.
Have one person you can DM when your brain is melting. It matters.

This Part Again, So There’s No Confusion

I padded my résumé to get interviews. It worked for me and came with anxiety tax. If you’re about to copy that, think hard. There are other paths: internships, apprenticeships, open-source with real maintainers, internal transfers. I’m not your conscience. I’m telling you what I did.

Your Next Step (today, not “someday”)

Pick one:

Write a 200-word README “case study” for one project: problem → constraints → choices → what you’d change.
Solve two pattern problems with a pen and timer. Stop at 45 minutes.
Record a 90-second answer to “What’s your stack and why?” Listen once. Fix one sentence.

Then stop. Show up again tomorrow.

I’m still showing up. Still learning in public. Still screwing up. Better.

I’m grateful to the people who helped, and to my past self for not quitting.

I Got My First Dev Job. I Was Not Ready.

Rich Park — Sat, 19 Jul 2025 00:56:18 +0000

After months of grinding through self-teaching, late-night tutorials, rejected applications, and learning English alongside JavaScript, I finally landed my first dev job.

Big corporate IT company. Big expectations. Big lie on my resume.

And still, somehow - I got in.

Let me tell you what it was like to land your first dev job after years of learning in the dark, lying just to get in - and realizing the real test had only just begun.

The First Standup

I knew what a standup was, technically. Say what you did yesterday, what you’re doing today, and if you’re blocked. That’s what the blogs said.

But in real life? Everyone was speaking fluent “Team Status Jargon.”

They were referencing internal tools I’d never seen, blockers I didn’t understand, other teams I didn’t know existed. And then it was my turn. I had maybe two sentences. I mumbled them. Camera off, voice shaking.

“I finished the ticket. Working on the next one.”

No context. No confidence. Just praying no one would follow up with questions.

Every other standup felt like I was crashing a conversation I didn’t belong in. One time, I actually pretended not to be there. Camera off, mic muted. My manager mentioned my name to get support for something he was saying, and I just… stayed silent. He awkwardly joked, “Ah, he does that.”

It was cringy. But it worked. And I hated that it worked.

It took me a year to figure out how to give a real update - not just what I did, but what mattered.

The Brainstorming Meeting

They said we were “designing a system.” I expected diagrams, specs, maybe a whiteboard.

Instead, I sat there watching my teammates casually build architecture with a mix of hand gestures, inside jokes, and tool names I only vaguely recognized.

“We can pull from Kafka into Lambda, wrap it in this monitoring thing, maybe use X for orchestration?”

“Rich, thoughts?”

I had nothing. I recognized some names. Didn’t know how they fit together. Didn’t even know what the actual goal was.

So I nodded and said something like, “Yeah I could probably take the X part and look into hooking it up to Y.”

It wasn’t wrong, but it wasn’t real. And I knew it.

Weirdly, just seeing someone nod at me in meetings - even if they didn’t really know what I was saying - gave me confidence. I clung to those nods like lifeboats.

What No One Told Me

No tutorial prepares you for this.
No one teaches you how to speak when you have no clue what’s going on.
No one explains how to gauge if you’re doing okay.
No one gives you a dictionary for acronyms flying over your head.
No one tells you that it’s totally normal to feel like an idiot.

And here’s the truth: It’s not about being smart. It’s about learning how to survive long enough to learn what matters.

How I Got Through It

I stopped trying to impress anyone. I started taking notes on everything. I copied how others spoke. I wrote my own scripts. I tracked every acronym, tool, and decision until it made sense.

When I didn’t know, I admitted it. When I got quiet, I followed up later in DMs. I learned to prep for every meeting like it was a mini performance.

I once kept a Google Doc called "Meetings I Survived." It wasn’t a joke. It was therapy.

Slowly, I stopped drowning. Then I started treading water. Then I started contributing.

If You're There Too

If you’re reading this and nodding: same. You’re not broken. You’re not behind.

You’re just new. And this industry is terrible at welcoming new people.

Here’s what helped me in those first days:

Prep one sentence for every meeting
Ask dumb questions early - they get harder later
Find the teammate who’s kind and latch on
Write your own glossary of tools and terms
Keep your updates short but real
Don’t fake confidence - earn it through consistency

Don’t expect clarity. You won’t get it.
Expect to sweat, mumble in meetings, and learn the hard way - with people watching.
And keep showing up anyway.
I’m still doing it. Faking less. Screwing up better.

Next post: what happens when the meetings don’t stop, but the expectations keep rising.

Good vs Bad Engineers

Rich Park — Thu, 17 Jul 2025 15:00:13 +0000

Everything, Everywhere, All at Once

I’m about to dump another batch of stressful moments exactly as I lived them - no mercy. Scary meetings, tricky tasks, an alien work environment, and a crowd of new teammates all hit me at the same time. I was so deep in my own anxiety that it never crossed my mind others might be struggling too. Everyone looked knowledgeable and confident, so of course I assumed I was the only one drowning.

You’re probably not alone. Most people around you are juggling the same stress. They’re just better at hiding it.

My DM Habit

Whenever I needed help, I jumped straight into someone’s DMs expecting an instant rescue. When that didn’t happen, I mentally stamped the person “not helpful” and pinged someone else, building a private table of “good” versus “bad” engineers. (Spoiler: the real problem was me.)

Typical messages:

Direct: “Hey, can you help me clarify this?”

Polite: “Hi, I’m Rich from Team Z working on A. I saw you handled it before, could you point me in the right direction?”

Polite usually worked better, but the reply was often just a quick link and a ✌️. My “good/bad” table kept growing. The truth? Nobody was ignoring me for fun, everyone had their own goals, tasks, and responsibilities. Back then I didn’t see that; I thought, “Come on, it’s only a few clicks - just help me!”

Slow replies ≠ bad teammates. People have their own sprint goals and meetings. Respect their queue, and don’t confuse “busy” with “rude.”

The Feature That Broke Everything

One day I shipped a shiny feature to prod, celebration time, then discovered I’d accidentally broken another part of the app. I combed through commit history, pinged the last dev, and got no immediate reply (which, honestly, I should have expected during a bug crisis). Normally I’d message someone else, but this fix was urgent. Hours later the engineer answered, we patched the bug, and I thanked him privately in DMs. Remember that detail; it matters later.

Did I learn the lesson? Nope. More bugs followed: no quick DM response, panic escalated, the issue went public, multiple people piled in, and the same engineer swooped into the thread, fixed it in minutes, and walked away with a hero emoji parade. I grumbled and added another name to my “bad” column, still missing the bigger picture.

Visibility beats private heroics. Public threads let others spot issues faster and document the fix for next time.

Saying Yes to Everything

Because I’d suffered without context, I swore no one else would. I started saying YES to every request or DM, often without looping in my team or PM. If it takes 15–30 minutes and costs nothing, why not help? I still handled my own tickets (by working late), convinced it would pay off. My ego ballooned: I was the “helpful guy.”

Then reality bit back. One “quick question” ballooned into a mini-project. Suddenly multiple people looped me into threads asking for estimates. When I froze, they brought in my PM, lead, and EM. Now it looked like I’d promised to build an entire application. My PM and lead pushed back, but others quoted my original “Sure, no problem” DMs, putting my own team in a bad spot. Trust slid. I learned, back-slid, and learned again.

Ticket real work. If it’ll take more than a coffee refill, log it so the effort (and impact) is visible and prioritized.

Politics, Priorities, Perspective

Slowly the penny dropped: I’m not a solo fighter. I’m on a team, and team goals come first. Being a good teammate isn’t just laughing at jokes, shipping code, and turning up to meetings. It’s knowing the bigger picture. Context rules everything. There will always be a backlog. If you’re free, grab something from it. Don’t burn time on work that’s off-road for the team. Why? Because your team survives by showing achievements to leadership and stakeholders. How do you know what counts? Ask your PM. They know what’s visible, what’s priority, what moves the metrics.

So now, when a request smells like real work, I loop in the PM right away. I’m still helping, but the effort becomes visible and counts toward team achievements. Everybody wins. Back in my “YES-man” days none of that help was tracked, so it disappeared into the void, and my PM had no idea I was burning velocity on tasks that didn’t push us forward. At first I didn’t care. long term, it matters.

I cringe at how I judged engineers who didn’t jump on my DMs. Now I’m like them, not because I’m uncaring, but because I finally understand priorities. The corporate grind didn’t steal my soul - it just taught me when to protect my time and my team’s.

Your PM is an ally, not a gate. Involve them early, keep the backlog honest, and everyone wins.

Quick takeaways (so you don’t scroll back)

Slow replies rarely mean someone’s a jerk - they’re just busy.
If it’s actual work, ticket it. Visibility beats private heroics.
When someone helps you, praise them publicly whenever it’s appropriate and possible so their effort shines, it really matters!
Your PM is an ally, not a gate. Loop them in early.
Saying “No” (or “Not now”) is sometimes the most helpful thing you can do.

Your Next Step
Today, audit your last ten Slack DMs.
How many could have been a public thread or a ticket? Pick one, log it properly, and watch how much smoother the hand-off feels.

Got your own war story? Drop it in the comments. I read every one.

my blog, please subscribe