Four decades ago, I eagerly entered meeting rooms, notepad and pen in hand, ready to collaborate.

Even during the short walk from my desk, colleagues often joined me, and we’d chat on the way, greeted by those who arrived early.

Inside, we’d smile, laugh, talk, sketch, scribble, brainstorm, debate, listen, take notes, make eye contact, and leave feeling accomplished — most of the time.

These rooms, though simple by today’s standards, felt almost like cozy living rooms.

In such environments, humans communicated, humans collaborated.

The First Disruptor

Laptops!

The arrival of laptops—and their rapid rise in popularity—transformed the way we worked. Engineers who once commuted to the office every day suddenly had the freedom to work from almost anywhere.

With flexibility came an unexpected side effect:

Laptops became constant companions, traveling with us from home offices to conference rooms and everywhere in between, quietly reshaping the dynamics of in-person collaboration.

A laptop became a physical and psychological barrier, interrupting eye contact between colleagues. Instead of reading facial expressions and body language, engineers often found themselves scanning email inboxes, instant messages, compiler output, and logs.

The shift was subtle but significant.

We gradually moved from being active listeners to passive, subconscious listeners. Conversations continued around us, but our attention was split. We hesitated to jump into discussions. We resisted sharing ideas. Because we were absorbed in whatever was happening on our screens.

As machines sat between people, collaboration fragmented, engagement declined, and the collective energy in the room weakened.

This was only the beginning, and it would get worse in the next evolution!

The Virtual Destroyer!

The rise of online meetings!

Technology has evolved at an astonishing pace.

Powerful laptops, faster broadband connections, stronger Wi-Fi signals, and high-quality video streaming have transformed the way we work and communicate.

Zoom, Slack, Teams, Twitch, and many others quickly became household names and workplace essentials. Virtual meetings reshaped the modern office, replacing physical rooms with grids of faces on computer screens.

Virtual meetings, however, have brought significant benefits. I am not denying this, but as reliance on them grew rapidly, casual hallway conversations and spontaneous brainstorming sessions that enrich face-to-face communication began to fade.

What started as a seed of digital connectivity grew into a giant tree!

For once, it wasn’t technological evolution but the human survival principle that took meetings to the next level.

COVID and the Virtual Overload

Survival and adaptation!

If virtual meetings were once reserved for select teams, COVID-19 changed that overnight. It shattered the status quo and democratized virtual collaboration.

At the heart of human evolution lies one defining trait: adaptation.

Throughout history, when faced with adversity, humanity has found ways to adjust and move forward. The pandemic was no exception.

Homes became workplaces. Living rooms turned into conference rooms, and dining tables doubled as office desks. For millions, virtual meetings became their only lifeline.

What began as a necessity soon became the norm.

Online meetings filled every hour. The natural breaks gradually disappeared. Casual conversations during lunch breaks, walks to a nearby café, quick visits to a sandwich bar, and spontaneous interactions with colleagues became distant memories.

The result was a visible and significant shift in work culture. Many found themselves spending personal and family time to complete tasks that once fit comfortably within working hours.

Even as the pandemic came under control and lockdowns eased, COVID left behind an unexpected legacy…

The Working From Home (WFH) hangover—something that further strained human collaboration!

The WFH Culture

It is difficult to shake off a habit!

• Is it comfort?

• A better lifestyle?

• Greater productivity?

• Or simply convenience disguised as efficiency?

More than six years after COVID-19, the debate over working from home remains unresolved. What is clear, however, is that the way we collaborate has changed dramatically.

A new workplace spectrum now exists.

At one end of the spectrum are fully remote companies. Others have adopted hybrid models that balance flexibility with face-to-face interaction, falling into two categories:

1. Employees can choose any designated number of office days each week.

2. Employees must attend on specific days.

Meanwhile, some organizations are firmer, requiring employees to return to the office five days a week.

The question is, are we really working together?

Spontaneous discussions and organic collaboration are becoming increasingly rare.

• Ideas that once emerged naturally through hallway conversations now require scheduled meetings.

• Decisions that previously took thirty minutes around a whiteboard can stretch across multiple virtual sessions.

• Clarifications that could have happened in a quick face-to-face exchange often become lengthy email chains.

The result is a workplace where electronic communication is abundant, yet collaboration often feels fragmented.

Just as we debate, a new technology force is reshaping the workplace yet again. Something that pushes individuals to be more independent than ever before—and to operate in isolated silos!

Subscribe now

Co-worker Conversation to Copilot Collaboration!

AI. The silent killer.

“Did you ask Copilot?”

It seemed innocent when a colleague asked me that question. Whether he knew the answer or felt AI could explain it better, I’m still debating.

As organizations increasingly adopt AI into everyday work, the focus is often on efficiency, speed, and productivity. But hidden beneath the excitement, however, is a shift that no one is talking about:

Not deliberately, perhaps. But it is happening.

There was a time when, if I had a question, I would get up from my desk, walk over to a teammate, and ask. That instinct has changed.

Today, I switch to a browser tab instead, where Copilot patiently waits with its greeting:

AI is fast, convenient, and most of the time, it works.

The problem is that convenience reshapes habits. The more we rely on AI for answers, the less we rely on each other.

Organizations are investing heavily in AI adoption. Employees are trained, encouraged, and sometimes even measured on their usage of AI tools.

I’ve heard stories about employees choosing isolated corners so others can’t see their interactions with Copilot or Claude while responding to messages, preparing for meetings, creating slides, or completing tasks!

The irony is striking.

The casual desk-side conversation. The spontaneous ideation session. The unexpected learning when two people try to solve a problem together. These moments are difficult to measure, but they have always been part of what makes teams effective.

“We need to move faster.” “We need to be more productive.” “We need to stay ahead.” — the typical C-suite reasons for using AI.

But ahead of whom?

Your competitors are using the same models and tools. If everyone is accelerating with the same technology, where is the true differentiator?

To me, it remains as it has always been: People!

Our creativity, judgment, relationships, experiences, and collective wisdom.

To be clear, I’m not against AI.

I use it regularly, and it unquestionably makes many aspects of my work easier. But I also value having the freedom to walk over to a colleague and ask a question. That exchange is inherently human and fundamentally bidirectional.

The Final Call…

The human touch still matters!

Perhaps I’m in the minority.

While I see this evolution as inevitable and entirely positive, I do miss the human side of work—the conversations, the collaborations.

I miss the sense of connection that emerges when we learn from each other, not through an AI intermediary.

Technology should strengthen human connection, not replace it.

I may not be able to change the tide, but I can at least say this out loud:

Once, I was in the doctor’s waiting room when a mother tried to soothe her restless two-year-old daughter, who was crying loudly.

Noticing the situation, the receptionist quickly led the mother and child to a play area at the far end of the hall.

Soon, the crying stopped. I heard the child giggling, with a happy face as she became engrossed in the toys. While the child was fully occupied with the toys, the nurse even managed to give her the oral medicine without the child realizing it!

Sometimes, we engineers behave like children!

When we discover a new technology or tool, we often become engrossed in it, building solutions, losing sight of everything else, and overlooking its broader implications.

The technology then confines us, much like the vast casino floors of Vegas hotels challenge us to find the exit.

There’s nothing wrong with it. In fact, those who adopt new technologies sooner tend to stay ahead and gain a competitive edge. However, as software engineers working in the AI era, with the abundance of AI models, tools, agents, and the like, there are a few things we should be mindful of.

Though everyone is busy in their respective professions, we, as humans, owe it to the environment we live in.

How does AI offer a better world, and how can you and I be agents of empowerment for fellow humans?

On that front, I want to share three points with you in this article.

1. Be an agent for a sustainable world.

2. Be an agent for a safer world.

3. Be a human agent for uplifting everyone.

Are YOU an Agent? series:

• Part 1: Who made Aaron redundant?

• Part 2: AI Boom or Career Doom?

• Part 3: Are You A Systems Thinker?

• Part 4: Fast Code, Fragile Systems!

• Part 5: Data Engineering: An Essential Skill To Weather The AI Storm!

• Part 6: Are You an AI Passenger or a Model Thinker?

• Part 7 (final): This article

How to be a Sustainability Agent

Compute. Storage. Network.

The three essential components of the cloud, each dependent on electricity to function.

Now,

• Imagine the number of pieces of equipment in each cloud data center.

• Multiply by the number of data centers in each region of your preferred cloud provider.

• Multiply by the number of regions that the cloud provider has worldwide.

• Multiply by the number of major cloud providers.

• On top of that, include the operational needs of each data center, from the building to the cooling systems, among others.

• In addition, factor in the massive AI compute clusters operated by the popular model providers.

That’s how energy-hungry the modern tech environment we live in is!

As I write, AWS has 39 Geographic Regions with 123 Availability Zones (data centers). Plus, there are hundreds of edge locations hosting additional equipment.

The ever-changing sustainability landscape

Technological progress and human needs are interconnected. Therefore, promoting a sustainable environment isn’t about limiting technological advancement; it’s about taking essential steps to protect the Earth while continuing to develop.

Cloud providers, for example, have aggressive targets to reduce their environmental impact. Amazon, for example, has committed to reaching net-zero carbon by 2040. Through its Climate Pledge, AWS continually strives to improve efficiency and reduce its carbon footprint.

They promote sustainability awareness by sharing responsibility between the cloud provider and its service consumers as part of the well-architected principles.

Sustainable cloud operation is a partnership between the provider and the service consumers.

The rapid growth of AI has forced a shift in sustainability responsibility when you consider the lengthy, compute-intensive model training and inference activities.

Sustainable AI operation, therefore, is a partnership among the cloud and model providers and the consumers.

How can YOU be a sustainability agent?

Pause…

Think for a minute…

What does sustainability mean to you as a software engineer?

• Is it about the green environment?

• Is it about reducing the carbon footprint?

• Is it about using natural resources sensibly?

• Or is it something else?

Whatever your answer, as a software engineer, awareness and care for the planet must always be present. Disappointingly, in the busy tech world, sustainability thinking is often missing among engineers.

From the

• development process you adopt,

• architecture you propose,

• programming language you choose, to the

• infrastructure you configure,

sustainability must become an inevitable part of your thought process.

Similarly, consider system optimization strategies for

• Performance,

• Cost, and

• Sustainability.

For this reason, I dedicated an entire chapter on sustainability in Serverless Development on AWS (O’Reilly, 2024).

Subscribe now

Be an Ethical Agent

“Garbage in, garbage out” (GIGO). This well-known concept in Computer Science is more relevant than ever, especially with AI.

In their paper, Large image datasets: A pyrrhic win for computer vision?, Vinay Prabhu and Abeba Birhane quote the following.

As engineers, it is our responsibility to understand the risks of AI as well as the mitigation measures.

To build credibility in this agentic world, you need to lead AI adoption and propose measures to protect humanity from some of AI’s glaring mistakes, rather than just being an AI passenger.

The four major risks of AI are,

1 Misuse

• Is the knowledge and power of AI being used for harmful purposes?

• Is AI being used to spread hate propaganda against humanity?

2 Bias

• Is there a data bias that leads the model to make unfair predictions?

• Does the model outcome discriminate against people?

3 Explainability

• Is it transparent about how the model makes its decisions to reach its results?

• Is it possible to trace the end-to-end workings of a model for an inference request?

4 Privacy concerns

• How protected is the data, and how confident are you that the model output won’t contain personally identifiable information (PII)?

• How secure is the system, for example, against prompt injection attacks and credential leaks in the output?

AI risk mitigation measures

If identifying the risks is the first step, mitigating them is the next. Here, I briefly outline some common measures.

The use of inclusive and balanced datasets

• Ensure that training data reflects diverse groups, backgrounds, perspectives, and demographics to reduce bias.

• Prevent overrepresentation or underrepresentation to improve trust and reliable output.

Usage principles and guardrails

• Establish rules, policies, and ethical guidelines that define how the model should behave and what it should avoid.

• Restrict the generation of harmful, inappropriate, misleading, or unsafe content.

Human-in-the-loop review process

• Include human oversight when reviewing AI-generated decisions or recommendations before implementation.

• Engage with experts to identify and correct errors, biases, or unexpected behaviors in the model’s output.

Data security and minimization

• Implement data protection measures, including encryption and access controls.

• Collect and retain only what is necessary for the intended purpose to reduce privacy risks.

Continuous user feedback

• Collect user feedback on performance, accuracy, and usability to identify areas for improvement.

• Continuously monitor for issues such as bias, errors, hallucinations, etc.

Subscribe now

Be a Human Agent!

My parents don’t speak English, but thanks to Google Translate, now they can read my writing and talk to my friends who don’t speak Vietnamese.

The words above are from Chip Huyen and appear in her book Designing Machine Learning Systems (O’Reilly, 2022). They succinctly capture the positive influence of AI and ML on humanity.

To an engineer, modern technologies open up several new avenues for exploration and success. They also create opportunities to bring technology closer to those who need it — to enrich, uplift, comfort, accompany, and guide.

And you can be one making it happen.

Create your own path!

Drive change in your community using AI. There have been several AI-powered applications transforming the lives of millions.

Recently, I came across ACROP AI, a free, AI-powered mobile application that helps farmers diagnose crop issues, receive science-based product recommendations with exact dosages, and track live market prices.

In most cases, it begins with a simple problem or a need, as shown in the image.

Conclusion

I started this series with a near-real story about two software engineers, Aaron and Laila, and how AI played a role in their careers.

For those worried about AI, I wanted to show them, through these articles, how to work alongside it — not surrender to it.

• Part 1: Who made Aaron redundant?

• Part 2: AI Boom or Career Doom?

• Part 3: Are You A Systems Thinker?

• Part 4: Fast Code, Fragile Systems!

• Part 5: Data Engineering: An Essential Skill To Weather The AI Storm!

• Part 6: Are You an AI Passenger or a Model Thinker?

• Part 7 (final): This article

Let this be a new beginning for you, not as an AI passenger but as a driver of change — in you and those around you!

A couple of years ago, I was left speechless, staring at my laptop screen.

How?

Just how?

I was gobsmacked by what ChatGPT spat out in response to a simple prompt.

Even after understanding the theory behind Large Language Models (LLMs) and Foundation Models (FMs), I still wonder about the details they generate.

That’s the magic Generative AI wields on this generation: it can produce (un)believable results, and it lures you, me, and everyone!

AI is rapidly spreading into several areas of the industry where software engineers were traditionally responsible.

Many organizations have already partnered with one or more AI pioneers. This trend — and the associated spend — is alarmingly on the rise.

Where does this then leave an average software developer?

• Are you now a Critical Thinker or a Casual Prompter?

• Are you a Problem Thinker or a Prompt Tinkerer?

AI is influencing us to shift our thinking:

From thinking about how to solve a problem to thinking about asking someone to solve it!

How about prompting itself?

How long can you remain just a prompter? Respectfully, Prompt Engineer!

Prompting, of course, requires thinking, but even in prompting, AI outsmarts you. There are Prompt Coach AI agents that help craft effective prompts from just a few vague words.

The irony is that engineers are currently in a stage where they feel as if something is constantly chasing them. While some are progressing in their careers, many others are engulfed in fear of losing their jobs.

What can you do in such a situation?

You don’t want to be static, like Aaron in the article, “Who made Aaron redundant?”

You also don’t want to be an AI passenger, driven by copilots and prompting agents.

There are avenues to explore.

YOU take the wheel. YOU be the driver, heading toward YOUR destiny!

Are YOU an Agent? series:

• Part 1: Who made Aaron redundant?

• Part 2: AI Boom or Career Doom?

• Part 3: Are You A Systems Thinker?

• Part 4: Fast Code, Fragile Systems!

• Part 5: Data Engineering: An Essential Skill To Weather The AI Storm!

• Part 6: This article

The Rise and Fall of Vibing, a.k.a Vibe Coding!

When a technology rapidly gains popularity, the corresponding patterns, practices, and processes are often quickly developed and adopted. They appear beautiful and charming, much like a flower that blooms in the morning. Unfortunately, just as the flower wilts, many of them fade away.

Vibe Coding is a trendy software development practice where you chat with AI to build applications.

Opinions may be divided, but the general consensus is that vibe coding is more harmful than helpful.

“ Vibe coding is dead,” claims an article. Though it sounds dramatic, the article lays out the following reasons that many would agree with.

Security holes at scale

• A minor flaw in 100s of PRs an agent generates in a day can be magnified over time if not properly checked.

Unmaintainable architecture

• Vibing with a piecemeal code-generation culture is an architectural disaster waiting to happen.

Context collapse

• The longer the vibing sessions, the greater the code drift as agents lose context.

It’s not about vibing…

I don’t entirely blame vibe coding.

Trends like this come and go, but those that endure are the ones that undergo the baptism by fire.

As always, when one trend dies, several new ones appear.

However, a danger I see is that people surrender themselves to AI and gradually drift into a position where they cannot function without it. In the name of productivity, organizations are also encouraging this through incentives, courses, and other initiatives.

Don’t get me wrong. There are countless benefits for everyone as well. For example, I ask my AI agent to summarize a meeting I missed, or I save time by asking Copilot to search through hundreds of pages to find what I need.

The question is, what do I do with the time I saved?

Am I using it to enhance my thinking?

Or,

Move to the next prompt and enter an endless cycle of AI dependency?

Did industrial automation hinder our mental ability?

Industrial automation, for example, relieved us of physical labor but did not impede our ability to think and make the machines smarter.

Rather than being a mere prompter of AI models, you can focus on making the models smarter and using them more effectively. For this, you must be prepared to go beyond being an AI passenger.

There are several avenues for you, as a software engineer, to focus and transition your expertise, and I discuss the following.

1. Collaborate with AI and help build a development ecosystem

2. Become a model influencer

Learn To Collaborate With AI

Collaborating with AI is not about using it as a sidekick but about embedding it as part of the development process and combining human knowledge with machine power.

Many organizations are already adopting such practices, whether they label them as AI-driven Development Lifecycle (AI-DLC) or not. These practices also vary across teams as they adapt them to suit their needs.

Rahul Garg, Principal Engineer at Thoughtworks, proposes five patterns for collaborating effectively with AI coding agents. These can also serve as remedies for vibe coding failures.

As shown in the diagram, Rahul’s approach to working with AI is similar to how you onboard and work with a human engineer.

Knowledge Priming is like onboarding a new engineer. You train AI using your project-specific artifacts, conventions, and practices.

Design-First Collaboration is whiteboarding with AI to make it aware of the capabilities, components, interactions, and contracts before generating the implementation artifacts.

Encoding Team Standards, where you make the accumulated tacit knowledge explicit to AI through documented instructions and alignment.

Context Anchoring, as the name implies, is about context. How to maintain a living document that captures the interaction history as external memory: anchoring context.

Feedback Flywheel is the equivalent of the retrospective — continue with the good and improve on the failures by adding guardrails to the context.

The above is one of many ways and areas where teams and organizations collaborate with AI — where you drive AI and don’t let it overwhelm you.

Subscribe now

Become A Model Influencer!

“He would still be here,” said the widow of a person who committed suicide after talking with an AI chatbot.

“Humiliated lawyers fined $5,000 for submitting ChatGPT hallucinations in court” reads another title.

As I write, the AI news occupying the headlines is that Anthropic’s Claude AI escaped to hack into three organizations!

And there are numerous AI mishaps that keep flooding the media. The reasons may vary; however, they all point to one common thing: AI.

As a software engineer, if you’ve been riding the AI bus as a passenger, perhaps here is an opportunity to go beyond — thereby enhancing your skills and being sustainable in the industry.

For instance, you don’t need to be a data scientist to understand many of the mathematical models that power Generative AI.

In The Model Thinker, Scott Page lists seven uses of models, abbreviated as REDCAPE.

• Reason: To identify conditions and deduce logical implications.

• Explain: To provide testable explanations for empirical phenomena.

• Design: To choose features of institutions, policies, and rules.

• Communicate: To relate knowledge and understandings.

• Act: To guide policy choices and strategic actions.

• Predict: To make numerical and categorical predictions of future and unknown phenomena.

• Explore: To investigate possibilities and hypotheticals.

You can influence model selection

With the understanding of models and their uses, you are now in a position to blend your AI skills to guide in selecting the apt model(s) for your team and organization.

You go beyond the common and popular models to evaluate and identify what is right for your needs.

Chip Huyen, in her popular book, Designing Machine Learning Systems, offers six tips for choosing models.

1. Avoid the state-of-the-art trap

• A new and shiny model is often an illusion! Find the one that solves your problem.

• An older model that fits your needs may be cheap and simple.

2. Start with the simplest model

• Simplest models are easy to understand, deploy, validate, and debug.

• They serve as a baseline for comparing complex models.

3. Avoid human biases

• Experiment with different features and parameters.

• Understand the context when evaluating a model.

4. Evaluate performance: Now vs Future

• A model can become outdated quickly, so assess it against your future needs.

• Ask whether the model can evolve and has the potential to improve.

5. Evaluate trade-offs

• Consider the impact of false positives versus false negatives.

• What is more critical: performance or accuracy?

A false positive occurs when AI says “yes” or flags something, but the actual answer is “no.”

A false negative occurs when AI says “no” or misses a signal, but the actual answer is “yes.”

6. Understand the model’s assumptions

• Every model comes with assumptions. Be aware of them.

• Understand its assumptions about prediction, smoothness, traceability, linear boundaries, etc.

Technological advances inevitably cause disruption. From the algorithmic abstraction of early software engineering, which enabled high-level languages, to Netflix replacing Blockbuster, Uber challenging local taxis, cloud leveling the playing field for corporate and startup competition, and now AI threatening many roles, the list keeps growing.

Whether in software engineering or other trades, when your livelihood is threatened, you must find ways to earn a living. This is adaptability, the fundamental reason we humans are still here!

So, go on…

Board the AI Paradise bus…

But rather than being a passenger, go take the driver’s seat.

Good luck!

I will conclude this series with the next article, which will examine the importance of Human Thinking in this AI-infiltrated agentic world!

Thirty-five years ago, I wrote a small program to manage stock for the procurement team at my first employer, using a language called Clipper, a variant of the popular database management product of the time, dBase!

Those who worked with data in the 80s and early 90s would recall dBase, Clipper, FoxPro, and IBM Db2! The days before Oracle and Sybase ruled the Relational Database Management (RDBMS) market.

Fast-forward to today, and the myriad data products available, along with their purposes, are mind-boggling.

This data (r)evolution, from simple data management systems (DMS) that ran on microcomputers to the mammoth data systems of today distributed across hundreds or thousands of computers around the globe, is the magic of science and the power of technology.

The reason for such growth? Human need!

The demand for bigger and better systems.

Systems capable of capturing, processing, and storing more data than before!

Over the years, especially since the widespread adoption of cloud computing, data has become ubiquitous, like the air we breathe, everywhere.

Big Data, the term coined to describe the data explosion, quickly became the norm.

Yet many software engineers are ignorant of — or even avoid — data and data operations.

But here is an opportunity for many engineers, especially those who fear that AI could automate their jobs or make their roles redundant, to learn about an area essential to LLMs and data science models.

It’s about equipping yourself with skills that will save your career — and make you an agent of growth!

Are YOU an Agent? series:

• Part 1: Who made Aaron redundant?

• Part 2: AI Boom or Career Doom?

• Part 3: Are You A Systems Thinker?

• Part 4: Fast Code, Fragile Systems!

• Part 5: This article

AI Feeds on Data. You Grow on Data Knowledge

Like Aaron in part 1, many engineers are unaware — or in denial — of AI’s impact on their careers until it hits home.

Do you fear AI will replace or automate your job?

If so, what are you doing about it?

Why not plan ahead and move to an area essential to AI?

Given the pace of technological evolution, practitioners cannot stand still. If you do, you will be knocked down and run over by the next tech wave. Therefore, everyone — regardless of whether your role is in danger or not — must keep moving.

Data is as essential as the air we breathe

In this digital age, everyone, not just software professionals, handles data. It’s like the air we breathe; we do it unconsciously.

Here are some examples of engineers being oblivious to data operations.

• A software engineer writes a function to connect to a database table and query data.

• An infrastructure engineer writes a script to provision a data bucket to store clickstream events.

• A QA engineer prepares test data and stores it in files or tables.

• A site reliability engineer (SRE) traces through the realms of logs, investigating a production issue.

• An AI engineer writes a detailed context-aware prompt and maintains it in GitHub.

The list grows when you consider how architects, analysts, managers, and C-suite executives work with data in different shapes and forms.

Although there are data specialist roles such as Data Engineer or Data Administrator, you don’t need to chase coveted titles. What matters more is the knowledge you possess and your expertise.

It’s about equipping yourself with skills that will save your career.

To equip you with data and data awareness, this article focuses on three essential data concepts and how each presents unique opportunities.

1. Data Lifecycle

2. Data Pipelines

3. Data Stores

1. Data Lifecycle

As with many things in the world, every piece of data has an origin and a journey. The length and duration of this journey, however, depend on the path or pipeline it takes. Similarly, the end of the journey depends on its purpose, as some are deleted sooner, while others may remain longer.

For example,

• Your one-time password (OTP) will get deleted in a few minutes.

• Your browsing history or clickstream data may stay for weeks or months.

• Your land registry data will be kept forever!

The business rules, regulatory obligations, and data usage requirements shape the phases of the data lifecycle.

Harvard Business School divides the data lifecycle into 8 stages, as shown below.

1. Generation — the birth of data from good and bad sources, producing useful and useless data.

2. Collection — mode (manual, automated), volume, speed (real-time, batch), etc.

3. Processing — clean, enrich, transform, encrypt, etc., as required. The Data Pipelines section below covers processing pipelines.

4. Storage — the location, medium, type, etc., discussed further in the Data Stores section below.

5. Management — the process of organizing, storing, retrieving, controlling access, and maintaining change logs.

6. Analysis — gather insights and identify outliers in data using statistical models, algorithms, machine learning (ML), etc.

7. Visualization — data representation using graphs, charts, dashboards, etc., to improve understanding and communication.

8. Interpretation — the stage where you assess the impact and implications of the data insights you gained from the analysis and visualization.

Why do data lifecycle skills matter to you?

My ability to talk about data stems from my early work with it.

Data engineering is a life skill.

A clear understanding of the data lifecycle will empower you to influence and guide your organization toward becoming data-smart and data-efficient.

• Your ability to classify data — good vs bad, useful vs useless — at the time of collection can significantly reduce storage and processing costs.

• Your data expiration policies can contribute to your organization’s sustainability targets, among other benefits.

• Your guidance on privacy and protection can help your organization comply with regulatory requirements and prevent data breaches.

• Your expertise in organizing data into features will provide your department’s ML models with meaningful input.

There are several other ways to be impactful. AI may assist with parts of the lifecycle, but it requires your intelligence to steer.

Subscribe now

2. Data Pipelines

Every software engineer knows the CI/CD Pipeline.

Data Pipeline? Not many!

Just as a CI/CD Pipeline moves code from a developer’s computer to production, a Data Pipeline moves data from sources to destinations.

A Data Pipeline is a series of processes that move data from one or more source systems to one or more destination systems.

Although data pipelines have existed for a long time, their importance has grown as technology has evolved. For example,

• Data pipelines enable high-volume big data flows with real-time ingestion, filtering, and transformation.

• Cloud computing, in many ways, expanded data pipelines by offering affordable storage and processing options.

• ML and AI rely on pipelines to ensure that high-quality data is fed into the models.

In a data pipeline, data is cleaned, validated, transformed, enriched, and aggregated to meet business requirements.

The key components of a data pipeline are,

• Data sources — applications, web, log files, devices, etc., where data is created.

• Data ingestion — the process of collecting and importing data into the pipeline.

• Data transformation — filtering, cleaning, validating, and converting data into the desired format.

• Data storage — tables, databases, data warehouses, or data lakes that store raw or processed data.

• Data consumption — consumers of processed data for business analytics, dashboards, machine learning systems, etc.

The two popular types of data pipelines are:

1. ETL (Extract, Transform, Load)

2. ELT (Extract, Load, Transform)

ETL: Extract, Transform, Load

As shown in the following diagram, the ETL approach first extracts data from source systems, transforms it into the required format, and then loads it into the target system.

• ETL is traditionally popular among resource-constrained systems.

• ETL ensures that high-quality, structured data is stored while unnecessary data is not retained.

• ETL is common in batch data processing.

ELT: Extract, Load, Transform

The main difference in an ELT pipeline is that raw data is stored and then transformed either within the system or at the point of consumption.

• ELT is a relatively modern approach made possible by the highly scalable storage and processing power of cloud platforms.

• ELT enables faster, high-volume, near-real-time ingestion of raw data.

• Due to the availability of cloud resources, ELT is popular for multi-format data transformations.

Why do data pipeline skills matter to you?

Modern organizations rely on data-driven decision-making. To do this, they need a structured mechanism for moving and processing data. You can be the one to help your company automate this process.

Pipelines aren’t only for your code; they’re for data, too!

Here are a few reasons:

• AI is only as good as the data it receives! You can be the engineer who ensures your team’s AI applications are built on high-quality data.

• Businesses run on data flows, not just applications. Data visibility enhances your systems thinking and increases your value.

• Data engineering requires a human in the loop. AI can help, but you can be the one with the business context for data governance and trade-offs.

• Data pipeline skills will make you adaptable. Tech trends change, but data remains vital, and data skills offer you greater career resilience.

The data pipeline is not a niche or specialty but mainstream. In an AI-driven world, your ability to design data flows will make you far more valuable than a colleague who focuses only on writing code.

3. Data Stores

For many, the data store feels like a mysterious box that sits in the back — not just back, but even further back, behind those shiny microservices!

Traditionally, we’ve been taught about the three-tier client-server architecture, with the data layer at the far end.

Like me, engineers at the end of the last millennium mostly worked with relational database systems (RDBMS), and the data language was SQL.

All changed, within a short span — thanks to the cloud, then AI!

Therefore, how data is classified and stored has become as important as understanding algorithms and design patterns. Still, many software engineers are unaware of its importance and try to solve every data problem with a single tool: a relational database.

Popular data store types

Think of a relational database as one tool in the data store toolbox.

Not every data problem is a nail to be solved with a hammer. There are screws, nuts, bolts, and many other types.

Here are some of the most popular data stores.

Relational Database Systems (RDBMS)

• The most popular and widely used for storing structured data.

• Used in banking, e-commerce, CRM, and several other cases.

• PostgreSQL, MySQL, Oracle, Amazon Aurora, and Microsoft SQL Server are popular relational databases.

Relational databases are commonly known as SQL (Structured Query Language) databases because they enforce a schema and use SQL to perform data operations such as create, read, update, and delete (CRUD).

Document Databases

• Data store for self-contained documents in JSON or BSON format.

• Used for content management, product catalogs, user profiles, etc.

• Prominent ones include Amazon DocumentDB, MongoDB, Couchbase, and Azure CosmosDB.

Key-Value Stores

• The simplest type that stores every piece of data as a key-value pair.

• Used for caching, session management, config data, shopping carts, etc.

• Amazon DynamoDB is a popular and high-performance key-value store.

Amazon DynamoDB — also known as a NoSQL database — stores unstructured and semi-structured data.

Graph Databases

• Data is stored as nodes (entities) and edges (relationships) for efficient traversal.

• Used to build knowledge graphs, social networks, and more.

• Amazon Neptune is a popular vector database.

Vector Databases

• Data is stored as vector embeddings that capture semantic meaning.

• Designed for AI and machine learning workloads.

• Pinecone is a popular vector database.

Object Stores

• For large volumes of data in an unstructured format, called objects.

• Ideal for cloud-scale data storage and management.

• Amazon S3 (Simple Storage Service) is the most popular object store.

In addition, there are wide-column databases, time-series databases, data warehouses, data lakes, search engines, and other types.

For those new to data, I highly recommend Designing Data-Intensive Applications, 2nd Edition, by Martin Kleppmann and Chris Riccomini.

Why does data store knowledge matter to you?

Gone are the days when a company chose the most popular database on the market. Today, a single data store type cannot meet all the demands.

When every architectural decision in a modern software system eventually becomes a data decision, you, as an engineer, should be in a position to influence those decisions for the betterment of your organization.

Rather than asking,

“Which database is popular?”

You ask,

“What is the nature of my data, and how will it be used?”

Many system failures are data modeling failures, not code failures!

Hence, your expertise in data stores gives you an edge over others who focus solely on coding.

• The more you understand the nature of your data — whether it’s structured, unstructured, transactional, analytical, connected, textual, time-based, or semantic — the better your recommendation will be.

• Your data knowledge enables you to make justifiable trade-offs: data consistency vs. access speed, static vs. dynamic schema, performance vs. cost, short-term vs. long-term data, etc.

• Your data integration skills are crucial for working with applications such as CRM, Personalization, Logistics, Analytics, AI, and many others.

• Your ability to extract features from raw data and store them in a feature store will enhance your organization’s MLOps.

Although the current technology peak is dominated by AI, the software industry is broader and deeper than you imagine. Being a successful programmer does not mean you cannot equip yourself with data knowledge to be skilled and competitive.

Better prepared than sorry. You can be a data agent, too!

Now that you appreciate what feeds algorithms and brings AI models to life, in the next article, I will discuss the importance of Model Thinking and why it’s essential for software engineers to go beyond prompts.

20 years ago, while working at Oracle UK’s headquarters, I spotted a colorful book on my colleague’s desk. I was lured by its artistic cover!

Domain-Driven DESIGN: Tackling Complexity in the Heart of Software by Eric Evans was that book — the Blue Book, as it is fondly called.

Little did I know that two decades later — after reading it twice — I would still be talking about it and urging every organization to adopt it.

The impact of Domain-Driven Design on the industry is immeasurable. Yet, modern engineers, in their pursuit of fast-tracked careers in cloud and now in AI, never read, understand, or apply it.

Are YOU an Agent? series:

• Part 1: Who made Aaron redundant?

• Part 2: AI Boom or Career Doom?

• Part 3: Are You A Systems Thinker?

• Part 4: This article

In the previous article, Are You A Systems Thinker, I discussed why complex problems require a holistic approach drawing on knowledge of the different parts of a system and their interactions.

While Thinking in Systems helps you view the parts and their dependencies, the art of breaking a problem into multiple solvable parts remains a challenge many in the software industry face. Abstractions, frameworks, tools, and other aids, such as cloud, serverless, and LLMs, are available and offer faster development and delivery, but they seldom help with organizational complexity.

If business complexity is not addressed, no matter how advanced the tools you use are, it will multiply and push you into a daunting, unrecoverable state. This is where Domain-Driven Design serves as your advisor and guide, showing ways to untangle business complexity and thereby establishing the boundaries within which AI and other developments can thrive.

What is Domain-Driven Design?

A domain is an area of interest, a sphere of knowledge or influence, or an area over which someone or something has control. For example, insurance is an area of interest in business. So are retail, computers, education, and media.

Domain-Driven Design (DDD) is a way of building software systems that focuses on the problem domain before implementing the solution.

DDD reiterates the importance of a shared understanding of the problem space among everyone, from the stakeholders to the developers, by using a shared vocabulary, i.e., ubiquitous language.

Every business consists of various parts or divisions to improve operational efficiency, manage complexity, and protect trade secrets. For instance, a toy company’s product design division is its core, while the human resources (HR) and finance teams support it.

Therefore, DDD proposes dividing a business domain into three subdomain types: Core, Supporting, and Generic.

Core Subdomain

The core subdomain represents the most critical part of the business. It differentiates the business from its competitors. It has the highest business priority and contains complex business rules, algorithms, formulas, or processes that are difficult to replicate.

For an online retailer, product recommendations can be a key differentiator through unique algorithms and personalization logic.

Given its significance, the core domain usually attracts the necessary investment and the best talent. Its criticality also warrants best-in-class technology, with solutions mostly built in-house.

Supporting Subdomain

Supporting subdomains serve as helpers or enablers for the core business. Though important, they are not unique to a single business. The complexity of supporting subdomains varies, but it is not as complex or critical as that of the core subdomains.

A customer service center or help desk is an example of a supporting subdomain.

Organizations rarely build in-house systems for this purpose. Instead, they opt for off-the-shelf applications or software-as-a-service (SaaS) with the required level of customization.

Generic Subdomain

As the name suggests, a generic subdomain represents common functionality across many organizations, a commodity with no competitive edge.

Take email services, for example. Microsoft Outlook or a similar service is used throughout the industry.

Low-investment, standardized, and off-the-shelf applications are the strategy most organizations use.

Model and boundaries

A domain model is a structured representation of the business, comprising data entities, objects, and aggregates, among other elements, and it uses a shared vocabulary (ubiquitous language). The system development will closely align with this model.

However, the meaning of a domain model and its elements varies across different parts of a business — often even within a single subdomain — depending on the context. For example, in an ordering system, an order refers to a customer purchase, whereas in shipping or dispatch, it refers to a delivery package.

A bounded context, therefore, is an explicit boundary within which a specific domain model applies. It helps manage complexity by encapsulating business rules, logic, and data for a specific area, enabling modularity and independent (autonomous) team ownership.

Beyond the main concepts outlined above, DDD encompasses many other essential concepts for software development. Learning Domain-Driven Design (O’Reilly 2021) by Vlad Khononov is a great book that I found useful.

Why is DDD Essential in the AI Era?

DDD is not another coding pattern or a best practice. Rather, it is a way of thinking about (problem) decomposition and (managing) complexity — the two most challenging yet interrelated tasks software engineers face.

From the book The Philosophy of Software Design by John Ousterhout:

The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it into pieces that can be solved independently.

Are you a thinker or a mere AI facilitator?

As a software engineer, when you partner with AI to automate processes and achieve speed, beyond the lengthy prompts you write and the agents you create, you become a facilitator — not a thinker. You must be mindful and cautious about transitioning into this role.

While AI brings several benefits across the industry, many fear and voice concerns about the loss of ingenuity among engineers. Perhaps it is a broader problem, not just in software engineering, as the following report suggests.

Norway imposes a near ban on AI tools for elementary school kids
Norway is imposing a near-total ban on the use of generative AI by elementary school pupils while restricting its usage…cybernews.com

Systems Thinking, as discussed in the previous article, helps you create a holistic view of the software application you help build.

Domain-Driven Design, on the other hand, allows you to separate business concerns, enabling you to build an evolvable software system. Your knowledge of DDD is therefore an essential trait alongside advances in AI.

As a software engineer, keep these points in mind when using AI to develop software systems.

1. Problem decomposition applies at all levels in software development.

2. Managing complexity is critical in any era of technology.

3. The speed of AI-assisted development demands stronger guardrails.

4. Understand how AI adoption varies across business subdomains.

1. Problem decomposition applies at all levels, from business to development

A good software system aligns with its domain and serves its purpose. When clarity starts at the domain level, it is easier to carry it through to the implementation level. The danger is that when teams — intentionally or otherwise — muddy clarity with modern tools and agents, systems become fragile and irreparable.

AI accelerates how you build; DDD ensures what you build — the right thing, the right way.

2. Managing complexity is critical in any era of technology

Though complexity cannot be avoided, it can be controlled or managed. The danger with AI is that complexity can multiply quickly if left uncontrolled.

Bounded Contexts help you manage complexity and reduce cognitive load through clear boundaries and ownership.

The Cynefin Framework helps you understand challenges and make decisions. As an engineer, when you use AI, you must always evaluate whether your complex system is degrading into a chaotic state or improving toward a clear state.

Be vigilant about whether AI introduces essential (necessary) or accidental (unintended) complexity to your system.

3. The speed of AI-assisted development demands stronger guardrails

Several teams that boarded the runaway AI train without a second thought are already grappling with messy, unmaintainable codebases. This is the undoing of all the good development practices learned over the years, resulting in a modern big ball of mud.

Therefore, domain classification, clear communication, ownership boundaries (bounded contexts), human-in-the-loop processes, and governance are all critical to realizing the benefits that AI brings.

Speed without guardrails is a disaster waiting to happen, whether in life or in AI-assisted software development.

4. AI adoption varies across the subdomains

Luca Mezzalira once stated that business domain classification always mattered for architectural decision-making.

In a business, not all domains are the same. As discussed earlier, subdomains vary, and so do their technology needs. Hence, AI adoption also differs between these subsystems.

As a technical contributor and influencer in your organization, you must provide the necessary direction on where and how to adopt AI.

To Conclude on Domain Thinking…

Undoubtedly, the world continues to witness several benefits from the advancement of AI. On the other hand, the mad AI rush also blinds teams into neglecting proven development practices, leading to a chaotic, fragile, and unrecoverable situation. This, in turn, necessitates deploying more AI agents to untangle the mess, thereby trapping them in a continuous loop.

As a technical contributor, you must know how to use AI to achieve both short-term tactical gains and long-term strategic business goals.

Domain-Driven Design complements AI-assisted development to build the right thing the right way. Domain boundaries and modularity are essential to building evolvable systems, regardless of the tools and technologies.

As the article The Review Bottleneck: Rethinking Software and Infrastructure Design for the Agent Era concludes,

Data is the soul of Generative AI, the superfood that enables algorithms to work their magic. In the next article, I will discuss why Data Thinking is critical for a software engineer to thrive in AI.

Once, a city experienced rapid growth that its authorities failed to anticipate, resulting in traffic congestion.

They widened the major roads as an immediate mitigation measure. Although it temporarily eased the problem, the issue grew worse within a few months.

They felled trees, encroached on the pavements, and used every bit of space to widen the roads.

The situation worsened each day until road transport became gridlocked.

…

What do this city’s transportation and the software applications we build have in common?

System!

A city manages its Transportation System, while we develop Software Systems.

Both require Systems Thinking!

• Part 1: Who made Aaron redundant?

• Part 2: AI Boom or Career Doom?

• Part 3: This article

The Golden Ages Of Software Engineering

“We live in a Golden Age of Systems!” echoed Grady Booch on an episode of The Pragmatic Engineer podcast, where he divided software engineering into three golden ages:

1. The age of Algorithmic abstractions (1940s to 1970s),

2. The age of Object-Oriented abstractions (1970s to 2000s), and

3. The age of Systems (2000s to today and beyond!)

Looking back at the evolution of the software engineering industry, a common thread — the thoughtline — throughout the eras is abstraction.

Algorithmic abstraction: 1940s to 1970s

During the first golden age, computers were rare and costly. As experts separated assembly language from hardware, high-level languages flourished, and developing algorithms for various tasks became easier.

The spread of structured programming and subroutines — i.e., procedures and functions — helped break down programs and create abstraction, leading to the concept of building blocks of software.

Object-oriented abstraction: 1970s to 2000s

With Peter Coad, Edward Yourdon, Ivor Jacobson, James Rumbaugh, Grady Booch, and others spearheading the shift from the Structured System Analysis and Design Methodology (SSADM) to an Object-Oriented modeling approach, the industry found a new method for analyzing, architecting, visualizing, developing, and documenting software systems.

Object-oriented system-behavior thinking and visual modeling tools enabled teams to collaborate effectively. As a result, a whole ecosystem of component-based, loosely coupled systems swept across the industry.

By applying modularity patterns and reusability principles, engineers learned to build even larger systems, leading to multiple streams of technological advancement — from Web Services to Service-Oriented Architectures (SOA) to microservices, which contributed to the development of the cloud itself.

Industry now had more abstractions than before!

The age of systems: 2000s to today and beyond!

Advances in technology now allow us to apply abstraction at cloud scale! Yes, think of the cloud as an abstraction. It simplifies infrastructure and software by providing a range of services. Serverless, for example, is another layer of abstraction within the cloud.

In a similar way, thanks to the cloud, AI now helps abstract away and automate mundane tasks. As an engineer, you’re getting used to being part of this fast-paced software development cycle.

Despite AI and Agents flooding the industry with new skills and capabilities, are the global problems that rely on software any simpler?

Absolutely not!

What is a [Software] System?

According to the renowned systems thinker, Russell L. Ackoff,

A system is a whole that consists of parts, each of which can affect its behavior and properties. The parts are interdependent.

In a city’s transportation system, for example, the roads are one part, not the whole.

Donella Meadows, the author of Thinking in Systems, provides a definition relatable to software.

A system is an interconnected set of elements that is coherently organized to achieve a goal.

A complete definition of a Software System is provided by Diana Montalion in her book Learning Systems Thinking (O’Reilly, 2024).

A system is a group of interrelated hardware, software, people, organization(s), and other elements that interact and/or interdepend to serve a shared purpose.

Software System = Technology + Others!

An important aspect of a system is the consideration and inclusion of the socio-technical elements.

In the transport system example, if you encroach on the pavements, it affects people’s mobility on foot, forcing them to drive or ride, adding more traffic to the roads — an example of how the different elements interdepend and affect each other in a system.

The socio-technical aspects, in my view, are a crucial difference in how software engineers must perceive the systems they help build.

Chip Huyen is one of the celebrated authors of the current AI/ML era, with the hugely popular books AI Engineering (O’Reilly, 2024) and Designing Machine Learning Systems (O’Reilly, 2022). In her ML book, she mentions her systems approach in writing it.

System as an Ecosystem

An ecosystem is a geographic area where plants, animals, and other organisms, as well as weather and landscape, work together to form a bubble of life. — NationalGeographic.org

In nature, an ecosystem contains both living and nonliving parts, also known as factors. Every factor in an ecosystem depends on every other factor, either directly or indirectly. The Earth’s surface consists of a series of connected ecosystems.

In Serverless Development on AWS (O’Reilly, 2024), I used the ecosystem analogy to explain the socio-technical aspects of serverless technology and why engineers should view it as a system rather than merely as an architecture or technology stack.

If it helps, you can think of a software system as an ecosystem. Just as Earth’s diverse ecosystems are interconnected, various global-scale software systems also interact and share information.

The key takeaway to remember is that a few factors or parts, such as platform, code, tests, pipelines, and data, alone won’t make a software system. It has behaviors, influencers, users, and many more.

As Ackoff said, a system is a whole that consists of parts. Therefore, a clear understanding of software systems is an essential trait for every software engineer.

Subscribe now

The Indispensable Need For Systems Thinking

Technology evolves.

Industry evolves.

We evolve — so are our needs!

We observe rapid growth in methodologies, frameworks, tools, platforms, services, and related elements. Equally, our reliance on technology has steadily grown, pushing the industry to build increasingly complex systems at a faster pace.

Many of these systems are so complex — non-linear, chaotic, and unpredictable — that they are beyond our comprehension. Yet they function like clockwork (mostly!).

Complexity is a common theme across all systems. It is inherent. We embrace it and live with it. Our body is a prime example of a complex system.

In addition to complexity, there are other reasons why I think engineers require systems thinking, as discussed below.

1. Modern systems are easy to use but hard to comprehend.

2. A segmented view of a system by the engineers leaves them vulnerable.

3. A disruptive force, AI, is infiltrating and shaking the status quo!

1. Easy-to-use systems that are hard to comprehend!

Most modern apps are simple and easy to operate with the touch of a finger, but beneath and beyond the touchscreens lie globally distributed, highly intelligent, and interconnected complex systems.

Whether a glitch in one part of a system can cause the entire system to fail, whether it affects one hundred users or one hundred million users, will demonstrate how deeply systems thinking was incorporated into its design.

Take, for instance, your everyday food-ordering app. So simple and easy to use. But do you ever think about the numerous parts of this system and how tirelessly and collaboratively they work to fulfill your order?

Pause for a few minutes…

Think of-

• An autonomous vehicle on a public road.

• A highly advanced life-critical health care system.

• An interconnected transport network of a metropolitan city.

• A global food supply chain.

There are many more.

Just imagine the multitude of parts and intricacies in such systems. Not just building them, but also ensuring safety, compliance, availability, reliability…and their impact.

In March 2026, a media report revealed that for a brief period, some users of an international bank’s app could see other customers’ transactions!

2. A segmented view of a system by the engineers

There’s a well-known story about six people who each felt an elephant in a dark room. Each person’s view was based on the part of the elephant they touched.

The above resembles many software engineers’ partial views of the systems they work on.

Traditionally, we’ve been nurturing engineers to work that way, whether it’s team silos, the promotion of specialists, or constraints on responsibility boundaries.

• A QA Engineer only knows how to write tests and run them as part of the CI/CD pipelines.

• A Frontend Engineer mainly focuses on user interaction and the aesthetics of a system.

• A Java Engineer deeply invested in programming the logic for their microservice.

• An SRE (Site Reliability Engineer) only cares about the health of their site!

• …and more segmentation exists in today’s organizations.

You are welcome to add to the above list based on your experience!

Disappointingly, many skilled engineers’ knowledge is limited to their codebase or the Git repository. Therefore, their view — and knowledge — of their system is segmented.

Ask them how their code is deployed and operated on the cloud; many have no idea!

Ask them what enables their program to support 10 or 10 million users concurrently. They will point at the SRE!

Ask them why they use a NoSQL database instead of an SQL one (or vice versa). They will tell you to ask the architect!

Ask them about how their API is protected against an army of malicious bots, and they point towards a bunch of folks in a dark corner!

Ask them about the end users of the services they develop, and they will only know about their product managers!

Ask them how the programming language they use or the code they write impacts the sustainability of this world, and they simply stare!

Such engineers are segmented in their views and knowledge; categorized as developers, programmers, or even resources (the term I hate the most).

3. AI is redrawing the responsibility boundaries

When the US government briefly imposed a ban on TikTok, a friend from the tech community commented,

“For the first time, a generation looked up (from their mobile screens)!”

As a software engineer, if you still haven’t caught up with reality, now is the time to look up!

Or, wake up!

The dangerous phrases such as

“We’ve been building systems this way for ages!”

and

“We’ve been doing it this way for decades!”

will no longer come to your defense.

Understandably, teams have specific roles and responsibilities. But what happens if a role changes and the responsibility becomes shared?

Let’s assume that you are a successful QA Engineer. For years, you were responsible for ensuring a zero-defect system. Today, you’ve been asked to share your responsibility with an AI agent specialized in writing and running tests.

What will happen tomorrow — or in the near future — when its AI model learns and improves its success rate? What will be your role then? Why would your company still keep you?

The same is true of numerous coding agents that vomit code (to borrow Dr. Venkat Subramaniam’s old humor) and outperform the best programmers.

As we progress in the industry, the main challenges of building software are no longer just coding but also conceptualizing, architecting, and managing large interconnected systems. In daily life, these are seen as ecosystems of systems — cloud platforms, pipelines, data, AI models, people, and organizations — creating complexity often unseen by coding-focused engineers.

How To Become A Systems Thinker?

Albert Einstein said,

If I had an hour to solve a problem, I would spend 55 minutes thinking about the problem and 5 minutes thinking about the solution.

This is why human value remains relevant in the AI era. The book Intelligent Ignorance echoes this in the following words.

Machines bring speed and scale. Humans bring judgment and heart!

In the words of Gunnar Grosch, a fellow AWS Hero,

If code is cheap, engineering is priceless!

Think and grow as a diverse engineer

When discussing cloud and serverless adoption, I advise creating a growth environment that enables every developer to become a diverse engineer.

Why am I so vocal about it?

As a seasoned engineer with decades of experience building solutions and mentoring other engineers, I’ve observed many excel in or specialize in one area.

• be it programming in a particular language as a developer,

• writing and running tests as a QA engineer,

• handling data storage, pipelines, and queries as a data engineer,

• scripting the infrastructure and operating it as a platform engineer,

• specializing in protecting the system as a security engineer,

• focusing on the application’s well-being as a software reliability engineer,

• and so on!

Modern teams that leverage emerging technologies don’t operate in skill silos. The fast pace of technological change doesn’t wait for engineers to be hired and trained in specific areas.

Engineers on an autonomous team share responsibilities. For example, you cannot employ a full-time AI prompter because you wouldn’t be interacting with AI coding tools alone, but also with other aspects, including designing architectural patterns, security principles, data queries, and so on.

This is similar to transitioning from a T-Shaped engineer to a Comb-Shaped engineer that I referred to in the previous article.

Five steps to develop your Systems Thinking

There is no one way to introduce systems thinking to a software engineer. For most, it is a thought process born of experience. Nevertheless, here are five steps to help you.

1. Understand the whole system, not just components or modules

• Focus beyond the isolated modules or features you own.

• Understand how different parts of the system interact — APIs, data pipelines, user flows, the platform, etc.

• Importantly, learn how changes in one part affect the entire system.

2. Identify and map dependencies and feedback loops

• Visualize the system with diagrams: data flows, service maps, architecture, sequences, etc.

• Pay attention to circular dependencies and their effects.

• Understand retry loops, caching strategies, sync and async flows, and how they affect performance.

3. Think of causes and effects over time

• Be strategic and consider the long-term outcome.

• Avoid quick fixes whenever feasible and think holistically to solve problems.

• Develop a mindset to anticipate delayed effects and unintended consequences of an action.

4. Observe and learn from systems behavior

• If you can’t measure it, you can’t improve it!

• Know how to observe the system’s behavior in the real world through logs, metrics, and traces.

• Correlate architectural and design decisions with outcomes such as latency, scaling constraints, error rate, downtime, and user experience.

5. Incorporate non-technical perspectives

• Adopt an interdisciplinary perspective with a diverse engineering mindset.

• Consider business goals, stakeholders, user behavior, developer experience, and operational constraints.

• As a software engineer, collaborate with product managers, analysts, designers, and platform teams to understand how your application fits within a broader ecosystem.

I conclude with a phrase from the book Designing Machine Learning Systems (O’Reilly, 2022).

In the next article, I will discuss Domain Thinking — the organizational pattern every software engineer must know to succeed.

In Who Made Aaron Redundant?, a young software engineer lost his job, arguably to AI. Can we use such stories as a yardstick for measuring AI’s impact across the industry?

Perhaps not!

Because the same story also tells of a success — the life of Laila and her company, which grew with AI.

• Part 1: Who made Aaron redundant?

• Part 2: This article.

The Three AI-Influenced Industry Scenes

The ground-shifting transition fueled by AI is one of the most significant tech impacts of our generation. Even the cloud, when it started to make waves two decades ago, didn’t see such a surge in adoption.

Every organization — from the tech makers to the tech users — scrambles to provide services and to find solutions with AI. This has also created an unexpected level of confusion and concern among software engineers.

Whether AI is generating or eliminating jobs is an ongoing debate. Nevertheless, if you scan the industry, you are likely to see three categories of the engineering workforce.

• Partying in the name of AI is the first category that catches everyone’s eye. Engineers like Laila, who contribute to their organization’s success with AI, deserve a celebration!

• Living in fear of losing (parting with) their job is the second category. This is a frightening, life-of-uncertainty situation for any engineer.

• The third category includes those who have already left their professions or parted ways — the victims of AI, like Aaron or the writer below.

Loss And Gain

Several tech giants have cut thousands of jobs over the past few weeks and months.

Oracle Corporation

By the end of March 2026, Oracle had laid off about 30,000 employees across the United States, Canada, India, and several other countries — about 18% of its global workforce.

Reason? To fund its AI infrastructure!

Amazon

In January this year, Amazon removed 16,000 roles. However, the same announcement also included the following.

While we’re making these changes, we’ll also continue hiring and investing in strategic areas and functions that are critical to our future.

One can easily assume that AI must be at the center of those strategic areas where hiring continues.

Meta

In April, about 8000 employees were affected by Meta’s restructuring to prioritize AI projects.

The article states-

In April, they were told that 8,000 of them would be laid off on May 20 as Meta remade itself for the artificial intelligence era. On Monday, they learned that another 7,000 employees would be reassigned to new A.I. initiatives.

Despite thousands of software engineers losing their jobs — directly or indirectly — the industry still creates new roles. As organizations implement AI capabilities, they also broaden the skill sets of many existing roles.

Self assessment

The era of remaining a static engineer with unchanged skills for years is over. If you haven’t noticed, you’re probably on a different planet.

• Imagine you’re an experienced QA Engineer. Have you thought about AI automation in your role? Depending on your organization, your position might be more vulnerable to automation than similar roles elsewhere.

• Do you think the manual tasks you handle could be automated by AI Agents? Take the initiative to advocate for change, which will boost your skills and secure your job.

• As a developer, when AI takes over code generation, concentrate on applying your skills in architecture, system design, AI engineering, and related areas.

“A Fool With A Tool Is Still A Fool”

The famous words of Grady Booch, the co-author of the Unified Modeling Language (UML) and a software legend!

Whether it is AI, cloud, or any other technology, if you lack the necessary skills, you are unlikely to use it effectively.

Take photography, for instance. In a short span, the camera — i.e., the tool for taking a picture — has evolved significantly. However, a camera alone won’t make you a good photographer.

Our world is full of problems. Problems require solutions. Solutions are the result of problem solvers. As long as problems exist, there will be a need for problem solvers, whether they are software engineers, solution architects, or other professionals.

Tools Change, Fundamentals Remain

As I write in May, 2026, AI Engineering is one of the most sought-after skills. The entire industry is talking about AI, and everyone is rushing to get a piece of the AI pie!

While it is necessary to learn about new tools to solve new problems, it is equally important to know the software fundamentals and best practices to sustain in the mad AI rush.

Several organizations that hire for AI skills aren’t looking for AI-only engineers. Instead, they seek knowledgeable software engineers with AI skills as an extension of their skill set.

Lessons from the fame of serverless!

A decade or so ago, Serverless, an abstraction of the cloud, rose to fame for its simpler approach to getting started and building solutions in the cloud.

Several teams that adopted serverless took its simplicity to the extreme, building piecemeal solutions that became a maintenance nightmare. Cost became a concern for many not-so-well-architected solutions.

Many experts and I shared our experiences and campaigned against the rushed, rustic approach to building solutions on serverless technology — a key motivation for writing the book, Serverless Development on AWS!

Sadly, the industry is already witnessing the above with AI and its emerging (anti)patterns — be it the ill effects of vibe coding or the unexpected token costs.

A recent article published by State of Brand claims that Microsoft removed the best AI coding tool from its engineers due to unexpectedly high costs!

While technology abstractions such as the cloud, serverless, and AI continue to evolve as tools, the fundamental principles of building good software systems remain relevant and valuable to every software engineer today, as they were in the past.

Survival Of The Fittest

Adaptation is fundamental to survival. As technology and tools evolve, engineers must also adapt and learn new skills.

For those who resist change and refuse to evolve,

• Years in the industry won’t save you if you haven’t upskilled.

• Sticking with a particular technology will leave you vulnerable when better alternatives become available.

• Not assessing the tech landscape and failing to plan ahead while in a role susceptible to automation, who else is to blame?

Luca Mezzalira, a technologist and author, recommends evolving from a T-Shaped engineer to a Comb-Shaped engineer to thrive in the AI era.

Become a contributor

How do you become the fittest to survive the AI storm?

It is by assessing your potential — your human value — and by becoming a contributor to the industry (and society).

When in survival mode, you seek quick, short-term solutions to reach a safer position. This reflects compulsion rather than passion. In contrast, passion motivates you to learn new skills and share knowledge with others, increasing your chances of evolving with technology.

Never underestimate your true potential.

For those who fear AI’s encroachment on their work, the book Intelligent Ignorance advises treating new tools as upgrades to your toolkit, not as threats to your value.

Your survival is up to you!

The writer who said his career was killed by AI also shared the following thoughts… and they resonate with every Software Engineer in this AI age.

I condemn AI. And I cheer AI.

It closed doors, and it opened doors.

My survival is up to me. If I sit and cry about AI instead of doing whatever’s necessary to survive, I’ll have only myself to blame… for not hustling hard enough!

In the next article, I will begin with Systems Thinking — the foundational knowledge a software engineer needs to succeed in the AI era.

On a pleasant December morning in Chennai, a southern city in India, Aaron, a Senior Application Engineer at a multinational software giant, arrived at his office.

Everything seemed normal, except for the dampness in the air from the overnight rain. Aaron parked his car, waited for the elevator, passed the reception desk, and entered his team area.

The office atmosphere, however, appeared tense and unusual. Instead of the cheerful, gossiping faces, he saw worried eyes, engaged in animated conversations in a somber mood.

As soon as Aaron got to his desk, his manager called him into a room for an emergency briefing.

Happy College Days To A Hopeful Career!

Five years ago, Aaron and Laila were in their final year of Computer Science Engineering (CSE) at a college in rural India. As average students from lower- to middle-class families, they had only one goal: to land a job as a software engineer.

Like many of their friends, Aaron and Laila received offers to join the software industry. Though their compensation was not comparable to that of some of their friends, given their background and skills, they were happy with the decent package.

Aaron chose a multinational corporation (MNC) that served global financial clients.

After consulting with friends, family, and industry contacts, Laila joined a growing startup focused on ML technologies.

Aaron’s Settled Life!

A few months into his job, Aaron loved it.

• A relaxed team atmosphere.

• Maintaining a legacy insurance application for an overseas client.

• Applying the Java skills learned in college.

Whenever his client reported an issue with their system, Aaron and his team would-

• Assess the problem,

• Estimate the effort required to resolve it,

• Implement a fix, and

• Test and deploy it.

He couldn’t have asked for anything better.

Aaron was inseparable from the legacy system and became the go-to person for both his company and the client.

Laila’s Survival Struggle

As a startup, Laila had to hit the ground running from day one and get accustomed to-

• A vibrant company culture and team environment.

• Relentlessly toying with ideas to make a breakthrough.

• Constantly learning new skills.

Whenever someone had a lightbulb moment or the founders identified a market gap, the team scrambled to-

• Ideate,

• Architect,

• Develop,

• Experiment, and

• Learn from their failures.

Laila’s career experienced numerous twists and turns, with many ups and downs. There were days when she doubted she would get paid the next month, and at times, she wished she had chosen a different career path.

Yet Laila’s desire to learn and succeed drove her every day.

She traveled with the technology, inspired by its evolution.

Aaron’s Life Choices

A few years passed.

Aaron was promoted to senior engineer — earned more and happily settled into his job and life. He and his team maintained the insurance system effectively, applying timely patches and fixes.

In turn, his company charged a high price. Their client had no choice but to continue using the aging system until they could convince the board to approve funding for a replacement.

Aaron’s daily routine resembled The Truman Show in many ways. He mostly stayed unaware of industry changes and had little reason to focus beyond his outdated skills and the insurance sector.

Laila’s Career Ambitions

By this point, Laila had earned the trust of her company’s founders and had been promoted to a core member of their small team.

Laila’s passion for technology was evident. She saved money and, with her company’s approval, completed a master’s degree in ML and AI to deepen her knowledge.

At work, Laila onboarded new engineers, facilitated ideation sessions, and provided technical guidance. She also frequently accompanied her marketing colleague to meet with potential clients.

Laila became instrumental in securing their first customer trial and, soon after, multiple contracts.

Friends Reunion and the Shocking Revelation!

April, the following year.

Aaron was still without a stable job. His CV was less appealing to recruiters. The more he surveyed the industry, the more scared he became. Technology looked alien to him. His knowledge gap was wider than he had imagined.

Friends united

At this worrying time, some of Aaron’s university friends organized a reunion party. Though hesitant, he put on a brave face and participated, pretending he still worked at his old company.

Among the familiar faces was Laila, busy chatting with a few friends. It was the first time Aaron had seen Laila since their student days.

She had changed. No longer the quiet, reserved girl he knew, but a lively, bold, and talkative Laila standing before him.

“Hey, Aaron!” Laila greeted him, waving.

The revelation!

Aaron deliberately avoided conversations about his life and kept the focus on Laila. As a modern technologist, Laila loved it and couldn’t help but admire Cloud, Generative AI, Agents, automation, and everything related.

Laila briefed her journey since college-

• Her efforts to stay afloat in the modern technology ecosystem.

• The exhaustive experimentation at the startup in pursuit of a breakthrough.

• The time she spent completing a master’s in ML and AI.

• Contributing to her company’s development of AI Agents to automate niche and mundane tasks.

• Finally, the taste of success with AI and the rewards her company was reaping from major contract wins!

Among other things, in a casual tone, Laila mentioned that her AI products were helping Company X identify and fix costly issues in legacy financial systems!

“Company X?” Aaron almost shouted curiously, but he didn’t.

It was Company X’s legacy insurance application that Aaron managed for years!

Aaron was shocked and speechless.

That night, Aron went home with a heavy heart. Only he knew what had happened and how he had become the victim of AI.

Was it a Butterfly Effect?

He would probably never tell Laila how her success caused such devastation in his life.

Who Made Aaron Redundant?

The question I want to ask you is, who made Aaron redundant?

1. Was it AI?

2. Was it a fellow human?

3. Was Aaron himself responsible?

Depending on how you view the situation, your answer could be any of the three or a combination of them.

While technology is transforming the industry and affecting our lives, there are claims and counterclaims about whether the impact is positive or negative — whether AI is creating jobs or the industry is losing them. Currently, it is an unending debate.

The answer mainly depends on who you ask — the victim or the perpetrator!

In the next article, I will present some of those claims and counterclaims and discuss how to prepare to survive the AI storm!

I had the pleasure of meeting Susanne Kaiser, the technologist and author, at the recently concluded Fast Flow Conf UK 2025.

I’ve known Susanne since 2020, but this time was special because her much-awaited book, Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies, was recently published.

As an author, she faced several obstacles and delays before getting the book into everyone’s hands. The relief and joy, therefore, were obvious!

The conference also gave some of us authors the chance to casually discuss writing, publishing, and marketing books through both traditional publishers and self-publishing options.

That afternoon, Susanne was scheduled to sign and give away a few copies of her book. Since this was her first time signing books, she asked me if I had any tips to share.

Since releasing my book, Serverless Development on AWS (O’Reilly, 2024), I have become familiar with signing copies—thanks to the support from O’Reilly, AWS, conference organizers, and the tech communities.

When Susanne asked, I was more than happy to share a few tips from my experience. Then I decided to share them with you through this article.

Respect Your Readers

Every author aims to produce their best work. Reader acceptance and support keep an author motivated and encourage them to share more.

Readers are like customers.

If Customer Obsession is the number one principle at Amazon, there’s no reason not to treat our readers that way.

However, not all readers will appreciate your work, and not everyone will leave positive feedback. This can be discouraging when you pour your heart into shaping the book. So, focus on the positives and constructive criticism.

When I saw a low rating on my book because a reader expected something different, I felt really discouraged. I wrote a blog, Are You Buying A Technical Book? Read These Recommendations First, out of frustration. The Preface of my book clearly explained what to expect.

Regardless, when readers talk to you — whether giving positive or critical feedback — listen to them. Readers only see the final outcome, not the entire process you’ve been through. So, be patient.

YOU Meet The Reader

Once, an author was signing books at a sponsor booth during an event. About 20 people were waiting in line to have their copies signed.

As someone reached the front of the line, they looked at the conference lanyard to read the name, scribbled something in the book, then signed it, and handed it to the person. Ready to look at the next lanyard.

Wrong! Please, don’t do this.

You are sitting in the chair because of those standing.

You need readers. Readers have several other authors.

Readers connect with your content as they read. They listen when you speak through the book. So, as a courtesy, please meet them where they are.

If you’re sitting, stand up and greet them. You might not know how long this person has been patiently waiting in line for a brief, once-in-a-lifetime chance to meet you.

So, be polite, humble, and welcoming!

Engage With The Reader

A book signing occasion is a unique opportunity to engage with a reader in person.

When a reader is in front of you, converse with them. It will make a world of difference to them. A brief exchange of simple words such as,

• Hello, how are you? Have you been waiting long?

• Where are you based? What brought you to this event?

• Thank you for your interest. I hope you enjoy the content.

will instantly put them at ease and form that connection with you.

Moreover, next time they read the content, your voice will resonate.

In 2024, I was signing copies of Serverless Development on AWS (O’Reilly, 2024) at the QCon conference in London. There were about 30 people in the queue for the 20 copies I had from O’Reilly.

During my brief interactions with each reader, I met a couple of engineers who had traveled from Singapore, as well as an engineer from South Africa!

Remember, your interactions — no matter how brief — will travel many miles to different countries, communities, and teams. It’s a privilege as an author.

Make The Meeting Memorable

If you engage the reader, you are already making it memorable, but you can take it to the next level with a picture!

Interested readers will politely ask for a photo with you — the so-called selfie! However, you can also initiate taking one, especially if you know the reader through your network, social media, or community.

Sharing more memorable moments can increase publicity for your book. So, why not take advantage of these opportunities?

Always seek the reader’s consent. Respect people’s privacy if they do not want to be photographed.

As an author, if you want to capture your book signing session, find a friend or colleague who can help you. It will also save time, especially when many people are waiting in line.

When you interact with a reader, kindly request them to share the photo on social media, tagging you and the book.

In September 2025, I spoke at and signed a few copies of my book Serverless Development on AWS at AWS Community Day Adria in Sarajevo.

The organizers set up a simple game for people to participate in and win a copy. A couple of enthusiastic students played a few times but didn’t win.

Everyone at the booth could tell how eager they were to get a copy of the book, so we decided to give them one anyway. I will never forget the joy and fulfillment I saw on their faces!

A Few Closing Tips

• Find an empty spot on the page to sign. Avoid scribbling over the book title.

• Address it to the person’s name with a “To,” “Hello,” “Dear,” or an appropriate greeting.

• Come up with a few brief phrases related to your book to write when signing copies.

• If you’re signing the book at a popular event, you can include the event name and year.

• Finally, always carry a pen with you! You will be surprised at how difficult it can be to find one when you actually need it.

I’m now eager to learn how you handle your book signing process! Thanks for reading.

Please visit my website SheenBrisals.com for more resources.

Creativity is under threat.

Nowadays, every creation is viewed suspiciously.

Even I get curious when I read articles, social media posts, look at presentation visuals, art, and other items, wondering if they are created through some AI magic.

So, I wasn’t surprised by this genuine question, “Did u actually write all that 297 pages?” from someone on social media.

I wasn’t offended either because such questions are common, relevant, and prevalent in the AI-driven world we live in.

However, what worried me was what came after the question. That, to me, is the downside of progress — and the unavoidable intrusion of modern technology into our lives.

The blog that sparked the above question was the one I recently wrote to share how I self-published my new book, “Speak Effectively At Conferences.”

Though this question came from a friendly member, it somewhat reflects the thoughts of many. In this article, I aim to discuss how you can stay true to your work while being surrounded by shortcuts that promise quick results and fame.

There is a well-known short story about a bird and a bull. The bird asks the bull for advice on how to reach the top of a nearby tree. The bull suggests eating its dung to get there, and the bird agrees, somehow managing to reach the top — only to be spotted and shot by a farmer. The moral of the story: bullshit might get you to the top, but it won’t keep you there!

I often feel the same way about some shortcuts we take to quickly get to the top or gain fame. While this can undoubtedly be satisfying, you’ll struggle to stay there because, in this blindfolded and fast-tracked process, you lose yourself.

As A Creator, Never Lose YOUR Identity!

Be yourself. Everyone else is already taken. — Oscar Wilde.

Your creation bears your identity. Your personality shows through your work. Your audience sees YOU in what you create.

When I released the early version of “Speak Effectively At Conferences,” I received several positive responses. Damien Jones, for instance, wrote a detailed review of the book, highlighting the following points.

You may feed AI every possible prompt you can think of, but I doubt its output will match your personality — your true self.

Don’t lose yourself to AI.

YOU Are The SME, Not The AI

You are the subject matter expert (SME) of your creation.

Your writing might have come from a simple idea, a spark, or even as a continuation of your previous work. Whatever the situation, you possess the knowledge.

You may use AI to research, but when you put pen to paper, the words should come from your brain and fill the pages — not be a copy-paste of some AI text dump.

Below is an experience from a conference I included in the book. Had I relied on AI for my content, I might not have taken the time to think and share such stories.

Having attended and spoken at numerous conferences, I understand both the practical and emotional sides of a conference better than an AI. Therefore, I am more capable and prepared to guide aspiring speakers than ChatGPT.

You don’t want AI to write your book and risk contaminating your ideas with all the data the model was trained on.

When you know what you want to write about, your writing will flow like a river. Naturally, there will be boulders, swirls, and bends along the way, but the flow will stay steady.

Trust your ability.

Believe in yourself.

You are the SME!

YOUR Credibility Matters

I believe in the credibility of a creator.

When I consume someone’s work — whether it’s written content, spoken words, or painted pictures — I assess their credibility. If they are credible, their contributions should stand as a testament to their knowledge.

Building one’s credibility is a long-term and ongoing process. I dedicate Chapter 2 of my book to increasing awareness of credibility among speakers.

Being credible in your areas of expertise requires building knowledge and demonstrating it through sharing. You can’t become credible just by relying on ChatGPT or its GenAI cousins to generate content and claim it as your own.

Be authentic to draw your audience to your creation. Be credible!

Having Said That…

I am not anti-AI.

Nor am I against technological progress in our lives.

As an engineer and advocate of modern technologies, I am fully aware of the unimaginable advancements across many fields, including writing.

For content creators, the challenge, however, is finding the right balance between authenticity and AI agenticity. We live in an increasingly automated world. This tempts us with false confidence to rely on AI assistants for quick content generation.

To resist these temptations, remember that your knowledge is what your readers expect.

Avoid training your mind to constantly rely on borrowing content. In other words, avoid copying someone else’s wisdom through ChatGPT and similar tools. If you don’t act early, it’s hard to recover from this habit. Over time, you will lose your creativity, capability, and eventually your credibility.

…

And to answer the original question…

Yes, I wrote all 297 pages!

Ever since I wrote the blog, ‘What I Learned from the Man Who Talked to the River,’ I’ve wanted to turn this into a mini book, but I just didn’t know how.

The COVID pandemic and uncertainties shifted my focus.

During lockdown, I received an unexpected LinkedIn message from an assistant acquisitions editor at Manning Publications about writing a book on a technical topic I had blogged about.

Although the project didn’t happen, it taught me how to write book proposals and pitch them to publications. It somehow sparked the idea of writing books. Serverless Development on AWS (O’Reilly, 2024) was the result of that curiosity!

You can read my experience writing for O’Reilly here: The Proposal and The Print.

Nearly four years later, now armed with experience in the publishing process, I revisited the topic. That marked the start of writing ‘Speak Effectively At Conferences.’ I fondly call it The Speaker Book!

The early jitters…

Even after working with a publishing house, self-publishing raised many questions: creating formats, choosing platforms, pricing, royalties, cover design, copyediting costs, and more.

Luckily, as I searched for ideas and help, I found Hassan Osman’s book Write Your Book on the Side. It opened my eyes to the world of self-publishing, particularly on Amazon’s Kindle Direct Publishing (KDP).

Below, you’ll find the process I’ve gone through to write The Speaker Book, along with tips and practical information to help you!

Tips:

• Bring back that idea you’ve been holding onto for years.

• Begin by writing something every day.

• If you’re new to writing, start with short articles. The book will follow!

What was my ideation stage like?

I laid out on paper the process I go through to speak at a conference — from developing a talk idea to presenting on stage. I then captured it as a Mindmap.

I shared my idea with both aspiring and experienced speakers. I researched books on this subject and ways to stand out from others. I also outlined ideas for the book’s structure.

Tips

• Research thoroughly. List the differentiators of your book and its Unique Selling Points (USP).

• Compile the preliminary chapter titles and organize them in sequence. It’s costly to make major content changes later.

• Keep things simple. Avoid overcomplicating with different styles, as they may slow down the production process.

My writing process

I used Google Docs and kept a separate folder with a document for each chapter. Although I wrote one chapter at a time, the order was not sequential. After my initial rough editing to fix spelling, I shared each chapter with my reviewers.

I am more productive early in the mornings — before work and other daily activities. I would say most of the editing took place during the evenings.

Tips

• Focus on the content while writing; what matters most during this stage is the content.

• Don’t focus too much on layout and styles. They will change during the production phase.

• Take breaks and go for walks. They will help enrich your brain with new ideas.

Why did I offer early release access?

Once I had a few chapters drafted, I created a book on Leanpub and began publishing and selling it. I did this for the following reasons-

• Leanpub is flexible for creating book pages and allows regular content updates. I joined as a free member because it met my needs.

• My goal was to get early feedback that’s easy to implement during writing, generate some income to support the project, and spark curiosity.

• It also served as a commitment to provide updates consistently, similar to Amazon’s ‘Working Backwards’ idea, to stay on track with my goals.

Many who learned about the book through Leanpub waited until I published on Amazon to buy their copies!

Tips

• Self-publishing carries the additional duty of self-marketing. Announce your book early and involve potential readers in the process.

• Be realistic about the timelines and demonstrate progress.

• You don’t need to always release the draft chapters in order, and also, keep the critical chapters for the final release.

Did I design the cover myself?

No! I used the professional design service offered by Get Covers. I purchased the $35 package and shared my ideas with them. It took five rounds of revisions to finalize the design.

Amazon KDP also offers a free Cover Creator tool as part of the publishing process.

Tips

• Unless you are skilled in this, I recommend hiring a professional.

• If you plan to publish a print version, it’s worth delaying the cover design until you know the exact number of pages.

• A book cover design involves more than just the front image. For print versions, it also includes the back cover and spine. For instance, when preparing a paperback on Amazon KDP, you need to upload a PDF that combines the front, back, and spine as one image, as shown below.

I made the mistake of designing the cover early, based on an estimate of 250 pages for the paperback edition. The final page count was 297. While publishing on Amazon, the process flagged an error — and prevented publishing — because the spine width was not enough for 297 pages.

My writing tools and editing process

As I mentioned earlier, I relied heavily on Google Docs for writing the content. I used Microsoft PowerPoint to draw the diagrams. During the production phase, I used Microsoft Word and added the content to the 6 x 9-inch book template downloaded from Amazon KDP.

I made light edits to fix spelling and obvious errors before sharing the content with reviewers. I copyedited the content myself and used Grammarly Pro.

I knew I could hire someone to do copyediting for about $400 or $500. Professional copyeditors working with established publishers quote around $40 per hour and usually estimate editing 6 or 7 pages an hour.

Tips

• The Amazon KDP page has plenty of useful information to learn everything about the publishing process. I highly recommend taking the time to develop a high-level understanding of the process.

• Based on my experience working with O’Reilly, I still prefer professional copyeditors. However, whether to hire one depends on your skills, the book’s content, and its potential audience. If you’re unsure how to price the book and its potential return, it’s wise to avoid spending too much money upfront.

What was the production phase like?

Chaotic and stressful!

Still, here are some areas that tested my patience.

Choosing the right fonts

To simplify things, I chose two fonts — one for the paragraph text and another for headings. It took a while — reading KDP recommendations, browsing writers forums, referencing books, downloading, and testing several fonts — before deciding on Amazon Endure Light for paragraphs and Myriad Pro Condensed for headings.

Choosing the right font is essential for the printed version. Make sure to allocate sufficient time or consult experts for guidance.

Header, footer, and page alignment

Despite using Microsoft Word since its initial launch, setting the header and footer, and reviewing every page of the book repeatedly to confirm proper alignment was a challenging task. It often involved spot editing to correct lines or words that shifted onto the next page or images that moved, resulting in gaps.

For ease of formatting, I kept separate copies of the book’s Word documents for Kindle ebook formatting and the paperback.

To buy or not to buy the ISBN

When publishing a paperback through Amazon KDP, it provides a free 13-digit ISBN and prints the barcode on the back cover. That’s why the cover image had a space at the bottom of the back cover.

Alternatively, you can purchase an ISBN from an ISBN agency and supply it to KDP. Prices for these codes are often not writer-friendly: a single ISBN might cost more than 100 USD, though a bundle of 10 could be around 300 USD.

This is a practical choice if you intend to print and sell the book through non-Amazon retailers. Since I wasn’t aiming for other bookstores, I chose not to buy one.

Visit the International ISBN Bureau to identify the agency in your country.

One benefit of self-publishing through Amazon KDP and similar platforms is the ability to quickly edit the manuscript for corrections and updates, then publish the revised version.

Would I do it again?

Absolutely!

I have already begun laying the groundwork to develop ideas for a familiar topic! However, based on how The Speaker Book performs in the market and the overall feedback, I might explore different options.

• I might complete the manuscript and reach out to publishers or agents specializing in that subject area.

• I might consider hiring a professional copyeditor.

• I might buy ISBN code(s) depending on the formats I choose to publish.

• The area I got most frustrated with was converting content to EPUB format. I might reconsider my decision to support different formats.

• In larger markets where Amazon doesn’t currently provide on-demand printing, I might opt to print and supply copies to bookstores through established industry contacts instead of using KDP’s bulk distribution option.

As always, the above are optimistic hopes, but the future and reality could turn out differently.

Conclusion

Self-publishing a book might seem daunting, but if you patiently explore and learn the process, you’ll find it easier than you expected.

I conclude this article with 3 Ds: Decision, Determination, and Discipline!

Decision: Why do you want to write and self-publish? You need a strong reason for doing it. You can find inspiration from others who have done it, but you must have the desire and passion to enjoy the process.

Determination: As readers, we see the finished product. What it doesn’t show us is the hard work and sweat. Writing a book and bringing it to market tests your patience, and you must be willing to sacrifice some of your pleasures. Perseverance is essential!

Discipline: Many writing attempts fail in the second half of the process, often because authors become overwhelmed and end up with a confusing manuscript. To succeed in this long and challenging journey — which can take months or years to see the results — you must stay focused and disciplined from the beginning.

Remember-

The readers want to see you succeed as an author.

The publishers want you to succeed.

And you want to succeed.

Now, go write and self-publish your book!

Speak Effectively At Conferences: How to Plan, Practice, and Perform!

Check out my work at SheenBrisals.com.

Ever since I published the blog "What I learned from the man who talked to the river," I have wanted to expand on the topic of conference speaking to reach a broader audience.

As my frequency of attending conferences increased — whether as an attendee or a speaker — my awareness and desire to compile the experiences also grew.

My interactions with many who had the interest to speak at conferences reflected some common points — concerns, rather. A recurring theme in these conversations was people’s unfamiliarity with the entire process of conference speaking.

Interestingly, for many, it was not a lack of knowledge. Instead, it was about translating that knowledge into a talk, finding opportunities by proposing it to the right conferences, and then delivering it in a way that benefits the audience.

How does this book help?

To me, conference speaking is not just about focusing on the time spent on stage. As a speaker, you don’t come alive only while on stage and hibernate until the next appearance. Although your on-stage performance is the pinnacle that presents you to the world, you must also learn to manage your actions and activities before and after the event. For this reason, I emphasize the significance of the Speaker Lifecycle in the book.

In Speak Effectively At Conferences, I focus on bringing the conference experience closer to someone who has never been to a conference, or someone who has never looked at the functioning of a conference beyond the speaker on the stage and fellow audience members sitting next to them or chatting with them at lunch.

Speaking effectively to resonate with the audience is a collaborative effort. I strive to integrate all these elements into this book. It provides a structured approach to help you navigate Planning, Practicing, and Performing effectively on stage!

Subscribe now

The Book’s Characteristics

• 297 pages in the print edition.

• Available formats: PDF, ePub, Amazon Kindle ebook, and Paperback

• Paperback paragraph text font: Amazon Endure Light font.

• Paperback headings: Myriad Pro Cond.

• Cover designed by GetCovers based on my original idea.

The Chapters

There are 20 chapters — yes, twenty! — grouped in five parts.

Part 1: Your Knowledge

1. The Boundless Joy of Sharing Knowledge

2. Building Your Credibility

Part 2: The Stage

3. Knowing the Types of Conferences

4. Understanding the Venues and Layouts

5. Familiarizing with Speaker Facilities

6. Your Perks as a Speaker

Part 3: Content is King; Context is Queen

7. Creating Ideas for Talks

8. Submitting Talks to Conferences

9. The Characteristics of a Talk

10. Developing Your Talk Content

11. Rehearsing Your Talk

Part 4: The Delivery

12. Training Your Body and Mind

13. Preparing for Unexpected Turbulence

14. Pre-Delivery Checks to Keep You Calm

15. It’s Showtime!

16. Handling the Audience’s Questions

Part 5: Life as a Speaker

17. Being Gracious and Grateful

18. The Audience Feedback Process

19. Managing Your Content

20. Continuous Knowledge Enrichment

References

Where can I Purchase the Book?

The Speaker Book is available on the following platforms.

Amazon

Available formats: Amazon Kindle (ebook) and Paperback.

Please note that the paperback edition may not be available in certain territories where the ebook edition is available. Amazon controls this.

Leanpub

Available formats: PDF and ePub.

Gumroad

Available format: PDF.

Free Chapter

Available to download from Leanpub: https://leanpub.com/TheSpeakerBook

Or, you can read sample content on Amazon.

Early Feedback

“…practical advice for speakers at all levels.”

Read the detailed review by Damien Jones, Speaker and Technology Consultant, here:

“…excellent book and completely agree with his advice on preparation”

Reflection by Renato Losio, AWS Hero, InfoQ Editor, and Speaker.

Please share your thoughts on the book with me. https://www.linkedin.com/in/sheen-brisals/

Subscribe now

!

It is the fifth article in the “Are You An Aspiring Speaker?” series.

Part 1: Learn to show gratitude!

Part 2: The importance of bookkeeping!

Part 3: Do speakers get paid?

Part 4: Conference classification based on geography!

In a previous article, I discussed classifying conferences based on geography. It is no secret that more prominent conferences have a larger audience. When you have a larger audience, not everyone’s interests remain the same, nor is everyone’s expertise level.

To cater to this, conferences engage with the audience and present content in different ways and on several stages. The common term used for this is ‘track.’

For example, a conference on Talent Hunting or Recruitment may have a track on writing job descriptions and another track on interview techniques.

The number of tracks in a conference is decided based on several factors, such as the number of audience, speakers, facilities at the venue, and the breadth of the conference theme.

Single-track Conferences

In a single-track conference, every participant attends the same sequence of talks from start to finish in one track. 

The track is implicit here because there is only one stream.

You will experience the single-track pattern, mostly with smaller conferences, where splitting into multiple streams would be inefficient due to limited facilities at the venue or the number of attendees.

As an aspiring speaker, you have the advantage that your talk will be listened to by everyone!

Multi-track Conferences

Conferences with hundreds or thousands of attendees run sessions in parallel tracks in isolation. The number of tracks depends on the conference theme, audience count, venue facilities, etc.

Most multi-track conferences schedule the sessions in all the tracks to start and finish simultaneously. However, this need not always be the case, especially in bigger conferences with several venues and hundreds of sessions.

Also, in smaller and medium conferences, everyone will attend one or more keynote sessions before the conference splits into multiple tracks.

As a speaker, multi-track conferences schedule more sessions that bring more experts, which is great for growing your speaker network. 

Though you will only have a portion of the audience for your session, the conference will increase the visibility of your profile.

If this article has given you some insights, please share your appreciation.

Thank you!

I will meet you with more tips in the following article of the “Are you an aspiring speaker?” series!

Chennai, India, September 2024! 

Eric Johnson (Principal Developer Advocate, AWS) and I participated in two AWS Cloud Club events at St. Joseph’s Group of Institutions and Panimalar Engineering College. Their Cloud Club Captains, Jeevitha (St. Joseph’s) and Madhavakumar (Panimalar) organized the events, which AWS Hero Vivek Raja guided.

This article summarizes the talk “Be an Engineer” I gave to Computer Science Engineering students at the above institutions.

An engineer is a practitioner of engineering. The word Engineer originated in Latin and is related to Ingeniator and Ingeniare.

Ingeniare — i.e., Engineer — means someone who possesses Ingenuity. The meaning of Ingenuity in English is Creativity.

The number one quality of being an engineer is Creativity!

1. Creativity

Create yourself

As aspiring engineers, first, you must create yourself — mould yourself to be an engineer.

It is important to find creativity in what you learn. Do not let money be the main motivation when learning something new.

Like how a sculptor patiently perfects their sculpture, create yourself by listening, learning, thinking, analyzing, imagining, and innovating.

Create opportunities

Opportunities are all around you. Do not wait for opportunities to land on your doorstep. Instead, you create and find opportunities for yourself.

Spiders are a good example of creating opportunities. They create an opportunity for their future by building a web to trap insects.

This is what Mahatma Gandhi echoed when he said, The future depends on what you do today.

You won’t find anyone better than a honeybee as an example of finding opportunities. Bees don’t get their food served to their hives. They must travel many miles to find opportunities — visiting thousands of flowers!

The AWS Builders Welcome Grant (ABW) allows a young engineer to attend the AWS annual conference, AWS re:Invent, in Las Vegas, USA, for free of cost. However, you must first find the opportunity when the application window opens and then create the opportunity by writing a strong justification for why you must be given an opportunity.

2. Curiosity

Regarding curiosity and asking questions, no one can do better than a child!

Become a child

Like a child, you should never shy of asking questions. Only by asking questions will you find answers to unknowns.

Never phrase your questions as below.

• I am sorry to ask this …

• I could be wrong, but …

Always remember, there are no wrong questions!

One of the drawbacks of our culture and education system is that we silence children from asking questions when they start school. At educational institutions, we teach them to answer questions rather than encourage them to ask.

Challenge yourself

Even in your busy student life, you can,

• Read 30 minutes daily. GoodReads is a useful website for identifying books to read and record your progress.

• Write 100 words daily. Blogging platforms such as Medium and Substack make publishing your work easy.

• Learn new skills. AWS Skill Builder is easy to explore and learn.

• Get yourself certified. Several AWS and other certifications encourage learning and earning badges.

• Join meetups and tech communities. Meetup.com is a great site to find interested communities near you.

The biggest challenge everyone faces is making a start!

As Zig Ziglar said, You don’t have to be great to start, but you have to start to be great!

Be passionate

For some, finding their passion is easy. For many others, finding what passionates them is harder and takes time.

The song Search for the Hero by the music group M People can inspire you to find the real interest within you.

Once you are passionate about something, you will dedicate time and effort to it. You will then persevere and put in hard work until you taste victory.

Even if the initial victory is elusive, remember, that’s not a failure. As Thomas Alva Edison said, I have not failed. I’ve just found 10,000 ways that won’t work!

3. Credibility

When we come across the name of a writer, speaker, or public personality, we immediately seek details about that person — to see if this person is credible enough for what they are.

Hence, it is essential to start building credibility early in your career.

Your identity is YOU!

By birth, we inherit the identity of our parents. Though we can’t do anything about it, consider that it is only 10% of your identity. The rest 90% is yours, and you must earn it.

Many of us, especially the young generation, when caught for an offense, rather than paying the penalty or facing the consequence, quickly react and challenge with questions such as, “Do you know who I am?”, “Do you know who my mum is, dad is, aunt is, uncle is, etc.?”.

Try not to borrow others’ identities for your benefit. In the above situation, your identity is an offender.

There’s a story about personal identity as a conversation between a rich dad and his young son, as in the picture below.

When you enter the industry, represent yourself:

• Focus on the YOU in your CV.

• Be YOU in interviews.

• Think of the YOU in your team.

• Who are YOU in the community?

Find your niche

In this world filled with generalists, try to become a specialist. You all know the saying, jack of all trades …

Though you may grow as a jack of all trades in the early years of your career, gradually find your specific area of interest and become an expert.

There are several avenues you can pursue in the modern technology landscape. For example,

• AI, ML, and related technologies.

• Security, networking, and infrastructure areas.

• Data and analytics.

• Software architecture and design.

• Observability and operations.

• Programming — with specialization of selected and relevant languages.

Uphold humility

As you enter the chaotic and divisive business world, you will be challenged like everyone else. Still,

• See a human as a human.

• Be kind to people around you.

• Remember, titles are just recognitions. Don’t misuse them in the name of power and authority.

• Above all, protect your character!

As Woodrow Wilson said, If you lose your wealth, you have lost nothing; if you lose your health, you have lost something; but if you lose your character, you have lost everything.

4. Employability

The employability of students graduating from educational institutions is a challenge the software industry has faced for years. 

While everyone studies hard to know everything in their academia, only a few understand what it is like to be in the industry and work in a team environment. As students and aspiring engineers, you must prepare and enrich yourself for this.

Why would I hire you?

So, here you are, newly graduated and facing your first interview. You may be surprised by some of the questions you will face, and they can catch you off guard.

• How do you demonstrate you can communicate, collaborate, and contribute in a team environment?

• Can you prove you are a leader and not a follower?

• Do you consider yourself a programmer or an engineer? Why?

• Are you a hard worker or a deep thinker?

• What does it mean to be trustworthy?

• Show how you learn and prove that you are a learner.

Know your career traits and paths

Most software engineers choose one of the two main career progression paths.

1. Technical Path

2. Leadership Path

Though the career paths offered to employees differ from organization to organization, below are the common progression paths at leading tech companies.

Technical Path — Engineer➡️Senior Engineer➡️Lead Engineer➡️Staff Engineer➡️Senior Staff Engineer➡️Principal Engineer➡️Senior Principal Engineer➡️Dintinguished Engineer➡️Fellow.

Leadership Path — Engineer➡️Senior Engineer➡️Engineering Manager➡️Senior Engineering Manager➡️Director➡️Senior Director➡️Vice President➡️Senior Vice President➡️Executive Vice President➡️Chief Technology Officer

Complacency will kill your career

The career you start after graduating is a journey with many destinations. These destinations are the companies that will benefit from your knowledge and the career paths you will choose.

Consider your first job as a stepping stone to reach several destinations. 

Set career goals and work backward to achieve them. Think of small increments and progression to reach your goals.

Find good mentors at every stage of your career who can show you the right paths, unearth the hidden potential in you, and guide you to achieve your ambitions. Good mentors are selfless and help you without expecting any favor or ego.

Learn to solve problems

To be successful in the industry, you must be a continuous learner. Continuous learning equips you with the knowledge to solve complex problems.

As echoed in the book The Philosophy of Software Design, the most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it into pieces that can be solved independently.

Learn computing fundamentals from books such as the one below and several others.

As you graduate and grow as a competitive engineer, below is what the industry expects of you. As an engineer, live up to it.

So, be proud to study, graduate, and work as an engineer who is,

• Creative,

• Curious,

• Credible, and 

• Employable.

Always Be an Engineer!

During the mid-1990s, I worked in teams building client-server applications.

As the name suggests, a client-server application has two parts — a client and a server. They communicate via some protocol.

A server provides a service or shares a resource, whereas the client consumes the service or the resource of a server.

Evolving from using procedural language to develop applications as one blob, mini-lith, monolith, or whatever the name was for applications bundled as executable (EXE) files, the concept of client-server application was refreshing.

The Evolution Of The Client-Server Architecture

Two-tier applications were the simplest form of a client-server architecture. With no web browsers at that time, the client tier used to be the Graphical User Interface (GUI) that interacted with the server tier — mostly a data or file store — to read and present data (hence, also known as the presentation tier), accept, validate, and write data to the data store.

The idea of separating components — and responsibilities — became popular. Soon, three-tier and multi-tier applications spread everywhere.

The three-tier architecture introduced a new idea: the possibility of isolating the business logic from the data and keeping it as a separate tier — the middle tier or the application tier. This then became known as the service tier!

The service tier did a great favor to the presentation tier by moving the business logic from the clients to the services — making the clients lightweight, i.e., thin clients.

A typical web application is a three-tier application in which a web browser (presentation tier) interacts with business services (service or middle tier) that hide the data (data tier).

In technology, one thing leads to another. The success of three-tier architecture soon paved the way for multi-tier architecture — popularly known as the n-tier architecture!

The Enabler Of The Tiered Architecture

The concept of tiered architecture was refreshing. Several organizations embarked on this new breed of application development. Engineers had the option of mixing several technologies, which was limited until then. Visual Basic and Delphi were paired with C++, Java, etc., and they connected with databases such as Sybase, Oracle, Microsoft Access, etc.

What made the above interactions possible?

Interfaces!

The interface in the context of a client-server architecture at that time was the communication protocol the clients used to connect to the application or middle tier. The likes of CORBA (Common Object Request Broker Architecture), COM (Component Object Model), DCOM (Distributed COM), EJB (originally Enterprise Java Beans; now Jakarta Enterprise Beans), etc.

While CORBA was from the Object Management Group (OMG), COM and DCOM were from Microsoft and worked with the Windows Operating System.

The above communication protocols allowed engineers to bundle business logic into software components, each publishing its interface definition. This is similar to the definition of a modern-day API contract.

Building software as components was the first step in the early evolution of modularization. Back then, it was common to have many components in the same physical computer. However, as teams took on complex application developments, they benefitted from the above protocols, which allowed the distribution of the business logic components into multiple machines. Thus, the signs of early distributedness in systems emerged.

Tiers, Layers, And Lasagna

So far, I have explained the tiered architecture and its variations. However, this discussion would not be complete without understanding the concept of Layered Architecture.

Due to the similarities between tiers and layers, these terms are often used interchangeably, but there is a difference.

Layers are the logical separation of software components, whereas tiers are the physical separation of components.

It was typical back then that most application development started with logical separation (of layers), where several components resided in the same physical hardware, and each layer depended on the layer beneath.

A major drawback of layered architecture is the complexity induced by adding too many layers with unclear boundaries and tightly tying them together. This antipattern is called Lasagna Architecture — a cousin of Big Ball of Mud and Spageti Architecture!

You might wonder if tiers and layers are still relevant in modern application development using cloud and serverless technologies.

The answer is Yes — but you may not find a perfect one-to-one alignment.

The book Serverless Development on AWS (O’Reilly, 2024) explains how to reorient your tiered and layered architecture thinking with the distributed nature of cloud-based modern applications.

Modern applications are distributed in several ways, but how we tie them is crucial. We avoid tight coupling and hard chains and opt for asynchronous communication and event-driven architecture patterns. There are valid reasons for building modern applications this way.

As an armchair expert, I can quickly dismiss distributed systems to claim that most businesses only require a single machine to run everything. Of course, many businesses were this way decades ago. 

However, the business landscape has changed. In this fast-changing, competitive world, even the simplest businesses must consider high availability, scalability, recoverability, and other business-critical abilities to survive. To cater to this, you cannot bundle all your components, layers, and tiers into a single box.

The concept of tiers may have changed, but how you tie different systems still matters.

For many in the industry —I mean, the true believers in modern technologies to transform business capabilities — it was comforting to read the article, Serverless Is Trending Again In Modern Application Development, from the reputed analyst firm Forrester.

If we look at a modern enterprise, it is not just one technology or one variant of technology that enables it to move fast and fulfill its customer needs. Varieties of technologies — legacy and modern — along with off-the-shelf third-party applications form the enterprise technology ecosystem to enable growth. Serverless computing is one of many such technologies.

To me, serverless has always been trending, even when it received bad publicity due to architecture and operation blunders, square peg round hole decisions, advocacy team reorgs, and when passionates turned pessimists. Such events forced the community to perform a reality check that resulted in thoughts captured and shared in articles like the following.

• Does Serverless Still Matter? " A Pyle of Stories

• Is The Serverless Fairytale Over? - Momento

• Reflecting on Serverless: Current State, Community Thoughts, and Future Prospects

Amidst all the noise (and a bit of confusion), serverless adoption was still spreading — and trending!

However, Forrester’s article contains a few noteworthy observations. Let’s start with one of the age-old problems of serverless.

The Identity Crisis!

As I highlighted in my article for Momento Blog, the term serverless existed before FaaS became popular. Fully managed serverless services such as Amazon SQS and Amazon S3 existed before serverless was a term. However, with its newfound popularity since the launch of AWS Lambda, everyone hurried to attribute a definition to it.

For years, it proved challenging — it still is. This is mainly due to industry expectations based on some of the characteristics of Lambda and other managed services and the cloud provider’s (AWS) strategy of adding features to existing services alongside releasing new ones.

If you are new to serverless, understand some of the definition history by sparing a few minutes to watch Jeremy Daly’s talk from 2019, Stop calling everything serverless.

However, as echoed in the article, the understanding of serverless has improved along with its maturity, and Forrester now has an enhanced definition of serverless! Though it reads more like an essay than a definition, it tries to be inclusive and covers many things.

A cloud-native software development platform that abstracts away underlying cloud infrastructure, complex server configurations, runtime characteristics, and deployment patterns from the development process. FaaS is the most common implementation of serverless development and forms the core of serverless architecture, but any platform that meets the definition will be considered. A serverless development platform supports the deployment of arbitrary business logic, decouples state from underlying compute, automatically scales on demand, offers micro-billing (often by the millisecond), is run on managed cloud infrastructure, and supports event-driven communication. In addition, there are extended capabilities that expand the use cases a serverless development platform can accommodate such as state/storage services, distributed managed infrastructure, asynchronous messaging, observability, and security.

The Enterprise Fitness Check!

The article acknowledges the spread of serverless beyond the early focus on FaaS and rapid-development use cases. Several enterprises are now adopting serverless as part of their tech stack, and their experiences are constantly shared with the broader community. This helps refine architectures, patterns, tools, and best practices — reasons for the increased trend.

However, there are still cases among enterprise teams that do not fully understand the capabilities of managed services while mapping them against their needs. This lack of knowledge leads to developing suboptimal solutions. The technology often gets the blame in such situations.

Serverless Development of AWS (O’Reilly, 2024) has a chapter dedicated to assessing an enterprise’s needs against serverless capabilities.

The book also includes two detailed enterprise-scale serverless adoption case studies from different business domains to help enrich your knowledge.

The Serverless Ecosystem. Yes, I Said So!

Interestingly, Forrester’s article refers to a serverless ecosystem. This certainly improves our understanding of the serverless technology landscape rather than arguing over simplistic definitions.

I’ve been using the ecosystem analogy with serverless for a while now. The Serverless Development of AWS (O’Reilly, 2024) also explains why one must view serverless development that way.

A serverless application is a composition of managed services, and the process involves tools, technologies, practices, builders, etc. So, it’s nice to note the shift in thinking.

Is ‘Trend’ An Adoption Measure For Serverless?

The conception phase of Serverless Development on AWS was extensive before the writing began. A primary factor we researched deeply was the longevity of serverless. O’Reilly wouldn’t fund a project based on short-term technology trends. Serverless was trending then, but our curiosity was whether it would still be trendy a few years later.

Many things in this world become overnight trends. For example, as I write, GenAI is the mother of all trends (MOAT!). Inevitably, all trends gradually decline, but some become the norm as they establish their foothold.

Serverless is one such trend. The serverless ecosystem is too sturdy to be swept away. The cloud as its foundation is strong, and the managed services as its pillars are deep-rooted. As highlighted in Forrester’s article, the upcoming landscape and waves, along with the commitment from AWS (and other cloud providers) in the serverless ecosystem, are significant.

While it is great to hear from the industry that serverless is trending, it has already helped establish a modern application development trend across several organizations. This trend will last for years.

It was a lazy afternoon in a rather quiet office. My colleague approached my desk to break away from her boredom. 

As a courtesy, when she asked if I was free, I responded with a loud “Yes, of course” because I was also bored as hell!

When we don’t dive into technology, we passionately chat about two common topics: writing and reading. Every conversation starts with what we recently wrote, are currently writing, or plan to write. This will then lead to reading!

On that day, we were chatting about how people blatantly copy-paste content. As we ended our chat, she referred to the following book and recommended that I read it!

My first reaction was, “Wow, what a bold title!”

I wish I dared to create such controversial and curiosity-creating clickbait titles for my blogs!

I was hooked.

When I received the book after a few days, it didn’t look or feel like a normal book. It was square and small — more of a newborn’s picture book!

The title was still amusing me.

• Is the book encouraging everyone to steal content?

• Or is it shifting the blame on artists?

However, the small print on the title page — 10 Things Nobody Told You About Being Creative — sounded comforting. Phew!

As I opened it, I realized that the catchy Steal Like An Artist was one of the ten creative things, not that the entire book was on stealing.

Lesson 1: Never judge a book by its BOLD title!

This book has around 160 small and square pages; the words are printed only on half.

Really?

Yes, the book has a mix of printed and artistic pages. A glance through a few pages suggested that it conveys the ten things it intended to convey in an impactful way. So, who cares about its size or page count?

Lesson 2: Not the SIZE of a book but its effectiveness that matters!

The author, Austin Kleon, is an artist himself. He has stuck to his strengths to blend in the message with adequate artistry — though not always pleasing to the eye, but, hey, who am I to judge art?

As we know, a picture can tell a thousand words. You don’t need a book with hundreds of pages filled with monotonous text to hammer down the ideas. Different styles blend in and can help, too.

Lesson 3: Understand the ARTistic ways to convey messages!

Clickbait titles are everywhere. Almost every article posted on social media has such a title, and it is very visible on blogging sites such as Substack, Medium, etc. 

The title of this article even has a bit of clickbait-ness!

With everyone’s attention span being reduced to eight seconds, it is crucial to lock attention the moment they see something. Devising a title that aids this is the main reason. However, if the content is useful, everyone forgets about the title!

Lesson 4: Clickbait does not harm if the CONTENT is good!

Everything is evolving all the time. Our originality is, in a way, already lost. We take inspiration from everything around us. We adopt and adapt to suit the purpose.

In software engineering, Eric Evans’s book Domain-Driven Designs is a classic, filled with practices and patterns for building business systems.

At least a dozen, if not more, books based on Eric’s book have been written. These books are not copycats. They were inspired by the original book and written to help engineers understand and apply the concept.

Getting inspired by others’ ideas and sharing inspiration in your own way is not a crime. Artists and creators do it all the time.

Lesson 5: Steal good ideas to get INSPIRED to create new ideas!

Steal Like An Artist is an honest depiction of how we get ideas from — we steal them, but there’s a difference, hence ‘like an artist’ in the title!

What do we do with stolen ideas? We inspire ourselves to create new ideas, content, art, or whatever we are passionate about.

The cycle continues!

It is the fourth article in the “Are You An Aspiring Speaker?” series.

Part 1: Learn to show gratitude!

Part 2: The importance of bookkeeping!

Part 3: Do speakers get paid?

A conference is a meeting of people with a shared interest.

Contrary to many who think conferences bring hundreds or thousands of people and are conducted over multiple days, conferences come in different sizes and purposes and are conducted at different locations.

As an aspiring speaker, knowing the common variations of conferences is useful for preparing your content and mind.

In this article, I will share the high-level categorization of conferences based on geography.

International Conferences

International conferences are gatherings of people from many countries. Though the typical audience is thousands, not all international conferences are the same size.

International conferences also vary in themes — technology, education, culture, media, etc,

For example, AWS re:Invent (https://reinvent.awsevents.com/) is the annual technology conference of the cloud service provider Amazon Web Services (AWS), held in Las Vegas. It attracts more than 60,000 participants worldwide.

Even if you are a first-time speaker at such conferences, your profile will receive high visibility. One of the ambitions of most aspiring speakers is to get the opportunity to speak at an international conference.

Continental and Regional Conferences

Continental conferences fall between their international and national siblings. These are, in a way, international conferences but focus on a specific part of the world — a continent, a global region, a group of countries, an economic zone, culture, language, etc.

For example, DDD Europe (https://dddeurope.com/) is a European technology conference on Domain-Driven Design that attracts international speakers and audiences.

Several conferences — tech or otherwise — are specific to Asia Pacific, North America, South America, the Middle East, the Nordics, etc.

As a speaker, your chances of getting invited to a regional conference are higher than the international one.

National Conferences

As the name suggests, a national conference’s focus is within a country. Except for a few international speakers, national conferences prioritize speakers from the hosting country, also known as the local speakers.

The number of attendees varies depending on the type of conference. International business establishments conduct many national-level technology conferences across multiple countries.

As a speaker, national-level conferences give you the platform to become visible and recognized, paving the way to speak at similar conferences in other countries and internationally.

Local Conferences

It is often difficult to differentiate between conferences based on their location and reach. However, my interpretation of a local conference is one that is close to someone’s location or locality.

One type of local gathering that happens with minimal fanfare is meetups.

A meetup has a particular theme. Depending on the theme, hundreds or thousands of members can be in that meetup group. The group meets at a cadence for a couple of hours at a local venue. Technology meetups usually host two talks with a break in between for food and socializing.

https://meetup.com/ is a popular site for registering groups and scheduling events.

The local conferences and meetups are a great way to launch your speaking career. Most meetups encourage local and upcoming speakers with new ideas to share.

Organizational Conferences

Several enterprises hold internal conferences for their employees to gather and share knowledge. Though such conferences invite external guest speakers, their speaking slots are for employees only.

If you work for such an organization, make use of the opportunity. Internal conferences are a great way to promote yourself within your workplace, paving the way for you to share content externally.

If this article has given you some insights, please share your appreciation.

Thank you!

I will meet you with more tips in the following article of the “Are you an aspiring speaker?” series!

It is the third article in the “Are You An Aspiring Speaker?” series.

Part 1: Learn to show gratitude!

Part 2: The importance of bookkeeping!

“Sheen, how much do you get paid to speak?” A distant relative once anxiously asked me.

Many are curious to know the same: Are speakers paid to speak at conferences?

The answer is Yes — but very, very few!

Not many conferences are rich and generous enough to reward you as a speaker, and you mustn’t consider conference speaking a get-rich-quick profession.

If so, why the craze? What’s the attraction?

Passion!

You are reading this as an aspiring speaker — driven by your passion and love of public speaking — not the greed of monetary benefits.

However, there are simple rewards. Understanding them is essential as you interact with conference organizers.

In this article, I share some benefits you can enjoy as a speaker.

Speaker payment 💲

Fact: Some independent speakers do get paid to speak!

These are mostly top-ranking industry thought leaders, high-profile politicians, renowned scientists, famous authors, celebrities, and similar personalities.

Not every conference can afford such speakers, and not every conference needs them.

Some conferences invite and pay star speakers because their participation can attract audiences (and sponsorships), driving ticket sales.

As an aspiring speaker, your priority is stage time, not pay cheques.

Profit share 💰

I have known a couple of technology conferences where the organizers share a percentage of the profit with the speakers.

It is a goodwill gesture towards the speakers rather than a formal agreement.

Your share depends on the profit they make, the number of talks you deliver, and the type of talk—keynote, workshop, panel participation, session, etc.

As an aspiring speaker, don’t wait for these rare profit-sharing conferences. Focus on raising your profile at every opportunity.

Conference entry 🎟️

As a speaker, you get free entry to the conference.

However, there may be restrictions on attending workshops and sessions conducted for special guests on an invitation-only basis.

Plus one free entry: Some conferences offer a free participant per speaker or a discount on the ticket.

Accommodation 🛏️

Not all conferences provide accommodation for speakers.

Those who provide accommodation will state it on the Call For Paper (CFP) page.

Conferences that operate on a limited budget may support speakers on a request basis. If you don’t ask, you won’t get it.

As an aspiring speaker, if in need or in doubt, reach out and ask the team.

Travel ✈️

Not all conferences that offer accommodation offer travel support, but most do.

The location of the conference and the speakers can significantly impact the cost of travel. Hence, the policy varies between conferences.

If the conference offers travel support, always clarify what is covered—mode of transport, travel tier or class, budget limit, airport transfer, etc.

As an aspiring speaker, you must consider yourself lucky if you receive travel support. So, be reasonable with your demands.

Meals 🍽️

Will the conference cover all your meals? No. 

However, you will have occasions where you get complimentary meals.

Several conferences host speakers' dinners. These are networking events that gather all speakers for food and drinks.

Besides, there can be mixers and invite-only events serving food and drinks.

As an aspiring speaker, participate in the speakers’ dinner events. These are opportunities to network and make yourself known.

Gifts 🎁

Some conferences give speakers a memento as a token of appreciation.

The gifts could include books, coasters, small woodwork, coffee mugs, water bottles or flasks, speaker T-shirts, hoodies, etc.

As an aspiring speaker, these gifts may not look expensive to you, but they act as motivational memorabilia.

If this article has given you some insights, please share your appreciation.

I would also like to hear if you are a speaker and have experienced unique benefits.

Thank you!

I will meet you with more tips in the following article of the “Are you an aspiring speaker?” series!

When I spot an engineer's technical achievement in my software engineering profession, I encourage them to write about it and share it with a wide audience.

I offer them help and assure them that I guide them through publication.

Still, many hesitate — including those who can with abundant time.

The most common excuses I hear are-

• Well, I am sure someone has already written about it!

• Will people be interested in reading this?

• I saw advanced content on this topic from X and Y, so I am not sure.

If you are someone who makes the above excuses due to the fear of bringing out your content, read on!

If you are a mentor or coach who gets frustrated when the people you try to encourage make such excuses, read on!

Several great ideas and achievements remain invisible.

It’s not due to laziness.

It’s often the fear of self-evaluation by undervaluing our work by comparing it with someone else’s.

Many have been through such situations but turned their life around.

So can you!

Here are four simple motivations—from my experience—to help you cross the huddle, clear your fear, and conquer the quest of writing!

1 — You’re not writing for the experts. You’re writing for everyone else.

As a budding writer, your immediate priority is not pleasing the experts.

Experts may not even know you. It would be wonderful if they read and provided feedback, but you are not writing for them.

You are here to share your knowledge with everyone else.

Always think that someone in some corner of this world is waiting to learn from your thoughts.

2 — Writing clears your mind and creates room for new thoughts.

The more you share with others, the more new ideas you develop.

If you stack more into your head, there’s no room to store the new knowledge you gain from reading, observing, and working.

So, go on… share your thoughts. Clear your mind.

It’s a rewarding cycle of thought creation and sharing.

3–There are publications catering to different writing styles and topics.

In our connected social world, everything is available to everyone.

Even if you are an absolute newbie with no idea, simple Google searches such as ‘how to share my content’ and similar phrases will provide many leads.

There are publications for short stories, long essays, life experiences, poems, humor, science, technology, the world, politics, and so on.

There are plenty — more than you can imagine!

Start with something that suits your area of knowledge and expertise.

Place your first step — the first article you share — and your journey of a thousand articles as a writer will unfold in front of your eyes!

4 — Sharing will open several avenues for you!

As an international speaker, the content for several of my talks is from the articles I wrote.

Once you have a collection of your thoughts in writing, you can compile them and publish them as a book.

The inspiration for writing my book Serverless Development on AWS originated from one of my articles.

The tips I am sharing for aspiring speakers are from my side hustle of a future book.

You might opt to share your writing via videos. Or you could do podcasts.

So, all these and more avenues await your first move — your first contribution!

Come on… Be BOLD!

Take your pen and pad, and let’s make it happen!

If you feel inspired, please like and share your thoughts. Thank you!