5 Things I Wish I Had Known Earlier as a Software Engineer
After a few years of experience, I look back and share five lessons I wish I could pass on to my younger self.
When I started my career as a software engineer, I had a lot of energy, some skills, and even more unanswered questions. Today, after a few years of experience, I look back and think: “If only I had known then what I know now”.
That doesn’t mean I took the wrong path the whole way. Not at all. But there are things — both fundamental and practical — that could have saved me time, frustration, and a few poor career decisions.
In this post, I’ll share five lessons I wish I could pass on to my younger self from a few years ago. If you’re just starting out or are mid-career and wondering what to do next, maybe they’ll be useful to you too.
1. Find Your Specialization (And Dive Deep Into It)
At first, it seems to us that the sensible direction is to become a “full-stack” developer and learn a bit of everything at a surface level. That’s what I thought. But after a few years, I understood something more important: depth beats breadth.
When you choose a domain — whether it’s Fintech, robotics, DevOps, or something else — and you truly immerse yourself in it, you become more than just a programmer. You become a specialist. And specialists are worth more (both to an employer and on the job market).
It’s not about never learning something new. It’s about having a core domain — an area where you know not only the code, but also the business, the regulations, the best practices, and the history of technology in that sector.
When you go to a job interview and say: “For 3 years I’ve been working with microservices on Kubernetes and I know it like few others” vs “I know a little about everything” — the difference is enormous.
My advice: Don’t panic if you don’t yet know where you want to specialize. But start paying attention right now to what excites you most. What brings you joy? What do you want to master? And once you know — go deep.
2. Continuous Learning Is Not Optional — It’s a Necessity
I remember thinking: “I’ll finish my courses, learn Java, and it’ll be fine for the next 5 years”.
Ha! How wrong I was.
The IT industry changes faster than anything else. What was standard a year ago is already outdated today. The framework everyone used now has competition. A new architectural paradigm emerges every few months. And in recent years, AI has joined the mix — and it’s changing everything.
If you stop learning, you don’t stay in place — quite the opposite: you fall behind.
That doesn’t mean you have to take courses 12 hours a day. It’s about consistency. Reading articles, experimenting with new tools, listening to podcasts, talking to industry peers — all of this counts.
Especially now, with AI reshaping the landscape: we need to understand how to use it in production, how to integrate it, what its limits are — this is becoming an everyday baseline.
My advice: Schedule at least 5-10 hours per week for learning. It can be anything — an article, a video, an experiment, or even reading source code. Consistency beats intensity.
3. Ask, Ask, and Ask Again
This was the biggest lesson for me.
When I was a junior, I thought I had to know everything. That asking a question would put me in a bad light. “Maybe they’ll think I’m not competent?”
Nonsense.
Instead of asking, I’d sit down at my computer and spend 3 hours on Google, StackOverflow, and debugging. When I finally broke down and asked a senior — I got the solution in 5 minutes. The problem was in three lines of code I had no idea even existed.
It was painful, but educational.
Here’s the truth: every expert once didn’t know what they know now. Everyone asked questions. And furthermore — everyone still asks, because there are always things at the edges of our knowledge. Even the best engineers at Google or Meta ask questions every day.
Asking questions is not a weakness — it’s a sign of wisdom. Those who ask don’t wander. Those who don’t ask collect knowledge randomly and inefficiently.
There are no stupid questions. There are only questions not asked, which cost hours, if not days, of work.
My advice: Cultivate shamelessness. Ask your seniors, colleagues, mentors. Post questions in the community (Discord, Reddit, Forums). Build relationships based on something you don’t understand — it’s the best starting point for a conversation.
4. AI Is Not the Future — It’s the Present
I may be the biggest AI skeptic, but that doesn’t change the fact: I have to live and work with it.
Already today — not in 5 years, today — employers expect you to know the basics. Where to use generative AI in your workflow? How to use it safely? How to automate boring tasks? How to speed up the development process?
It’s no longer “nice, great if you know it.” It’s “you should know this.”
I remember thinking: “Maybe AI will never take hold at that scale in programming”. I was a bit too optimistic. Today, every third line of code I write is AI-assisted (whether it’s GitHub Copilot, Claude, or another tool). And I’m more productive.
If you don’t learn this now, within 2-3 years you’ll clearly be behind the competition. This isn’t fear-mongering — it’s the reality of the job market.
My advice: Install Copilot, try out ChatGPT, Claude — stay practically up to date. You don’t need to be an expert, but you need to know how it works and where it’s useful. Treat it as a mandatory skill, like Git or SQL.
5. Engineering Is More Than Code
Here’s what surprised me early on: the best engineers on my teams didn’t always write code the fastest.
But they could:
- Talk about problems in a way that the whole team could understand
- Understand DevOps — not as an Ops person, but enough to communicate
- Think architecturally — choose solutions with awareness of long-term consequences
- Know the business — understand what we’re really trying to achieve, beyond the code itself
These are multiplier skills. Good code + poor communication = wasted potential. Average code + excellent communication + understanding of scope = usually a decent project.
Too many young engineers think: “I’ll just learn to code and everything will work out”. But the truth is: code is only one part of an engineer’s job. The rest is soft skills, understanding context, and a willingness for continuous growth.
My advice: Don’t ignore communication skills or the basics of DevOps. Ask about project architecture. Talk to product managers. Understand why we’re doing something, not just how to do it.
Summary
If I could tell my younger self just one thing, it would be: Engineering is a marathon, not a sprint. You can’t know everything at once and that’s OK. But how you approach learning, asking questions, and listening to feedback — that defines your trajectory.
Choose a domain where you want to be a master. Never stop learning. Ask without shame. Watch the trends (AI won’t wait). And remember that the best engineers are those who understand that code is only part of the story.
If you found this article useful, share it — maybe it’ll help someone else too!