
When I look back at my time with **Pravesha.lk**, it wasn’t just a project — it was a mirror that showed me who I really am as an engineer, a leader, and a person.  
It challenged my patience, pushed my limits, and redefined how I look at problems, people, and purpose.  

---

## 1. Leadership Is Not About Control — It’s About Trust  

When you’re leading a team under pressure, you realize very quickly that you can’t do everything yourself.  
I learned to trust others, even when I wasn’t 100% sure. Empowering people — giving them clarity and space — always leads to better outcomes than micromanaging.  

---

## 2. Pressure Reveals Priorities  

There were days when deadlines, expectations, and dependencies all collided.  
That’s when I realized that architecture and management aren’t about perfection — they’re about making the right decision at the right time, even if it’s not the perfect one.  
It taught me to focus on what truly moves the project forward.  

---

## 3. Communication Is the Strongest Architecture Layer  

The more complex the system became, the more I realized that *miscommunication breaks things faster than bad code.*  
I learned to spend time explaining, documenting, and aligning — because clarity saves weeks of confusion later.  

---

## 4. Responsibility Is Not Just About the Work  

Being part of a national project meant that what we built would impact millions of people.  
That changed how I looked at software — it’s not just about performance metrics or uptime. It’s about **responsibility**.  
Every line of code, every design choice had a real-world impact.  

---

## 5. Growth Comes from Discomfort  

Nothing about Pravesha.lk was easy.  
But that’s exactly why it was meaningful.  
It taught me resilience, discipline, and patience — not just as a professional, but as a person.  

---

## Closing Thought  

Pravesha.lk wasn’t just the start of a project — it was the start of *me understanding me* — how I think, lead, and grow.  
It showed me that real engineering isn’t about the tools or frameworks; it’s about the **mindset**.  
And that realization continues to shape everything I do today.  


How Pravesha.lk Helped Me Understand Myself


My journey began in **April 2014** with **Pravesha.lk**, the Sri Lanka Railways Smart Ticketing and Seat Reservation System.  
When I joined the project, the architecture was *semi-finalized*, but many crucial pieces were still missing. In other words, I had to start almost from the beginning — refining the design, aligning the team, and preparing for development under a very tight deadline.  

## Understanding the Starting Point  

My primary responsibility was to **design the system** and **initiate development** as quickly as possible.  
The requirements were locked and finalized, and the proposed architecture looked promising — but there were still a lot of gaps that needed attention and practical alignment.  

## What I Had to Look Into  

Considering the defined tech stack, requirements, and team structure, I had to make some key adjustments based on the following factors:  

- How skilled the current team was in the defined tech stack and architecture.  
- The individual capabilities and strengths of each team member.  
- The team allocation and their working hours (full-time vs part-time).  
- How to convince the technical consultant team if we decided to change parts of the tech stack.  

After carefully evaluating these areas, I made several **adjustments to the architecture and technologies** we used to ensure the team could deliver efficiently while maintaining scalability and reliability.  

## Why the Team Structure Mattered  

The team structure was a **critical factor** in architectural decisions.  
Understanding each member’s capabilities and roles helped me align the design with real execution potential. We had a mix of full-time and part-time members — the leads were part-timers, but they were extremely skilled and dedicated.  

I had already worked with some of them before, but to get a complete picture, I conducted **one-on-one sessions** with each team member and prepared a **skill-map**. After these discussions, I had a clear understanding of both the technical requirements and the team’s strengths.  

## The Next Step  

The next step was to **revise and refine the existing architecture and design** before submitting it again.  
The client had a **technical consultant team** made up of senior industry experts. Collaborating with them wasn’t easy at first — there were challenges, debates, and a lot of validation. However, they were supportive and open-minded once they understood the reasoning behind our proposed amendments. Eventually, they agreed to the new direction of the technical design.  

## Reflection  

Looking back, that phase shaped how I approach large-scale system design even today.  
It wasn’t just about technology or architecture — it was about **aligning people, process, and product** to build something that truly works. The foundation we laid during those early months became the **backbone of what evolved into Sri Lanka’s national railway ticketing platform**.  

> Every system has a story — and for me, Pravesha.lk wasn’t just about tickets or trains. It was about building something that could move an entire nation, literally.

## What’s Next  

In the next part, I’ll share how we refined the architecture further — from designing the **core microservices** to tackling **real-time seat availability**, **payment gateway integration**, and **deployment under extreme time constraints**.  


My Journey with Pravesha.lk — Redefining a National System from the Ground Up


## Why You Should Never Romance with the Job

You may have already read many articles about why you should treat your job as just a job.  
But this one is different — it’s not from theory or philosophy. It’s from experience. A hard, real-life one.

---

### The Start of Trust

Last year in April, I joined a company owned by one of my friends.  
I had already worked with him before — part-time — and helped him complete a few successful projects. Because of that trust and past experience, he offered me a full-time position to help lead their main product.  
And I accepted it without hesitation. After all, friendship plus passion for work — what could go wrong?

---

### When Things Went Wrong

At first, everything seemed fine. But soon, I started to notice small cracks.  
A few part-time engineers complained about late payments. Some even mentioned they hadn’t been paid at all for months.  

Initially, I didn’t think too much about it — I believed my friend would handle it.  
But after a few months, the same thing started happening to us — the full-timers. Salaries were delayed. Promises were made. Explanations came and went.

---

### The Hard Truth

When I decided to dig deeper, the truth shocked me.  
He had used the money meant for salaries and project expenses to invest elsewhere — and later, he quietly migrated to another country, leaving the team behind.

Months later, he sent me a WhatsApp message as if nothing had happened.  
I responded, probably with a bit of emotion — because it wasn’t just about the money. It was about trust, hard work, and the long nights we spent believing we were building something meaningful together.

His reply was short.  
Cold.  

![WhatsApp reply screenshot](/images/why-you-should-never-romance-with-the-job.jpeg)
*The actual message I received that day.*

And that was the moment I truly learned what it means when people say:

> “Never romance with your job.”

---

### The Lesson

No matter how much you love what you do — don’t tie your self-worth, your peace of mind, or your relationships to your employer or company.  
Do your best. Work hard. Be proud of what you build.  
But don’t let your emotions blind your judgment.

Because jobs will change. Companies will change. People will change.  
And at the end of the day — **you** are the only one who will face the consequences of how much you gave, trusted, or sacrificed.

So, don’t romance with your job.  
Spend time with your loved ones — your family, your friends, the people who truly matter.  

Respect your work, give your best, but remember to keep your heart for life — not for work.

---

*Have you ever trusted a company or person too much — and paid the price for it?*


A real-life story about trust, loss, and the hard lesson of keeping your emotions separate from your job.

Why You Should Never Romance with the Job


# Who I Am and Why I Built chamith.dev

Welcome to my corner of the internet — a space where I share my journey from curious developer to Head of Engineering, and everything I've learned along the way.

## From Developer to Head of Engineering

My journey started like most developers — curious, fidgety, and in awe at how little code could turn into something people depend upon. I moved through positions from developer to team lead, architect, and now Head of Engineering.

Each move taught me something new — not just technology, but also people, systems, and compromises. I learned that engineering is not just about coding. It's about constructing systems that function even when humans make mistakes, when servers crash, or when 10x traffic hits unexpectedly.

## Why I Love Solving Complex Systems Problems

I've always loved the architecture side of engineering — creating hundreds of moving pieces into something you can't even see from the end user's perspective. Whether it's designing microservice communication, database tuning, or orchestrating containers on OpenShift, I find satisfaction in solving the problems most people will never even realize.

There is beauty in systems thinking — the invisible logic behind making things happen. And in a global village where technology unites millions of people, I believe engineering has to be ambitious and responsible.

## What You Can Expect Here

chamith.dev is where I reflect on what I have learned (and what I continue to learn).

Here's what you can expect from my future posts:

### 🏗️ Architecture & System Design
Planning beyond code — resilience, scalability, reliability.

### 🚀 DevOps & OpenShift
Learning in the real world from building and deploying nation-scale systems.

### 👥 Engineering Leadership
Leading teams, making decisions, and building lasting culture.

### 📊 Case Studies
Detailed stories of projects like Pravesha.lk — what went right, what went wrong, and how we fixed it.

### 💭 Personal Reflections
The human aspect of engineering — from burnout to equilibrium.

## My Vision

I built this space not as a portfolio, but as a journal of lessons learned — a place to share my experiences, document insights, and maybe inspire the next engineer who's trying to make sense of the chaos.

My goal is simple:

> **To build and share systems that serve millions — responsibly, reliably, and with heart.**

If you've ever been debugging a production bug in the middle of the night at 2 AM, weighing business needs against engineering morals, or simply trying to create something worthwhile — you'll be at home here.

---

## 🔜 What's Next?

**"How We Designed a National-Scale Ticketing System for Sri Lanka Railways"**

An inside look at architecture, tech, and decisions that enabled Pravesha.lk — coming soon to this space.

Articles

Featured Article

Who I Am and Why I Built chamith.dev

All Articles

How Pravesha.lk Helped Me Understand Myself

My Journey with Pravesha.lk — Redefining a National System from the Ground Up

Why You Should Never Romance with the Job