When I started, I had no idea which area to get into.
I'd search online and find giant lists. Front-end. Back-end. Cloud. AI. Blockchain. DevOps.
Every list said something different, and with so much information and so many options it's really hard to make a decision.
I ended up spending weeks reading about areas instead of coding in one specific one.
Over time I put together a way to organize all of that which worked for me. It's not the only way, nor necessarily the best one, but it worked for me and it still does today.
Here's the map, and at the end a diagram: you answer three questions and you come out with an area to start specializing in.
The map reads in three ways, not one
What used to confuse me was seeing everything in a single list, as if it were all the same kind of thing. And it isn't.
Split it into three questions:
- Where does the software run? → platform or destination
- Which part of the system do you touch? → technical layer
- What problem does it solve? → domain
The same job lives in all three at once.
They're three answers to three different questions. They're not three jobs.
Let's go one by one.
1. By platform: where your code runs
The easiest one to understand. What device does what you write end up living on?
- Web — Applications designed to run in web browsers. Examples: an online store, a booking system, a company's intranet. You work with HTML, CSS, JavaScript or TypeScript, React, Angular, Vue, and Node.js. It's where a lot of people get in; me included.
- Desktop — Software you install on your computer. Examples: code editors, design tools, point-of-sale systems. You work with .NET and C#, Java, Electron, or Qt.
- Mobile — Apps for iOS and Android. Examples: your banking app, the delivery one, the fitness one. You work with Swift, Kotlin, React Native, or Flutter.
- Operating systems — Kernels, drivers, file systems: everything that manages the hardware underneath. You work with C, C++, Rust, and even assembly. It's a tough area with fewer openings than the others.
- Embedded and IoT — Software that runs inside devices with little memory and little processing power: sensors, cars, refrigerators, medical equipment. You work with C, C++, Rust, and real-time systems. If it excites you that your code moves something physical, this is it.
2. By technical layer: which part of the system you touch
Here the device no longer matters. What matters is which part of the system is yours.
These layers exist in almost every platform. There's front-end in web, mobile, and desktop. There's security in all of them.
- Front-end — The part the user sees and touches. It's not just "putting buttons": it's making the screen load fast, making it work on an old phone, and making sure a thirty-field form doesn't break.
- Back-end and APIs — The logic that runs on the server: APIs, integrations, databases, message queues. Examples: a payment gateway, a notification service, the process that calculates your bill.
- Full-stack — Both of the above. It's common in startups and internal tools; that's how I started, and I learned incredibly fast, mostly because there was no one else to do the other half.
- Cloud — Applications designed to scale using cloud services. You work with GCP, AWS, Azure, Kubernetes, Terraform, and serverless functions.
- DevOps, platform, and SRE — Automating builds, deployments, monitoring, and everything that keeps the system from going down, with Docker, Kubernetes, GitHub Actions, Terraform, Prometheus, and Grafana. Your end user isn't a customer — it's another developer.
- Security — Protecting systems, detecting threats, and responding when something happens. Examples: vulnerability scanners, identity management, encryption.
3. By domain: what problem you solve
Two people can use the same tools and do completely different jobs, because they're solving different problems.
- Video games — Games for PC, console, and mobile, plus virtual and augmented reality. You work with Unity and C#, Unreal and C++, or Godot.
- Data, AI, and machine learning — Models that predict, recommend, understand text, or see images, and now, agents. Examples: fraud detection, chatbots, prices that change on their own. You work with Python, PyTorch, TensorFlow, scikit-learn, and vector databases. It's the fastest-growing area right now; it's also the one with the most noise around it.
- Blockchain and Web3 — Smart contracts, wallets, decentralized applications. You work mostly with Solidity and Rust.
- Enterprise software — The systems that run a company: finance, HR, sales, logistics. Examples: SAP, Salesforce, Dynamics, Power BI. It pays well and there's always work.
- Developer tools — IDEs, compilers, linters, plugins, internal portals. When it's done well, nobody notices (allegedly).
Nobody works in just one area
Two examples from my own path, in case they're useful as a reference:
At a startup I built the backend in Node.js, integrated the WhatsApp and Instagram APIs, managed the servers, set up the certificates, and also did on-site installs with clients.
Today, at a large company, I work on an internal developer portal: frontend and plugins in React and TypeScript, APIs in Spring Boot, infrastructure on GCP with Terraform.
Choosing an area of specialization isn't limiting yourself, it's a good way to decide what you'll specialize in first, and you always have the chance to change your mind.
Three questions and a prompt
The map's done. Now the practical part.
Answer these three questions with the first thing that comes to mind. Don't overthink it.
With your answers you can walk away with a real project to start this weekend. Here's a prompt you can use for that:
Replace everything in brackets [ ] with your own information.
You are an experienced software engineer helping me decide where to start
specializing. Don't sell me a trendy area: ground what I give you.
MY ANSWERS
1. Where I want my code to run: [your answer to question 1]
2. The part I like most: [your answer to question 2]
3. The problem I want to solve: [your answer to question 3]
CONTEXT ABOUT ME
- Attach your resume as a PDF or Word doc (or paste the text) so you use my real experience.
- Time I can dedicate per week: [hours]
- Why I want this: [changing jobs, growing where I am, curiosity]
GIVE ME THIS, IN THIS ORDER
1. RECOMMENDED AREA — just one, with the why in 2-3 lines. Also tell me
which one came in second and what would change the result.
2. DAY-TO-DAY — what it's like to work there, boring part included.
3. STARTER PROJECT — just one, small, finishable in the time I gave you.
Include: requirements, stack (justified against my context), MVP
(what IS and is NOT included), and what "done" means (deployed and
reachable from the internet).
4. FIRST THREE STEPS to get started today.
RULES
- Be specific, no generic lists of technologies.
- If anything is ambiguous or missing, ask me before answering.
Question the answer. Ask why it ruled out the other areas and what problem each piece of the proposed stack solves.
You already have the plan, but you'll gain the specialization by facing real problems while you build.
Keep in mind: this is an entry point, not a destination. And it's my way of organizing it that has worked for me, not a universal truth.
I got in through technical support and today I build platforms and help developers deploy software to production.