Skip to content
Back to Blog

How to choose a path in technology without predicting the future

If you are starting out in technology, it can feel as if you must choose today the job you will have ten years from now. New roles keep appearing, and every new tool seems urgent. I would not try to guess the perfect job title. I would ask which problems I enjoy solving and where I can learn well.

My work has taken me through databases, infrastructure, architecture, leadership and AI. It was not a straight line. At each turn, I had to carry over what I knew, admit what I did not know and learn again. The approach below comes from that experience; it is not a formula for everyone.

Build foundations you can take with you

A tool may fall out of use. Understanding how systems receive data, run processes, fail and serve people remains valuable in many fields. Start with a small project and learn to explain:

  • Whose problem it solves and why.
  • Where the data comes from and what happens when it is wrong.
  • How you know it works, including when something fails.
  • Who will maintain it after the first release.

You do not need to master everything before seeking a job. You do need to show how you think, where you were uncertain and how you checked your answer.

Try three kinds of problem

Instead of changing courses every week, run three short experiments in the same context. A simple record keeping application is enough:

  1. Building: implement one function, test it and document a design choice.
  2. Operating: deploy it, observe errors and learn how to recover it.
  3. Data and decisions: ask a useful question, organize the data and explain what the evidence can and cannot tell you.

If you use AI, ask it to suggest alternatives or explain something difficult. Then test, review and record what you had to correct. Judging an answer matters more than simply receiving one.

When you finish, notice which experiment made you want to investigate further, even when it became difficult. That is more useful information than a ranking of promising careers.

Choose a next step, not an entire career

Treat a career decision as an eight week experiment. Pick an area, a project that fits your schedule and a person you can ask about the real work in that role. Then review:

  • What could I do without a step by step tutorial?
  • Which part gave me energy, and which part drained it?
  • Which technical gap appeared more than once?
  • Is there demand for this work in places where I can work?

If the evidence points elsewhere, the experiment was still useful. Keep your project, decisions and questions. They make for a better mentoring conversation than a list of certificates without context.

Ask for help with a concrete question

Find someone who will question your reasoning rather than choose your life for you. You might ask: “I have these two options. I tested this and observed that. What am I missing?” Good mentoring helps you see constraints, possibilities and consequences. The choice remains yours.

Technical work will keep changing. Your first path can change too. Build foundations, run small experiments and learn to revise your route honestly. That skill travels with you, whatever the next job title becomes.

Continue reading: Jobs in transition and What to do when you get stuck on a project.

Comparing the Four Core Engineering Tracks by Daily Reality

To help you run an honest self-assessment, compare the four primary technical tracks not by their marketing slogans, but by the actual problems and failure modes you will deal with at 2:00 p.m. on a Tuesday:

Technical TrackPrimary Daily ArtifactTypical Pain Point You Must Enjoy SolvingCore Foundational Skills
Product / Frontend & MobileInteractive UI, state management, accessibility, design systemsBrowser quirks, bundle performance, UX edge cases, product ambiguityTypeScript, DOM/Web APIs, HTTP caching, component architecture
Backend & Distributed SystemsAPIs, domain rules, database transactions, integrationsConcurrency bugs, third-party API timeouts, database lock contentionSQL, ACID/Indexing, API design, queues, automated testing
Data Engineering & BIPipelines (ELT), Lakehouse models, executive KPIsDirty upstream schemas, reconciling conflicting numbers, query costAdvanced SQL, Python, dimensional modeling, data governance
Cloud, DevOps & PlatformCI/CD, IaC (Terraform), Kubernetes, observability, FinOpsProduction outages, IAM security boundaries, cloud cost spikesLinux, networking/DNS, containers, Terraform, telemetry

No matter which door you walk through first, remember that shipping one small, documented, working system to production teaches you ten times more than collecting twenty completion certificates from online courses.

Cesar Zanis / Management & careers

Good ideas keep the conversation going.

Share this article or publish the visual deck to your Stories and Feed.

WhatsApp ↗LinkedIn ↗X ↗
Cesar Zanis
Written by·Software Architect & Technology Leader

Cesar Zanis

15+ years leading software architecture, database performance, FinOps, and applied AI across enterprise operations. Built and scaled an engineering organization from zero to 20+ developers.

15+ yrs experienceArchitecture & DataCloud & FinOps0 → 20+ Devs

Enjoyed this article?

I publish practical analyses on software architecture, FinOps, data, AI, management, and economics directly on LinkedIn.

Continue Reading

Take this analysis further with data and sources

All visual cards of this article are ready above to share on your Stories, Feed, WhatsApp, or LinkedIn with full sources.