From Curriculum Developer to Software Engineer: 4 Years at Dicoding, and What’s Next

This is my first article about career journey 🙂 and I’m genuinely happy to share about it.

Four years ago, I joined Dicoding as a Curriculum Developer. Last month, I left as a Software Engineer. In between, I got to do something most engineers never get the chance to do: build the products and teach thousands of people how to build software. It’s been one of the best opportunities of my career so far.

This is a look back at that journey: what I built, what I learned, and what I’m looking for next.

Where it started: teaching frontend web

I spent my first three years as a Curriculum Developer for the **Front-End Web learning path**, writing and maintaining every course in it. But writing course content was only half the job.

The real challenge was:

• how to teach thousands of people so they could fully grasp the material,
• how to make it convenient for learners to learn, and
• how to guide people through the fundamentals, so they don’t get trapped in tutorial hell and can learn on their own.

So yes, you are right. A great course is not always about having extremely long or exhaustive content. Material delivered effectively and interactively is often more than enough.

A few things we built to solve that:

• Everyday analogies We used relatable analogies to explain complex concepts, especially for the harder topics. For advanced courses, we focus only on the discussed topic.
• Interactive code with Sandpack Instead of asking learners to read code examples and try it themselves on their computer environment, we let them write and run real code directly in the classroom.
• Interactive activity We also added lightweight interactive activities throughout the course: drag-and-reorder exercises, fill-in-the-blanks, and flashcards. Lastly, we added an SQL playground. These weren’t graded assessments; learners could skip them entirely. The goal was to give learners a low-pressure way to reinforce a concept right after learning it, instead of only testing them at the end of a module.
• Sync training sessions Beyond async content, I also ran live sessions directly in front of learners, like Instructor-Led Training (ILT), Dicoding Developer Coaching, and other Dicoding offline events. Honestly, this was the part I struggled with most. I’d barely ever been on a public-speaking stage before this role.
• Autograder submissions The scholarship programs we ran brought in thousands of submissions. That’s why we built autograding systems that gave learners fast, consistent feedback on their submissions. Reviewing them also taught me which parts of a course needed retouching, and honestly, I learned just as much from reading submitters’ code as they did from the feedback. This wasn’t new territory for me either I’d already built two autograders for two other courses before this.

There was plenty more I learned in this role, and the journey of building a better learning experience (LX) continued into my next one: Software Engineer.

Then: moving into engineering

In my fourth year, I moved into a Software Engineer role, working on the systems behind Dicoding’s own products rather than the learning content itself.

Some of what that looked like:

• Learning notes The first feature I built from scratch, which supports the classroom in giving learners a better LX. It could make learners revisit without re-reading an entire module. We also ran a simple survey to collect feature feedback from learners using developer tools such as Posthog.
• Interactive glossary The next classroom feature I built. A lot of early confusion in programming isn’t conceptual, it’s vocabulary. This glossary surfaced definitions right where learners needed them.
• Scholarship program registration systems I worked on the registration flows behind scholarship programs, including IDCamp, AWS, Microsoft Elevate Training Center, Dicoding Bangun Negeri, and CodingCamp powered by DBS Foundation. Each program initially had its own scattered registration logic, which meant duplicated code and different behavior across programs.
• Refactoring into a reusable component I led the effort to refactor that scattered logic into a single, reusable registration UI component used across all these programs. This meant thinking carefully about where each program’s rules genuinely differed versus where they were just accidental duplication, and designing something flexible enough to handle both without becoming unmanageable.
• Domain-Driven Design in a Laravel codebase I got hands-on experience applying DDD principles to structure our Laravel backend, which changed how I think about organizing code for the long run rather than just making it work today. It’s also a great way to keep the business logic aligned between stakeholders and engineers.
• Building with AI 🤖 As AI-assisted development matured, I started using Claude Code to build features and fix bugs directly, including about 95% of the Dicoding Bangun Negeri (DBN) registration system. My role shifted from writing every line myself to directing the AI, reviewing its output, and making the architecture and business-logic decisions it can’t make on its own. It changed how I think about what “shipping fast” actually means without sacrificing code quality.
• Day-to-day engineering Plenty of bug fixing, refactoring, and working closely with a cross-functional team to ship reliably.

There’s also one classroom feature I left unfinished when I left: a learning time tracker. I wrote the technical implementation decision document and built the domain logic backbone in the backend, so the next engineer can pick it up and continue with the application and UI layer.

What this combination taught me

For a while, I had two different roles at the same company. Most engineers only do one thing: build the product and ship it. Most educators only do the other: explain the product and hope people understand. Getting to do both, on the same product, for the same users, taught me things I don’t think I’d have learned otherwise:

• Good curriculum design is really a UX problem, not just a content problem. The interactive tools helped learners more than any paragraph of text ever could.
• Assessing real submissions is the fastest way to see where a technology is genuinely hard to learn. Reviewing them helps us pinpoint exactly which topics need work.
• Refactoring duplicated code into one reusable component isn’t just a technical task. You need to understand why each program’s rules are different first. Otherwise, you build the wrong solution.
• Teaching and engineering make each other better. When you explain code clearly to a beginner, you end up writing clearer code yourself.
• AI tools are only as good as the engineering judgment behind them. Vibe coding with Claude Code dramatically sped up delivery on several features and bug fixes, but the real work was still reviewing the output, testing it, and making sure it actually fit our architecture.

What’s next

I’m currently looking for my next role as a Software Engineer or Frontend Engineer. My core stack is PHP/Laravel on the backend and HTML/CSS/JS, React, Next.js, and Vue.js on the frontend, with hands-on experience in DDD architecture and building learning/edtech tools. I’m also comfortable working with AI-assisted development tools like Claude Code, not as a replacement for engineering judgment, but as a way to move faster without cutting corners. But those are just tools. What I bring is a strong sense of responsibility and a high willingness to learn. I believe these are the real keys to future success.

If any of this resonates with a team you’re part of, or you know someone who’s hiring, I would genuinely appreciate a message or an introduction. 🙌