Learning, Coding, Leading: A Software Engineer’s Story

A Personal Journey

Kalpa Senanayake
10 min readJul 5, 2024
It’s more about the journey than the destination- Ralph Waldo Emerson —[Image: Bebeah Garden Estates, Mt Wilson]

The Journey Begins

My journey began 20 years ago with a spark of curiosity about how things work. It wasn’t just about the computer itself; the magic of displaying information from the internet was a colossal puzzle that captivated me.

At the time, our school had a shiny new computer laboratory with a gorgeous teacher who encouraged us to explore computers and introduce how to communicate with those via something she called “Codes”.
And guess what? These computers obey the commands and create graphics, pop-up windows, and buttons on the screen. For me, that was more fun than any other game that I could think of.

This simple love of computers and how they work grew in me over the years. Despite the majority choosing other disciplines at the university, I decided to pursue a career in software engineering and computer science.

I soon realised it takes a lot of work. The degree was designed to upskill students in electrical engineering. Computer science and software engineering electives are only available in the third year. For the next three years, I was responsible for building skills and knowledge for myself.

I started by learning a programming language during the three-month break at the end of the first year. While others enjoyed the well-deserved break or worked as an intern, I was in Kandy, Sri Lanka, learning Java programming language for three months and getting ready for a certification. I managed to complete the certification just before the break ended.

Returning to university with my newly acquired skills felt like stepping into a world of endless possibilities. This taste of knowledge fueled a hunger for more.
A few months later, I bought myself books on building web applications with Servlet and JSP, diving headfirst into self-learning.
Weekends were different for me.
While my friends left the boarding house to visit their families, I would rise early, make a cup of tea, and lose myself in these books.
Each page was a challenge; understanding a few took over an hour. But those quiet mornings, with the world still asleep, became my sanctuary of learning and growth.

I didn’t go to university to get a job qualification. I went to satisfy my curiosity, learn how things work, and become good at what I will do for the rest of my life. However, the degree program wasn’t designed for that purpose, so I had to take on the role of an autodidact.

This quest began to consume more and more of my weekends and weekdays. Electrical engineering lectures, once intriguing, now felt like a burden. I was drawn to the excitement of building and learning new things. This created a continuous battle between my passion for coding and the reality of my academic responsibilities. Finding a balance between these two worlds was a constant challenge.

This era of learning and growth taught me a remarkable superpower: the ability to transform the unknown into the known.
It taught me how to unravel mysteries, turn uncertainty into mastery, and navigate the vast landscape of uncharted knowledge with confidence and curiosity. This skill became my compass, guiding me through every challenge and discovery that lay ahead up until today.

The internship

We can intern in the industry at the end of the third year. However, the company’s interview before the placement is confirmed.
I come from a town 60 km away from Colombo, which was an alien place to me. I went home, got instructions from my sister about this address in a posh area where elites live, and took an early morning bus to attend this interview.

The office’s smell was fantastic, but it also made me nervous. The atmosphere had this posh sense; kids outside Colombo are not used to it. A few batch mates were there with me, ready for the interview. I felt that they had the same mixed bag of feelings as me.

When my turn came, I stepped in nervously. A senior engineer greeted me warmly, and our conversation began. It started with the basics and gradually progressed to more complex questions. This was the moment all those weekends of hard work started to pay off.
The questions made sense, and I could decipher the underlying challenges. I had built and rebuilt these applications countless times, facing failures and learning from them. Those experiences taught me how things could go wrong and, more importantly, how to fix them.

A few days later, the confirmation came to the university — I secured my first internship at a prominent startup in Colombo.
This opportunity opened doors I hadn’t even known existed.
I learned to use Linux properly, moving beyond the click-and-go familiarity of my school days.
For the first time, I discovered version control systems, unit tests (which revolutionised my approach to software development), and the vibrant open-source community. Realising that someone like me could contribute to open source through knowledge, talent, and skills was transformative.
I met many people who are way smarter than me and have accomplished careers. I had tons of things to learn from them.
This internship truly changed the course of my entire career.

The Project

Fast-forward a year. While everyone else was selected to do internal university projects for the final year project, I gathered a bunch of like-minded batch mates.

I pitched the idea of going out there and bringing a project from the industry. They trusted me, so I went to Colombo again and met a few people I knew from my internship. I asked if we could do a collaborative project with them. Few liked the idea since most other universities do this collaborative project.

Every mid-semester, we went to Colombo from Galle. Our task was to present our progress and results to the company’s co-supervisor. We took the early morning train, which lasted about three hours. We showcased our results and discussed the next steps. The return trip to the university was a time for reflection on what went well and what went wrong.

Jobs-Challenges-Learnings

Phase One

Fast-forward another year, and we completed the project successfully. I started my first job as a software engineer at the same company. It was an incredible learning experience.

I learned the art of conducting webinars, grasped marketing fundamentals, and communicated effectively on pre-sales and post-sales calls. I managed releases and navigated crises, tackling challenges that the university never prepared me for but the industry demanded.

Phase Two

The second phase of my journey began when I took my first job in Australia. It was a completely new landscape — the people, culture, working methods, slang, and jokes were different.

Suddenly, I was connecting systems, ensuring security, supporting mission-critical production environments, keeping stakeholders informed, and dealing with other software vendors — all at once.

The challenges were immense. I realised that my knowledge and skill levels in networking and security were below the expected level.

Most of my free time was dedicated to learning and honing my skills. I spent countless hours coding, debugging errors, reading articles, and surfing through Stack Overflow.

I worked eight weekends continuously alongside my team to complete my first project, which was already delayed by 1.5 months. This intense work and learning period was one of my career’s most challenging phases.

Back to Basics

Three and a half years later, at the end of my first job, I realised I needed to challenge myself further to continue growing. My computer science basics were losing their sharpness then, and I was getting bored of solving the same problem in different words, so I took a five-week break to travel through Europe.

Upon returning, I decided to take a two-month break from work. During this time, I dived into “Algorithms” by Kevin Wayne and Robert Sedgewick, brushing up on my fundamentals. I coded data structures from scratch and shared them on my GitHub profile. I learned how to design APIs, build resilient systems, leverage caching, and understand API security fundamentals.

Algorithms” by Kevin Wayne and Robert Sedgewick

“The Pragmatic Programmer” by Andy Hunt and Dave Thomas

“Clean Code” by Robert Cecil Martin

“Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems” by Martin Kleppmann

“Advanced API Security” by Prabath Siriwardana

A few books that helped me develop my skills. This period was still intense; it reignited my passion and strengthened my skills.

Three months later, I found myself in a face-phased digital bank in a team that builds customer-facing APIs. So far in my career, I have only been in the product or deep in the backend.

But here, I worked with frontend engineers, mobile engineers, and user experience designers.

The mindset of my new team was a revelation. They sincerely cared about the user journey, considering how different age groups interacted with our applications.

My colleagues disliked excessive network bandwidth usage and emphasised the importance of graceful error messages for our customers.

Dealing with people’s finances heightened this sense of responsibility, as any issue with their bank accounts was incredibly sensitive. This environment taught me the importance of empathy, precision, and the profound impact of our work on users’ lives. Designing and implementing systems in this environment requires attention to detail. Careful, diplomatic negotiation with stakeholders is a different ball game than coding and building systems.

To learn how to navigate this environment, I started reading

“How to Win Friends & Influence People” by Dale Carnegie

“Negotiate Without Fear: Strategies and Tools to Maximise Your Outcomes” by Victoria Medvec

Bridging Language Barriers

At the same time, I realised that English, being my second language, sometimes made it challenging to communicate my ideas effectively. I could articulate my thoughts fluently in my native tongue, but my English explanations lagged behind.

Reflecting on this, I decided to improve my skills by writing blogs on Medium, focusing on technical content.

This effort paid off over time. I regularly sought feedback from my teammates and managers to ensure my writing conveyed my ideas. This helped me become skilled at writing quality documentation, a skill that most other software engineers need to improve.

The Human Side of Engineering

I learned that to become a truly great software engineer, I must be able to explain complex concepts in simple terms to a general audience.

I must negotiate effectively, understand what is at stake, and be direct yet respectful of technical opinions.

Equally important is investing time and energy in learning how to mentor others and cultivate genuine human relationships.

These skills are essential for personal and professional growth, ensuring that I contribute meaningfully to my team and the broader community.

Bitter Bits

long-hours

Part of the software startup culture involves working long hours, often around 60 hours a week. While this pace suits some, it can be challenging for others. I understand the high stakes and the passion driving this intensity. However, it’s essential to recognise our human limits. Balancing hard work with well-being is crucial; I struggled with this.

on-call

During this time, I began to see the bitter side of the industry. Building systems is challenging, but maintaining them in production is even more complex, which is part of the job. Being on call for the systems you develop is fair since you know them best.

However, many non-software companies would prefer to spend on-call rosters, expecting you to be available on weekends and weekdays. Early in my career, I did this without compensation. As I matured and confident in my skills, I started advocating for fair compensation.

estimates

Most non-software companies value realistic estimates, which is understandable. While having estimates is important, achieving the level of accuracy these companies desire can be challenging.

Estimates, like plans, are rarely perfect, but they provide a necessary framework. Without your input, someone else will make the estimates for you. I estimate incorrectly all the time.

Coding, among other things

Over the years, coding has been a small, albeit important, part of solving problems through software and perhaps the easiest.

The complexity lies in navigating the intricate web of people, processes, finances, regulations, and ethics.

Our work's real challenge and art is balancing these elements within a dynamic market and unpredictable world.

Journey Continues

It has been 13 years since I began my journey as a software engineer in this industry. I have learned an incredible amount along the way, only to realise how much more there is to know.

This field is ever-evolving, and what is true today may be outdated tomorrow. The rise of artificial intelligence signals a shift in this industry. Yet, the complexity of building and maintaining successful production systems continues to grow.

Programming has become more accessible, transforming coding into a routine task. However, the challenges lie in understanding human needs, designing systems that fulfil those needs, managing the people who maintain these systems, and making these systems cost-effective and sustainable.

Even as artificial intelligence advances, the human touch remains irreplaceable. Our ability to empathise, innovate, and solve complex problems ensures our vital role in this industry.

I will adapt and embrace these changes with hope and resilience, knowing my journey is far from over.

--

--

Kalpa Senanayake
Kalpa Senanayake

Written by Kalpa Senanayake

Solutions Architect | Senior Engineer | Cloud | API | System Design

Responses (2)