Career
Balancing DevOps, ERP, and Web Dev as a Final-Year Engineering Student
April 20267 min read
Photo by Unsplash
Photo by Unsplash
Most career advice says to specialize early, go deep in one area, and let breadth come later. I went the other way — not entirely by choice. Finishing my degree at Swiss German University while working part-time as a DevOps engineer at Commsult Indonesia and building custom web apps and ERP systems on the side means I'm constantly context-switching between three distinct technical domains. It's harder than I expected and more rewarding than I anticipated. This is an honest account of how it actually works.
It started with DevOps. I got into Linux and Docker through university coursework, built a few side projects on DigitalOcean, and found that I genuinely enjoyed infrastructure — the precision of it, the way a well-configured CI/CD pipeline becomes invisible and reliable. That led to the part-time role at Commsult, which is a consulting firm that builds and maintains ERP systems for Indonesian businesses. Suddenly I was also doing ERP: NestJS backends, approval workflows, accounting modules, HR leave management.
The hardest part isn't the technical depth — it's the mental mode shift. DevOps work requires a systems mindset: thinking about failure modes, network topology, resource limits, monitoring signal vs noise. ERP development requires a business logic mindset: understanding approval hierarchies, accounting rules, data integrity constraints. Web development requires a product mindset: user experience, performance perception, visual hierarchy. Switching between these modes mid-day is genuinely cognitively expensive.
Swiss German University runs a curriculum that is broader than most Indonesian universities, with coursework in operating systems, cloud computing, software engineering, and a final capstone project. The academic work is both a burden and a gift. It's a burden because it competes for time with paid work and side projects. It's a gift because it forces me to formalize knowledge I've acquired informally.
BREADTH (general software engineering)
◄──────────────────────────────────────────────────────►
Linux │ Git │ SQL │ REST APIs │ TypeScript │ Bash │ Docker
──────┼─────┼─────┼───────────┼────────────┼──────┼───────
│ DEPTH │
▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ DevOps / │ │ ERP / │ │ Web App Dev / │
│ Cloud Infra │ │ Business │ │ Next.js │
│ │ │ Systems │ │ │
│ GCP, Docker │ │ Workflows, │ │ React, next-intl │
│ Nginx, CI/CD │ │ Approvals, │ │ TypeScript, │
│ Monitoring │ │ NestJS APIs │ │ Tailwind, SEO │
└──────┬───────┘ └──────┬───────┘ └────────┬─────────┘
│ │ │
└──────────────────┴─────────────────────┘
Each domain REINFORCES the others:
DevOps → deploy web apps & ERP in production
ERP → teaches real business logic for web apps
Web Dev → builds UIs for ERP & monitoring toolsWrite three bullet points at the end of every work session summarizing where you left off and what the next step is. This ritual costs 2 minutes and saves 20 minutes of warm-up time the next session. The cognitive overhead of multi-domain work is mostly in the ramp-up, not the actual work.
The unexpected benefit of multi-domain work is the cross-pollination. DevOps knowledge makes me a better web developer: I know how Nginx serves Next.js, how to configure proper cache headers, how to set up a staging environment. ERP work makes me a better systems thinker: business logic has invariants and edge cases that are more complex than most tutorial examples. Web development makes me a better DevOps engineer: building user-facing tools for internal teams is much easier when I understand the UX requirements.
The T-shaped engineer framework describes where I'm heading rather than where I am now. Right now I'm more like an M-shape: moderate depth in three connected areas, with shared breadth underneath. Shared breadth across all three domains includes: TypeScript, PostgreSQL, REST API design, Linux, Git, Docker, and basic networking. These fundamentals appear in every domain and investment in them is never wasted.
# My rough weekly rhythm (not always this clean, but aspirational)
MON–TUE │ DevOps / Infra work at Commsult
│ → VPS provisioning, CI/CD pipeline fixes,
│ monitoring alerts, cloud cost review
WED–THU │ ERP feature development
│ → NestJS backend: approval workflows,
│ invoice generation, RBAC, email triggers
FRI │ Web app / portfolio / side projects
│ → Next.js, Tailwind, SEO, performance tuning
WEEKEND │ Study: Swiss German University coursework
│ → Operating systems, cloud computing,
│ software engineering capstone
# Context-switching tricks I actually use:
# 1. End each block by writing 3 bullet notes: "where I left off"
# 2. Keep separate terminal workspaces per domain (tmux sessions)
# 3. Short 5-min "warm-up" re-read before diving in
# 4. Never mix domains mid-flow — finish the task firstIf I could give advice to myself at the start of this journey: embrace the breadth, but be intentional about it. Don't spread yourself thin by accident — spread yourself thin by design, with a plan for when and how you'll go deep. Document everything you learn, not for others, but for your future self. The knowledge accumulation compounds over time in ways that aren't obvious month-to-month but become unmistakable year-to-year.
The real risk of multi-domain work isn't burnout — it's staying permanently shallow. It's easy to touch DevOps every week, ERP every week, and web dev every week, but never go deep enough in any of them to build genuinely novel solutions. Set a quarterly depth goal in one domain to counteract this drift.
Time management across three domains and university comes down to a few non-negotiable habits: time-blocking by domain (not by task), context notes at every session end, and ruthless scope limitation on side projects. The biggest lever is saying no to interesting things that don't fit the current focus. The second biggest lever is automating the DevOps toil so it doesn't consume disproportionate time.
I don't plan to stay multi-domain forever. The strategy is to use the breadth as a foundation and converge on a primary specialty as opportunities crystallize. The three domains naturally converge toward building production software systems that run reliably — which describes most interesting engineering roles. Whether the primary specialty ends up being platform engineering, full-stack product engineering, or technical consulting, the three-domain foundation will have been worth it.