Staff Engineering on Peter Fulop

Switching from doing to directing

Sun, 12 Jul 2026 00:00:00 +0000

We are already in the era of AI-assisted software development. In that world, I think software engineers need to spend less time only doing and more time directing.

I work with young, sharp, deeply motivated colleagues. Many of them are already strong builders. What I want to encourage is not less ambition or less hands-on work, but a shift in where more of their thinking goes. Not just into writing code, but into setting direction, shaping context, and taking responsibility for the outcome.

I use the word “directing” very intentionally.

It means setting direction: sketching the architecture, defining standards, and establishing working patterns.
It means shaping the script: building the context, boundaries, and guardrails that guide the work, then refining them as the solution evolves.
It means owning the result: understanding what is being pushed to production and avoiding comprehension debt later, when the system needs to be supported, changed, or debugged.

I had this on my mind already, and then over the weekend I read Addy Osmani’s article The Agent-Era Career. He touches several parts of how software engineering is changing in the agent era. The part I want to stay with here is simpler: directing is not about stepping away from the work. It is about being more deliberate about where human judgment is still needed most.

For me, that starts with how much autonomy I give the tool. I do not think this should be treated as a fixed setting. If the task is small, easy to review, and easy to roll back, I am comfortable giving an agent more room. If the change affects production behavior, data quality, or something painful to unwind later, I want a much tighter loop.

It also made me separate two skills that are easy to blur together. One is being clear enough about the task that the agent has a fair chance of doing something useful. The other is checking the output properly. Those are not the same skill. A clean instruction does not remove the need for verification, and fast output does not mean safe output.

That is why I keep coming back to ownership. If agent-assisted code goes to production and causes trouble, the real issue is not who typed it first. The issue is whether the engineer behind it understood what was being shipped well enough. That is the standard I think we should keep.

I am curious how this is handled in your team. Are experienced engineers still mainly expected to do more themselves, or to direct, verify, and own AI-assisted work more deliberately?

After writing this, I realized that directing starts even earlier than setting context for an agent. In Software solutions do not start with code, I explore the work that comes before implementation: understanding the real problem, identifying constraints, and building the mental model that makes useful direction possible.

Effectiveness anti-patterns — part 6: YAGNI: don’t abstract before the second use case

Sat, 23 May 2026 00:00:00 +0000

The prototype was meant to ask a question

YAGNI — You Aren’t Gonna Need It — is usually explained as: do not build something until you actually need it.

The version of over-engineering I have learned to watch most carefully is not the dramatic one.

It is the small, reasonable-looking abstraction that appears during a prototype.

A new piece of work lands. The requirement is small, the user is one team, the use case is specific. The prototype has one job: answer the question on the table.

Then a second thought appears:

“If this works, others will probably want it too.”

That thought is not wrong. It is often a useful instinct.

The risk is letting it drive the first version.

Instead of writing the simplest thing that answers the question, the prototype starts turning into a framework. A configuration layer. A second abstraction. Support for variants that nobody has asked for yet.

The trap with prototypes is that I often know the least about the problem at the exact moment the future shape looks easiest to design.

The second use case does not exist yet. The third is even less defined. But the blank file makes it easy to imagine a clean framework, all the right extension points, and all the variants that might arrive later.

That can feel like care. Sometimes it is. Often, in a prototype, it is just over-engineering arriving early.

A CI prototype we kept intentionally small

A while back, our team wanted to improve how we shipped DAG images to our Cloud Composer environment.

The pattern was roughly this: a data engineer built the image locally, pushed it to Artifact Registry from their laptop, and then updated the DAG. It worked, in the sense that production kept running. It also broke in small but annoying ways: wrong tag, stale dependency, local build differences, unclear ownership of what had actually been deployed.

The agreed direction was to move image builds into CI.

I took the work on. The goal was deliberately narrow: prove that one DAG image, for one representative pipeline, could be built and pushed automatically through GitHub Actions when its source folder changed.

That was enough for the first question.

While sketching the workflow, I could already see the reusable version.

Multiple image conventions. Several target environments. Branch-based tagging. A registry abstraction. A small YAML schema for teams to declare their own build configuration.

All of that might become useful later.

But at that point we had one real pipeline, one team, and one deployment path. Turning that into a shared abstraction would have meant designing from guesses instead of evidence.

In review, we named the trade-off explicitly: are we trying to prove the CI path, or are we designing the future deployment platform?

That question helped keep the first version honest.

So I kept the first version intentionally boring: one workflow file, one image, one Artifact Registry path, and one DAG folder. It also worked.

The next morning someone copied it as a template for a second DAG image. The differences between the two were already enough to show that a shared abstraction would have needed more evidence.

A few weeks later, another team asked if they could use the same pattern. Their setup had a separate registry, an environment-specific build step, and a security review checkpoint that did not exist in our pipeline. A shared platform designed too early would probably have made those changes harder, not easier.

What we have now is a small library of similar GitHub Actions workflows, each specific to its team. There is some duplication. There is also no premature framework in the way.

The day a shared abstraction is actually needed, we will have several concrete examples to abstract from instead of one example and a lot of imagined ones.

I do not want to overstate it. This was a small, deliberately boring piece of CI.

But it was a clean moment of restraint. We shipped the narrow version, and let the second real case teach us what the shared shape should be.

What I had to admit

For a long time I called this kind of thinking “planning ahead.”

Sometimes that was true. Often it was a more comfortable story than the real one: abstraction was more interesting to write than the boring concrete version.

Some of that came from my early object-oriented training. Open/closed. Dependency inversion. Interfaces before implementations. Those principles are useful in long-lived codebases. They are less useful when a prototype has one user, one use case, and one question to answer.

Same habit. Different context.

The simpler version is often harder to choose because it feels less impressive while you are writing it. But it is usually easier for the next person to read, review, debug, and change.

That asymmetry took me longer to internalize than it should have.

What has helped in practice

A few small habits have helped more than any framework or guideline.

They line up with one of the points Addy Osmani makes in his chapter on this anti-pattern: by the time the imagined future requirement arrives, you will usually know more about the real problem than you do today. That has held up almost every time I have honored it, and bitten me almost every time I have ignored it.

Before I add a parameter, abstraction, or configuration layer to a prototype, I try to finish one sentence honestly:

“This exists in this prototype because the specific question being asked requires it.”

If I cannot finish the sentence, the abstraction does not ship.

I also try to write imagined future use cases down in a note or design doc, not in code. A note is cheap. An unused configuration option creates a small maintenance tax that can last for years.

In design reviews, I try to name the temptation out loud: “I wanted to make this generic. I am not going to. Here is why.” Saying it explicitly often makes other people more comfortable doing the same.

The narrowness of the prototype is not a flaw. It is what lets the prototype answer the question quickly.

If it is wrong, we can throw it away cheaply.

If it is right, we can add the abstractions later, with more information than we had at the start.

YAGNI does not mean ignoring future reuse.

It means refusing to encode future reuse before the future has produced evidence.

The question I try to use now

When I notice the temptation to generalize too early, I ask:

If I delete this abstraction right now, does the prototype still answer the question it was built to answer?

If the answer is yes, the abstraction does not belong in this version.

It might belong later, when there is a second concrete case.

But the next version is not what I am building today.

Effectiveness anti-patterns — part 5: when good work is invisible work

Sat, 09 May 2026 00:00:00 +0000

There is a sentence in Addy Osmani’s chapter on engineering effectiveness anti-patterns that stayed with me longer than I expected: visibility issues often become critical when pursuing staff-level roles.

This post is mostly a reflection on that idea and how it connects with platform and data infrastructure work I have seen, and sometimes made harder for myself.

The uncomfortable part is simple: good work is not always visible work.

That is especially true on platform teams.

When success looks like silence

In product work, success often leaves a visible artifact.

A feature ships. A customer-facing bug closes. A screen loads faster. Someone can point to the thing and say: this changed.

Platform and data infrastructure work is different.

A pipeline that runs cleanly does not generate a Slack thread.

A migration that does not break downstream BI does not produce an incident review.

A Snowflake access policy that quietly enforces the right boundary does not get a demo.

The better the work is, the less it may look like anything happened.

For a long time, I was comfortable with that. I liked the idea that reliable systems should be quiet. I still believe that. Noise is not a sign of impact.

But I have also started to see the risk in taking that too far.

If only the three people closest to the work understand what changed, what tradeoff was made, and what failure was avoided, then the work is not just quiet. It is partly invisible.

That matters more as the scope gets wider.

The instinct I had to question

I used to trust the idea that good work would eventually speak for itself.

There is something honest in that instinct. I do not like performative visibility. I do not want every small task turned into a victory lap. Most engineering work is team work anyway, and claiming too much individual credit usually feels wrong.

But I think I confused two different things.

Not performing is good.

Not communicating is different.

If a migration avoided a BI outage, but nobody outside the immediate team knows what risk was avoided, then the result is not legible.

If a production DAG runs without paging anyone, but the handoff decision, operational constraint, and ownership change are only remembered by the person who implemented it, then the system got better but the organizational memory did not.

That is the part I had been underestimating.

The work does not need a louder story. It needs a clearer record.

The distributed-team version of the problem

There is also a structural reason this matters.

I work from Budapest. Some of the people who need to understand my work are in US or in other teams. They do not see the pull request as it happens. They do not sit in every refinement. They do not read every runbook.

They see whatever surfaces.

Incidents surface.

Delivery dates surface.

Cross-team blockers surface.

But a lot of good platform work prevents those things from surfacing in the first place.

That means the absence itself needs some shape.

I do not mean exaggerating it. I mean writing down enough context that someone who was not in the room can still understand the decision.

What could have broken?

What tradeoff did we choose?

Which downstream team was protected?

What would we do differently if the same pattern had to work at ten times the scale?

Those are small questions, but they change the usefulness of the update.

“Airflow upgrade shipped” is a status line.

“We moved the pipeline to the newer 3.0.6 Airflow version, accepted some migration cost now, and reduced the risk of running critical data workflows on an aging orchestration layer” is closer to a decision someone else can repeat.

The second version takes longer to write. It is also the version that carries judgment

Making absences legible

The reframing that has helped me most is this:

Much of platform work creates useful absences.

No incident.

No broken dashboard.

No confused access path.

No data scientist blocked because a notebook-to-DAG handoff was unclear.

By default, those absences disappear.

So I am trying to get better at making them legible without inflating them.

For me, that usually means a short note after meaningful work:

what changed
what risk it reduced
what decision mattered
who benefits from it
what remains unresolved

This is not a grand communication framework. It is closer to a small maintenance habit.

The audience is not only leadership. It is also the future version of the team that will ask, three months later, why we made this choice and what we were optimizing for.

When I do this well, it does not feel like self-promotion. It feels like design documentation written close to the moment when the context is still fresh.

When I skip it, I usually regret it later.

The question I am using now

I am still not naturally good at this.

My default is to finish the work, move to the next thing, and assume the outcome is obvious. In platform work, it often is not.

So I have started asking one question when I finish something that actually mattered:

If somebody two levels away from the work asked what changed, could they explain it in one sentence I would agree with?

If the answer is no, the work may still be good.

It is just not legible yet.

Sometimes the fix is a paragraph to my manager. Sometimes it is a short note in a shared channel. Sometimes it is a small design record. Sometimes it is a blog post like this one, written after I notice the same pattern more than once.

The point is not to make every task visible.

The point is to make the important decisions understandable outside the room where they happened.

That feels, to me, like one of the quiet shifts from senior execution toward staff-level scope.

Not louder work.

More legible work.

A senior mindset is ultimately about trust

Tue, 18 Nov 2025 00:00:00 +0000

For a long time, I felt the pressure to always have an answer, or at least pretend I did.

Gregor Ojstersek’s recent article in the Engineering Leadership newsletter really cuts through this myth. He argues that being comfortable saying “I don’t know” is actually a sign of experience, maturity, and true seniority.

Because a senior mindset is ultimately about trust.

A senior engineer isn’t the one who knows everything — it’s the one who responds confidently and constructively when they don’t know:

“I don’t know yet, but I’ll look into it.”
“Let’s explore this together.”
“I know someone who might have the answer.”

What began as a light weekend read ended up strongly reinforcing something I deeply believe: honesty builds trust.

Admitting you don’t know something isn’t a flaw — it’s part of being reliable, especially in senior roles.

I’d love to hear what you think about this. Drop a comment on the related LinkedIn post or reach out directly.