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.
Top comments (42)
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 :)
It is likely that when you are in charge of a big project, you will be involved in only a small part of the work. On the other hand, if you are in charge of a small project, you will likely be involved in a wide range of work. Welcome to my startup! It is so small that you can do anything you like! 🤣
Hey WDH!! Thank you for the comment, and having me in your startup too I guess😭 It really makes me feel better to know I have a backup plan right here🤣
Sounds like my first job in big corpo 😄 I think communication issues come naturally in such an environment. It's still an important lesson – since it's your first job, you're figuring out what you like, what you want to do in your life, what works for you, and what doesn't. It's not the knowledge you start with; rather, you get it by trying out different things.
Also, for your next job, consider a smaller company (maybe a start-up?). They usually give much more flexibility, and in the case of a start-up, you do not have to maintain old technologies.
Eheheh, I see many colleagues struggling with production to such an extent that very often what they suggest as a solution for the dev environment has no chance of working on prod, for example under heavier load 😄 But this is another important lesson, and, in my opinion, dev colleagues simply undervalue prod – in the end, whether we like it or not, this is where the money comes from.
Good luck with your first job, Aryan! You're doing great!
Hey Klaudia! Thank you for taking your time to write this... I think I lucked out with the right skills at the right time, and I am also thinking of moving to a smaller company after my N2 is done, or might even go solo, will cross that bridge when I get there.
Hahaha, consider me one of your dev colleagues then, I've been listening to lectures and taunts in group meetings, about the same thing for the last 2 weeks now😭 and I genuinely try not to make any mistakes but still somehow manage to miss a unique step every time. It's like some bad luck is onto me ಥ‿ಥ
Once again, thank you for the comment and the well wishes. Good luck to you too(＾∇＾)ﾉ♪
My first job in tech was back when I was still at university, teaching kids to code in Python. I ran one on one online lessons with kids from Ukraine and the EU. We wrote Minecraft scripts and built small games in Python :D
That is such a cool job man!!! I hope I can find something fun like that soon!
Yoo, thats actually a good job to have!! the kids must be so excited every time!!
This is the part no one really prepares you for, learning that engineering in the real world often means understanding old systems before changing anything. Still, those experiences teach you more than a rewrite ever could.
Yes definitely Allen, thank you for commenting!
One thing that stood out to me is the distinction between being responsible for your work and being in control of the system around your work.
In large organizations, productivity is rarely just about how fast one person works. Tooling, access, dependencies, process design, training, and communication all become part of the equation.
I also liked the point about learning what you don't want to spend the next ten years doing. A first engineering job doesn't necessarily have to confirm your career direction — sometimes it gives you enough evidence to change it.
Hey Suraj! Exactly my thoughts, I think we figure out exactly what to do as we move ahead.
Thank you for your comment!!
Exactly. I think that’s one of the underrated benefits of a first job — it gives you evidence, not just experience.
You may not immediately know what you want to do, but you start getting a much clearer picture of what kind of problems, environments, and responsibilities actually fit you.
And honestly, realizing that early can be just as valuable as finding the “perfect” role.
love the energy of the article really interesting thanks you sharing
Thank you so much for reading and the supporting comment @jsb-securedme !!
it just right in time for me to read your article im looking for a job it 5 years im a solo dev it will be so weird working for someone else i don't know what to expect and i end on your article it was perfect i'm not alone with my fear other have thanks you sharing your story it help me coping with the stress so thanks to you ^_- all honor are your's
Hey Jean! 5 years as a solo dev is huge, and it's okay to feel weird, it might be little different from your usual experience as a solo dev, but other than that I think you'll be better than most.
If you don't mind me asking what position or JD are you joining in as?
And also really appreciate your comment man, really sweet of you... All the best to us for the future! Thank you so much(/^-^(^ ^*)/
To be honest, I'm still figuring out exactly what role to target! I've been building SeCuReDmE solo for the last 5 years, and since I wear every single hat—basically handling all the C-suite tasks—it’s hard to figure out where I fit in, especially since I don't have a formal diploma. My biggest fear right now is that without a degree, I'll just end up stuck doing administrative tasks, filling out endless paperwork, or running test after test, without ever getting to use all the deep technical knowledge I've built to actually create something useful.
Looking for a traditional job feels weird because I always have this hope that my company is going to take off at any moment. The reality is that the architecture of my project is incredibly complex. The funny part is, whenever I jump into someone else's codebase to fix their bugs, it feels so easy! But navigating my own massive system is a long, arduous journey. I definitely didn't choose to build something simple. Ultimately, the hardest part right now is accepting that I have to go work on someone else's dream while trying to keep my own alive.
Thanks again for the kind words and encouragement—it really means a lot to me as I navigate this massive transition!
Wow that's so cool!!! You made something so difficult that everything else feels easy... But I really hope you find something that doesn't take too much of your energy or time so you still can keep your own dream alive. I really wish the best for you Jean. All the best!!
Your honest take on the 6:30 AM wake‑up and the surprising lessons you’re learning on the job really resonated with me. If you think it could help more devs, consider syndicating it on ZyVOP (zyvop.com) to reach a wider audience.
Hi Aryan, please check zyvop.com, I hope you like it, some developers from here are already registered
The gap between what we imagine engineering will be and what production support actually looks like can be huge. But honestly, learning to work with legacy systems, understand constraints, and protect production is valuable engineering experience too. The “new guy rewriting everything” phase is probably best avoided!
Hahaha yeah, that's why not everyone is given the access to edit everything, it's for the best. But that itch of curiosity to only know about the architecture or why something happens doesn't just fade away.
Anyways thank you for commenting Edward!!
I totally agree with the meeting being the bottleneck part, some sprints back in retro, we (the dev team) pulled this issue that the meetings take too long and doesn't require everybody on call for a single person's issue/doubt and they listened haha, now our meetings are hella short, like only a standup call 4days a week and two grooming calls not more than an hour long and that concludes our meetings for the sprints haha.
sometimes if your team lead is willing to bring up the topic as well as the PO's are understanding people then the team can function without being a pain in the butt of each other.
anyways, about the lesson part my bordie, you dont have to have it figured out, afterall that's what life is all about, we never know what's coming your way, a punch on the face or warm embrace of prosperity haha
That's... something I am jealous of
Some comments may only be visible to logged-in visitors. Sign in to view all comments.