4 Disciplines That Separate Effective Engineers From Busy Ones

Learn about the daily habits that help engineers be more effective. (7 min)

Feb 24, 2026

This post outlines my personal experience working with numerous engineers across various companies and distilling what habits an effective engineer has.

Those engineers ship less, talk more, think further ahead, and treat AI like a power tool, not a replacement for judgment.

Share this post & I’ll send you some rewards for the referrals.

Imagine spending six weeks building a sleek, real-time notification system that nobody actually requested.

You nailed down the “right architecture”, covered the codebase with tests, and perfected the documentation.

Then comes the week before launch. Your PM demos the masterpiece, and suddenly part of your customers refuse to use it while the other asks why a certain bug still exists.

Stories like this project remind me of the difference between being efficient and being effective.

Efficient engineers do things right.
Effective engineers do the right things.

After 8+ years of shipping software, hiring engineers, and watching teams succeed and fail, I’ve distilled what makes engineers genuinely effective into four disciplines.

And none of them is about writing clever code.

BrightData: Connect Your AI To The Internet’s Data - Sponsor

Bright Data’s Web MCP solves web access for LLMs and AI agents, allowing them to effectively search, extract, and navigate the web without getting blocked. It helps to:

Search the web in real-time
Extract data from any website
Navigate and interact with pages
Bypass blocks and restrictions

It comes with a generous free tier - 5,000 MCP requests every month - for free!

Try For Free

1. Solve the Right Problems; Not Just Any Problem

Traits: Care about the user. Understand team strategy. Prioritize ruthlessly.

The most expensive line of code is the one that solves the wrong problem.

I’ve seen teams spending time into plubming, like managing a custom-built deployment pipeline, instead of leveraging $50/month SaaS.

Here is the uncomfortable part: most engineers aren’t trained to say no.

We’re rewarded for building. Promotions come from shipping. Saying “we shouldn’t build this” doesn’t show up in a pull request.

But caring about users, I mean actually caring, not only claiming that on a performance review, means understanding their real problems deeply enough to know which solutions are worth pursuing and which are engineering vanity projects.

And you can’t make that judgment in a vacuum.

You need to understand your team’s strategy:

What are we trying to accomplish this quarter?
How does my work connect to revenue, retention, or reliability?

Engineers who can answer those questions prioritize themselves.

Engineers who can’t are always waiting to be told what to do next.

So next time, before writing any line of code, force yourself through these three questions:

Who suffers if this doesn’t ship? If the answer is “nobody, really,” put it in the icebox.
What’s the cheapest version that tests the hypothesis? A spreadsheet, a Figma prototype, or a hardcoded endpoint can often answer the question a six-week feature build was supposed to answer.
What am I not doing by doing this? Opportunity cost is invisible until you’ve missed a deadline on the thing that actually mattered.

Of course, we can’t do some of these things by ourselves. That’s why we have Product Managers who are the point of contact to the end users and our organization.

Our job as Effective Engineers is to advocate for users, do extensive user research, and prioritize user needs.

2. Keep It Simple; Leave It Better

Traits: Simplicity over cleverness. Quality as a discipline. The Boy Scout Rule.

I’ve reviewed pull requests where the author used three levels of abstraction to avoid repeating four lines of code.

The DRY principle is good. But taken to its extreme, it produces code that’s “elegant” but unreadable to everyone except the person who wrote it, and often to them too, three months later.

Simplicity isn’t the absence of thought. It’s the result of deep thought.

It means you’ve understood the problem well enough to solve it without over-engineering.

The engineers I respect most write code that a new team member can read on their first day and say, “Okay, I see what this does”.

But simplicity alone isn’t enough.

The effective engineers also leave things better than they found them.

Every PR is an opportunity: fix a flaky test, update a stale README, delete dead code, or rename a confusing variable.

None of these show up in a sprint demo.

All of them compound into a codebase that’s a joy to work with versus one that slowly rots.

So the next time you write and ship code, try to:

Set a complexity budget. If a solution requires more than one new abstraction, pressure-test whether that abstraction earns its keep. Often it doesn’t.
Timebox polish. I allocate roughly 10-15% of every feature’s time for cleanup, not gold-plating, but genuine improvement to the code I touched and the code around it.
Measure quality that matters. Track things like time-to-first-meaningful-PR-review for new hires, or incident rate per deploy. These tell you more about codebase health than test coverage percentages.

You have to be comfortable with invisible contributions.

The payoff comes in months, not days: fewer incidents, faster onboarding, less time debugging code nobody understands.

3. Earn Trust; Communicate Relentlessly

Traits: Build trust and social capital. Communicate effectively. Operate with autonomy.

Early in my career, I thought trust was a soft-skills thing, something you got for free by being “nice”.

That’s not how it works.

Trust is an engineering asset.

It’s the reason one engineer can get a risky refactor approved in a single meeting while another spends two sprints writing a design doc that still gets rejected.

Think about it mechanically: engineers who’ve built trust get more autonomy.

More autonomy means they can take bigger swings.

Bigger swings, when they land, build more trust. It compounds like interest.

And the inverse is just as powerful: one blown deadline or one surprise production incident you didn’t communicate about can set you back months of accumulated credibility.

Communication is the engine that drives all of this.

Not “being good at presentations”, I mean the boring, daily discipline of keeping people informed. Status updates nobody asked for. A Slack message before you merge something risky. Flagging a blocker on Day 1 instead of Day 5.

The engineers who do this consistently become the ones everyone wants on their project.

Here are a few things you could try:

Estimate honestly, then pad 20%. On one project, I started adding explicit “risk buffers” to my estimates, and my on-time delivery rate went from roughly 60% to over 85% in two quarters.
Communicate bad news early. If a project is slipping, saying so on Day 3 builds trust. Saying so on Day 13 destroys it. I’ve never seen anyone punished for early transparency. I’ve seen plenty punished for late surprises.
Review others’ code generously. Fast, thoughtful code reviews are one of the highest-leverage trust-building activities in engineering. They signal “I respect your time and your work”. They also build social capital, the kind of relationship equity that means people answer your Slack messages in minutes instead of hours.
Invest in relationships outside your team. Grab coffee with the infrastructure team. Understand what the data team is struggling with. Cross-team relationships pay dividends when you need a favor, a quick answer, or buy-in on a proposal.

Building trust slowly means you won't be the hero on Day 1. You might watch a louder, faster colleague get more visibility early on. The patience required is real.

And there's an uncomfortable truth: trust is context-dependent.

Switching teams or companies resets the meter. You have to be willing to re-invest every time.

4. Think Long-Term; Adapt Constantly

Traits: Second-order thinking. Comfort with new challenges. Wielding AI as a force multiplier.

Junior engineers think about whether their code works. Mid-level engineers think about whether their code is maintainable. Senior engineers think about what their code causes, downstream, six months from now, in systems they don't own.

And here's the thing that's changed in the last two years:

Long-term thinking now includes your relationship with AI tooling.

The engineers who treat GitHub Copilot, Claude, or Cursor as magic black boxes are building on sand.

The ones who understand what these tools are good at (boilerplate, scaffolding, routine refactors), what they're bad at (nuanced architecture decisions, security edge cases, understanding your specific business context), and how to verify their output, are the engineers who are genuinely 2-3x more productive.

But only because they bring the judgment the AI lacks.

Treat AI-generated code like a pull request from a confident but context-blind junior.
Review every line. Question every assumption. The speed is real, but so are the subtle bugs.

Being comfortable with new challenges has always mattered. Now it's existential.

The landscape shifts every six months.

The engineers who thrive aren't the ones who memorize every new framework.

They're the ones who've built strong enough fundamentals that they can pick up any tool quickly and evaluate it critically.

Second-order thinking is slow.

Learning new tools takes time away from shipping.

There's a real risk of analysis paralysis, and an equally real risk of chasing every new AI tool instead of mastering the one you have.

The discipline is knowing when the blast radius is large enough to warrant the extra thought, and when to just ship.

You can learn a new framework in a weekend.

You can learn a new AI tool in an afternoon.

These four disciplines take years. Start now.

See you next time! 🙌

PS: My friend Marko Denic has recently launched his new FREE e-book: The Technical Decision Framework. It’s about a framework for the choices that shape your codebase.