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 and 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.
So... what did I think I'd be doing?
When I joined my current company, I had a pretty simple idea of what my first engineering job would look like. I'd write code, learn new systems, make mistakes, get better, maybe work on some cool technology and generally do all the things I had imagined software engineers do.
Simple toodledoo.
But no, I got dropped into a large company 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 mini side project.
Which is fair, because people actually depend on these systems and I don't think anyone wants the new guy deciding at 10 AM that the architecture could be "cleaner" if we just rewrote everything.
Please don't. 🥹 Someone will materialize right behind you.
A lot of my current work is around supporting existing mainframe systems, maintaining records, following processes and dealing with systems where privacy and security are taken pretty seriously.
So there aren't many moments where I can just go "hmm, what if we did this instead?" and start changing processes. The system already exists, people already depend on it, and there are manuals that you have to check before doing what sometimes looks like a very tiny operation. Which again gets reviewed on multiple layers, from team lead to onsite.
And one of the weirdest parts of being new here is that sometimes I don't even know WHY I'm doing that operation.
I might be told to add, delete 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 that.
But then there's this little voice in my head going, "Okay... but what does this value actually DO man?"
What depends on it? Why are we adding this thing in the first place?
And more times than most the answer is:
I DON'T KNOWWWWW.
I'm not talking about the big business purpose of the application either. I'm talking about the 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 always know the reason behind the procedure.
I could spend hours trying to understand every little detail, but that's not always practical either. There's already a ridiculous amount to learn, and I can't spend that much time on something that "needs to be done ASAP". EVERYTHING NEEDS TO BE DONE ASAP.
So I'm slowly trying to figure out where that balance will stirke.
This is something I never really had to think about with my side projects. There, I usually knew exactly what I was building and why. If I created some random React app at 2 AM, at least I knew why the database had a particular field because I was the idiot who put it there.
Here, nuh-uh.
Then came the training
The onboarding process was basically split into three stages: KT, simulation and then hands-on.
During KT, we learned the systems, processes, terminology and all the things we were apparently expected to know. Then came simulation, where we performed the work without actually working on the real tools. Straightforward stuff.
And then hands-on, that's when things got interesting, because simulation is... well... only simulation.
You can understand the steps, follow the documentation and complete the scenario correctly, but 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. I think it's just that knowing what you're supposed to do and actually doing it inside a real system are two different things.
You can read about Git for weeks, understand deployments, build a demo application, yada yada... and then something actually breaks and suddenly you find out about something the tutorial never mentioned.
And this is probably where I've felt the most confused. I understand why mistakes can't just be ignored. These are important systems and getting something wrong can cause actual problems.
But if you've only just moved from simulation to actually using the tools, making some mistakes is also kind of the point. That's how you figure out what you don't know. That's how you slowly get those little instincts that make the work easier later.
The experience thingy
There's another part of this that I've thought about quite a lot.
The people who worked on this project before us had around 20+ years of experience.
I'm 22. Well, 23 in a week or 2, 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 with most of the experience on our side.
And he's obviously one person. He can't handle every technical question, every problem, every decision and every communication issue for an entire team. So sometimes you really feel the experience gap.
We're learning, we're making mistakes, and at the same time we're being expected to work at a level set by people who had already spent years learning the system.
And in my case there's another thing too, because 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 trying to understand what someone is telling me in a language I'm still learning.
That's not an excuse for making mistakes. If I mess something up, I still need to get better, and it really is a skill issue sometimes.
I didn't understand something properly, I missed something, I made the wrong decision. It happens a lot. And I am guilty of making the same mistakes 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 without being in control
Another thing I've started thinking about is responsibility and control.
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. Obviously I'm responsible for the work I do. If I make a mistake, that's on me.
But I'm not 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.
You can be responsible for your work without being responsible for everything around your work. And there's another thing here too. Not everyone is working with the same setup. The people questioning our turnaround times sometimes have access to systems and tools that make certain operations much faster, while our side is working with a 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. That's something I probably wouldn't have thought about much before working in a big company.
How fast you work isn't only about how hard you're working. The tools you have, what you can access, the process you're following and how many other people you depend on all matter too.
Communication is a whole other thing
Communication has honestly been its own learning experience. There are multiple layers of management, different expectations and sometimes different instructions. One person says one thing, another person says something slightly different, you follow what you were told, and then someone else asks why you did it that way.
Suddenly you're wondering whether you're solving a technical problem or playing a very elaborate game of telephone.
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 took 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 that, I've started noticing that communication isn't just about whether the information reached the other person. 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 GitHub issues, Discord messages and "hey can you review this PR?"
Somehow communication keeps coming back no matter where I go, it's kind of ironic that people always say how important it is but miss that point when it comes to actual practice.
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 look easy, it's pretty easy to start thinking that maybe you're not good enough.
I don't think I should look at it that way(for my own sake). We're inexperienced. We're learning a system that existed before we joined, we're learning through KT, simulation and hands-on work, and we're expected to become productive pretty 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. Sometimes I did misunderstand something and that's it.
But I've also realised that you eventually have to let people actually do the work if you want them to get good at it.
You need enough room to make mistakes, understand why they happened and slowly build the kind of understanding that a manual can't give you.
Also I think I don't like this kind of work
There's also something else I've had to accept during all this. I don't really enjoy the work itself.
Support and maintenance aren't what I imagined myself doing long-term. Mainframes aren't something I see myself specialising in, and honestly I don't think that's a bad thing to realise.
I used to think that if I got a software engineering job, I'd automatically know whether I liked being a software engineer.
You can build products, maintain systems, work on infrastructure, support enterprise applications, solve incidents, design architecture, work with clients or just write code.
And apparently, wake up at 4-something in the morning. 😭
Maybe that's one of the useful things about a first job. You don't always find exactly what you want to do. Sometimes you find out what you definitely don't want to spend the next ten years doing. That counts too right?
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. Even though 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 big companies a little better now. I notice communication problems I probably would've ignored before. I understand why training and experience aren't the same thing, and I'm starting to notice how much stuff experienced engineers just know without even thinking about it. Baffling. I've also become a lot less afraid of asking stupid questions. And maybe the biggest thing is that I have a much clearer idea of the kind of work I don't want to spend the next ten years doing. Knowing which direction is wrong is still useful when you're trying to figure out where to go.
I still don't know what the lesson is
I don't know what the final lesson is yet, and 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 and still wondering when I'll finally become a morning person.
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 always give you the experience you thought you were going to get. Sometimes it gives you something else entirely, and maybe you only understand what that was much later. For now, I'm still figuring it out.
If you've been working for a while, I would definitely like to know what your job taught you without you realizing it at the time.
