DEV Community: Harshavardhan Katkam

The Senior Developer Mindset: How to Turn Abstract Ideas Into Production Code

Harshavardhan Katkam — Thu, 04 Jun 2026 08:04:16 +0000

The single skill in my career that has compounded the most isn't a language, a framework, or a system design pattern. It's the ability to take a vague, half-formed idea — a feature request from a PM, a "we should make this resilient" from an architect, a new project ask from an account, a half-formed integration plan that crosses three teams — and turn it into something shipped, working, and useful.

This is the skill nobody teaches in a course. It's also one of the most rewarding to develop, because it's what allows you to grow into the engineer your team can hand ambiguous problems to with confidence. Here's the mindset, the framework, and the lessons that helped me grow toward it.

The Skill That Doesn't Have a Name

Every engineer learns to write code. Most learn to debug, design, and ship. Few practice the skill that comes before all of that — the skill of taking ambiguity and giving it shape.

You've felt this if you've ever been on the receiving end of:

"We need the dashboard to feel faster."
"We should split this service — it's getting unwieldy."
"Can we deliver a POC for the client conversation by Friday?"
"Let's partner with team X to ship this end-to-end."
"Can we set up a new module for this account?"
"The system should be more robust."
"There has to be a better way to do this."

Some of these are features. Some are architectural decisions. Some are new projects within an account. Some are cross-team integrations. None of them is a specification. The gap between any of them and a working outcome is where most real engineering effort goes — and the gap is the same shape whether the work is one PR or six months across three teams.

What follows is the framework I've built from doing this work. I'm sharing it in case it saves you a few of the wrong turns I took.

Where Abstract Ideas Come From

Not all abstract ideas are equal. Each source has its own failure mode and its own opportunity.

Source 1 — Product / Business. PMs, BAs, and clients describe outcomes ("users should be able to..."). They rarely describe systems.

Trap: building exactly what they asked for, only to discover what they meant was different. Opportunity: catching the misalignment before any work begins.

Source 2 — Technical Leadership. Architects and tech leads describe direction ("we should make this more resilient," "we need to migrate off X"). Vision, but rarely a roadmap.

Trap: treating the suggestion as either a command (over-investing) or a passing thought (ignoring it). Opportunity: turning the suggestion into a concrete proposal that leadership can green-light or refine.

Source 3 — Your Own Observations. The bug keeps coming back. The deployment keeps breaking. The on-call rotation keeps paging at 2 AM.

Trap: complaining without doing, or doing something massive without communicating. Opportunity: building the smallest fix or proof-of-concept that demonstrates value, then asking forgiveness rather than permission.

Source 4 — Improvisations That Become POCs. Some of the best work I've shipped started as a quick script, an internal tool, an idea jotted during a meeting.

Trap: treating it as throwaway and never investing in making it solid. Opportunity: recognizing when an improvisation is actually a POC for something bigger.

The framework that follows works for any of these — feature, architectural, project-level, or cross-team.

Before the Framework: Understand the Terrain

Before you can translate an abstract idea into anything real, you need to understand the system the work will live inside. Whether the "system" is a codebase, an architecture, an account, or a set of stakeholders — the principle is the same.

It's tempting to jump from "great idea" to "let's start" without pausing to ask: what's already here, why is it set up this way, and what will my work actually touch? I've fallen into this many times, and the result is fairly predictable. A clean new piece of code that conflicts with an existing pattern. An architectural change that breaks a downstream system nobody mentioned. A new project that quietly steps on another team's roadmap.

Slow down at the start. Before any meaningful translation work, ask:

What does the existing system look like? Read the code. Trace the data flow. Read the contracts between services. Talk to the teams adjacent to your work.
Why was it built this way? Git history, old PRs, design docs, informal Slack threads. The current state reflects past decisions you don't see in the present.
What's the messy part nobody wants to touch? Every system has zones of accumulated complexity. Knowing where they are tells you where the risks live.
Who knows this best? Find that person. Ten minutes with them saves a week of trial and error.

This stage is unglamorous. It can feel like you're not making progress. But the time you invest in understanding the terrain compounds — every later decision becomes faster and less risky.

Sometimes You Have to Take Ownership of the Mess

Sometimes the existing structure isn't just unfamiliar — it's tangled, undocumented, and getting in the way. Code paths nobody fully understands. Configuration buried across services. A "we'll clean it up later" that's been there for two years.

It's tempting to route around it. The more rewarding move is often to engage with it. That can look like:

Documenting what you've understood, even if no one asked you to
Refactoring the parts you've had to touch, leaving them better than you found them
Naming the problem out loud — in a writeup, a Slack thread, a one-on-one — so it's visible instead of invisible
Proposing a small, low-risk cleanup as a side-quest to the main work

Not every mess needs cleaning, and not every cleanup is yours to drive. But occasionally picking up the mop, when the cost is fair and the impact is real, tends to be one of the most rewarding kinds of work — and quietly earns trust over time.

The Framework: Five Stages

Translation work has five stages. They're not always linear — sometimes you loop back — but they're always present. The discipline is not skipping any of them.

Stage 1: Capture

Write down the idea verbatim. Not your interpretation. The exact words.

If a PM said it, copy from Slack. If an architect said it, summarize back and confirm. If it's your own observation, note the symptom that triggered it. Your brain immediately starts interpreting — capturing the original wording gives you something to come back to when you realize three days in that you've drifted.

Every translation effort starts with one written line that nobody can later argue about. That line is your anchor.

Stage 2: Clarify

Find the real problem, not the stated one.

The stated request is rarely the real problem. "The dashboard should feel faster" might mean: data takes too long, layout shifts on render, no loading indicator, comparison to a competitor, slow connection. Five interpretations, five different solutions ranging from one day to one quarter.

The habit worth building: ask "what does success look like?" and don't start work until you can describe success in measurable terms. Five questions I always ask:

Who experiences this? (Specific persona, not "the user")
What are they trying to accomplish?
How will we know it's better? (Measurable, even approximately)
What's the cost of not doing this? (If "nothing concrete," the priority is probably wrong)
What would the absolute simplest version look like?

If I can't answer these five, I don't write code, draw architecture, or kick off a project. I go back to whoever raised the idea and have a conversation. This is rarely glamorous and often slightly awkward. It's also the single most valuable habit I've built.

Break It Down to Layman Terms — The Feynman Move

A habit I've made non-negotiable: before I start anything, I make sure I can explain the problem in the simplest possible language, with an analogy a non-engineer could follow.

This is the Feynman technique applied to engineering. If you can't explain something simply, you don't really understand it.

In practice, my first move on any meaningful task is to ask either a peer or an AI tool: "Explain this to me like I'm new to the system. Use an analogy if it helps."

If the ask is "improve the consistency of our distributed cache," a layman framing might be: "Imagine three people each have a copy of a shared notebook. When one writes something, how do the others find out, and how fast?" That sentence — minus the engineering vocabulary — anchors my thinking for everything that follows.

I sometimes write the layman version at the top of a doc before any technical detail. It serves as a north star — every time the work feels tangled, I come back to that one sentence and check whether I'm still solving the problem I started with.

The senior engineers I admire most can describe extremely complex problems in remarkably simple terms. That's not a coincidence. It's a habit, built deliberately.

Stage 3: Constrain

Decide what not to build.

This is the stage that's easiest to skip — and the one I've come to value most. Once you're convinced something is worth doing, the next question is: given my time, my team's bandwidth, and the actual cost of getting this wrong — what's the smallest meaningful version?

Constraints to think about:

Time: A week, a quarter, a spare hour?
Scope: What's in, what's out, what's a "later"?
Risk: What could go wrong, and what's the worst case?
Reversibility: One-way door (hard to undo) or two-way door (easy to undo)?
Audience: Who uses it, who maintains it, who approves it?

A useful tool: the 3-day version. Force yourself to design what you'd ship if you had three days, no more. Even if you eventually have three weeks, the 3-day version teaches you what's truly load-bearing and what's optional. Often, the 3-day version is what should ship first anyway.

This stage prevents most "scope creep" — not by saying "no" to features after they're requested, but by deciding upfront, in writing, what's not going to be built.

A Lesson I Wish I'd Learned Earlier: Timebox, or Start Fresh

For a long time, I had a habit I didn't recognize. When faced with an ambiguous problem, I'd dive into analysis. Open documentation, sketch designs, weigh trade-offs, talk to people, draw more diagrams. Hours would pass. The work felt productive — I was thinking deeply, after all.

A tech lead I worked with eventually pointed it out: I was in analysis paralysis. I was so focused on getting the design right before starting that I was burning hours on decisions that would have taken five minutes to validate with a quick prototype.

The advice he gave me changed how I work: timebox the analysis, and if you're not converging, start fresh.

Practically:

Give yourself a fixed amount of time to clarify and constrain — usually no more than half a day for typical work
If you're still spinning at the end of that window, stop
Either commit to the best option you have and start building, or reset entirely with a blank page and 30 minutes — often the second pass is faster and clearer than the first

Starting fresh feels like wasted work, but it's almost always faster than continuing to refine a tangled first pass. Your second attempt benefits from everything you learned in the first one, but isn't burdened by the dead-ends you got stuck on.

Stage 4: Construct

Build the thing.

By this point, you usually know what you're building, why, and what you're not building. The actual construction is faster because the ambiguity has been resolved upfront. This is often the stage we think is the job — but it's actually the stage where the upstream work pays off.

A few principles I've internalized:

Decompose into demoable units. If you can't show progress in 2–3 day increments, the unit is too big.
Sketch before building. A diagram, a flowchart, a written API contract — anything that lets you reason about the design before code, architecture, or commitments lock you in. Five minutes of sketching saves five hours of rework.
Use AI as a force multiplier, not a replacement. AI tools accelerate boilerplate, surface edge cases, draft tests, review for blind spots. They do not make the design decisions or skip the clarify stage. The judgment is yours.
Lean on your peers. Quick gut-check messages — "does this approach make sense?" — to a senior peer or architect cost five minutes of their time and can save you days. The habit worth building is asking early and specifically.

Stage 5: Confirm

Close the loop with whoever raised the idea.

Once it's working — even partially — show it back. Not a deck. Not a status update. The actual thing.

This stage catches the misalignments that survived all earlier stages. You'll find that what you built is 95% right and 5% wrong, and the 5% only became visible when they saw it. Better to find it now than after the next sprint.

Sometimes this stage reveals that the original idea was wrong, and what they actually needed was different. That's the whole point of staging it iteratively. The faster you close the loop, the less wasted work.

What Makes the Framework Actually Work

Three force multipliers worth investing in:

1. Dedicated, focused time. Translation work cannot happen in 15-minute slots between meetings. The clarify and constrain stages especially require uninterrupted thinking. I block calendar time explicitly — not for "writing code," but for "translating idea X into a plan." When I started doing this deliberately, my output quality changed more than from any tool or technology I adopted.

2. AI as a thinking partner. AI tools, used well, accelerate the framework. I lean on them for: generating "what could go wrong" lists (Stage 2), asking "what's the simplest version?" (Stage 3), boilerplate and test scaffolding (Stage 4), drafting demos and writeups (Stage 5). I do not lean on them for the judgment calls — whether to build, whether the simpler version is enough, whether the design will hold up. The AI removes friction around your thinking. It doesn't replace it.

3. Mentorship — both ways. Earlier in my career, having a senior to validate or redirect my translation work saved me from countless wrong turns. Now, increasingly, I'm the one being asked. Both directions of this exchange compound the skill. Senior engineers don't translate ambiguity better because they're smarter — they've just seen the same shapes of ambiguity hundreds of times. Mentorship is compressed exposure.

Improvisations Compound

Some of the highest-leverage work I've shipped started as something improvised — a small script, an internal tool, an idea jotted in a meeting. The pattern looks like this:

You notice a recurring annoyance — manual process, flaky test, something that keeps breaking
You spend an hour or two building a quick fix
The fix works for your case
A teammate asks if it could work for theirs
You generalize it — another half-day
By the end of the month, three people are using it
By the end of the quarter, it's the recommended approach

None of this was on a roadmap. None of it was in a sprint plan. But it shipped because you noticed something, took it seriously, and applied the same translation framework you'd apply to any ask.

This is, in my experience, where engineers create the most outsized value — not in the work that's handed to them, but in the work they spot and pursue. The framework still applies, just with you as both originator and implementer. The discipline keeps you from two equally common pitfalls: ignoring your ideas entirely, or over-investing in them without validation.

Three Failure Modes I Watch in Myself

1. Skipping clarify because the request "seems clear." It rarely is. The clearer it seems, the more likely you've assumed something the asker didn't say.

2. Building first, asking later. A common reflex, and one I've fallen into many times. Once you've built, you're emotionally invested in the solution, and it gets harder to walk away from it even when it's the wrong shape.

3. Using AI to skip thinking. AI can generate output that looks right but isn't the right thing. The framework — clarify, constrain, confirm — is exactly what AI tools cannot do for you. Don't outsource it.

What This Skill Grows You Into

If I had to point at the single thing this framework has unlocked, it's the chance to grow into what some teams call a feature anchor.

A feature anchor is the engineer the team can trust to take an ambiguous problem — feature, architectural change, new project, cross-team integration — and bring it to a working outcome. Not because they're the best coder. Not because they know the most. Because they're willing to ask the right questions, decide what to build and what to skip, work through the messy middle, and demo something useful at the end.

That role is rarely assigned. It tends to grow on you quietly, as you keep running through this kind of process on enough problems that people start handing you the ambiguous work because they know it'll get done. It's one of the more rewarding milestones in an engineering career, because it's the moment the judgment part of the job — not just the code — starts to compound.

If becoming the engineer your team turns to when something fuzzy lands on the table sounds appealing — this skill, more than any specific technology, is the path.

Closing Thoughts

The framework is simple. The discipline of running it every time is what's hard.

So much of growing as an engineer is not about the code. It's about everything that happens before and after the code. The clarify conversation that prevents weeks of rework. The patience to understand the existing system before changing it. The discipline of restating the problem in layman terms. The constraint exercise that ships something useful in days instead of months. The improvisation that becomes a team-wide tool. The willingness to demo half-built work and absorb feedback. The wisdom to timebox analysis and restart fresh. The willingness to take ownership of the messy parts when the team needs someone to.

None of this is glamorous. None of it makes for a flashy pull request. But over time, it's the work that compounds the most.

If you're earlier in your career and this resonates — try one stage of the framework deliberately this week. Pick one ambiguous ask, run it through clarify and constrain explicitly, and notice what changes.

If you're further along — I'd love to hear what's missing or what you'd phrase differently. Every engineer I've learned from has a slightly different version of this, and I'm always curious to hear theirs.

If this helped, a clap goes a long way. And if you've shipped something that started as an improvisation, I'd love to hear that story.

All views in this post are my own. The framework is drawn from my own learning and not from any specific employer, project, or codebase. Examples are illustrative.

RestTemplate vs RestClient vs WebClient

Harshavardhan Katkam — Fri, 24 Apr 2026 08:41:33 +0000

The HTTP Client Showdown Every Spring Developer Needs to Understand

If you've been writing Spring applications for a while, you've probably had this conversation: "Should I use RestTemplate? Someone said it's deprecated. What about WebClient? And wait, what on earth is RestClient?"

Let's settle this once and for all.

The Short Version (For the Impatient)

Client	Introduced	Style	Status in 2026
RestTemplate	Spring 3.0 (2009)	Blocking, imperative	In maintenance mode — not deprecated, but not evolving
WebClient	Spring 5.0 (2017)	Non-blocking, reactive	Actively maintained, still the async champion
RestClient	Spring 6.1 (2023)	Blocking, fluent	The new recommended default for synchronous code

If you're starting a new project today and your code is synchronous — use RestClient. If you're doing reactive or truly async I/O — use WebClient. If you have an existing RestTemplate codebase — you don't have to migrate tomorrow, but plan for it.

Now let's dig into why.

A Quick History Lesson (Because Context Matters)

To understand these three clients, you need to understand the problems each was born to solve.

2009 — RestTemplate arrives. Back then, calling REST APIs in Java was painful. You were stitching together HttpURLConnection, Apache HttpClient, and custom serializers. RestTemplate wrapped all that ceremony behind a clean, synchronous API. It was revolutionary — and for a decade, it was the way.

2017 — WebClient arrives. The reactive revolution (RxJava, Project Reactor) changed how we think about I/O. Microservices meant one request often fanned out into ten. Blocking threads became expensive. Spring introduced WebFlux and, with it, WebClient — a non-blocking HTTP client built on Reactor's Mono and Flux.

The problem? WebClient became the only modern choice. If you wanted modern features (builder pattern, better error handling, interceptors that don't fight you), you had to adopt reactive types — even if your app had zero reactive code. Teams were writing .block() everywhere and pretending they weren't.

2023 — RestClient arrives. The Spring team finally admitted the obvious: most applications are synchronous, and they deserve a modern, fluent, blocking API that doesn't force reactive types down their throat. RestClient is what RestTemplate would look like if we designed it today.

RestTemplate: The Veteran

@Service
public class UserService {
    private final RestTemplate restTemplate;

    public UserService(RestTemplateBuilder builder) {
        this.restTemplate = builder
            .rootUri("https://api.example.com")
            .build();
    }

    public User getUser(Long id) {
        return restTemplate.getForObject("/users/{id}", User.class, id);
    }

    public User createUser(User user) {
        return restTemplate.postForObject("/users", user, User.class);
    }
}

What's good:

Everyone knows it. Zero learning curve.
Massive ecosystem, battle-tested, boring in the best way.
Works synchronously — matches how most business logic thinks.

What hurts:

The API is overloaded beyond recognition. Look at the Javadoc — exchange, execute, getForObject, getForEntity, postForObject, postForEntity, postForLocation... twenty ways to do one thing.
No fluent builder. Headers, query params, and body-building are awkward.
Error handling defaults are surprising. A 4xx throws; a 2xx with no body returns null.
Not evolving. New features go to RestClient and WebClient.

Official status: Not deprecated. This is important. The Spring team has explicitly said RestTemplate will not be removed. But it's in maintenance mode — no new features, just bug fixes.

WebClient: The Reactive Powerhouse

@Service
public class UserService {
    private final WebClient webClient;

    public UserService(WebClient.Builder builder) {
        this.webClient = builder
            .baseUrl("https://api.example.com")
            .build();
    }

    public Mono<User> getUser(Long id) {
        return webClient.get()
            .uri("/users/{id}", id)
            .retrieve()
            .bodyToMono(User.class);
    }

    public Flux<User> getAllUsers() {
        return webClient.get()
            .uri("/users")
            .retrieve()
            .bodyToFlux(User.class);
    }
}

What's good:

Truly non-blocking. Perfect for high-concurrency fan-out (a single Netty event-loop thread can handle thousands of in-flight requests).
Fluent, modern, discoverable API.
First-class streaming support — Flux<User> lets you process a 10GB response without loading it into memory.
Backpressure. If you're consuming a fast producer from a slow consumer, WebClient handles it natively.

What hurts:

You're now in Reactor-land. Mono, Flux, flatMap, zip, onErrorResume — there's a real learning curve.
Stack traces are ugly. Debugging reactive code is genuinely harder.
If you .block() everything, you get WebClient's complexity with RestTemplate's performance characteristics — the worst of both worlds.
Needs spring-webflux on the classpath even in a servlet app.

When it shines: WebFlux apps, streaming responses, SSE/WebSockets, fan-out aggregation where latency matters, any place you're genuinely doing async I/O.

RestClient: The Goldilocks Client

@Service
public class UserService {
    private final RestClient restClient;

    public UserService(RestClient.Builder builder) {
        this.restClient = builder
            .baseUrl("https://api.example.com")
            .build();
    }

    public User getUser(Long id) {
        return restClient.get()
            .uri("/users/{id}", id)
            .retrieve()
            .body(User.class);
    }

    public User createUser(User user) {
        return restClient.post()
            .uri("/users")
            .contentType(MediaType.APPLICATION_JSON)
            .body(user)
            .retrieve()
            .body(User.class);
    }

    public User getUserWithCustomErrorHandling(Long id) {
        return restClient.get()
            .uri("/users/{id}", id)
            .retrieve()
            .onStatus(HttpStatusCode::is4xxClientError, (req, res) -> {
                throw new UserNotFoundException(id);
            })
            .body(User.class);
    }
}

Look at that code. Notice something? It reads exactly like WebClient — but there's not a Mono or Flux in sight. It's synchronous. It blocks. It returns the value directly.

What's good:

Same fluent API as WebClient, zero reactive types.
Modern error handling with .onStatus().
Can use any underlying HTTP client — JDK's HttpClient, Apache, Jetty, Reactor Netty.
Integrates cleanly with Spring's @HttpExchange declarative clients (think Feign, but built in).
Familiar mental model for anyone coming from RestTemplate or WebClient.

What hurts:

Newer. Smaller community base of examples and Stack Overflow answers (though that's changing fast).
Not reactive. If you need non-blocking, it's the wrong tool.

Pro tip: You can build a RestClient from an existing RestTemplate — a huge win for gradual migration:

RestClient restClient = RestClient.create(existingRestTemplate);

All your existing interceptors, message converters, and error handlers come along for the ride.

The Deep Comparison

1. Syntax and Ergonomics

RestClient and WebClient share near-identical fluent APIs. RestTemplate is the outlier with its overloaded method zoo.

2. Threading Model

RestTemplate — one thread per request, blocked until response arrives.
RestClient — same model (blocking), but the underlying transport is pluggable.
WebClient — event-loop based, one thread handles many in-flight requests.

For a typical CRUD service handling a few hundred req/sec on a well-sized thread pool, the difference is invisible. For a gateway aggregating 50 downstream calls per request at 10K RPS, WebClient wins by orders of magnitude.

3. Error Handling

RestTemplate throws HttpClientErrorException / HttpServerErrorException by default. You override a ResponseErrorHandler globally to change it. Not fine-grained.

RestClient and WebClient offer per-request .onStatus() handling — you decide what a 404 means in the context of this specific call. Huge ergonomic win.

4. Testing

RestTemplate — MockRestServiceServer is mature and easy.
WebClient — needs either ExchangeFunction mocking or an MockWebServer setup.
RestClient — works with MockRestServiceServer (shares the infrastructure). Big win for teams migrating.

5. Declarative Clients (the underrated feature)

Both RestClient and WebClient support Spring's @HttpExchange:

@HttpExchange(url = "/users")
public interface UserApi {
    @GetExchange("/{id}")
    User getUser(@PathVariable Long id);

    @PostExchange
    User createUser(@RequestBody User user);
}

Wire it up once and you have a type-safe client — no implementation code to write. This is effectively what Feign gave us, now built into Spring. RestTemplate doesn't support this.

The Decision Framework

Ask yourself three questions, in order:

1. Is your codebase reactive (WebFlux, R2DBC, Kafka reactive)?
→ Use WebClient. Don't fight the paradigm.

2. Do you need genuine non-blocking I/O for performance (high fan-out, streaming, SSE)?
→ Use WebClient. The complexity pays for itself.

3. Everything else?
→ Use RestClient. It's the modern synchronous default.

And for legacy code on RestTemplate — there's no emergency. Plan a gradual migration as you touch code. RestClient.create(restTemplate) makes incremental migration almost free.

A Word on Performance

I'll save you the benchmark drama: for synchronous workloads, RestTemplate and RestClient are effectively identical. They share transport layers. The real performance story is WebClient vs. everything else in high-concurrency async scenarios — and even there, it only matters if you're actually constrained on threads.

Don't pick WebClient for "performance" if your app does 50 RPS. You'll pay the complexity tax for benefits you'll never measure.

Common Mistakes I See on Code Reviews

Using WebClient with .block() everywhere. You're burning all of WebClient's benefits and eating its complexity. Switch to RestClient.
Creating a new RestTemplate/RestClient per request. These are designed to be singletons. Inject the builder, build once, reuse.
Ignoring timeouts. Default timeouts are "forever." Always set connect and read timeouts — production will thank you.
Catching RestClientException broadly. Use .onStatus() for semantic error handling. Catch specific exceptions at the boundary.
Not using @HttpExchange. If you're writing repetitive CRUD wrappers, you're writing code that Spring will generate for you.

Closing Thoughts

Spring's HTTP client story went from "just use RestTemplate" to "use WebClient and suffer" to — finally — a clean, ergonomic split based on what your code actually needs. RestClient in particular is one of the best Spring improvements of the last five years. It quietly fixes the biggest complaint developers had without breaking anyone's existing code.

If I had to sum it up in one sentence: use RestClient by default, reach for WebClient when you're genuinely reactive, and migrate off RestTemplate at your own pace.

That's it. No dogma, no hype. Pick the tool that matches your workload.

If this helped, a clap goes a long way. And if you disagree — especially on the "don't migrate tomorrow" take for RestTemplate — I'd love to hear your war stories in the comments.