DEV Community: Shinya Saita

If you can't answer "Where do you see yourself in 5 years?" — you're not broken"

Shinya Saita — Tue, 18 Aug 2026 16:23:51 +0000

TL;DR

If you freeze when asked "Where do you see yourself in five years?", it doesn't mean something is missing in you.

I believe there are three types of people who climb mountains:

People who climb because staying below is dangerous

People who climb because there's something they want at the summit

People who climb because they love climbing itself

All three are valid. There's no ranking — they just place value in different spots.

Simply knowing this fact can lift two burdens at once: the anxiety of not having a five-year plan, and the urge to "fix" a teammate who doesn't seem to have one.

I used to dread career development talks

"Where do you see yourself in five years?"

Whether it comes up in a performance review, a 1:1 with your manager, or a job interview, you know this question. Have you ever just... blanked on it?

I have. Many times.

My coworkers seemed to answer effortlessly: "I want to be a tech lead," "I'm aiming for engineering management." Meanwhile I'd search my brain and find no clear picture of a "future me" — or worse, find five blurry pictures and no way to pick one.

And here's the frustrating part: I love this job. Precisely because I love being an engineer, not being able to answer made me spiral:

Do I lack ambition?
Am I just not serious about my career?
Is something wrong with me?

Let me give you the conclusion up front: you're fine. Nothing is missing. You and the person asking simply belong to different types.

This article is for two kinds of readers: engineers who carry the same quiet anxiety I did, and the seniors and managers looking at a report and thinking "I need to fix that person."

The story of Ging, from Hunter × Hunter

Bear with me — I need to talk about a manga for a minute.

Hunter × Hunter by Yoshihiro Togashi is one of the most beloved manga in Japan, serialized in Weekly Shōnen Jump (the magazine that gave the world Dragon Ball, Naruto, and One Piece). If you haven't read it, the English edition is published by Viz Media, and the anime is streaming pretty much everywhere. Mild spoilers ahead for volume 32.

In that volume there's a scene I've reread more times than I can count. At the top of the World Tree — a tree so tall its crown pierces the clouds — the protagonist Gon finally sits down and talks with Ging, the father he has been chasing for the entire series.

Gon asks him: "What do you want, Ging?" And Ging answers by telling the story of why he became a Hunter.

Long ago, Ging desperately wanted to enter the royal tomb of a certain dynasty. But it wasn't a place you could just walk into — only a trusted organization would ever be granted access. So at fifteen, Ging founded a nonprofit and spent two years surveying and restoring the site. Friends he'd met online supported the project for free.

And when he finally set foot inside the tomb he'd dreamed about, Ging realized something. The happiest moment wasn't laying eyes on the tomb's long-hidden "truth" —

"It was when we looked at each other and shook hands, the friends who'd wished for this together."

The thing more important than what he wanted had arrived before he got what he wanted. The truth inside the tomb, he says, was just a bonus. And then Ging gives Gon the line that fans still quote today:

"You should enjoy the little detours. To the fullest.
Because that's where you'll find the things more important than what you want."

Source: Yoshihiro Togashi, Hunter × Hunter Vol. 32, ch. 339 "Silence" (Shueisha; English edition by Viz Media).

When I first read this, it hit me hard — because it put into words something I had vaguely felt my whole life.

A side note

I realized later that this scene is a beautifully constructed nesting doll. Gon himself has spent the entire series climbing toward one summit — "meet my father" — and what he actually gathered along the way (Killua and his other friends, his mentor Bisky) became his real treasure. And the conversation itself takes place, literally, at the top of the World Tree. Gon reaches the summit, and what he finds there is neither glory nor treasure — it's a lovely, rambling chat with his dad.

Come on. That's just perfect.

My own detours

Two examples of why this resonated so much.

1. How I travel

When I travel, I pick the main destination — and deliberately plan almost nothing else. Not where to stop along the way, not where to eat.

Why? Because every trip, without fail, the road throws something interesting at me: a place I didn't know I wanted to see, a conversation I didn't know I wanted to have. I leave blank space in the itinerary precisely so I can grab those. As a wonderful side effect, wandering together has deepened my relationship with my family more than any landmark ever did.

Honestly, the time we spend later saying "that trip was so good, remember?" might be the part I love most.

In my travels, the destination ends up being the bonus. Exactly like Ging.

2. How I became an engineer

The second example is this job. I originally became an engineer chasing a dream: "I'll become a great engineer who builds great systems." I wanted to be, let's say, a 10x engineer.

But once I was actually in the field, what became precious was something else entirely:

The sheer fun of programming itself
The joy of watching real people use software I built

Not the systems as such — the countless things that happened on the way to building them. Those became my treasure.

These days, what I love most about this profession is that product development lets you genuinely help someone, somewhere in the world. Of course, the goals my job asks of me are far more concrete than that. But the fuel that actually moves me? It's this.

The main point: three types of people climb mountains

OK, here's what I actually want to propose. I believe people who climb mountains come in three types.

Type 1 climbs because staying below is dangerous. The sea level is rising; stay put and you drown. So you climb. Survival-driven.

Type 2 climbs because the summit holds something they want. A legendary sword at the peak. A record to set. The value lives at the top, and the path is simply the cost of getting there.

Type 3 climbs because they love climbing. Of course they aim for the summit — that's what climbing a mountain means. But the main dish is the path itself. Ging is this type. So am I.

Translated into engineering:

Type 1: "If I stop learning, my market value drops and I can't pay rent." So they study.
Type 2: "I want to be a CTO. I want the salary. I want to be a committer on that project." So they push.
Type 3: "Writing code is fun, and the things that happen while building are the best part." The summit just happens to be up ahead.

Same mountain — "learning technology" — but where each person places the value is completely different.

This is not a ranking

Let me be very clear, because I don't want to be misread: I am not here to evangelize "enjoy the journey."

Type 1's strength is reliability. Necessity is arguably the strongest fuel there is, and someone studying hard to feed their family deserves nothing but respect.

Type 2's strength is clarity. A clear summit lets you plan the shortest route backwards from it — and the people who leave dents in the world or set great records are, more often than not, this type. Answering "where will you be in five years?" without blinking is a genuine skill this type has.

And Type 3: they'll wander off the optimal route without a second thought, and from the outside it can look like "does this person even want to get to the top?" But the things they pick up on their detours have a way of compounding into assets later — that's their particular magic.

All three are correct ways to climb. The only fact here is that the value sits in a different place for each.

What happens when nobody knows this fact

The problem was never the ranking. The problem is not knowing the difference exists.

A Type 3 engineer faces a question designed for Type 2 people — "Where do you see yourself in five years?" is exactly that — fails to answer it, and concludes they're defective. That was me at the start of this article.

Meanwhile, a Type 2 senior looks at a Type 3 junior and sees "someone with no ambition who needs to be fixed." And the reverse happens too: a Type 3 senior tells a Type 2 junior "you should enjoy the process more!" and receives a blank stare. Both are acts of goodwill. Both are also impositions.

So, to those carrying the anxiety I used to carry: you are not weird, and you are not broken. There's nothing to feel down about. You've simply been grading yourself against a different type's scorecard. Freezing at that interview question isn't a lack of career awareness — it's that your values live somewhere the question doesn't look.

And to the seniors and managers thinking "my report has no goals, I have to change them": you probably don't. That person isn't refusing to climb. They're climbing the same mountain with their value placed somewhere different from yours. Try watching them once through the lens of "which type is this person?" — and things that looked like flaws may resolve into nothing more than a difference in type.

One caveat. If your company or organization implicitly endorses a single type, people of the other types will slowly start to feel like they don't belong. If that's you, it's worth genuinely considering your options: keep up the dialogue, try a different team — or make the jump to somewhere that fits.

Closing

Ging's "enjoy the detours" is, to me, an all-time great line. But if I recommend it to you as-is, I'm just committing the Type 3 version of the same imposition. So let me rephrase it as a question instead:

Why do you climb the mountain?

Whatever your answer is, own it with confidence. Just remember that the person climbing next to you may answer differently — and knowing that single fact can change how reviews, teams, and your own career anxiety look.

I wrote this for the past me who needed to hear it. If it reaches someone else carrying the same weight, even better.

So — which type are you? I'd love to hear in the comments.

How to answer "Why did you pick this language?" so people actually nod

Shinya Saita — Mon, 10 Aug 2026 16:17:55 +0000

You've been in this meeting, right?

Every new project starts with the same ritual: picking the stack. Requirements and architecture get all the attention, but "what do we build this with?" matters just as much.

So your team debates it properly. You weigh the options, land on a choice, and everyone agrees: "Yeah, this is the right fit for us." Then you present it in a review meeting, and someone — a manager, a stakeholder, an architect from another team — asks:

"Why did you choose this language?"
"Would another language not have worked?"

If reading that made your stomach drop a little, keep scrolling. 😅

Here's the thing I wish someone had told me earlier: this question is not an attack, and it's not someone doubting your skills. What the asker actually wants to know is much simpler:

"Is this decision sound from a business perspective?"

Let me put one disclaimer up front:

There is no absolute ranking of programming languages.

This is not a "language X is better than language Y" post. But every language that survives has reasons it keeps getting chosen — and whether you can articulate those reasons out loud is the entire game.

I've been asked this question many times across my career. For years I answered with technical merits, and every time I got the same politely unconvinced face. Eventually it clicked: what's really being tested isn't "is it the most modern?" or "is it the fastest?" It's:

"Can you explain this choice to a third party, in business terms?"

That's what this post is about. By the end, I hope you'll feel ready to walk into your next review and defend your stack with confidence.

What decision-makers are actually evaluating

When engineers talk tech selection, we gravitate toward performance, modernity, and trends. Those matter. But the people approving your proposal are usually worried about something far more mundane — and far more long-term:

Can we hire and hand over this codebase years from now?
Can we maintain it without heroics in year three?
Will it survive spec changes and reorgs?
Does the cost actually pay off?
Does the project depend on one irreplaceable person?

Looking back at projects I've been on, these are exactly the things nobody worried about at kickoff — and everything that quietly hurt later.

A language with a steep learning curve slows down every onboarding. A team of three can absorb that; a team of fifteen can't. And a niche technology means one resignation can destabilize an entire project.

Which leads me to the definition I now use:

Tech selection isn't picking the best option for this moment. It's making a choice you could re-explain to your future self in three years — and still nod at.

"This language is trending and I want to try it" is a fine reason to start a side project. It's a terrible reason to bet a product on.

Languages that keep getting chosen have reasons

Across the languages that survive decades in production, the same traits show up:

Easy to learn — new members become productive fast
Easy to build with — you spend time on the actual problem
Easy to operate — the thing stays maintainable after launch

(Plus domain-specific strengths: easy to build securely, easy to squeeze hardware performance, and so on.)

In an industry this trend-driven, anything still standing after 20 years is not standing out of inertia.

I spent the longest stretch of my career in PHP shops, so here's an example from that world: WordPress and MediaWiki (the software behind Wikipedia) are PHP. What they share isn't elegance — it's that they've been continuously maintained for decades. A language's longevity directly becomes the longevity of the products built on it.

And this isn't a PHP thing. Python's machine-learning ecosystem, TypeScript's grip on frontend, Go's dominance in cloud-native infrastructure — each has clear, articulable reasons it keeps being chosen.

What matters is whether you can explain, in your own words, why your language keeps being chosen.

The 4 lenses of defensible tech selection

Here are four lenses that work regardless of language. If you can answer "why this language?" along these four axes, you'll convince most rooms.

Lens 1: Talent depth — can you avoid a bus factor of one?

The most overlooked question in tech selection: how many people in the market can write this?

A language with a large developer population gives you options — for hiring, for mid-project reinforcements, for handovers. Choose something niche and you've signed up for "if this person leaves, we're stuck."

For example:

Python — huge population across data science and web; lots of career-changers learning it, so the hiring funnel is wide
TypeScript — effectively the lingua franca of frontend; JavaScript developers convert easily
Go — growing fast among infra-leaning engineers, though the pool for business-app web development is still thin in some markets

Choose with "can the team keep shipping?" in mind, not "do I love this language?". It's unglamorous, and it's the foundation everything else stands on.

Lens 2: Fit for purpose — is this the shortest path?

Every language has home turf. Yes, most modern languages can technically do anything — but whether they get you to your goal by the shortest path has a huge impact on productivity.

"I just want to write business logic, but my week is disappearing into environment setup and plumbing..."

Sound familiar?

Building a web application? Pick a language whose ecosystem naturally speaks HTTP, sessions, and templating
Data processing / analytics? Very little competes with Python's ecosystem (pandas, NumPy, ...)
High-throughput API servers? Go's concurrency model earns its keep
One type-safe language across frontend and backend? That's the realistic case for TypeScript

If you can say "this language is specialized for — or at least strongly aligned with — what we're building", your proposal gets dramatically more persuasive.

Lens 3: Ecosystem maturity — will you reinvent wheels?

Modern development runs on frameworks and libraries. Auth, validation, email, background jobs — whether these come ready out of the box directly determines your velocity.

Python — Django, FastAPI. Django's "batteries included" philosophy ships an admin UI, ORM, and more from day one
TypeScript — Next.js, NestJS. The full-stack-in-one-language ecosystem has genuinely matured
Go — an excellent standard library; you can go far without a framework, but business-app "we also need this and this and this" features often end up hand-rolled

And here's the part people miss: ecosystem maturity isn't just about building fast.

It's about surviving change.

With a mature framework, a spec change means a small adjustment, not a rewrite. That's what lets a team keep moving without flinching.

Lens 4: Cost and operations — can you keep this running?

The final piece is total cost — not just infrastructure, but operations, incident response, and salaries. Think ROI, not hosting bill.

Does it need a special runtime or environment?
Does it run on a simple infrastructure setup?
Can you start small and scale later?

Being able to say "we can start cheap, and it holds up if we grow" carries enormous weight with business decision-makers. It's not flashy — but for anything meant to run for years, "sustainable without heroics" is priceless.

The inevitable question: "But is it fast enough?"

Whenever languages get compared, this one shows up. And yes — some languages extract more from the CPU than others.

But look at where most web applications actually spend their time:

Database access
External API calls
Network latency

The raw execution-speed gap between languages is the bottleneck far less often than people assume.

Of course, if you're building real-time systems or handling massive concurrent connections, the calculus changes. But for most business systems and web services, architecture and query optimization move the needle far more than language benchmarks ever will.

The mature answer isn't "this language is fast" — it's: "For these requirements, is language performance actually going to be the bottleneck?" Usually, it isn't.

When you're asked to compare — compare like this

"How does it stack up against language X?" is unavoidable. The goal is not to win a technology debate. It's to explain the lowest-risk business choice.

Here's my rough mental cheat sheet for commonly compared languages:

Language	Strength	Watch out for
Python	Low learning curve, unmatched in AI/data	Large-scale web apps need deliberate architecture
Go	High performance, great concurrency	Business web apps mean hand-rolling things frameworks give you elsewhere
TypeScript	One language across the stack, type safety	Fast-moving ecosystem; dependency management needs discipline
Rust	Safety and performance	Steep learning curve, harder hiring

(Disagreements welcome in the comments 😄 — this is my experience, not a benchmark.)

No language is perfect. Which is exactly why the winning move is explaining "given our constraints, this is the best fit" — from the listener's point of view.

The ready-to-use script

"Okay, I get the theory. What do I actually say?" Here's a template you can deliver calmly in one to two minutes:

For this project, we selected the technology based not just on performance or trends, but on long-term operability and fit with our organization.

[Language] has [track record / market share], including long-running production systems like [concrete product examples].

We chose it because the large developer population keeps hiring and handover risk low, and because it specializes in [the language's home turf], giving us a good balance of learnability, implementation speed, and maintainability.

We did evaluate alternatives, but for these requirements, [language] was the lowest-risk choice in terms of speed, cost, and continuity.

Example: making the case for Go

For this project, we selected the technology based not just on performance or trends, but on long-term operability and fit with our organization.

Go is widely adopted across the cloud-native landscape — Kubernetes and Docker are written in it — with a strong track record of long-running production systems.

We chose it because its simple language design keeps code consistent across engineers, and its concurrency performance matches the requirements of our API platform.

We also evaluated Python and TypeScript, but for these requirements, Go was the lowest-risk choice in terms of speed, cost, and continuity.

Notice the framing: not "we picked the most impressive option" but "we picked the lowest-risk option." Decision-makers relax at the second one, not the first.

And there's a bonus effect: even if the answer is still "no," a structured explanation like this makes it obvious which specific concern is blocking approval — so your second attempt becomes a targeted fix instead of another shot in the dark.

Tech selection is accountability to your future self

If I had to compress this whole post into one line:

Tech selection isn't choosing what's most impressive today. It's making a decision you can still explain — and stand behind — years later.

You've probably heard (or been the subject of) the line: "They can build things, sure, but they never think about operations." I've been on the receiving end of that one. It stings because it's fair: being right today isn't enough.

And if you're drawn to a language because it's trending or because you want to learn it — protect that curiosity, it's what keeps this job fun — but on its own, it won't get a proposal approved. Pair it with a business case built on the four lenses:

✅ Deep talent pool — low bus-factor risk
✅ Fit for purpose — shortest path to the goal
✅ Mature ecosystem — no wheel reinvention
✅ Realistic cost and operations — sustainable for years

Cover those four, and you can propose any language with your head held high.

Now go pitch your stack.

This article is an English adaptation of a piece I originally wrote for the pamphlet of PHPerKaigi 2026, a Japanese PHP conference, later reworked for Qiita (Japanese).

I got tired of heavyweight Markdown editors, so I built one in Rust + Tauri that doesn't ship a browser

Shinya Saita — Mon, 10 Aug 2026 16:06:49 +0000

TL;DR: I wanted a Markdown editor that just opens instantly and gets out of the way. Nothing quite fit, so I built Bokuchi with Tauri v2 + Rust + React. Instead of bundling a whole Chromium instance, it renders through the OS's native WebView — so it's light enough to leave open all day and opens before you finish reaching for your coffee. It's open source: github.com/Bokuchi-Editor/bokuchi

The itch

Here's a situation you probably know too well.

You want to jot down a quick note. Maybe a release checklist, maybe a snippet of Markdown for a PR description. So you open your editor of choice — and your laptop fan spins up like it's about to take off. A "note-taking" app just claimed a serious chunk of your RAM before you typed a single character.

I love VS Code. I've used Atom (RIP). I respect Obsidian. But for the specific job of "open a window, write some Markdown, close it", they all felt like renting a moving truck to carry a sandwich.

I had three requirements, and only three:

Simplicity — Markdown editing. That's it. No plugin marketplace, no account, no sync daemon.
A design I won't get tired of — minimal, calm, something I'd happily stare at all day.
Speed above all else — this was non-negotiable. It has to feel instant.

I looked around. I couldn't find the thing that hit all three. So I did what every engineer eventually does when they should probably know better:

I decided to build it myself.

Why "build your own" is the developer's disease

Building your own tool is a trap and a joy at the same time.

It's a trap because "how hard can a text box be?" is one of the great lies we tell ourselves. It's a joy because the moment your own tool does exactly the thing you wanted, in exactly the way you wanted, there's nothing else like it.

The real question wasn't "should I build it" (my ego had already decided). It was "what do I build it with?"

If I reached for Electron, I'd be right back where I started: shipping a whole Chromium instance to render a text area. That defeats requirement #3 before I write a line of code.

Enter Tauri.

What is Tauri, for the uninitiated?

If you haven't touched it yet:

Tauri lets you build desktop apps with a web frontend and a Rust backend. The key difference from Electron is that Tauri doesn't bundle a browser. Instead it uses the operating system's native WebView (WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux).

That one design choice cascades into everything I cared about:

Tiny footprint — no bundled Chromium means dramatically smaller binaries and lower memory.
Rust backend — safe, fast, and genuinely pleasant for file I/O and heavier logic.
Security by default — the app can only touch the OS capabilities you explicitly grant it (more on this below).
Cross-platform — one codebase for Windows, macOS, and Linux.

For a "must feel instant" Markdown editor, this was the right foundation.

Meet Bokuchi

So I built Bokuchi — a lightweight, cross-platform Markdown editor.

Stack:

Layer	Choice
Framework	Tauri v2
Backend	Rust
Frontend	React + TypeScript
Build	Vite
Platforms	Windows / macOS / Linux

Light enough to forget it's running

I originally wanted to open this section with a big, satisfying RAM number. I'm not going to — because honestly measuring memory for a WebView-based app is murkier than it looks. Do you count the OS's WebView helper processes? Shared frameworks already resident because the system uses them anyway? Depending on where you draw the line, you can make the number look heroic or ordinary, and I'd rather skip the benchmark theater.

So here's the claim I can stand behind: Bokuchi doesn't bundle a browser. There's no Chromium instance spinning up just to render a text area — the UI runs in the WebView your OS already ships. In practice that means it opens instantly, idles quietly, and never gives you a reason to close it.

That's not a spec-sheet flex — it's the entire reason the app exists. When opening the editor costs you nothing, you actually use it for the two-line notes instead of reaching for a sticky note.

What's actually in it

I kept the core minimal, but "minimal" doesn't mean "bare":

Real-time preview with synchronized scrolling
Tab management + auto-save + state persistence (close it, reopen it, everything's where you left it)
Markdown toolbar — headings, bold, italic, lists, links, tables
Search & replace with match highlighting
KaTeX for math ( $...$ and $$...$$)
Mermaid diagrams from fenced code blocks
Marp slide presentations with custom themes
CJK-aware word count (yes, it counts Japanese/Chinese/Korean characters correctly)
9 themes and a 14-language UI
HTML export, plus HTML/TSV/CSV table → Markdown conversion

The feature I'm quietly proud of: a variable system

Here's the part that started as "a small convenience" and turned into my favorite feature.

I write a lot of repetitive documents — release procedures, runbooks — where the structure is identical every time but a few values (a date, a version, a command) change. Copy-pasting last week's doc and hunting for the three things to update is exactly the kind of small, dumb friction that adds up.

So Bokuchi lets you embed variables directly in your Markdown:

<!-- @var version: 2.3.0 -->
<!-- @var deploy_date: 2026-07-01 -->

# Release Procedure {{version}}

Scheduled for **{{deploy_date}}**.

Run:

    git checkout v{{version}}
    ./deploy.sh --version {{version}}

Define once at the top, reference with {{...}} anywhere, and the preview renders the resolved document. Variables can be file-local (like above) or global (set once in Settings, reused across every file). No spreadsheet, no find-and-replace ritual — the template is the document.

Security: you grant, or it can't

One thing I genuinely appreciate about Tauri v2 is that access to the host machine is opt-in. Your app declares a set of capabilities, and anything not on the list simply cannot be called from the frontend.

A capabilities file looks roughly like this:

{
  "identifier": "default",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "dialog:default",
    "fs:allow-read-file",
    "fs:allow-write-file",
    "clipboard-manager:allow-read-text",
    "clipboard-manager:allow-write-text"
  ]
}

The frontend can open a file dialog, read and write files, and touch the clipboard — because I said so, explicitly. It can't spawn a shell or hit the network unless I add those permissions. For a tool people run on their own machines, that "least privilege by construction" model is exactly the guarantee I want to be able to make.

The Tauri v2 developer experience

A few honest takeaways after shipping with it:

The web frontend is just the web. React, Vite, hot reload — all the muscle memory transfers. No weird framework-specific rendering layer.
Rust is where the calm lives. File I/O, external-change detection, the variable resolver — pushing that into a typed, compiled backend meant a whole class of "undefined is not a function at 2am" bugs never happened.
The capability model makes you think about your surface area early, which sounds like a chore and is actually a gift.
The lightness is real. Not bundling Chromium shows up exactly where you'd hope: smaller installers, faster startup, and an app you can leave open all day without thinking about it.

Is it all frictionless? No — you'll spend time learning the permission system, and WebView differences across platforms are a real thing you have to test. But for the class of app where "lightweight" is a feature and not an afterthought, Tauri v2 is the most fun I've had building desktop software in years.

Try it / break it / star it

Bokuchi is free and open source.

Download (auto-detects your OS): bokuchi.com
Source & releases: github.com/Bokuchi-Editor/bokuchi

If you've ever grumbled at a note-taking app for hogging your RAM, I'd love for you to give it a spin. Issues, feedback, and PRs are all genuinely welcome — and if it saves you a little friction, a ⭐ on the repo helps more people find it.

Thanks for reading. Now go write something. Quickly.