Well, first real job and I still haven't gotten used to waking up for a 6:30 AM shift... I've been doing this for months now. At this point you'd think my body would've accepted that I am, in fact, a morning person.
It has not.
And honestly, waking up early isn't even the hardest part of the job.
It's everything that happens after I actually get to the office.
When I joined my current company, I had a pretty simple idea of what my first engineering job would look like.
Write code. Learn new systems. Make mistakes. Get better. Simple toodledoo.
Instead, I got dropped into a large enterprise environment where the technology is old, the systems are important, most of the work is support and maintenance, and you can't exactly treat production like your latest side project. Which is fair since people actually depend on these systems.
And somewhere along the way, I started realizing that this job was teaching me things I hadn't really thought about when I was busy imagining what my first "real" engineering job would be like.
Welcome to the world of support
The work I'm doing isn't exactly what I imagined when I was studying React, Node, building random projects and generally trying to convince myself that I could build anything if I stared at Stack Overflow long enough.
A lot of my current work revolves around supporting existing mainframe systems, maintaining records, following established processes and dealing with systems where privacy and security are taken pretty seriously.
There aren't many opportunities to just go:
"Hmm... what if we just rewrite this? My architecture would be cleaner."
Please don't. 🥹 Someone will materialize right behind you.
The system already exists. People already depend on it. There are manuals, procedures and a whole lot of things that you're expected to check before doing what sometimes looks like a very tiny operation.
And one of the strangest parts of being new here is that sometimes I don't even know why I'm performing that operation.
I might be told to add something, delete something or update a particular value. There's a manual telling us which fields to check and what conditions need to be satisfied, so we follow it.
But then there's this little voice in my head going:
"Okay... but what does this value actually DO?"
What exactly changes because I changed it? What depends on it? Why is this particular thing being added in the first place?
And sometimes the honest answer is:
I DON'T KNOWWWWW
I'm not talking about the grand business purpose of the application either. I'm talking about the much smaller, very specific "why are we changing this thing?" kind of why.
That's a weird place to be in as an engineer because you're doing the work correctly according to the procedure, but you don't necessarily have all the context behind the procedure.
I could probably spend hours trying to understand every little detail, but that isn't always practical either. There's already a ridiculous amount to learn, and I don't want to spend half my day trying to reverse-engineer something that I only need to safely operate for now.
So I'm slowly trying to figure out where that balance is.
How much do I need to understand before I can say I actually understand the work?
That's something I never really had to think about with my side projects. There, I usually knew exactly what I was building and why. But here nuh-uh.
Then came the training
The onboarding process was basically split into three stages.
First came KT (Knowledge Transfer). We learned the systems, processes, terminology and all the things we were apparently expected to know. Looked simple then.
Then came simulation, where we performed the work without actually working on the real tools. Still not very tough.
And finally came hands-on. That's when things got interesting.
Because simulation is... well... simulation.
You can understand the steps. You can follow the documentation. You can complete the scenario correctly.
Then you open the actual tools and suddenly there are ten tiny things you didn't know you needed to think about.
It's not necessarily because the training was bad.
It's just that knowing what you're supposed to do and actually doing it inside a real system are two different experiences.
I think every developer eventually discovers some version of this.
You can read about Git for weeks. You can understand deployments. You can build a demo application. Yada, yada...
And then something actually breaks and you suddenly discover an entire category of knowledge that the tutorial conveniently forgot to mention.
Production has a funny and painful way of doing that.
And this is probably where I've felt the most conflicted.
On one hand, I completely understand why mistakes can't just be ignored. These are important systems and there are real consequences to getting things wrong.
On the other hand, if you've only just moved from simulation to actually using the tools, making some mistakes is kind of the point of the hands-on stage.
!!!
That's how you figure out what you didn't know. That's how you build the little instincts that eventually make the work feel obvious.
So sometimes I'm caught between:
"Yeah, I need to get better."
and
"Bro, how am I supposed to get good at this without actually doing it?" 😭
The slightly unfair part
There's something else I've been struggling to reconcile. The people who worked on this project before us had around 20+ years of experience.
I'm 22. Well, 23 in a week or so, but let's keep it 22 for the story. 😭
Most of the people around me are relatively young as well, with our team lead being the person carrying most of the experience on our side.
And he's obviously one person. He can't magically handle every technical question, every problem, every decision and every communication issue for an entire team. So sometimes the experience gap becomes painfully obvious.
We're learning. We're making mistakes. And at the same time, we're being expected to perform against a standard shaped by people who had already spent years learning the system.
And in my case, there's another layer to this too. I'm still learning Japanese.
A lot of my time outside work has gone into getting better at the language, and I'm also using it at work while trying to understand the technical side of the job.
So there are moments where I'm not just trying to figure out what the system is doing. I'm also processing what someone is telling me in a language I'm still mastering.
That's not an excuse for making mistakes. If I mess something up, I still need to get better. And honestly, sometimes it really is a skill issue.
I didn't understand something properly, I missed something, I made the wrong decision. It happens. A lot. Repeatedly. Oof this is painful to write.
But I've also been learning to carry "I'm new at this" from "I'm genuinely bad at this."
You can be responsible for something without controlling it
This has probably been one of the stranger lessons. There have been conversations about idle hours, team structure, availability of work and why certain things weren't happening.
And sometimes the people being questioned aren't actually the people who control those things.
Which creates a weird situation. Obviously I'm responsible for the work I do. If I make a mistake, that's on me.
But I'm not exactly in control of how much work is available, how the team is structured, how the training was designed or what somebody else communicated to another manager.
I've started thinking about the difference between responsibility and control a lot more.
You can be responsible for your work without being responsible for everything around your work.
There's another layer that makes this even more complicated: not everyone is working with the same constraints.
The people questioning our turnaround times sometimes have access to more localized systems and tooling that make certain operations considerably faster, while our side is working with a much more limited setup.
Hey I ain't saying we shouldn't get better at it...
If something genuinely takes us too long, then yeah, we should figure out why and get better at it.
But there is a difference between a person being slow and the system they're working with being slow.
And that's another thing I've started noticing about large organizations: productivity isn't just about how hard someone is working.
Tools, Access, Processes, Dependencies matter.
And sometimes decisions made somewhere far away from you become part of your work whether you like it or not.
Communication can become the real bottleneck
The technical work isn't even the only thing making this difficult. There are multiple layers of management, different expectations and sometimes contradictory instructions.
One person says one thing. Another person says something slightly different. You follow what you were told. Then someone else asks why you did it that way.
And suddenly you're wondering whether you're actually solving a technical problem or participating in a very elaborate game of telephone.
And then there's the opposite problem.
Sometimes communication is happening perfectly fine... it's just happening for WAYYY too long.
I've sat through explanations that could probably have been communicated in twenty minutes and somehow consumed almost two hours.
Yes, I've skipped lunch for this. Several times.
At some point you stop wondering whether the system has a bottleneck and start wondering whether the meeting itself is the bottleneck.
But underneath all the frustration, there is something useful here too.
I've started realizing that communication isn't simply "did the information reach the other person?"
It's also:
Did they understand it? Did the right person hear it? Could this have been a message instead of a two-hour meeting?
These are things I barely thought about when most of my communication was basically GitHub issues, Discord messages and "hey can you review this PR?"
Large organizations make communication feel like part of the actual engineering work.
So... are we actually bad at this?
I've genuinely asked myself this.
When you're making mistakes, getting questioned, and watching people with years of experience do things that feel effortless, it's pretty easy to start thinking:
"Are we just bad engineers?"
I don't think that's the right conclusion. We're inexperienced. We're learning a system that existed before we joined it. We're learning through KT, simulation and hands-on work. And we're expected to become productive relatively quickly.
Sometimes I really do look back at a mistake and think:
"Yeah... that one was completely on me."
I'm not trying to convince myself that every mistake is because of bad training, bad tools or bad management.
But I've also realized that you eventually have to let people actually do the work if you want them to become good at it.
Enough to make mistakes, understand why they happened and slowly build the intuition that documentation can't give you.
And then there's the part I haven't figured out yet
I don't particularly enjoy the work itself.
Support and maintenance aren't what I imagined myself doing long-term.
Mainframes aren't something I see myself specializing in.
And honestly, I don't think that's a bad realization either.
One of the purposes of your first job is to discover what you actually like doing when software engineering stops being a university subject or a side project.
I used to think that if I got a software engineering job, I'd automatically know whether I liked being a software engineer.
Turns out there are many different ways to be one.
- Building products.
- Maintaining systems.
- Working on infrastructure.
- Supporting enterprise applications.
- Solving incidents.
- Designing architecture.
- Working with clients.
- Writing code.
And apparently, waking up at 4-something in the morning.😭
Maybe this year isn't as useless as it feels
There are definitely days when I wonder whether I'm wasting a year of my life. I'm learning technology I don't particularly want to specialize in. I'm doing work I don't particularly enjoy. I'm dealing with organizational problems I have almost no control over.
And I'm still trying to study Japanese, build things outside work and figure out where I actually want my career to go.
But then I think about what has actually changed since I joined:
I understand large organizations a little better now.
I notice communication problems I probably would've ignored before.
I understand why training and experience aren't interchangeable.
I'm starting to notice how much context experienced engineers carry around without even realizing they're carrying it.
I've also become a lot less afraid of asking stupid questions.
Which is probably good, because I have asked A LOT of them.
And perhaps the most useful thing of all:
I have a much clearer idea of the kind of work I don't want to spend the next ten years doing.
That counts too. Knowing what direction is wrong when lost in a forest is also good.
I don't know what the final lesson is yet
Maybe that's the most honest way I can end this.
I'm still in the middle of it... I'm still making mistakes.
Still trying to get better.
Still wondering when I'll finally become a morning person.
And I don't know yet whether I'll look back at this year and think:
"That was a waste of time."
Or:
"That was the year I learned how the real world actually works."
Maybe it's going to be both.
But I do know that your first engineering job doesn't necessarily give you the experience you imagined you were going to get.
Sometimes it gives you something else entirely.
And maybe that's still a lesson hidden in there somewhere.
So how about the experienced peeps here?
What did your first job teach you that you didn't realize you were learning at the time?
Was it technical?
Was it about people?
Was it about how companies actually work?
Or was it simply figuring out what you never want to do again?
I'd genuinely like to know.
Top comments (1)
It's all fun and coding until you get into an environment where you are not taught at all. I notice this when you start actually working instead of learning new languages and such. Turns out communication is a bigger thing than just coding lol.
Speaking of communication, I sent you a message on Slack in the Virtual Coffee group. It's important to let you know :)