Being a good software engineer is about more than just writing code or designing systems. Over time, I've realized how several underrated skills have made a real difference in how I work and grow as an engineer. These are things I learned through real product experience. Here's my take based on personal experience:
1. Reverse Engineering
This is essential when consuming internal or third-party services. Ideally, documentation and support should answer all your questions but reality differs.
When something doesn't work, internal teams might ask you to debug it on your own. Changing their code might be slow or deprioritized, especially for platform services used by many teams. Understanding how things work (or break) by reverse engineering helps you move forward independently.
Sometimes, it's the only way to adapt quickly and unblock yourself.
2. Impact Analysis
Every new feature brings a flood of questions:
- Will it affect performance?
- Is it compatible with our tech stack?
- Can our current system support this?
This kind of analysis is underrated but vital. It helps define timelines, assess risks, and avoid surprises. As a full-stack developer, this skill deepens over time as you start understanding the product end-to-end.
Poor analysis often results in unrealistic estimations or late-night firefights — both avoidable with a little upfront thinking.
3. Prioritization
A software engineer's day can be absolute chaos — bug fixes, feature development, calls with PMs, reviews, production issues, deployments; all stacked in random order.
You can't do everything at once. The real skill lies in constantly re-evaluating what matters most right now, especially when priorities shift with a single Teams message. Being able to communicate what's on your plate and how trade-offs affect delivery is a game-changer.
This is my daily mantra for life & work: "Prioritization is key to survival."
4. Writing Maintainable Code ~ Not Just Optimized Code
We all love writing clever, optimized code. But remember — requirements change. What was "perfectly optimized" yesterday may become a liability tomorrow.
Your code should:
- Be easy to debug
- Be adaptable to changes
- Avoid unnecessary complexity
If the code is too tight or abstract, even a small change can introduce regressions or require complete rewrites. Maintainable code is a gift to your future self and your team.
5. Logging Smartly
Logging is your best friend during debugging, if used wisely. Placing the right logs at the right places can save hours and weekends. Logs can reveal what went wrong without even opening the code.
A few tips:
- Use info, warn, error levels correctly.
- Always log in catch blocks with context.
- Don't log everything — it increases operational costs and creates noise.
It's a skill — some devs log everything, some log nothing, and the smart ones log just enough to catch bugs fast.
6. Comments & TODO Habit
Comments are a silent form of communication — dev to dev. Yet they're often neglected.
Vague or overly simplistic comments like "// calculate sum" are useless. Helpful comments explain:
- The why behind code, not just what it does
- The thought process behind edge cases or decisions
One coding practice I use is the Functional TODO method; it also takes care of writing useful comments. As soon as I complete the analysis of a feature, I map out where changes are needed and what should happen at each step in the code. For example:
// TODO: Call strategy engine with x, y, z input. Expect result as List. Apply fallback logic for timeout.
This helps build an end-to-end picture even before writing actual code. Many IDEs, code editors, and extensions support highlighting of TODO, FIXME, etc. take advantage of those.
7. Excel & Visual Thinking
This might sound irrelevant to our role, but Excel is a surprisingly powerful tool for communicating ideas — especially with non-technical stakeholders.
In real-world product development, we work with a variety of people: managers, consultants, sales teams, QA, product managers, and even customers. Whether it's tracking tasks, planning releases, or discussing complex features, Excel often becomes the go-to medium.
I remember working on a strategic recommendation engine - it was a complicated feature, and for almost a month, all our pre-grooming discussions with PMs happened entirely on Excel. No stories, no tickets; just spreadsheets that helped us all align on the logic.
Even in another product heavily dependent on numerical data, Excel was the first step before anything moved to engineering. Many devs often freshers use pen and paper - that's great for individual clarity, but when collaborating in online meetings, we need digital, visual communication. That’s where Excel or even whiteboarding tools like Excalidraw or tldraw shine.
TL;DR: If you want your ideas to be heard, make them visual and digital.
8. Communication (Not Just Talking)
As engineers, we talk to many people: other developers, product managers, leadership, juniors. Each conversation demands a different approach.
- Sometimes you need to take a stand
- Sometimes it’s about listening and finding middle ground
- Sometimes it's just about asking the right questions during a KT
Being clear, respectful, and purposeful in communication builds trust and saves a lot of back-and-forth.
At the end of the day, every job is about how well you manage people and communication is your biggest tool.
9. Understanding Stakeholders and the Business
Every product or service you build serves different purposes, depending on the stakeholder:
- Management cares about delivery timelines and revenue.
- Sales teams look for market differentiation.
- Platform services prioritize reusability and reliability for internal teams.
- Engineering teams want efficiency and scalability.
Sometimes not all points of view can be satisfied. Trade-offs are made but knowing each party’s perspective helps you adapt, plan better, and contribute meaningfully. Understanding the business is what makes you a complete engineer.
Always remember:
It’s about how the product moves money and creates value.
Final Thoughts
None of these skills are “hard skills” in the traditional sense — but they make a huge difference in the long run. You grow faster, collaborate better, and reduce friction across the board.
Because at the end of the day, writing code is just one part of the job.
Originally published on LinkedIn.