What to Learn as a Software Developer in 2026

How has AI changed what is worth learning?

AI has made memorising syntax and boilerplate much less valuable, and made fundamentals, code reading, judgement and communication more valuable. The typing is cheaper. The thinking is not.

A coding assistant can produce a working screen, a SQL query or a REST client in seconds. What it cannot do reliably is decide what you should build, notice that the output quietly mishandles a failed network call, or explain a trade-off to a client. When I review junior candidates, the gap I see is rarely “cannot write the loop”. It is “cannot tell whether this code is right”.

So the shift looks like this:

• Less: memorising API signatures, typing boilerplate from scratch, following a tutorial line by line.
• More: understanding how data flows through a system, reading unfamiliar code quickly, debugging, writing precise requirements, and checking AI output against reality.
• Unchanged: you still need to be able to write code by hand, because you cannot review what you cannot write.

What is the core stack every developer needs?

Every developer needs one language deeply, Git, data structures and algorithms, HTTP and APIs, SQL, testing, debugging, Linux basics and cloud basics. These barely change from year to year, which is exactly why they are worth the investment.

Two of these deserve extra emphasis. Debugging is the skill that grows fastest with deliberate practice and is the one AI helps with least, because the bug is usually in the gap between what you meant and what you wrote. And HTTP is the thing almost everything else sits on. If you can read a failing request, you can work on any backend or mobile app.

Once these basics are solid, the next layer is thinking in whole systems, which we cover in system design for developers.

What AI skills should developers learn?

Learn to direct coding agents with clear specs, call LLM APIs from your own code, build a simple tool-using agent, and above all evaluate AI output. These skills sit on top of the core stack. They do not replace it.

Using coding agents well

Treat an agent like a fast, eager junior colleague. Give it small, well-defined tasks, a clear definition of done and the context it needs, then read every diff. For a fuller treatment see AI agents in software development.

Prompting and writing specs

A good prompt is a good spec: the goal, the constraints, the inputs and outputs, and examples of edge cases. Writing this down also clarifies your own thinking, which is why it improves your work even when you ignore the AI.

Calling LLM APIs

This is ordinary API work with a new endpoint. You send messages, handle streaming, manage errors and rate limits, and control cost. The official Anthropic documentation is a good place to see the request and response shapes. Here is the idea in a few lines of Python:

import anthropic

client = anthropic.Anthropic()  # reads the API key from the environment
reply = client.messages.create(
    model="MODEL_NAME",  # use a current model from the docs
    max_tokens=300,
    messages=[{"role": "user",
               "content": "Explain idempotency in one paragraph."}],
)
print(reply.content[0].text)

Building agents

An agent is a loop: the model decides, calls a tool, sees the result and decides again. Start with one tool, such as “look up an order”, and a hard limit on the number of steps. Learning this makes you far better at using agents built by others.

Evaluating output

Write tests before you trust generated code, and keep a small set of example inputs with expected outputs for any LLM feature you build. If you cannot say how you would know the output is wrong, you are not ready to ship it.

Which specialisation should I choose?

Choose the one whose first project excites you enough to finish it, then check the local demand. Mobile, web frontend, backend, data and ML, and DevOps and cloud are all legitimate paths, and the core stack above is shared by all of them.

I cannot give you reliable salary or job-count figures for these paths, and you should be wary of anyone who does. Look at real job listings in your target market, count how many mention each skill, and let that guide you.

What is the best programming language to learn in 2026?

The best language is the one that matches your target path, because depth in one language transfers further than shallow knowledge of five. If you do not yet have a target, Python is the gentlest start and Kotlin is the strongest bet for the Kenyan mobile market.

• Kotlin: Android apps, and also server-side work. Good tooling and a modern, readable design. See kotlinlang.org.
• Swift: iPhone and iPad apps, with the same ideas as Kotlin in a different syntax.
• Python: data, automation, scripting and AI work. Forgiving for beginners.
• JavaScript and TypeScript: the language of the browser, and common on the server too.

Here is the sort of Kotlin you will write early on, a function that sums only the successful M-Pesa payments in a list:

data class Payment(val id: String, val amountKes: Int, val success: Boolean)

fun totalReceived(payments: List<Payment>): Int =
    payments.filter { it.success }.sumOf { it.amountKes }

fun main() {
    val list = listOf(
        Payment("A1", 500, true),
        Payment("A2", 1200, false),
        Payment("A3", 300, true),
    )
    println(totalReceived(list)) // 800
}

What is my roadmap, based on where I am starting?

Your roadmap depends on your starting point, but all four paths end in the same place: shipped projects you can show. Find the one closest to you.

KCSE leaver or total beginner

1. Months 1 to 2: pick one language and learn variables, conditions, loops, functions and collections. Write small programs daily.
2. Months 3 to 4: learn Git, then build your first full app with a screen, some data and a network call.
3. Months 5 to 6: add SQL basics, testing, and basic data structures. Build a second, more ambitious project.
4. Months 7 to 12: publish both projects, add AI tooling to your workflow, start applying for internships and junior roles.

Computer science student or graduate

You likely have the theory but not the shipped work. Pick a specialisation now, rebuild one university project as a real, deployed app, and spend the saved time on Git, testing and an API integration. Practise problems weekly using the interview guide as a checklist.

Career changer

Your previous field is an asset, not a delay. A nurse, accountant or logistics officer can build software for that domain with real insight. Choose a specialisation connected to your industry, set a fixed weekly schedule you can sustain alongside work, and aim for one genuinely useful project for people you already know.

Working developer levelling up

Find your weakest fundamental, which is often testing, system design or one layer of the stack you never touched, and close it. Then add the AI layer deliberately: use an agent on a real task, measure where it saved time and where it cost time, and write that down. Move toward ownership of design decisions rather than only tickets.

What should I not spend time on?

Do not spend your time on tutorial hopping, collecting certificates or chasing every new framework. These feel productive but produce little that an employer can verify.

• Tutorial hopping: watching course after course without building anything. If you finish a tutorial and cannot rebuild it with the video closed, you have not learned it yet.
• Collecting certificates: a certificate shows attendance. A working app shows skill.
• Chasing every new framework: frameworks come and go, while the ideas underneath them, such as state, networking and persistence, last. Learn those ideas in one framework and the next one will be quick.
• Outsourcing your thinking to AI: if every line is generated and you cannot explain it, you are building a dependency, not a skill.

How do I build a portfolio and proof of work?

Build two or three finished, deployed projects with clean READMEs, and explain your decisions in writing. A small project that works end to end beats a big one that stops halfway.

1. Solve a real problem for a real person. A tool for a small shop, a church group or a school is better than a generic to-do app.
2. Use a local integration. An app that takes M-Pesa payments through the Daraja API or handles flaky connections shows exactly the context Kenyan employers care about. For Android specifics, developer.android.com is the reference.
3. Ship it. Put it on the Play Store, TestFlight or a live URL, not just a repository.
4. Write a README. What it does, how to run it, what you would do next, and one bug you fixed and what it taught you.
5. Keep commits tidy. A history of small, clear commits is itself proof of how you work.

Remote work is a real route for Kenyan developers, but remote employers cannot see you, so your public work does most of the talking. Make it easy to read and easy to run.

What does a weekly learning plan look like?

A sustainable plan is 10 to 15 hours a week, split mostly into building, with short daily sessions rather than one big weekend binge. Consistency matters more than intensity.

Learning alone is hard to sustain, and a structured programme with deadlines and feedback helps many people. That is why we built the 12-week Foundation and Professional tracks at Bridgetree Learn, but the plan above works with any resources you trust. The point is the rhythm: build most days, review weekly, and publish something every month.

Frequently asked questions

Kevin Lagat

Founder and lead instructor at Bridgetree Learn. Former Senior iOS Engineer at Safaricom, where he worked on the M-PESA app. He has shipped production apps for the UK's NHS, a Saudi digital bank and US SaaS companies, and trained Saudi Digital Academy cohorts through Coding Dojo. LinkedIn · GitHub