There’s a widespread misconception in software engineering that “real work” means sitting at your keyboard pounding out code all day. That couldn’t be further from the truth. Writing great software isn’t about slinging syntax—it’s about thinking critically, solving problems, and architecting systems that can survive real-world use.

That’s why I’ve been saying for years:

“If you’re coding all day, you’re doing it wrong.”

Writing code should be the smallest part of your job. Thinking, planning, designing, collaborating, and solving problems—that’s what makes you a real engineer.

What Should Come Before Coding

Before you ever crack open your IDE, several critical activities should already be happening:

• Requirements gathering and clear feature documentation
• Design and architecture sessions—with documentation that actually gets used
• Research into the right tools, frameworks, and third-party libraries
• Proof-of-concept (POC) work to validate risky ideas before scaling
• Security considerations, including threat modeling and secure design principles

Skipping these steps doesn’t make you faster—it guarantees rework.

What Happens During and After Coding

Even once coding begins, it’s only one part of a much larger workflow:

• Writing unit tests and integration tests, and validating coverage
• Keeping technical documentation accurate and up to date
• Collaborating closely with QA, DevOps, and product teams
• Performing performance tuning, including memory profiling and benchmarking
• Ensuring observability is in place—logging, telemetry, and alerts for long-term support

If you’re only writing code and none of this, you’re building short-lived software.

If You’re a Senior or Lead Developer

Leadership isn’t hiding behind Jira tickets or pull requests. A large part of your role should include:

• Mentoring junior developers—something far too many companies undervalue
• Conducting code reviews that teach, not criticize
• Championing coding standards, performance best practices, and maintainability

At one company, 20% of my time was officially allocated to mentoring. As the .NET expert, there were days when a literal line formed outside my cubicle—developers at all levels, including leads, waiting for help. That’s not a brag. It’s a warning: mentorship is usually neglected until the damage is already done.

Too Many Meetings? You’re Still Doing It Wrong

On the other extreme, if your day is consumed by meetings, that’s another red flag. “Meeting-happy” companies are everywhere—and they’re productivity killers. Excessive, unfocused meetings don’t just waste time; they destroy momentum, drain morale, and push teams straight into deadline chaos.

At one company, meetings were treated like a badge of honor. I coined a name for them: “Merry-Go-Round Meetings.” Fifteen to twenty people stuck in a room for two hours, accomplishing nothing. Why? Because no one came prepared. Half the meeting was spent explaining documentation that no one bothered to read beforehand. The cycle never ended.

At that same company, I once stood up mid-meeting, looked at the manager in charge, and said:

“Call me when the right people are in the room and we’re actually making decisions.”

Then I walked out.

Blunt? Yes. Necessary? Absolutely. Wasted time costs money—and sanity.

Even worse is when managers spend all day in meetings. If you’re responsible for people, projects, or products, you can’t manage effectively from a Zoom box or conference room chair. That’s not leadership—it’s avoidance. And when accountability disappears, deadlines slip, bugs pile up, and engineers burn out.

I don’t stay long in environments like that—and frankly, neither should you.

Ask Yourself This

On average, how many hours a day do you spend actually coding?

If the answer is “all day,” you’re not engineering—you’re just implementing.

Real Success Comes from Planning, Not Hacking

In my experience, every successful project I’ve worked on—including the one that earned me a software patent—was built on solid architecture, careful planning, and strong collaboration.

The worst projects? They skipped all of that. No design. No planning. No documentation. Just “code and pray.” Most of them failed—or are barely hanging on today.

This isn’t a personal preference. It’s a systemic industry problem. And until companies prioritize engineering over hacking, software failures will remain the norm.

Summary

Being a great software engineer means far more than writing code. It means designing, planning, mentoring, testing, and communicating effectively. If you’re coding all day, you’re likely skipping the steps that lead to scalable, maintainable, and successful software.

Think bigger.

Engineer—don’t just code.

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.