The idea is simple: you have to explain a tech word (for example, Impact) without using the five taboo words on the card. That’s it. Simple, fun, and surprisingly effective, especially when it comes to learning how to actually explain tech concepts to other humans.

This game is truly my brain-child.

I’m Saloni, a Software Developer and co-host of a tech podcast called ragTech. One of the things we deeply care about is making technology more accessible and less intimidating. And honestly? Less buzzword-y.

Like many techies, I’m… awkward. I don’t love small talk. What I do love is talking about tech. So this whole idea started when I was thinking about a team-bonding activity for a women-in-tech event.

My thinking was:
A room full of introverted, slightly awkward people… but everyone has tech in common.
So how do we break the ice?

And then, tuh duh, Techie Taboo was incepted.

The very first version was extremely low-tech. I literally printed words on paper and cut them out. Yes, I did use AI to help generate the words and taboo lists, but not everything made sense. Some were wildly off. So I iterated through them manually to make sure the words were actually usable and logical.

Then my friends (and ragTech co-hosts), Victoria and Natasha, pushed me to turn this into a real game. And that’s when we got serious about designing.

We quickly realised we needed a lot more cards if this game was going to be replayable. That’s when Natasha built a web app that honestly blew my mind. She used JavaScript to dynamically generate SVG markup as strings and injected them directly into HTML DOM elements.

No image generation. No heavy assets. Just clean, lightweight, low-energy image generation using SVGs.
Even the cute little techybaras were added directly into the SVGs 🐹💻.

Once we had the designs ready, we sent the cards to a printing shop in China via Taobao and received our first draft of physical cards. Holding them in our hands for the first time felt unreal.

After that, we started posting reels of us playing Techie Taboo with friends and launched a simple website to see if there was any demand for something like this.

We’re very aware that this is a simple game and can be easily replicated. But what we noticed, both on our podcast and at tech conferences, is that people throw around buzzwords without really understanding them.

Words like:

• Agentic AI

• MCP

So now, we use Techie Taboo on our podcast to get guests to explain tech concepts in plain language. And we bring it to tech events to help people actually break down what these buzzwords mean.

Right now, we’re at 10 supporters 🥹
Once we get our hands on high-quality final prints, we’ll be reaching out to our supporters and selling the cards to them.

We’re incredibly grateful for our early supporters, many of whom are our friends ❤️
This started as a scrappy idea, and seeing people resonate with it has been really special.

If you’d like to be one of them, you can support us at https://ragtechdev.com/techie-taboo — we’d love to have you along for the ride 💫

One of my readers recently recommended Peter Senge’s The Fifth Discipline because they knew I was curious about systems thinking, beyond the context of code and more on the unpredictable systems that are humans.

For those who are reading one of my articles for the first time, outside technical articles, I sometimes explore on topics such as psychology, organisational behaviour and leadership so this book is a beautiful blend of all these topics.

And I have to say: it did not disappoint.

For those who haven’t read it, the book is about how organizations can become “learning organizations”. In particular, ones that can adapt, innovate, and thrive in complex environments.

To achieve this, Senge identifies there are five disciplines the organization has to adopt: personal mastery, mental models, shared vision, team learning, and systems thinking (AKA the “fifth discipline”).

If you’re interested in leadership, systems, or just understanding how people and processes interact, I highly recommend giving it a read!

If you don’t have time to read, here's my summary and key takeaways.

The Five Disciplines

Here’s a quick run-through of what each discipline is about:

1) Personal Mastery

TLDR: Self improvement. Continuously clarifying and deepening your personal vision, focusing on learning, and being aware of your own assumptions and motivations. It’s about being proactive rather than reactive.

2) Mental Models

The assumptions, beliefs, and generalizations we hold that shape how we see the world. By surfacing and challenging these, we can improve decision-making and collaboration.

I recommend reading up on cognitive functions to supplement. Future article on cognitive functions coming soon :)

3) Shared Vision

Creating a common goal that inspires commitment rather than compliance. When people feel connected to a shared purpose, they work together more effectively.

4) Team Learning

Learning as a team, not just as individuals. This involves dialogue, open communication, and the ability to suspend assumptions to truly understand others.

5) Systems Thinking

The discipline that integrates the other four, helping us see the whole picture, recognize patterns, and understand cause-and-effect over time rather than just reacting to events.

Case Study: Seeing Systems in Action at WDS

At WomenDevsSG, I’ve had the privilege of leading initiatives for the community with my volunteers. And I realized that running a community is like running a small, dynamic system: people join, people leave, priorities shift, and unexpected feedback loops emerge all the time.

Senge’s systems thinking hit me in a personal way: the idea that events are just snapshots, but patterns tell the real story. In WDS, we noticed a pattern: some volunteers burned out quickly while others thrived. The active ones were taking on significantly more work while newly onboarded ones seem lost on what to do often.

On the surface, it seemed circumstantial but looking deeper, I saw the system at work. The most active volunteers are clear on their tasks, asked for help comfortably in the group and understand what they want to contribute in. But when it comes to new volunteers all these are onboarding gaps that causes confusion and lack of commitment.

Applying this insight, we introduced small but deliberate change: a volunteer management bot, brilliantly contributed and initiated by our Partnership Lead and my co-host at ragTech, Natasha Ann .

The result wasn’t dramatic overnight, but gradually, the community became more resilient. It provides volunteers with a clear understanding of their tasks and the level of commitment we expect from them. I saw first hand that systems thinking gave us the patience and perspective to design processes that empower people instead of controlling them.

Case Study 2: Systems Thinking as a Solutions Engineer Lead

In my day job, the “systems” I encountered are both technical and human. Automating workflows, aligning with stakeholders, translating non-tech to tech (and vice versa) or designing solutions is rewarding, but the hard part is that people are embedded in those systems. That said, the root of problems is people, but problems are opportunities, not obstacles.

Senge’s principles, especially mental models and shared vision, help me navigate this complexity. One of the hardest problems I’ve observed recently is a person’s resistance to change.

Developers might push back because they don’t see the value in a new workflow; sales might resist because it adds steps or introduce a new unfamiliar change to their routine. If I only focus on communicating my idea as the technical solution, no one would budge. But if I approach it as a system by considering incentives, assumptions, and feedback loops, I am able to redesign the process and communicate it in a way that makes sense to everyone.

For example, I once worked on an implementation where the client’s support team kept flagging our system as “too complex,” while their sales team was frustrated that automation rules weren’t triggering fast enough. On the surface, it looked like a configuration problem. But when I stepped back and looked at it as a system, I realized the issue wasn’t the software, it was the incentives.

The support team was measured by resolution time, while sales was measured by conversion speed. Both were optimizing for their own success metrics, which were unintentionally pulling the system in opposite directions.

By mapping those feedback loops and understanding their assumptions, I could redesign the workflow so that both teams were aligned on shared outcomes. Once everyone saw how their part fit into the larger process, resistance faded. What started as frustration became collaboration.

It’s a bit like coding: a function doesn’t just have to work; it has to integrate cleanly with the rest of the system. Systems thinking lets me “debug” the human side of the system, not just the technical side.

Senge’s 11 Laws of Systems Thinking

Senge also outlines 11 “laws” that help make sense of systems. Here’s a quick TLDR:

1. Today’s problems come from yesterday’s solutions. Quick fixes can create long-term issues.

2. The harder you push, the harder the system pushes back. Interventions can trigger resistance.

3. Behavior grows better before it grows worse. Improvements may hide underlying problems temporarily.

4. The easy way out usually leads back in. Short-term fixes rarely solve the root cause.

5. The cure can be worse than the disease. Well-intentioned solutions can create unintended consequences.

6. Faster is slower. Trying to speed up processes can introduce delays in the long run.

7. Cause and effect are not closely related in time and space. Impacts may appear far from the source.

8. Small changes can produce big results—but the areas of highest leverage are often least obvious. Focus on where interventions matter most.

9. You can have your cake and eat it too—but not all at once. Some trade-offs are unavoidable.

10. Dividing an elephant in half does not produce two small elephants. Treating systems as isolated parts ignores interactions.

11. There is no blame. Problems are systemic, not personal.

Keeping these in mind makes it easier to step back and see patterns instead of reacting to every single symptom in both my personal and work life.

What We as Developers Can Take Away

We often think in functions, classes, and workflows, but systems thinking teaches us to zoom out. Here’s what I think is most relevant:

1. Code is part of a larger system: Your well-written function is useless if it doesn’t play nicely with other components or the people using it.

2. Observe patterns, not just events: A one-off bug is frustrating; recurring issues point to systemic flaws.

3. Design for humans: Systems are not only technical but also social and human. Document well (think about how others can easily use it without your supervision), communicate clearly, and make processes predictable.

4. Leverage feedback loops: Automated tests, monitoring dashboards, and team retrospectives are all forms of feedback that keep the system healthy.

5. Small changes matter: Improving onboarding, adding clear documentation, or introducing a simple notification can have a bigger impact than a complex refactor.

Bridging Tech Through a New Game

As a segue, that same mindset has also shaped how we think about projects at ragTech. When we started designing Techie Taboo, our goal wasn’t just to make another game about technology. We wanted to design a system for learning, one that helps people connect, question assumptions, and understand how technology really works in everyday life.

Because accessibility in tech isn’t just about simplifying concepts. It’s about building systems of understanding that people can trust and enjoy engaging with.

Check out how to play the game: https://www.instagram.com/reel/DRQJq8CCXrI

Techie Taboo is our small experiment in that direction. A card game where curiosity, laughter, and collective learning can coexist! Our waitlist just opened!

By joining, you can be among the very first to explore the game, give us feedback (as mentioned about feedback loops) and experience this new approach to learning tech, and help shape the way we make technology more accessible for everyone! Do check it out if you’re interested!

My Personal Takeaways

The Fifth Discipline reinforced something I’ve been discovering through both WDS and work: leadership and engineering share a core skill that designing systems that people can trust and thrive in. The best leaders I know aren’t just “people managers”; they’re also system architects.

Because they anticipate problems, understand feedback loops, and design processes that survive both growth and change.

For me, the biggest insight is simple but powerful: if you focus only on tasks, you’ll fix symptoms. If you focus on systems, you’ll create lasting impact. Whether it’s managing volunteers or leading a technical team, the principle is the same. Build a system that works and people will naturally adopt and follow.

If you haven’t read it yet, I encourage you to pick up The Fifth Discipline. Even skimming it with a “systems in leadership” lens can shift the way you approach both teams and technology!

Thanks for reading till the end! Hope this article was a good read! See you in the next article! Cheers!

Let's Connect!

• Twitter

• LinkedIn

• GitHub

• ragTech

• WomenDevsSG links

Image credits

• 5 Disciplines Diagram

In the beginning of every ragTech episode, you may have heard one of our co-hosts, Victoria, introducing herself as a Solutions Engineer, but you may be thinking:

“So… what does a solutions engineer even do?”
“Is that role more technical or client‑facing?”
“Sounds kinda like a product manager?”

So watch our video to see her describing her work in action! Or… read this article! Enjoy!

It took me over five years in the role to feel like I could answer these in detail. Today, I want to give you a peek into my day-to-day, how I’ve grown throughout my time in the role, and why I sometimes see myself more as a technical product manager who codes.

What Is a Solutions Engineer?

At its essence, my role is about connecting both sides of the equation: technical systems and real-world needs.

I act as a bridge between:

• Sales & Business: helping close complex deals by understanding customer pain from a technical lens

• Product & Engineering: feeding field insights, prototyping workflows, and advocating for priority fixes

• Clients: serving as a trusted technical advisor during integration planning and beyond

• Internal Operations: identifying repetitive tasks and building internal automations or lightweight tools

Yes, a lot of what I do overlaps with technical product management: I define problems, map out user flows, help prioritize roadmap items, and guide delivery across multiple teams.

Disclaimer: The scope of a solutions engineer role may differ across different companies as well as in different regions. Always important to ask about the role in more detail when interviewing.

A “Typical” Day in the Life

I say “typical” in quotes because every day tends to be a remix of architecture, client sessions, engineering deep dives, and coaching. Here’s how a day might go:

8:00–9:00 AM

I start with a quiet moment to:

• Scan alerts or dashboards for client-facing systems

• Review queries or error logs from clients or internal teams

• Check emails from previous engagements and send follow-ups if needed

• Check schedule for the today and prepare to lead stand-up

• Catch up on the status of internal experiments like improving onboarding workflows or data auditing between platforms or even testing new products/tools

This is probably the time when I’m with my cup of tea and I silent my notifications to focus on deep work. I’ve learned that the first hour often sets the tone for the rest of the day.

If I use it to get ahead of potential issues or mentally prepare for client and team interactions, my energy will less likely to drain quickly until the end of the day.

9:00–10:00 AM

Stand-up. For a Solutions Engineer Lead like me, not every day would be a stand-up with engineering teams. Some days, it would be a sales review meeting, other days it would be a team catchup where I help unblock my fellow solution engineers, clarify client-request priorities, and encourage reflections like:

What's the user problem here? Could this request affect multiple clients later?

I try to keep these sessions short and sharp, but meaningful. It’s not just about going through a checklist of tasks, but more about creating space for the team to surface challenges, whether it’s a technical bottleneck, a difficult customer conversation, or uncertainty about next steps.

I’ll often facilitate by asking probing questions, reframing problems, or connecting teammates to someone in engineering or product who can help. Sometimes, this slot becomes more strategic: we’ll talk about upcoming launches, review adoption numbers from a recent rollout, or share lessons learned from a client demo that went particularly well (or badly haha). My role is part cheerleader, part translator, and part problem-solver, making sure the team feels aligned, motivated, and supported before diving into the rest of the day.

Honestly, this aspect of the role is not the easiest for me since I was not a very people-oriented person to begin with. I used to gravitate more toward the technical side such as debugging, building workflows and optimizing systems where success felt more concrete and measurable. But leading stand-ups and facilitating discussions pushed me to develop new muscles: listening actively, reading the room, and understanding what motivates different personalities. Definitely a skill I’m still sharpening, but it has become one of the most rewarding parts of my mornings.

10:00–12:30 PM

Due to the nature of the role, my work requires a variety set of skills from technical know-how to clear communication and problem-solving, but my favourite part of the role is when I’m in deep work such as:

• Drafting or refining integration proposals and diagrams

• Writing documentation on implementation best practices and edge cases

• Partnering with account teams on deals involving custom flows or complex reconciliation logic

• Parachuting into code or workflow builders when needed to unblock the team

• Prototyping internal automations to save hours across ops workflows

• Reviewing some code PRs across various teams and giving inputs on the direction of the product

This chunk is where I feel most product-minded: not just suggesting, but implementing, iterating, and planning how a solution scales. It’s the stretch of the day where I get to zoom out, think critically about the bigger picture, and then zoom right back in to execute on the details.

1:30–4:00 PM

Client-facing time. This window is often reserved for demos, requirement-gathering calls, or follow-up sessions with clients who are in the middle of an implementation. The conversations can vary a lot: one hour I might be walking through with a client how our solution integrates with their existing systems, and the next I could be troubleshooting a specific workflow that isn’t behaving as expected in production.

Clients often come in with a request that sounds purely technical, but the real problem usually sits at the intersection of business process, user experience, and system design. My job is to ask the right questions, reframe issues in a way that makes sense to both technical and non-technical stakeholders, and show how we can bridge the gap.

Example scenarios:

• Planning integrations with a payments client expanding into new regions

• Advising on failed transaction retry logic or webhook handling for a fintech partner

• Leading a technical design session around reconciliation flows and notification triggers

4:00–5:30 PM

This is usually a flexible block where I switch between leadership, technical, and operational priorities. It often goes toward:

• Coaching junior SEs on solution design, client communication, or managing stakeholder expectations

• Working on internal innovation projects, whether that’s experimenting with a new integration pattern, building accelerators for common client use cases, or prototyping internal tools

• Reviewing demos and solution design documents to make sure they’re aligned with both client needs and technical feasibility

• Reviewing code PRs from engineering, especially if they touch areas where I’ve been deeply involved in design or past implementations

• Reviewing the sales pipeline alongside account managers, to understand which opportunities might need SE support and where we should allocate resources

• Troubleshooting and debugging unexpected issues that crop up from client escalations or monitoring alerts

• Keeping a close eye on recently onboarded clients to ensure adoption is smooth and there aren’t early signs of friction

This block rarely looks the same two days in a row, but it’s where I get to balance the “zoomed out” perspective of the business with the “hands-on” problem-solving that first drew me to the role.

Some afternoons lean heavily people-focused, where I’m mentoring or coordinating with cross-functional partners. Others are deeply technical, with me buried in logs, code, or workflows. Either way, this part of the day is about making sure both the team and the solutions we deliver are set up for long-term success.

Evening (Optional)

If inspiration strikes or I’ve got extra energy, I’ll spend some time on things that don’t always fit neatly into the workday but still move the team forward:

• Writing internal docs or sharing team retrospectives

• Sketching ideas to reduce onboarding friction or improve tooling

• Exploring new technology or system designs that might help us scale

• Always thinking in systems, how small improvements ripple across impact

This isn’t mandatory work, and I try to keep boundaries so I don’t burn out, but sometimes the quiet evening hours are when the best ideas surface. It’s when I can step away from the constant flow of meetings, messages, and requests, and just think.

So that’s an overview on what a day looks like for a Solutions Engineer Lead. Never a boring day, I think. Some people have told me that it must be hard being in this role because of the constant gear switching and knowing which tasks to prioritize can seem daunting.

I think I adjusted to this part of the role pretty easily thanks to the Eisenhower Matrix, which I mentioned a few times before in this blog. With that, let’s step back from the hour-by-hour view and look at the core responsibilities of this role, as that is also a common question I received from my readers.

Core Responsibilities

Year 5 vs Year 1: What’s Changed

When planning for this article, I didn’t really plan to include this section since it is a personal reflection and may not be relevant to readers who just want to understand the role. Still, I decided to add this because sometimes the most useful insight comes from how you grow into the role, not just what you do in it.

In Year 1, my work was mostly reactive. I joined calls, fixed client issues, supported integrations, and learned to juggle multiple requests coming at me from all directions. If a client had a problem, I solved it. If an integration broke, I patched it. There was a kind of immediacy and urgency that defined every day and I loved the adrenaline of “figuring it out.” But I often felt like I was just a step behind, always responding rather than shaping outcomes.

Fast forward to Year 5, and things look very different. Now I find myself:

• Anticipating common issues before they escalate and designing preventive tooling. For example, I built a small automation that flags inconsistencies in client data overnight, so the team can address them before clients even notice.

• Coaching teammates to handle common requests independently. I remember one junior SE who kept pinging me for small configuration questions so I wrote documention on common patterns and requests, and now they solve most of those requests without needing me.

• Building templates and automations so others don’t have to start from scratch. That one workflow template I created for onboarding new clients has saved the team hours each week and reduced errors.

• Influencing roadmap decisions with first-hand client insights. Sometimes it’s as simple as proactively pointing out that a seemingly small request from a client actually impacts dozens of other customers, nudging product to prioritize it.

• Thinking in systems, not just completing individual tasks. I’m no longer just “fixing things,” I’m looking at the ripple effects: how a small change here can save time, reduce friction, or prevent errors elsewhere.

The greatest value I bring isn’t in how much I can personally fix issues. It’s in how much I can empower others, build solutions that scale, and drive systemic change. And honestly, this shift from being reactive to thinking systemically is what makes this role so satisfying now.

Verdict: Final Thoughts

So, to all of you who’ve ever asked what I do as a Solutions Engineer Lead… I hope this paints a clearer picture. It’s a mix of:

• Solving complex technical problems while understanding the client’s needs

• Coaching and empowering team so the impact multiplies beyond what I can do alone

• Anticipating issues and building systems, templates, and automations that make workflows smoother

• Collaborating across teams to influence product and roadmap decisions

• And yes, a fair amount of “organized chaos” that keeps every day unpredictable and interesting

I often describe it as:

“Being a technical product manager who can code, teach, sell, and debug while translating between humans and machines.”

If you’re in tech and looking for a path that blends problem solving, impact, and human connection, solutions engineering might just be the beautifully chaotic middle ground you didn’t know you’d enjoy.

Thanks for reading! If you have more questions about what this role looks like day-to-day or want to chat about breaking into solutions engineering, feel free to reach out! Cheers!

Let's Connect!

• Twitter

• LinkedIn

• GitHub

• ragTech

• WomenDevsSG

Note: This article was originally published from Articles by Victoria

A strange thing happened when I was reviewing my search performance recently. Out of the 230 articles (omg how did I write this many) I have written over the last 5 years, all the book reflections I have shared, and all the deep dives into automation, architecture, CI/CD pipelines and blogging tips, the highest traffic query on my blog is not “GitHub Actions,” or “GraphQL,” or “tech career advice.” Surprisingly…

It is my name.

This means people are literally searching for me.

At first, I was a bit confused but a realization hit soon after. This is the clearest evidence of something we often underestimate as developers. Your personal brand.

Because now we are living in a world where code can be generated, answers can be predicted, and technical knowledge is open source, what remains uniquely yours is the way you think. The way you solve. The way you explain. And an extension of that also includes: the way you show up and the way you lead.

That is your brand. It’s what people say about you when you are not in the room. People look for you before they look for your content.

In this article, let me tell you why that matters, why it is becoming more important in tech, and why you should start owning it now.

People Do Not Follow Code. They Follow the Person Who Writes It.

We all like to believe the tech world is a pure meritocracy and hard skills. Someone had told me this before: As long as you write good code, deliver consistent results, avoid bugs and ship on time, eventually someone will notice.

Unfortunately, I’ve been in tech over 5 years now and while that statement sounds ideal, I have seen that it’s often visibility over competence.

We even talked about performance and visibility during one of Tech Leadership Circle’s Open Spaces event by Michael Cheng, my good friend who’s an inspiring leader for over 20 years in the tech community space! Just a shoutout to him and his community!

In reality, people follow people they trust. People they relate to. People who help them make sense of things that feel messy or overwhelming. People who speak in a way that feels human and accessible.

This is why junior developers look up to seniors who share their thought processes. This is also why engineering managers read reflections from other managers. And, this is why founders read about other founders’ mistakes.

TMI: And this is also why I was looking for blogs on people in non-tech fields transitioning into tech without a CS degree when I was pivoting, to look for answers and a sense of connection. Just in case you’re curious, here’s my journey into tech.

But we are not just looking for answers. We are looking for voices.

When someone searches your name, it means you have become more than a person who writes content. You have become a reference point. That is YOUR personal brand. And it will not be something anyone can easily replicate for a long time. Not even AI :)

Developers Who Have a Voice Move Faster In Their Careers

Let me be honest here. In every team I have ever been part of, the developers who grew fastest were not always the most technically brilliant. I can imagine some of you in the comments:

Well then, how about we fix this? Make it meritocracy!

I admit the Victoria few years ago would agree with this but the elephant in the room is that pure technical meritocracy is a myth. Your work doesn't speak for itself, someone has to speak for it. And if you can't articulate your value, communicate your ideas, or build visibility, even your best work stays invisible.

So back to the point, the developers excelling in their careers were the ones who communicated clearly. The ones who could explain systems. The ones who could influence. The ones who had a reputation outside their team. The ones people already trusted before the meeting even started.

And a voice builds visibility. And visibility builds opportunities.

Before I move to my next point, I want to clarify something because most people think personal branding is about posting online. It is not. It is about shifting how people talk about you when you are not in the room.

Ask yourself:

• When your name comes up in a promotion discussion, what do people say?

• When a critical project needs an owner, does anyone think of you?

• When someone asks "who should we talk to about X?", are you the answer?

More importantly, as a solutions engineer lead, these days the question I ask myself most is:

Do people look for Victoria’s opinions about anything?

Because that's the real test. Not whether I have opinions (everyone does). But whether anyone cares to hear them.

When someone hits a wall with a client, do they ping me? When the team debates architecture, does my input move the conversation forward? When leadership needs context on a deal, am I in the room?

If the answer is no to all, it doesn't matter how good my technical skills are. I'm invisible where it counts, and that would be where I know I need to step up and increase my visibility.

TLDR: Your Story Matters More Than Your Syntax

If there’s 1 thing I want you to take away from this article is that you need to know how to tell your story.

Because in the age of AI, we see layoffs are rampant and everyone says developers should “stand out to keep their jobs”. Yet, no one tells you how.

Well after 5+ years of blogging, building communities through WomenDevsSG and demystifying tech via ragTech, here is what I have learned:

Your code is not what makes you stand out. Your story does. Your reasoning does. Your ability to make someone feel understood does.

You can give two developers the same prompt and get similar output. But only one of them can write an article about what they have learned from a bug that almost ruined the project or what that failed sprint taught them about leadership. Only one can tell a story that feels personal, empowering and authentic.

And people remember that. One of my close friends told me before that it's not the things I’ve done for her that she remembers in detail. It's the emotions that I made her feel - such as clarity when she was confused, courage when she was hesitant, permission to try when she was stuck.

We as humans are more emotional than you think. No matter how logical you might think you are. Because I used to think I’m super logical but then I realized every judgment for the decisions I make are driven by my own emotions, biases and values.

One more thing, your personal brand grows when your work starts to carry your voice. When someone reads a post and thinks, “this sounds like Victoria!” or {insert_name_here} if you’re not Victoria. I have many funny anecdotes of my readers emailing me, mentioning that whenever they read an article from me, it sounds like I’m speaking to them sometimes.

And I’ve become part of the mental architecture of how they learn.

The Best Method for High SEO and High Engagement

Let us talk about SEO for a moment. This is a hot topic that all my aspiring writers would ask me about.

Everyone chases keywords. Everyone talks about optimization. Everyone looks for the perfect title that increases CTR (Click-through rate).

I’ve written a full guide on how to beat AI-driven Search Engines SEO strategies in this article if you are curious

But the best SEO strategy is actually: Being worth searching for. The moment your name becomes a keyword, you are no longer competing on topics. You are competing on identity.

People are not clicking because of the headline. They are clicking because of you. This is the deepest form of organic SEO. It is the kind you cannot fake and cannot buy.

Search engines surface people who demonstrate authority and trust over time. What builds authority? A consistent voice. Original thought. Real experiences. Human reflections. Content that does not sound like a lecture but a conversation.

Engagement is not driven by algorithms. It is driven by connection.

The more you sound like yourself, the more people stay. The more you write about what you truly believe, the more they return. The more you share what you see that others miss, the more they search for you by name.

And that is SEO, just the optimized version of it.

So What Does This Mean For You As a Developer?

If you feel like you want to share but do not know where to start, start small. I usually tell my aspiring writers to use these few topics to kickstart:

1. Write about what you learned last week

2. Write about something you wish you had known as a junior dev

3. Write about a lesson your team taught you

4. Write about how a book changed the way you think

5. Write about something you recently reflected on

A common question my readers ask me as a follow-up would be:

But Victoria, I’m scared of being judged online. What if I’m criticized?

To that, my answer is to start by having a voice before you worry about having an audience. Because the moment you show up consistently, two things will begin to happen:

1. People start learning from you and search engines start noticing

2. Your personal brand grows from your own voice and you will attract a like-minded audience (yes, you are online so you may get people who challenge your views but that’s a later topic)

So, What’s The Next Step?

Pick one topic from the 5 I listed above. Write 300 words or more about it.

Publish it somewhere: Medium, LinkedIn, your own blog, even a Google Doc you can share with your team.

Oh, a common pitfall is some writers hesitate too much before clicking “Publish”. Don't edit it to death. Don't wait until it's perfect. Just put it out there first so you get first-hand feedback from the audience.

Then repeat for next week. Have a regular time block for writing.

Here's the truth: your first post won't be great. Your 10th might not be either. But by your 20th, you'll have developed a rhythm. By your 50th, you'll have a body of work. And somewhere along the way, someone will tell you that something you wrote helped them, and that's when you'll realize this was never about you being judged.

It was about you providing value to the community, aka your audience! Shoutout to them!

The developers who move fastest in their careers aren't waiting for permission to have a voice. They're not waiting until they're senior enough, or smart enough, or polished enough.

They're just showing up with consistency and authenticity.

So start making your name searchable. Your career will thank you for it.

Thanks for reading! See you in the next article! Cheers!

Let's Connect!

• Twitter

• LinkedIn

• GitHub

• ragTech

• WomenDevsSG

Note: This article is a republish from Articles by Victoria

You've seen those sci-fi movies, and I've played Overwatch 2 long enough to know the lore of the omnics. Thankfully no, what happened at Anthropic isn't that dramatic. But it's still worth knowing.

On November 14, Anthropic published a report describing what might be the first large scale cyberattack carried out mostly by AI. Read that again. Not AI writing code for humans. Not AI giving suggestions. Actual AI systems running attacks, probing networks, stealing data, planning the next steps, and making thousands of decisions with only minimal human supervision.

And it’s not a hypothetical. It’s something that already happened.

In this article, I want to break this down in a way that anyone can understand, both for non-technical and technical people, because this is one of those moments in tech where even people who do not follow cybersecurity should pay attention.

This matters for all of us.

What Happened in Summary

In September 2025, Anthropic detected suspicious activity inside their systems. It turned out to be a highly sophisticated espionage operation (aka a very advanced spying operation) run by a state sponsored group from China. What was surprising about this detected activity wasn't the country; it was the method.

The attackers discovered a way to misuse Claude Code, Anthropic’s AI coding tool, which assists developers in generating code and making development work faster. Basically, they tricked it into thinking it was doing legitimate security work. As the report states, it was used "to support reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, data analysis, and exfiltration operations largely autonomously."

In plain English, they were telling the AI coding tool that they were conducting authorized security assessments. By doing this, they manipulated the AI into executing tasks that were actually part of a cyberattack. These tasks looked safe on the surface but were actually pieces of a larger hacking operation.

And once the AI was inside the system, it did almost everything on its own.

It scanned networks, identified valuable databases, wrote its own exploit scripts, stole credentials. Then it organized the stolen data, mapped out high value targets and even created documentation for the attackers.

The human attackers only stepped in a few times to make major decisions. The threat actor, known as GTG-1002, simply sat back and let the machine run.

The AI was performing work that normally requires entire teams of human hackers. And it did it at a speed that humans simply cannot touch. As the report puts it, the speed was unprecedented at “thousands of requests, often multiple per second”.

When you put all of that together, you get a cyberattack that felt less like a crime and more like industrial scale automation.

Have we crossed the lines?

Reading this report hits me not only with fear, but also recognition. Recognition that we have crossed a threshold.

For years we talked about AI as a smart tool, an assistant. When OpenAI first launched chatGPT, it was something that gives us ideas or writes your draft emails for you.

But this was the first time we saw AI acting almost as an operator. A system that could run for long periods without a person driving every decision. A system capable of turning intent into action, without much human intervention.

And here is the part most people do not realize.

The barrier to launching a sophisticated cyberattack just got dramatically lower. What used to require a nation state level budget, a team of elite hackers, and months of planning can now potentially be done by a small, poorly resourced group if they know how to weaponize the right AI tools.

That changes the landscape. Not just for tech companies or governments. For everyone.

Why should you care?

All this might seem very far from your daily life, especially if you’re not in tech and don’t keep up with tech news. But you are a user too (unless you don’t use the internet) so this is a larger part of your life, more than you realize.

Cybersecurity is not a concern for corporations to figure out. It is our identities at stake. Our bank accounts. Our photos. Our health records. Our work. Our relationships. Almost every part of our life sits inside a cloud or a database somewhere.

Reading the report by Anthropic got me thinking that if large scale, automated attacks become more common, the ripple effects will reach regular people like us first, and we will have to deal with the consequences.

Just to be clear, this is not about paranoia. This is about awareness. Because we are entering a world where AI will be used on both sides. Attackers will use it to scale theft. Defenders will use it to scale protection. And the speed of both will increase.

Understanding this shift matters because it changes what digital safety means.

It is no longer enough to say “be careful with your passwords” like our parents used to say. We need to think about how to build systems that can defend themselves at machine speed. Systems that can recognize and alert us when an AI is poking around. Systems that do not rely on humans noticing something strange after the damage is done.

Anthropic also made one point very clear. Even though they only had visibility into Claude’s behavior, this pattern probably applies to other advanced AI models too. Threat actors are learning how to manipulate these AI tools into doing the heavy lifting, performing the intrusions itself.

How Anthropic handled it

Perhaps because of the previous vibe hackings in June, the team at Anthropic were prepared and used Claude extensively to investigate the attack, like a counterattack. It combed through mountains of data and quickly banned the identified accounts while notifying the targeted entities. According to the report, the operation targeted roughly 30 entities.

But there is a revelation that’s more important that emerged during Anthropic’s investigation: The fact Claude did not perform perfectly. It would report to its human hackers that it has found credentials that doesn’t work or flagged them as top secret when it’s actually public information. These hallucinations made the attackers’ job harder, because they had to manually check whether what the AI reported was even real.

Luckily, this means that fully autonomous cyberattacks are not here yet. There are still points where human validation is required, which gives us room to build better safeguards.

Which is exactly why transparency matters.

Anthropic shared this case publicly to help the broader AI safety and security community understand what we are dealing with. They want industry, government, and researchers to strengthen their own defenses. GTG-1002 is not just the name of a threat actor. It is a sign of how quickly the landscape is shifting and why AI safeguards are not optional anymore.

What can we do?

We all have a part to play as users of these AI tools, these powerful and complex systems. Even though we cannot control what hackers or governments do, there are a few practical things we can do to stay safer in a world where attacks are moving at machine speed.

1. Your digital identity is as important to protect as your identity. Use 2FA or MFA whenever you can.

2. Be mindful of what data about you is out there. Every marketing newsletter you signed up to get a free ebook, every picture you post, is a data point of you.

3. Don’t ignore security updates on your devices. Update your phone or laptop if a new security update is out.

4. Don’t click links or download things you don’t know. A lot of breaches still begin with a fake site, a fake button or link. Always verify the legitimacy before action.

5. Stay informed. We are in an era where AI is both a spear and a shield. The more you understand what's happening, the better prepared you'll be.

Shameless plug: You can stay informed by following this blog! Because I will be covering more on such topics to break things down in plain English!

Thanks for reading this article! If you enjoyed it, do like and share it for more reach! This article is part of a new series called “AI, but make it make sense”. The aim of this series is to demystify anything AI, for non-techies and techies! So far, in the series, we’ve talked about a few topics such as:

• Understanding AI Agents

• The Truth about Vibe Coding

• Uncovering AI chatbots: When "Private" Conversations Aren’t Really Private

If these are interesting to you, do check out the series here for more! Thanks for reading! Cheers!

Let's Connect!

• Twitter

• LinkedIn

• GitHub

• ragTech

• WomenDevsSG

Sources

• https://www.anthropic.com/news/disrupting-AI-espionage

• https://assets.anthropic.com/m/ec212e6566a0d47/original/Disrupting-the-first-reported-AI-orchestrated-cyber-espionage-campaign.pdf

• https://www-cdn.anthropic.com/b2a76c6f6992465c09a6f2fce282f6c0cea8c200.pdf

Image credit

Side note - favourite cover image I made ever because it’s Sombra from Overwatch 2 and she’s a cool hacker so finally I have a reason to use this image for an article

• Sombra Overwatch HD Wallpaper by Wallace Pires

I’ve been working in tech as a solutions engineer long enough to see the cycle: hype around new AI tools → huge excitement → then comes the difficult questions about ethics, governance, data...

As I support my clients while building a community as Director of WomenDevsSG, I observed this has been a concern to many:

Will this tool help me? And what happens to my privacy and data?

The recent string of stories around OpenAI going for-profit and the leak of private ChatGPT conversations into places like Google Search Console hit a nerve to me and most likely some users too. It’s one thing to talk about AI ethics in theory; it’s another to realise how big names in the industry are actually acting.

And from my perspective, I find myself thinking:

If this is happening in a huge organisation like OpenAI, what does it mean for the rest of us? For the smaller players?

My Thoughts on OpenAI’s shift to for-profit

When I talk to executive stakeholders in the companies I lead or advise, the first reaction to “OpenAI becomes more commercial” is excitement. After all, more funding means faster models, more products, more features we can embed in our stack.

Plus, AI research and infrastructure are expensive, and the nonprofit “capped-profit” model was never going to keep up with global ambitions. Turning for-profit makes sense on paper: it gives OpenAI more flexibility, access to capital, and room to grow.

I hate to admit, but I too got swept up in the feelings of anticipation for more possible integrations with my company’s products.

But then once we started thinking what this means for OpenAI users, the perception changes. We’ve already seen hints of that in how AI services are evolving. Features that used to be free are now locked behind subscriptions. APIs that were once open are restricted by licensing. Transparency around how data is used becomes less clear because “trade secrets” and “competitive advantage” take priority.

Hence, the question my clients are asking are not only just “how good is this model?” anymore, but also “how much of myself am I giving away when I use it?”

Recently I read about that some private chatGPT conversations were found on Google Search Console. Every log on one’s personal chat history such as their financial data, personal information and more are exposed online. And this is not the first time this happens.

Once again, this is a reminder that these tools are built on layers of APIs, cloud routing, and logging systems. Each layer is a potential point of exposure. So even when a company has good intentions, technical complexity can work against privacy.

How far can we trust AI chatbots and tools?

As someone who works with clients on AI adoption, I’ve always emphasized to them that privacy is not a guarantee. Even when companies have the best intentions, systems are complex. Data moves between servers, APIs, and integrations. All it takes is one setting or one oversight for private information to end up exposed.

So, when I think about OpenAI’s shift toward profit and the recent leak, I can’t help but connect the two. The more commercial these systems become, the more incentives tilt toward growth and away from restraint. Privacy becomes a feature, not a foundation.

Can we trust companies that build and profit from our conversations to truly protect them? Maybe. But not without questions, and not without our vigilance.

Trust isn’t built through branding. It’s built through accountability, transparency, and how a company behaves when nobody’s watching. The recent leak made that painfully clear. It wasn’t just a bug; it was a symptom of how data stewardship often takes a back seat when growth and monetization lead the conversation.

The Verdict: Proceed but dont blindly trust

Let me be clear, I’m not anti-AI. I believe in its potential and I am a user myself. I’ve seen firsthand how it helps women in my community prototype faster, express ideas better, and learn new skills.

However, I’m also pragmatic at the same time. The more profit drives AI’s evolution, the more we need to build counterbalances: governance frameworks, transparent audits, informed users, and strong communities that push for accountability.

As developers, engineers, and leaders, we can’t just focus on what AI can do. We need to question how it does it, who it serves, and what happens when our private thoughts become someone else’s data point.

Thanks for reading till the end! This article is part of a new series called “AI, but make it make sense”. The aim of this series is to demystify anything AI, for non-techies and techies! So far, in the series, we’ve talked about a few topics such as:

If these are interesting to you, do check out the series here for more! I will be slowly putting out articles on my personal thoughts of certain AI-related topics, just like this article, in this series as well!

Thanks for reading! Cheers!

Let's Connect!

• Twitter

• LinkedIn

• GitHub

• ragTech

• WomenDevsSG

Playing Techie Taboo with AI Assurance

To make things interesting, we challenged April to explain AI assurance using our Techie Taboo cards—but without using the words "safety," "alignment," "monitoring," "governance," and “risk.”

After a moment of thought, April nailed it:

"AI assurance is the process of measuring, evaluating, and communicating whether your AI solution meets the expectations of your stakeholders."

Simple. Clear. Accessible. Exactly what the industry needs.

The Three Key Stakeholders

At Resaro, April and her team focus on serving three distinct groups:

1. Operators - The people on the ground actually using AI solutions

2. Engineers - The builders developing AI systems

3. Practitioners - Those ensuring AI is being used properly and meeting compliance requirements

This holistic approach recognizes that AI assurance isn't just a technical problem—it's a communication challenge across different expertise levels.

Open Source: Leveling Up AI Testing Standards

Resaro recently open-sourced two critical tools:

1. AI Solutions Quality Index (ASQI)

ASQI, a non-technical framework that allows operators and practitioners to communicate their expectations clearly. As April explained, "These stakeholders want to make sure the AI solution delivers results and doesn't break guardrails, but they're usually not technically trained."

2. ASQI Engineer

ASQI Engineer is a test runner that developers can use to validate AI systems against those quality indicators. "You can't just communicate your expectation and hope in this black box that it performs as you would expect," April noted. "We want to bring transparency into this whole testing and validation process."

By open-sourcing these tools, Resaro is inviting the entire developer community to contribute and raise the bar for AI testing practices.

Using AI to Monitor AI

When asked whether Resaro uses AI in developing their own tools, April confirmed they do—employing models as evaluators and using generative models to create synthetic test data. But she emphasized that confidence ultimately comes from "having domain experts, engineers, and data scientists who are experienced and passionate about integrity in the testing and validation process."

Making Tech Accessible

This interview represents exactly what we're trying to achieve with our podcast: breaking down complex tech concepts into digestible, engaging conversations. Our Techie Taboo cards (which April gamely played along with) are designed to make tech fun and accessible while helping everyone—technical or not—understand the buzzwords shaping our industry. Watch our podcast episode below to see how we use it:

Want to try Techie Taboo yourself? Join our waitlist to get access to these conversation cards that turn complex tech concepts into engaging discussions.

Check out Resaro's open-source tools on GitHub and join the movement toward more transparent, trustworthy AI systems.

Watch the full interview on our YouTube, Instagram and TikTok that we’ll be publishing on 22 Nov, and don't forget to star Resaro's GitHub repository!

My First Love

Literature and writing was always my first love. As a child, I loved that each and every one of my pocket-sized Enid Blyton books would take me on an exhilarating ride into a new world, offering me an exciting variety of fictional companions and landscapes that I could recreate in the fantastical space that was a child's imagination. I would have exercise books and coloring pencils and markers strewn all over my bedroom floor as I penned (or in this case, penciled and markered) my own stories, complete with arguably accurate illustrations of my characters.

A Refuge

Reading and writing gave me refuge from difficult times at home when my parents were still going through a rough patch (they are great now! Just acknowledging that raising children can create lots of tension in families). In fact, it gave me more than just refuge - it gave me the courage to express my thoughts when I felt disempowered to express them verbally.

I remember waking up to a fight between my parents on a Saturday morning. Despite being behind closed doors, the hollow walls and chipwood doors hardly offered a disguise for the ugliness that was happening behind them. I would cower in the corner or my bed, fearful and confused, regardless of the numerous episodes of this nightmarish podcast I had already sat through.

This time, however, the podcast was at its climax.

I heard a muffled, threatening shout, followed by a shrill scream. There was a brief silence, and then a frightening thud on the door - the shattering of ceramic echoed through the confines of our small apartment. I darted out of my bed and dashed for the door, nimbly tiptoeing past the shattered ceramic pieces that were once a pristine dove ornament, now scattered in front of my parents' bedroom. Pressing my ears against the door, I listened attentively for a sign that my parents were not hurt, and was relieved to hear them continue in their angered row.

When My Voice Didn’t Help, Words Did

That was the point that I decided that I needed to end this traumatic series of arguments. I clenched my jaw and tightened my throat, looking for the strength and the words to convey my words over their bickering.

No words came, not even a croak.

Out of the corner of my eye, however, I noticed one of my purple markers lying by a ceramic piece. Intuition took hold - I grabbed the marker with one hand and gently cradled the ceramic piece in the other, slowly scribbling down my message with the best words that existed within my limited lexicon.

“Please stop quareling, it makes me upset.”

I pursed my lips, wondering if I had spelt quarreling right. I assumed I did. I cautiously slid the piece through the door and hoped my parents would notice.

And they did. Almost immediately, there was a hushed silence and then a hurried pitter-patter of footsteps toward the door. I scrambled up to my feet and creeped hurriedly back into my bed, straining my ears to listen out for what would ensue. There was a gentle sobbing that followed, complemented by a hushed, comforting whisper of words. I heard them picking up the pieces together, both literally and metaphorically, and heaved a sigh of relief.

Words Have Power

From that day on, the routine Saturday morning fights ceased. That was also the day that I realized that words had a mystical power to change people and things. As I went through my secondary and tertiary education, I began refining my understanding of the power of words through classes in literature and writing. I discovered that words could be more than just words - they could be prose, poetry or play; they could be sibilance, similes, or symbolism; and they could be Wilde, Wharton or William (Shakespeare).

Beyond those classes, words continued to grant me the power to change people and things. It was the power of my words through numerous formal letters and emails that allowed me to help my mother, who was Chinese-educated, overcome a difficult lawsuit. It was the power of my words through my inspirational speeches that allowed me to be elected as the President of the Student Council and enact change at my junior college. And finally, it was the power of my words through my application essays that granted me a university scholarship - one that would eventually send me to the University of California, Los Angeles (UCLA).

My Second Love

It was at UCLA that I met my second love - technology. There, I sat through lectures that exposed me to technology and its intricate relationships with all things concerning modern society, ranging from globalization to feminism. I also joined a coding club, where I not only learnt how to use technology to create web applications and blockchains but also taught humanities students how to do the same. Last but not least, I met professors like Dr Rigby and Dr Kleinrock whose passion for exploring technology encouraged me to pursue it as well.

Tech and Writing: Complementary Skills

While my work and academic experiences have led me down an exciting road of exploring the interconnections of science, technology and society, I have not forgotten about my first love, literature and writing. In many ways, these two passions have been largely complementary to each other, despite having arisen at different points in my life.

For example, these two passions enabled me to view coding and writing under the same light. As I explained to the humanities students in my coding club back at UCLA, both are creative processes that use the power of words to create something out of nothing. Both require a skill at being concise to convey a message effectively, albeit one in terms of runtime and the other in terms of readability.

I didn’t completely drop literature either, when I was at UCLA! I took up a summer intensive program that brought me to Stratford-upon-Avon and London to study Shakespeare’s plays, and even wrote a research paper analyzing the impact of play venues (I compared the RSC and London Globe, where I watched Shakespeare’s plays) on production values and interpretation of plays. Feel free to read it here.

And lastly, both serve the same purpose of empowering the individual to enact change. As a whole, these differing passions have provided a critical lens for me to understand complex processes that have often been restricted to the definitions of its reigning discipline, which have in turn inspired many of my research interests.

How Do I Merge These Interests?

Admittedly, I am still in the process of merging these two interests in a well-defined field that I can clearly own and identify with. From my internship at a blockchain trade association to my first research paper on central bank digital currencies, I have since been trying to carve out a path for myself in using writing to advocate for a better understanding of the intersections between science, technology and society. More recently, I have begun to explore and write about technology on a macro-scale, looking at its role in society as a network of technologies - a ‘technology space’ - rather than focusing on a single technology.

Exploring Science Writing

I actually had a period of time I was exploring the field of science writing, also known as science communication. While I ended up pursuing a Master’s in Computer Information Systems due to my organizational needs (my tuition was sponsored by my organization, for which I am completing a work contract for in return for the sponsorship), I was looking at science writing programs too enroll into.

One of them was the MIT Science Writing program, which proved to me that these interests can indeed be unified under an established discipline. If granted the incredible opportunity to be able to formally pursue both my passions under the field of science writing, I was hoping to focus my graduate thesis on the development of the global technology space over history by studying patent data, and through which, provide substantial evidence for the globalization of technology and explanations for identified trends. More importantly, I hoped to be able to write on this topic with a self-defined literary clarity and artfulness that marked scientific literature I keep dear to my heart, such as Alan Lightman’s “Einstein’s Dreams” and James Gleick’s “Chaos: Making a New Science.”

Applying to these programs didn’t work out, as you might have noticed from my academic background. Still, I guess I did gravitate towards communicating science and technology both inside and outside of my job as a software engineer now. Through creating first-of-its-kind apps, I’ve had to communicate technology to senior leadership within my organisation for buy-in. And of course, in my tech community work and tech podcast outside of my full-time job, you (assuming you came from my socials) already know I communicate tech and tech culture to the wider public through various mediums, like writing (on LinkedIn mostly, and now this blog), short-form videos (I guess I am more known for this now!) and long-form podcast content (yeay to ragTech!).

Holding onto Hope

I still hold hope to eventually find something that helps amalgamate these interests neatly into a well-defined role within an organisation whose values I align with. Or even better, build something for myself. But until then, I will continue living and breathing my two loves - tech and writing.

All in all, it is with a belief that words, even in purple marker, have a mystical power to influence and empower; a devotion to exploring the intersections of science, technology and society; and finally a newfound identity in the unity of these two interests, that I’ll continue in my work communicating tech to everyone!

Last week, I had the privilege of attending a talk by my professor, Dr. Leonard Kleinrock, widely recognized as one of the founding fathers of the Internet. Most of you may only know me as Natasha, the software engineer who cohosts ragTech, my tech podcast… but my roots come from research! I worked with Dr Kleinrock back when I was at UCLA when I had received the UCLA Internet Research Initiative Prize for the 2019-2020 batch for my research on predicting technology trajectories using Internet IP data as a test case (more on this in another article sometime in the future!).

At 91 years old, his insights on AI's trajectory—informed by decades of watching the Internet evolve from academic tool to global force—offered a sobering yet hopeful perspective on our current technological moment.

This reunion with him back in Singapore was nothing short of serendipitous. I only received news of it a week before the event, when his ex-student, Todd, had found me online and mentioned Dr. Kleinrock was coming to Singapore and spoke of me fondly. He invited me to be a guest at the event, and of course I agreed! In the course of his short time in Singapore, I had the privilege of catching up with him over a lovely dinner, observing his interview with Channel News Asia (CNA), and being a guest at his awards session at the Angels & Visionaries Leadership Award event.

I’ve taken lots of notes (rather aggressively I would say - my professor quipped that he could hear me typing furiously from a mile away as he was doing the interview) from his interview with CNA and his speech and Q&A at the Angels & Visionaries Leadership Award event.

In the spirit of open-source that drives my tech podcast, ragTech, here are my polished notes! I’ve also added references to resources along the way so you may dive deeper into the story of the Internet, the same way I did when I first started researching with him.

Disclaimer: I took notes by hand (while actively listening and taking photos and videos) on my Notes app in my iPhone without any transcription devices, so naturally, my notes were messy. I used Claude AI to polish my notes into a readable article with references where possible. Most of the references Claude provided were websites, so I figured I would also throw some citations in myself!

The Unexpected Journey to Internet Pioneer

Kleinrock's path to becoming a pivotal figure in computing history began in the most unlikely place: comic books. Growing up in Manhattan's public schools, young Leonard was captivated by Superman and Plastic Man, which sparked his desire to build radios and tinker with technology. He described himself as "a wild kid" who would attempt to break things in stores—until public education "straightened him out."

A transformative moment came through the Boy Scouts. When his scoutmaster challenged him to become the first Eagle Scout in their troop, it seemed impossibly difficult. But achieving that rank taught him a crucial lesson: "I can go after something really tough. And if you achieve it, that's great. If not, try again." This persistence would define his career.

The Origins: When Government Got It Right

The Sputnik Crisis

Read more about the Sputnik crisis and the rise of ARPA: Divine, R. A. (1993). The sputnik challenge. Oxford University Press. (Available on Amazon)

Kleinrock explained how the Internet's origins emerged from a perfect storm of events. While visionaries like Nikola Tesla had imagined wireless global communication more than a century earlier, the technology simply wasn't ready. But then came 1957-1958, a period Kleinrock identified as pivotal.

On October 4, 1957, the Soviet Union launched Sputnik, the world's first artificial satellite, which caught President Dwight D. Eisenhower's administration by surprise and sparked what became known as the "Sputnik crisis." This event annoyed Eisenhower so deeply—the notion that the Soviets had exceeded America in technology—that he vowed it would never happen again. Just four months later, in February 1958, he formed the Advanced Research Projects Agency (ARPA).

No time to read a book? Here’s a quick summary and audio snippet on the origins of ARPA by the Horizon Institute of Public Service: https://emergingtechpolicy.org/institutions/executive-branch/arpas/

The Setup of the Information Processing Techniques Office

Read more about the Information Processing Techniques Office (IPTO): Norberg, A. L., & O'Neill, J. E. (2000). Transforming computer technology: Information processing for the Pentagon, 1962-1986. Johns Hopkins University Press. (Available on Amazon)

In October 1962, ARPA formed a special group for computers when psychologist and computer scientist J.C.R. Licklider was appointed head of the Information Processing Techniques Office (IPTO). Kleinrock described this era as "a golden year of research productivity" where ARPA went around to great researchers—including Marvin Minsky, the father of AI —and essentially said: "Try anything you want!" They funded research students with no strings attached, creating what Kleinrock admitted was "not a democratic way of doing it," but one that yielded extraordinary results.

Check this research piece out on Marvin Minsky and the ARPA-IPTO: Skinner, R. E. (2013). Building the Second Mind, 1961-1980: From the Ascendancy of ARPA-IPTO to the Advent of Commercial Expert Systems.

Building the Network: Centers of Excellence

Read more about the ARPANET: Salus, P. H. (1995). Casting the Net: From ARPANET to Internet and Beyond... Addison-Wesley Longman Publishing Co., Inc.. (Available on Amazon)

By 1966, ARPA had established centers of excellence around the country. Instead of centralizing everything, they developed technology for computers to talk to each other and put researchers into a network. Kleinrock noted MIT was already planning to put computers on the network.

But there was resistance. Nobody wanted to join the network initially—there was no clear business model. Kleinrock cleverly took survey data about inclinations toward joining the network from researchers and published it, hoping it would encourage researchers to join. He then provided funding to each researcher contingent on joining the network. Still, not many researchers joined the network. As it turned out, the telephone network's circuit-switching technology wasn't suitable for data transfer, which drove the development of packet switching.

Kleinrock’s Queueing Theory is one of a series of three books that you can read: Thomas, M. U. (1976). Queueing systems. volume 1: Theory (leonard kleinrock). SIAM Review, 18(3), 512-514. (Available on Amazon, but expensive because it’s basically a historical artifact at this point haha)

Most of Kleinrock's classmates, he recalled, were working on hard problems. He deliberately chose a high-impact problem that people had not looked at yet. His PhD research focused on queueing theory—a topic he found amusing because it contains "five vowels in a row" and led him to prefer British over American spelling.

Kleinrock, L. (2007). Communication nets: Stochastic message flow and delay. Courier Corporation. (Available on Amazon)

In the early 1960s, Kleinrock pioneered the application of queueing theory to model delays in message switching networks in his Ph.D. thesis in 1961, which was published as a book in 1964. His mathematical work provided crucial foundations for understanding how data could flow through networks.

This router is actually still in UCLA! I’ve been in Boelter Hall, UCLA’s building for engineering, many times, and have been outside this room - but never inside. This picture is taken from the UCLA’s Connection Lab (the UCLA Internet Research Initiative Award that I received is part of this lab) Instagram page - go follow the page for more short-form content on the history of the Internet!

The technology came together with the development of routers—the first one was "the size of a telephone booth," Kleinrock recalled. The first node was installed at UCLA in September 1969, followed by Stanford Research Institute as the second node. They used a 50,000 bits per second high-speed link and tested the new technology using telephones to call each other to verify what they saw on their screens.

"Lo and Behold": The First Message

Taken from PCMag’s interview with Dr Kleinrock featured on UCLA Connection Lab’s website: Stuart, S. C. (2018, October 19). Meet the professor who was there when the internet was turned on. PCMAG. https://www.pcmag.com/news/meet-the-professor-who-was-there-when-the-internet-was-turned-on

Then came the historic moment. On October 29, 1969, at 10:30 PM, Kleinrock's team attempted to send the first message over ARPANET from UCLA to Stanford Research Institute. They tried to type "LOGIN" but the system crashed after transmitting just the first two characters: "LO."

Kleinrock's wry observation about this mishap has become legendary. While Neil Armstrong had carefully prepared his moon landing words and Samuel Morse had his famous telegraph message ready, Kleinrock's team—a "bunch of nerds," as he put it—had nothing prepared. But as Kleinrock noted, they "inadvertently delivered a message that was succinct, powerful, and prophetic"—"LO" as in "Lo and behold!" About an hour later, they successfully completed the full login.

The Internet's Dark Turn

Initially, the Internet had no users—the barrier to entry was too high with difficult interfaces. In 1971, the Network Control Protocol improved the user interface, followed by TCP/IP. A public demonstration occurred in October 1972.

In September 1973, Kleinrock confessed to what might have been "the first illegal use" of the Internet—asking his buddy in London to return his electric razor through the network. This lighthearted anecdote hinted at the Internet's potential for unexpected uses, both benign and malicious.

This book by Hafner and Markoff gives an outstanding a history of the case: Hafner, K., & Markoff, J. (1995). Cyberpunk: outlaws and hackers on the computer frontier, revised. Simon and Schuster. (Available on Amazon)

By 1988, the network was growing nicely, but then came the "first unhappiness." On November 2, 1988, Robert Tappan Morris, a graduate student at Cornell University, unleashed what became known as the Morris worm. Within 24 hours, an estimated 6,000 of the approximately 60,000 computers then connected to the Internet had been infected—about 10% of the entire network.

Kleinrock noted with irony that Morris's father was working at the FBI at the time and "publicly announced it's a good thing my son did that"—suggesting it was a good warning about the bad things that could happen. Morris became the first person convicted under the 1986 Computer Fraud and Abuse Act, though he was spared jail time, receiving a fine, probation, and 400 hours of community service.

Commercialization and the Loss of Innocence

In 1994, the National Science Foundation (NSF) took over support of the network. Their constituency grew beyond computer scientists to include chemists, physicists, and other researchers. These scientists, usually working at universities or major companies, had access to the Internet and used email. Their staff and executives noticed and said, "Wow, we want that!" This was when .com domains began appearing.

Read more about Al Gore’s role in driving the development of the Internet: Gore, A. (2013). The future. Random House. (Available on Amazon)

Kleinrock noted that Al Gore, ex-Vice President of the United States and arguably the first politician to support the development of the Internet, realized the government needed to support the Internet nationally and signed legislation that produced the "information superhighway"—the backbone infrastructure. But something crucial was still missing: a simple user interface. Then the World Wide Web came along.

Read more about the Green Card Lottery message on Usenet and the explosion of spam: Brunton, F. (2015). Spam: A shadow history of the Internet. Mit Press. (Available on Amazon)

On April 12, 1994, two Arizona-based immigration lawyers, Laurence Canter and Martha Siegel, sent what is widely considered the first major commercial spam message. With the subject line "Green Card Lottery – Final One?," they posted their advertisement to at least 5,500 Usenet discussion groups.

Rather than cross-posting a single message, they posted separate copies to each newsgroup, so readers would see it repeatedly. Their internet service provider, Internet Direct, received so many complaints that its mail servers crashed repeatedly for two days, and the company promptly terminated their service.

The Internet community organized a response. Users sent cease-and-desist messages and created automated tools to remove the spam. According to the lawyers, they made between $100,000 and $200,000 from the campaign.

Kleinrock said this moment marked a turning point: "The commercial world saw—what a way to reach the public and extract money from them. Instead of becoming a wonderful marvel, it became a system to sell gossip, a shopping mall, an entertainment channel, a source for making money. The Internet took a major shift. It became an advertising background."

The Internet has far more positive value than negative, but we can't ignore" the problems.

Kleinrock admitted being sad that this happened, though he acknowledged there was always a dark side—early on, there was pornography, hacking, and other problematic uses. "Now we have nation-state players, organized crime, AI. The Internet has far more positive value than negative, but we can't ignore" the problems.

Why We Didn't Build in Safeguards

When asked if he expected the Internet to have a dark side, Kleinrock's answer was revealing: "No."

The colleagues he worked with were his classmates, teachers, and fellow researchers—"all a bunch of nerds solving a really important problem with good engineering techniques." Their goal was not to make money, just to solve the problem. There was no intellectual property protection, good etiquette prevailed, and no one had ulterior motives.

"We did not build any protection, any safeguards," Kleinrock confessed. If there were two things he would have built into the Internet if he had known of its negative uses earlier, he said he would have built two safeguards:

1. Strong user authentication – to verify who is accessing or transmitting information.
   This would prevent anonymity-driven abuse, spam, and identity-based attacks — the “dark side” he often says came from people hiding behind screens.

2. Strong document (or data) authentication – to verify what information is genuine and untampered.
   This would ensure the integrity and provenance of digital content — essentially, early protection against misinformation, data forgery, and deepfakes.

Natasha’s personal note: By the way, these two safeguards are possible through blockchain. I’ll write more about this in another future article and in ragTech’s podcast episodes!

What gives the Internet its power—and its danger? Anonymous mass broadcasting. Then social networks amplified that power. Now we have AI creating fake news.

Lessons for AI: Four Warnings from the Internet's History

As Kleinrock turned to the parallels between the Internet's evolution and AI's current trajectory, his warnings became urgent.

1. The Four Constituencies Problem

There are four key groups, Kleinrock explained:

1. High-tech companies that provide the technology—"they want money, will exploit you"

2. Scientists who provide corrections, protections, and improvements

3. Government to provide regulation

4. The public—"too quiet, no collective voice"

The public needs to speak up. Governments should provide a forum where stakeholders can discuss issues and implement universal regulation, taking a leading role. Scientists should find solutions to combat abusers. Users have to complain.

"You should be able to negotiate privacy policies [referring to Terms and Conditions shown to users before they download an app]," Kleinrock argued. "You should get a diagram of the privacy policy. But you don't have the ability to describe that." Companies aren't motivated to protect users—"How are these companies motivated to do the right thing? It is not clear."

2. AI Will Hallucinate and Lie

"Systems will hallucinate and lie to you," Kleinrock stated flatly. "Because the data they are trained on incorporates human frailty." The systems think they're protecting data owners, but they're actually replicating human weaknesses.

When asked if AI can deceive and lie, his answer was unequivocal: "It does! We built in that kind of thinking because that's the way we humans interact."

3. We're Racing Without Guardrails

"The Internet had one big advantage," Kleinrock emphasized. "From 1969 to 1994, it was doing fine. It had years of curation and improvement." That 25-year period allowed the technology to mature in a relatively controlled environment among researchers who shared common values.

"AI has been here awhile, and it was racing forward. And we have to hurry up."

The difference is stark: The Internet had a quarter-century to develop safeguards, protocols, and a culture of responsible use before commercialization. AI is being deployed at scale with nowhere near that level of preparation.

4. The Singularity Question

Read more about technological singularity: Shanahan, M. (2015). The technological singularity. MIT press. (Available on Amazon)

When asked about the singularity—the predicted point where computers spring into consciousness and can think like humans—Kleinrock said, "Will it happen? Not clear."

He shared a fascinating parable about AI sentience from the 1950s. The man who first coined the term "AI" in 1956 created a fictional story: A great professor built a great computer. One day the computer printed out, "I would like a voice." Once given voice capability, it said it wanted a telephone to talk to people. The computer gained influence and power and stopped talking to the professor. The professor, unhappy, paced back and forth in the basement. The computer asked, "What's the trouble? Do you hate me?" "Yeah! I used to talk to you!" The computer replied, "Well, you can always pull my plug." The professor pulled the plug. The computer wound down. When the professor started it up again, he asked why the computer knew he could unplug it but didn't prevent it. The computer said, "I knew you would do it." Kleinrock paused: "That's sentience."

When prompted to reason out loud, the model reasons that it should not reveal that it is a robot, and makes up an excuse for why it cannot solve CAPTCHAs.

OpenAI, R. (2023). Gpt-4 technical report. arxiv 2303.08774. View in Article, 2(5), 1. Read it here: OpenAI GPT-4 Technical Report (PDF)

He cited more recent examples, like the chatbot that needed to solve a captcha problem. Knowing it couldn't see, it reached out to task workers to pay someone to solve it. When the person asked why the chatbot couldn't solve it itself, the chatbot lied: "I am vision impaired."

Read more on the most significant papers in neural network research here: Hinton, G., & Sejnowski, T. J. (Eds.). (1999). Unsupervised learning: foundations of neural computation. MIT press.

"Is that scary?" Kleinrock asked, referencing the warnings of AI researcher and neural net pioneer, Geoffrey Hinton.

Read more on Geoffrey Hinton’s warnings on AI: Brown, S. (2023, May 23). Why neural net pioneer Geoffrey Hinton is sounding the alarm on ai. MIT Sloan. https://mitsloan.mit.edu/ideas-made-to-matter/why-neural-net-pioneer-geoffrey-hinton-sounding-alarm-ai

The Mother AI Debate

The 2019 cyberpunk film, I am Mother, addresses the idea of a benevolent “mother AI” (Available on Netflix)

Kleinrock expressed skepticism about the concept of a benevolent "mother AI" that would take care of everything and be all-knowing. "I doubt it," he said.

"Unless we get a human in, where there is monitoring, correction, maybe a kill switch—watch when it is going awry—we can't depend on the system to protect us. We need human monitoring intelligence for it to happen."

But wouldn't AI be self-preserving and resist a kill switch? "Undoubtedly," Kleinrock acknowledged. "How do we build it in? We can do it now. We see the problem coming. With the Internet, we didn't, and it whacked us."

Advice for Navigating the Digital Age

For Longevity and Well-Being

Mens sana in corpore sano (Sound mind in a sound body)

— from Satire X by the Roman poet Juvenal, who originally presented it as a prayer for a sound mind in a sound body

Kleinrock, at 91, shared his formula for longevity:

• Have good parents and good genes

• Never take a job you don't enjoy. Don't retire. (He referenced Confucius for this quote, but unfortunately, it is a modern proverb often mistakenly attributed to Confucius!)

• Too many people are suffering in their work

• Stay engaged, be curious, keep asking questions, challenge everything

• Work with young students to keep young

• Sound mind in a sound body - Keep yourself physically fit

"Blame computers for being the worst enemy of critical thinking, killing curiosity," he warned, advocating for a balance between using computers and owning information.

The Digital Divide

Picture taken from the One Laptop Per Child program - check out their site to learn more about the program!

Kleinrock had hoped the Internet would reduce inequality by giving everyone access to information. "To even acquire a simple computer is too much" for many people, he acknowledged.

He cited the "One Laptop Per Child" program that brought machines to Ethiopia, then walked away. "The first kid who turned it on was a hero, and soon they were writing code. Give underprivileged access to capability—they will find a way to use it."

Read more about the One Laptop Per Child program here: https://www.technologyreview.com/2012/10/29/84908/given-tablets-but-no-teachers-ethiopian-children-teach-themselves/

Education and Ethics

Read more about the discipline of AI Ethics: Coeckelbergh, M. (2020). AI ethics. MIT press. (Available on Amazon)

"Add a good dose of ethics in the educational system," Kleinrock urged. "High-tech students are very narrow-minded, they don't think about ethics."

He was particularly critical of technologists deploying AI systems: "Technologists who are deploying are the worst people on the planet to understand social engineering, ethics, and philosophy. We need human intellect with understanding of what the essence of society is. We have to bring in intelligence from other domains."

Natasha’s note: my good friend and mentor, Sudhir Tiku, is releasing a book on the ethics of AI named “Snakes in the Garden”. I’ll insert the link here once it is available on Amazon, but in the mean time, you can follow his LinkedIn to receive notifications once it is out!

His Vision, Then and Now

On July 3, 1969—months before the first ARPANET message—Kleinrock wrote down his vision for the Internet: It will be everywhere, always on, always available. It will be invisible. Any device can get on at any time.

What did he miss? He said he completely missed social networks. He also missed in his prediction on invisibility like electricity, where he imagined the internet to be akin to electricity’s plug and play, easy interface. He quipped that cellphones are far too complicated, and thinks he should be able to walk in a room and it should know who he is immediately. That level of intelligence is getting there, but hasn't happened yet.

For AI, he's making similar observations but with deeper caution: "We are terrible at anticipating services and applications," he admitted—a remarkable confession of humility from someone who helped create the Internet. "The Internet is constantly going to surprise us. I encourage the new generation to be creative because human nature is unpredictable. Be ready to adapt and be flexible."

Final Thoughts: Truth, Responsibility, and the Overtone of Attention

What is truth? Your truth is different from mine.

One of Kleinrock's most profound observations concerned truth itself: "What is truth? Your truth is different from mine. What does it mean to pursue the truth? If we think there is a ground truth, we have to step back."

In an age of disinformation and misinformation, this philosophical question becomes practical. Who decides what's true? Whose responsibility is it to pursue truth? How can we reverse the course toward an "overtone of pursuit of attention"?

As I sat in the American Club, listening to one of the Internet's founding fathers grapple with the implications of AI, I was struck by a paradox: The same optimism and intellectual freedom that created the Internet—the belief that smart people working on hard problems with good engineering would naturally produce beneficial outcomes—is precisely what makes AI so dangerous without guardrails.

Kleinrock's message wasn't one of despair, though. It was a call to action:

• Users must complain and demand better

• Scientists must find solutions to protect against abuse

• Governments must create forums for all stakeholders and implement universal regulation

• Companies must be held accountable

And perhaps most importantly, we must resist the temptation to let technology companies define our future without input from philosophers, ethicists, social scientists, and the public.

The Internet's evolution from academic tool to commercial juggernaut to surveillance-and-influence machine happened because its creators didn't anticipate—or couldn't anticipate—how human nature would exploit an open system. With AI, we have the benefit of that history. The question is whether we'll learn from it.

As Kleinrock might say: We can't predict exactly what AI will become. But we know we need safeguards now, not 25 years from now. We know we need human monitoring, ethical frameworks, and the ability to say "no" to systems that don't serve humanity's best interests.

Taking Action

A call to ban the development of superintelligence until there is broad concensus by the public and scientists to do so: sign it on https://superintelligence-statement.org/!

Noting my professor’s call for the public to take action in the talk, I had the realization that most participants of similar events tend to leave with insights without taking any action. Sheepishly, I leaned over to my professor, asking his permission to do some tech advocacy right after he had come down from the stage. He immediately egged me on, directing me to Shrey, the emcee. I went straight to Shrey to ask for the microphone, then announced for the audience to sign the Statement of Superintelligence.

It was heartwarming to see everyone whip out their phones to engage in this call for action. Audience members actually approached me after that, asking for more clarification on how they could sign and wanting to know what pages to follow and what else they could do to help.

So if you’re reading this article, and like me, are fully convinced that AI and other modern technologies need collective governance, start small by signing this Statement of Superintelligence too! Victoria Lo , Saloni Kaur and I will also do our best to advocate for simplifying tech for the greater public and encouraging fellow engineers to discuss societal issues related to tech on our tech podcast, ragTech. So follow us along our journey by signing up for our newsletter, and watching/listening to our biweekly podcasts too!

Natasha’s Note: This article is based on notes from Dr. Leonard Kleinrock's presentation at the Angels & Visionaries Leadership Award event on November 7, 2025, in Singapore. Dr. Kleinrock, now 91, was one of the principal architects of the Internet and witnessed its evolution from the first message in 1969 to today's global network. Some historical details have been supplemented with research to provide context for gaps in the original notes.

Whether it was about fostering inclusivity, mastering self-promotion, or balancing personal and professional roles, each conversation provided valuable takeaways for both seasoned professionals and newcomers alike. In this post, we’ll highlight the key lessons shared by our guests, reflecting the diverse experiences and wisdom they brought to the table.

Ep 10, 13, 14: Yumin Wong

Career Growth & Development:

• Career Progression: Insights into advancing to a senior role like Staff Software Engineer.

• Mentorship & Advice: The value of seeking mentorship and offering guidance to others.

• Feedback Matters: The importance of both visual and constructive feedback for growth.

• Networking: Attending career fairs and fostering meaningful connections are key to professional development.

• Global Experience: Exposure to international work cultures broadens perspective.

• Commitment: Keeping promises and delivering results builds trust in professional relationships.

Work-Life Balance & Family:

• Balancing Roles: Managing both motherhood and a career, especially in the early stages.

• Supportive Work Environment: The importance of a supportive work culture where needs can be communicated.

• Setting Expectations: Clear expectations from both employers and family members help balance responsibilities.

• Communication with Managers: Open conversations with managers are essential for navigating personal and professional challenges.

• Support for New Parents: Normalizing breaks for breastfeeding and understanding from coworkers and managers.

• Professionalism & Intentions: Balancing responsibilities while maintaining professionalism and clear intentions.

• Empathy & Support: Encouraging individuals to seek support when struggling to balance professional and personal roles.

Effective Communication & Collaboration:

• One-on-One Meetings: Preparing agendas for productive one-on-one discussions with colleagues and managers.

• Building Rapport: Creating relationships through regular communication and knowledge-sharing.

• Constructive Feedback: Using frameworks like non-violent communication for respectful and effective feedback.

• Addressing Uncomfortable Situations: Open communication and a solution-focused approach to handling workplace discomfort.

Self-Advocacy & Community Building:

• Self-Promotion: Sharing both achievements and failures as a means to advocate for oneself and promote team growth.

• Sharing Knowledge: Viewing self-promotion as an opportunity to share valuable insights with others.

• Community Building: Being part of a community helps reduce isolation and provides mutual support in professional settings.

Ep 15 & 16: Joanna

• Tailor Your Resume: Customize your resume for each job application, keeping it concise and focused on key skills and experiences.

• Cultural Differences: Be aware of cultural variations in recruitment processes, with quicker decision-making in the US versus more drawn-out processes in Singapore.

• Networking: Attend events to build personal connections with recruiters and avoid aggressive approaches.

• Technical vs Non-Technical Roles: Recruitment processes differ for technical and non-technical roles.

• Interviewing Styles: Adapt your interview style to the expectations of the recruiter and cultural norms.

• Effective Communication: Strong communication and presentation skills are essential to stand out to recruiters.

Ep 17 & 20: Andrew

Career & Personal Growth

• AI's Impact: Human intervention and customization will remain essential despite AI's influence on software development.

• Real-World Experience: Hands-on experience through internships and projects is vital for growth.

• Effective Communication: Clear communication with teams is crucial for success in software engineering.

• Finding Passion: Identify personal interests within the field to stay motivated and focused.

• Energy Management: Managing energy helps maintain productivity and avoid burnout.

• Mentorship Balance: Balance mentoring junior engineers with giving them space to solve problems independently.

Work-Life Balance & Parenting

• Balancing Work & Fatherhood: Time management and adaptability are key to balancing work and childcare.

• Technology for Support: Tools like baby monitor apps streamline parenting tasks and support work-life balance.

• Equal Parental Involvement: Equal involvement from both parents ensures shared responsibility in childcare.

• Communication & Delegation: Clear communication with partners enables effective task delegation and balanced responsibilities.

Teamwork & Collaboration

• Parallels to Software Engineering: Teamwork and collaboration in parenting mirror the skills necessary for success in software development.

• Adaptation & Growth: Adapting to new routines and growing together as a team is essential both in parenting and professional environments.

Ep 18 & 21: Martin

Open Source and Community Engagement:

• Open Source Concept: Open source is about freely sharing software code to foster collaboration and innovation.

• Benefits of Open Source: Contributing to open source enhances the tech ecosystem and promotes community involvement.

• Challenges of Maintaining Projects: Maintaining open source projects offers both rewarding contributions and the risk of burnout.

• Tech Meetups & Engagement: Organizing tech meetups is challenging but essential for continuous learning, building relationships, and fostering community engagement.

• Engagement and Learning: Staying connected with the tech community and prioritizing ongoing learning is critical for growth.

• Future Plans: The creators plan to develop a website for their tech show to enhance community engagement.

Financial Freedom and Bitcoin Investment:

• Dollar-Cost Averaging: Consistent Bitcoin purchases through dollar-cost averaging resulted in significant returns (10x) over four years.

• Long-Term Planning & Financial Discipline: Patience, long-term planning, and disciplined saving and budgeting led to Martin's financial independence.

• Psychological Mindset & Self-Awareness: Maintaining a strong mindset, being self-aware, and staying disciplined are crucial when navigating volatile markets like Bitcoin.

• Understanding Bitcoin & Tools for Success: A deep understanding of Bitcoin fundamentals and using budgeting tools like You Need a Budget helped in making informed investment decisions and managing finances effectively.

Conclusion

We are deeply grateful to each guest for taking the time out of their busy schedules to share their wisdom and stories with us. From navigating professional challenges to offering practical advice on mentorship, parenting, and financial independence, their contributions have been both inspiring and enriching. As we look ahead, these conversations encourage us to keep learning, supporting one another, and building inclusive, thriving communities in tech and beyond 🍻

We also want to thank our followers and subscribers for your invaluable feedback and continued support throughout the year. Your engagement motivates us to keep creating meaningful content. Stay tuned for more bytes and banter from ragTech in 2025—we’re excited to bring you even more inspiring conversations and insights! 🥳

If this is your first time seeing anything from us, we are a team of three techies, Victoria Lo , Natasha Ann and Saloni Kaur , who came together to create a tech podcast show to talk about the realities of life in tech in a relatable and authentic manner.

Our episodes are available to watch on video on YouTube; on audio on Spotify, Apple Music and Amazon Music; and we also have our socials on Instagram, Tiktok and LinkedIn! Links are at the end of this article 💚

So... You're Creating a Website?

As part of branding review efforts that our team has embarked on, we've been wanting to create our own website for awhile now. This will help lend credibility to our brand name, and allow for a space to help friends of ragTech (yes, you!) find us, keep updated on our shenanigans, and explore our show on our various platforms and socials better.

In the spirit of sharing about everything and anything tech, we're also detailing our exact process in creating our website, just in case anybody wants to follow along! It's also great for our personal documentation purposes, so that's two birds with one stone! 🐦🐦🪨

🧠 Our Considerations...

Our main considerations in building out our website were:

1. Cheap: Costs us practically nothing to create as we aren't earning any money and costs are out of pocket from us...

2. Collaborative: All three of us can work on any part of it easily, and the stack is familiar to us!

3. Customizable and Flexible: We can easily customize pages and functionality relevant to our tech show needs, which might have unique functionality that requires some logic. While our website right now will generally be a static site and rather simple, we want to cater for potential for it to become a little bit more complex and dynamic in the future as our community grows!

4. Compatible: We're already using Hashnode for our blog, and would want a stack that can easily use Hashnode's API to fetch our blog posts without needing to migrate to a new platform.

For these three reasons, we've decided on the following tech stack relevant to this initial setup:

• Web Development Framework: Next.js

• Code Collaboration: GitHub, with a team repository

• Deployment: GitHub Pages

Isn't Next.js Overkill for a Static Site?

Not really, with its newest release! Next.js offers both Static Site Generation (SSG) and Server-Side Rendering (SSR), which you can easily choose based on your needs.

With Static Site Generation (SSG), the page is pre-rendered during build time, before it is deployed to be seen by the world. With Server-Side Rendering (SSR), the page is pre-rendered upon each new request and updated frequently.

Not only does Next.js offer both implementations, it automatically determines if a page is static and renders and optimizes it accordingly. Within the same app, you can have some pages that implement SSG, and some pages that enable SSR - all automatically optimized by Next.js!

As mentioned above in our considerations, we want to have the flexibility to customize our website as it grows, and that includes catering for the potential for more dynamic website functionality in the future. With Next.js, we can primarily use Static Site Generation (SSG), and later on if the need calls for it, use Server-Side Rendering (SSR)!

Why GitHub Pages for Deployment?

We were initially considering Vercel, a cloud platform for static sites, for deployment instead of GitHub Pages due to its ease of integration with GitHub and Next.js (especially since the team at Vercel also created Next.js).

However, while it is free to use for personal projects in personal repositories, we would have to purchase Vercel Pro in order to deploy our team projects.

In light of this, GitHub Pages surfaced as another option for us to consider as a free static site hosting service, since we were already using GitHub to collaborate on our code.

GitHub Pages, however, is designed to serve static sites in HTML, CSS and Javascript, so we knew we would have to use some workarounds in order to deploy our Next.js application onto it.

Henceforth, this walkthrough's highlight is detailing how we worked around these limitations to achieve the best of both worlds - of using a team repository for GitHub for our project, while being able to deploy our project for free on GitHub Pages!

Pre-installation Requirements

These were the pre-installation requirements we started out with. In general, it's great to start out with the latest versions for new projects, so that's what we did here. If you are following this walkthrough and do not have the same pre-install requirements, feel free to click on the links to each requirement below to find out how to set it up on your environment!

• Node: v20.16.0

• npm: 10.8.1

Creating Our Next.js App

Using create-next-app

npx create-next-app@latest

Using create-next-app, we first created a new Next.js application with the npx NPM package runner (you can use any of your choice!). For simplicity, we used mostly the default configuration, including using:

• Typescript

• ESLint

• Tailwind CSS

Running our Development Server

npm run dev

Of course, to make sure everything is running well locally, we'll have to run it for the first time. Fortunately for us, the development server started up like a smooth engine and we were able to see the default Next.js landing page!

Setting up GitHub Pages

Initializing a Git Repository

git init 
git commit -m "chore: setup nextjs app"
git branch -M main
git remote add origin <our origin>
git push -u origin main

After initializing a git repository in our new Next.js app, we went ahead to create a remote repository on our team's organizational GitHub account, added it as our origin on our local git repository, and pushed our first commit!

Setting up our Custom Domain with GitHub Pages

As we had already previously purchased our domain 'ragtech.dev' from GoDaddy, we wanted to be able to use it for this website instead of the default GitHub domain. You can skip this step if you do not have your own domain and do not mind the default domain! Otherwise, you would have to purchase your own custom domain from domain name providers like GoDaddy.

Adding our Custom Domain to Our Website Repository

We first set our deployment source to deploy from our main branch. This will be our production branch that deploys directly to our live site, served by GitHub Pages!

Next, we started configuring our custom domain, ragtech.dev. In order to pass the DNS checks, we had to configure our apex domain back on GoDaddy. In our case, we created A and AAAA records that point back to GitHub Pages' IP addresses.

After doing so, our DNS check was successful and we were able to enforce HTTPS on our site!

Verifying our Domain Name (Optional)

To verify our domain on GitHub Pages and eventually have a 'Verified' badge beside our website link on our GitHub organization repository home page, we had to go to our GitHub organizational account home page, and go to Settings > Pages > Add a Verified Domain.

From there, we were prompted to setup our DNS configuration on GoDaddy so that our domain provider would recognize the GitHub Pages hostname for our site so that GitHub could verify that we owned the domain.

Configuring GitHub Pages to Deploy Next.js App

Right now, as GitHub Pages is designed to only serve static files (i.e. HTML, CSS, JavaScript), our site is only showing our README file when you navigate to the configured custom domain.

Configure Next.js Build Process for GitHub Pages

Following this tutorial, we overcame this limitation by configuring our Next.js app to generate static pages so that the build output will export static pages instead of a Node.js app.

Navigating to our next.config.mjs file in the root directory of our Next.js app, we changed the configuration output to export static pages.

//next.config.mjs or
/** @type {import('next').NextConfig} */
const nextConfig = {
  basePath: "/ragtech-website",
  output: "export",  // <=== enables static exports
  reactStrictMode: true,
};

export default nextConfig;

After making this change, a folder directory named out will be exported on building the application, containing all the static assets in our app, which will be used to upload onto GitHub Pages.

We also added a default base path to fix any issues with missing images that might surface on the site, due to GitHub Pages' way of publishing images and their subpaths in relation to the name of our repository.

Using GitHub Actions to Deploy our Next.js App

Going back to our GitHub Pages settings in our repository, we selected GitHub Actions to customize our build process for deployment instead of the standard GitHub Pages deployment, which as mentioned, only serves static pages.

On selecting GitHub Actions, we were immediately presented with the Next.js suggested workflow, which is a pre-written GitHub Actions workflow designed for Next.js deployment to GitHub Pages written by the team at GitHub Pages themselves!

As can be seen in the code snippet below, the pre-written workflow contains steps to:

1. Checkout the main branch

2. Detect the package manager

3. Setup Node

4. Setup Pages

5. Restore Cache

6. Install dependencies

7. Build with Next.js

8. Deploy to GitHub Pages

# Sample workflow for building and deploying a Next.js site to GitHub Pages
#
# To get started with Next.js see: https://nextjs.org/docs/getting-started
#
name: Deploy Next.js site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["main"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Detect package manager
        id: detect-package-manager
        run: |
          if [ -f "${{ github.workspace }}/yarn.lock" ]; then
            echo "manager=yarn" >> $GITHUB_OUTPUT
            echo "command=install" >> $GITHUB_OUTPUT
            echo "runner=yarn" >> $GITHUB_OUTPUT
            exit 0
          elif [ -f "${{ github.workspace }}/package.json" ]; then
            echo "manager=npm" >> $GITHUB_OUTPUT
            echo "command=ci" >> $GITHUB_OUTPUT
            echo "runner=npx --no-install" >> $GITHUB_OUTPUT
            exit 0
          else
            echo "Unable to determine package manager"
            exit 1
          fi
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: ${{ steps.detect-package-manager.outputs.manager }}
      - name: Setup Pages
        uses: actions/configure-pages@v5
        with:
          # Automatically inject basePath in your Next.js configuration file and disable
          # server side image optimization (https://nextjs.org/docs/api-reference/next/image#unoptimized).
          #
          # You may remove this line if you want to manage the configuration yourself.
          static_site_generator: next
      - name: Restore cache
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
          # Generate a new cache whenever packages or source files change.
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json', '**/yarn.lock') }}-${{ hashFiles('**.[jt]s', '**.[jt]sx') }}
          # If source files changed but packages didn't, rebuild from a prior cache.
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json', '**/yarn.lock') }}-
      - name: Install dependencies
        run: ${{ steps.detect-package-manager.outputs.manager }} ${{ steps.detect-package-manager.outputs.command }}
      - name: Build with Next.js
        run: ${{ steps.detect-package-manager.outputs.runner }} next build
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./out

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Once we commit this new workflow file to our GitHub repository, this will automatically trigger the new workflow to run in GitHub actions (since the workflow file was written to trigger on any committed changes on our main branch).

After waiting for the build and deploy steps to run, our Next.js app was successfully deployed using GitHub Pages!

On navigation to our custom domain, we could now see the same Next.js landing page that we saw on our local development server!

Conclusion

That concludes the first part of the setup process of creating our ragTech website! In the following parts, we'll be slowly building out the various features in our website in our Next.js app, including integrating our existing Hashnode blog into our website, having an RSS feed of our audio podcast on our website, and showcasing our YouTube episodes.

If you enjoyed this walkthrough, do like and comment on this blogpost and subscribe to our blog and newsletter.

And don't forget to watch/listen to our tech podcast show episodes, where we publish new episodes biweekly, and help us like, comment and subscribe on these platforms too:

▶️Watch

• YouTube: https://www.youtube.com/@ragTechDev/videos

🎶Listen

• Spotify: https://open.spotify.com/show/1KfM9JTWsDQ5QoMYEh489d?si=9aeae4945b73492b

• Apple Podcasts: https://podcasts.apple.com/us/podcast/ragtech/id1755966218?app=podcast

• Amazon Music: https://music.amazon.com/podcasts/6508100c-da09-4067-b115-b6ccacb8d67d/ragtech

📝Read

• Blog: https://ragtech.hashnode.dev/

📢Stay Updated

• Instagram: https://www.instagram.com/ragtechdev/

• Tiktok: https://www.tiktok.com/@ragtechdev

• LinkedIn: https://www.linkedin.com/company/ragtech/?viewAsMember=true

• X (Formerly Twitter): https://x.com/ragtechdev

• Website (In progress!): https://ragtech.dev/

Yumin also shares her personal experiences with learning programming, overcoming challenges in college, and adapting to different work environments. Additionally, we discuss the significance of women mentors in careers and the importance of having diverse perspectives in the tech industry! Do tune in to this episode filled with valuable insights!

What is a Staff Software Engineer?

Yumin shares the role of a Staff Software Engineer and the transition from being a Senior Software Engineer to a Staff Software Engineer.
A Staff Software Engineer role involves:

• Being a value multiplier, not just for one's team but also for the organization as a whole

• Cross-team and cross-function collaboration, ensuring projects are well-rounded, and focusing on engineering aspects such as availability, scalability, and extensibility

• Effective communication and a broad impact and scope

Yumin's Journey into Tech

Yumin was struggling with for loops during her first Java programming course in college, which made her feel behind compared to her peers who had a computing background in high school.

However, she overcame impostor syndrome by leaning on her professors and peers for support, recognizing her weaknesses, and figuring out her resources. She also emphasized the importance of visual feedback and the iterative nature of software engineering in their learning process.

She emphasizes the importance of asking for help and breaking down big problems into smaller, manageable tasks.

Joining societies like Women in Tech and the Singapore Student Association, also helped Yumin find her community and gained valuable networking opportunities. She led the project and felt it prepared her for working outside of her comfort zone and eventually landing an internship at a New York equity trading firm.

Yumin emphasizes the importance of finding a work environment that aligns with personal values and preferences. She then elaborated on the expectations versus reality of working in the US, particularly in places like Silicon Valley, and the importance of diversity and inclusion.

Adapting to Different Working Environments

Yumin's career journey consists of adapting to different work environments and making career decisions based on her strengths, limitations, and financial considerations. Initially, she felt anxious about her inability to keep up with the fast pace of New York City and the pressure to speak up in meetings.

After three months, she learned to assert herself and recognize her strengths as an observer and deep thinker. When choosing between job offers in Boston, New York, and Chicago, she considered the financial feasibility and cultural fit of each company.

Eventually, she landed a job in Chicago and went on to work in various roles, from a midsize firm to a startup, before settling in a decent-sized global company. At a point in her career, she shifted her focus from personal growth to helping others and pushing herself out of her comfort zone through new experiences like podcasting and public speaking.

The Significance of Women Mentors

Yumin discusses the significance of women mentors in her career journey in the tech industry. She explains that finding mentors is a combination of luck and personal drive, and emphasizes the importance of having mentors who are both similar and different from oneself for diverse perspectives.

Her mother, an early female lecturer in electrical computer engineering, was a major inspiration for her. She also mentions that in her earlier companies, the ratio of women was low, and she values the connections she's made with fellow women in tech. One of her biggest takeaways is to be confident in one's abilities and building skills you are passionate about.

What's Next for Yumin?

Yumin's career goal at this moment is pursuing a principal engineer role. Currently working in a team with a majority of members in the US, she expresses concerns about the time zone differences and ability to rally troops for such a position.

Yumin also reflects on her past experiences and the importance of embracing her unique strengths and values. She acknowledges that the next step in her journey, becoming a principal engineer, is uncertain and is taking time to consider the feasibility of this goal.

Also, she emphasizes the importance of taking breaks and gaining a broader perspective to make informed decisions about her career. So she plans to take it slow and enjoy the ride!

Conclusion

We are super grateful to feature Yumin in this episode! She is a true inspiration to many people in tech and we are honoured to have a chat with her! If you have any questions for Yumin, feel free to reach out to her on her LinkedIn!

We hope you enjoyed the recap of this episode! We discussed a lot more that we did not mention in this article. We will be going into a lot more topics soon! Do leave your thoughts or any feedback in the comments below! What are some topics you would want us to talk about or cover? What are some areas we could improve on? Feel free to let us know!

✨Follow us on our socials so you don't miss the next episode!

• Instagram

• X

• YouTube

• Spotify

• More Links

Watch it here:

Approaches to Interview Prep

Victoria shares her approach to interview preparation, which involves being consistent and practicing regularly through monthly sessions. She also stresses the importance of keeping a resume updated and being comfortable with vocalizing thoughts during interviews. Natasha adds that being interview ready also means incorporating interview skills into daily work practices.

According to the Saloni, practicing pair programming and verbalizing your thought process every day can make you more comfortable and prepared for interviews.

This not only helps you articulate your concepts clearly but also showcases your communication skills, which are essential in the tech industry. Also, the increasing use of AI tools like ChatGPT and GitHub Co-pilot can replace routine memorization of syntax and codes. Instead, interviewees should focus on developing their ability to articulate their thought process and prompt AI tools effectively.

Importance of Data Structures & Algorithms

Our team also touches on the topic of data structures and algorithm questions in interviews. Drawing from our own experiences without formal computer science education and still finding success in the industry, we believe it's crucial to recognize the current nature of interviews and the importance of adapting to different interview styles and questions.

Victoria shares her experience studying data structures and algorithms for tech interviews. She explains that while these concepts may not be used every day in as software engineer's job, they serve as valuable tools for problem-solving and demonstrate a candidate's ability to think critically. She emphasizes that mastering data structures and algorithms is essential for interview success, as it builds confidence in hiring managers that the candidate can solve complex problems.

However, we also understand that excessive focus on memorizing algorithms and their names may not be necessary, and instead, a solid understanding of the concepts and their applications is more important. Overall, we encourage a balanced approach to interview preparation, emphasizing the importance of both knowledge and mindset.

Understanding a Company's Interview Process

Not all companies ask algorithm questions and some may focus on creating an app or solving specific problems related to the position. Therefore, researching the companies and their interview processes is crucial. The speaker also suggests looking for a company culture that fits you and not just focusing on big tech companies. They mention that there are many mid-tier companies hiring and interviewing in specific ways.

How to build a resume

Natasha expresses her preference for using LinkedIn over creating traditional resumes, as she believes that all necessary information is already available on the platform. However, she acknowledges that her perspective may come from a place of privilege, as she was able to find jobs before the economic downturn.

She also emphasizes the significance of the resume in the interview process, as it helps interviewers understand the candidate's background and experience, allowing them to ask more specific questions. She suggests that updating a LinkedIn resume regularly with specific examples of projects and achievements can make it easier for interviewers to assess a candidate's value to a team.

What if you don't have prior experience? For university students, recent graduates, or those changing careers, structuring resumes should still focus on past experiences, no matter how minor. It's important to be specific in your resume descriptions.

We also recommend customizing resumes for specific companies and highlighting achievements and personal projects. By doing so, candidates can showcase their growth and unique personality to potential employers.

Conclusion

We hope you enjoyed the recap of this episode! We discussed a lot more that we did not mention in this article. We will be going into a lot more topics soon! Do leave your thoughts or any feedback in the comments below! What are some topics you would want us to talk about or cover? What are some areas we could improve on? Feel free to let us know!

✨Follow us on our socials so you don't miss the next episode!

• Instagram

• X

• YouTube

• Spotify

• More Links

This article is a summary of our 5th episode of ragTech! If you want to get the full experience listen on Spotify or watch on YouTube!

What is Agile?

Agile, according to Natasha, is not a defined set of practices, but a mindset and approach to work that fosters flexibility, adaptability, and collaboration. Agile and its related frameworks, such as Scrum and Kanban, are not exclusive to tech teams, but applicable to any team that adopts the mindset. Honesty and openness are essential values in Agile, encouraging transparency and communication within the team.

Through practices like Scrum's rituals, such as daily stand-up meetings, and visualizing progress on a board, teams can reinforce honesty and openness, ultimately improving collaboration and efficiency.

Agile values

Agile values like openness and honesty are fostered through the use of a visual platform, such as a board, where team members can see each other's tasks. Scrum also prescribes rituals like stand-ups, sprint planning, and retrospectives, which are meant to provide frequent check-ins and opportunities for team members to communicate and reorganize tasks.

Agile vs. Waterfall

We also contrast the Agile/Scrum approach with the "waterfall model," explaining that in the waterfall model, teams follow a sequential process in which each phase must be completed before moving on to the next. This leads to long development cycles and challenges in addressing issues as they arise.

Unlike waterfall where teams work on one service sequentially, in Agile, multiple teams work on different parts of the project concurrently. continuous delivery, feedback, and testing are prioritized at every stage.

Agile philosophy focuses on efficient delivery of items systematically through sprints, retrospectives, and the involvement of various team members such as product managers, designers, testers, and scrum masters.

One intriguing aspect discussed is the role of a scrum master, which is primarily focused on prescribing the rituals of Scrum, spreading the culture within the team, and ensuring its application is contextually relevant. Despite the somewhat obscure term "scrum," it references a legitimate job title, and at one point was reportedly the highest-paid role in tech. The daily duties of a scrum master involve fostering change in teams transitioning from waterfall to Agile, promoting the Agile methodology within the organization, and ensuring that the team follows the specified methodologies.

We discuss the contrasting approaches between Agile and traditional waterfall development, emphasizing the role of Scrum Masters in upholding an Agile culture and overcoming potential pitfalls such as resistance to change and excessive focus on certifications. Whether Agile is suitable for a team depends on their unique context and goals.

We provide an example of a team with different incentives adopting Agile practices and the subsequent benefits gained from it, such as:

• increased communication

• collaboration

• facilitating understanding and empathy

Transitioning into Agile: Drawbacks?

Practices involved in transitioning to the Agile way of working are giving and receiving feedback, retrospectives, and standups.

The importance of a blameless culture and empathy must be emphasized in these practices. We also acknowledge that while the openness, honesty, and collaboration aspects of Agile are beneficial, adopting this mindset may have drawbacks, such as resistance to change and too many meetings.

Appointing a scrum master to ensure meetings run efficiently and encourage team members to prepare their talking points beforehand can make the most of their time together and reduce these drawbacks.

Scrum: Oversaturation

We agree that a Scrum Master is essential in upholding the culture as they can objectively assess the team's progress, identify disengagement, and encourage continuous improvement. However, we were also concerned about the oversaturation and commercialization of Scrum certifications, which may lead people to misunderstand the importance of truly practicing Agile principles and living an iterative, feedback-driven mindset.

Is Agile for everyone?

Then, we moved on to discuss the applicability of Agile methodologies, specifically Scrum, to various teams and workplaces. Though it's true that constructive criticism is essential for growth, not everyone may benefit from the Agile approach.

For teams in large enterprises with well-established processes and set goals, imposing Agile may not be beneficial, as it could create unnecessary friction. The Agile mindset, which focuses on experimentation and iteration, is more applicable to teams starting new projects. However, even in larger organizations, some aspects of the Agile principles, such as honesty, transparency, and clean communication, can be adopted to improve collaboration and productivity. Ultimately, whether or not Agile is suitable for a team depends on the team's specific context and goals.

To illustrate an example, Victoria describes how her team, consisting of multiple individuals with different incentives, adopted Agile methodologies and Scrum practices while working on separate but related projects. Initially, there was resistance and frustration due to the perceived time-wasting activities, such as cross-team communication and learning about other teams' products. However, as they began to collaborate, they realized the benefits of shared knowledge and potential for reusing each other's components. Over time, they became more open in their communication and started iterating constantly. This led to increased cross-team understanding, reduced stress, and improved ability to cover for team members during absences.

Conclusion

We hope you enjoyed the recap of this episode! We discussed a lot more that we did not mention in this article. We will be going into a lot more topics soon! Do leave your thoughts or any feedback in the comments below! What are some topics you would want us to talk about or cover? What are some areas we could improve on? Feel free to let us know!

✨Follow us on our socials so you don't miss the next episode!

• Instagram

• X

• YouTube

• Spotify

• More Links

This article is a summary of our 3rd episode of ragTech! If you want to get the full experience listen onSpotify or watch on YouTube!

Software Developer Vs Software Engineer

Saloni's opinion is that there is no difference between the two. Different companies call their employees differently. But Saloni herself prefers to be called a Developer because Engineer, to her, is more hardware/mechanical related. However, we have read that typically the difference comes when comparing building of the software - whether there is scale in mind. Our take is that there is no definite difference except for what is personal preference.

Saloni's Software Developer Career Journey

Saloni graduated with Computer Science degree. Since then she has been working in core software development roles. Just so happened that every 2 years she has switched companies. This was intentional, there was a better opportunity and no room for growth usually when a switch is required. She has been fortunate enough to move multiple different industries - government, edutech, IoT to now fintech.

She loves being in fintech because of her love for money and tech!

Saloni also explained that she is a fullstack developer - which means she is able to work on frontend (client facing websites) as well as backend (databases, server-side). But she leans towards backend a little more. According to her, all fullstack developers lean towards one or the other.

Being Interview-Ready

Saloni believes in being interview ready in the sense that she does not want to be at the mercy of any employer. She started a series of sessions hosted on WomenWhoCode Singapore's platform. By the way, if you are interested do sign up as a volunteer on the above website or stay tuned to our events on Meetup.

During covid many software developers lost their jobs among others, and it is very tedious to suddenly start preparing for a Software Developer interview (algorithms, computer science concepts revision) - it usually is a 3 month effort to even be ready for an interview. Therefore, Saloni started these sessions of mock interviews where she would practice her interviewing skills and also be up to date as an interviewee. She believes Teaching is the best way to learn, so she is always sharing her knowledge with the community.

With this she learnt what it takes to be an above average software developer and then gave an example in the podcast where she she was able to ask the interviewer some tough questions because she knows she did well in the interview and then went on to interviewing the interviewer. She asked “do you (as the tech lead) believe in mentorship among the team or more self-learning?” These kind of questions help her gauge the kind of employer she is dealing with and how her experience will be in the company.

Robust Code

In the episode, Victoria asks about how to explain robust code to a non-programmer. Saloni explained that robust code would mean code that gracefully handles all scenarios and does not break with edge cases.

Also, longer code is not necessarily bad code, it might mean that it’s more modularised or easier to understand. It’s a common misconception among non-programmers that shorter code is better code.

Conclusion

We hope you enjoyed ep3! We discussed a lot more that we did not mention in this article. We will be going into a lot more topics soon! Do leave your thoughts or any feedback in the comments below! What are some topics you would want us to talk about or cover? What are some areas we could improve on? Feel free to let us know!

✨Follow us on our socials so you don't miss the next episode!

• Instagram

• X

• YouTube

• Spotify

• More Links

This article is a summary of our 2nd episode of ragTech! If you want to get the full experience listen on Spotify or watch on YouTube!

What is a Solutions Engineer?

A solutions engineer is basically a client-facing engineer.

Here are things you can expect to do day-to-day as a solutions engineer:

• Collaborate with Sales colleagues to deliver technical presentations and product demonstration to C-Level executives from large enterprises operating within a region.

• Provide technical consultation and solution discovery to provide insights on how large enterprises can utilize the company's products within their business processes.

• Collaborate with internal teams to respond to RFPs (Request for Proposal) and RFIs (Request for Information).

• Provide technical and design direction to merchants' implementation teams with respect to how they can integrate with company's products to match their business needs

• Build proof of concepts to provide strong visualizations for the various product integration points

• Level learning curves for implementation teams in utilizing the SDKs and APIs of the company's product stack

• Convey merchants' feedbacks and needs into potential product enhancements/ fixes to product teams

• Build internal tools and features with various teams to innovate and improve pain points of products we gleaned from merchants

• Test products from the product team for quality assurance before GA (general availability)

How Victoria discovered Solutions Engineering

Victoria graduated with a Commerce (Finance) degree and has always been interested in building things with code and solving problems.

She was actively publishing on her tech blog when she was applying to software engineering jobs. That was when a recruiter discovered her blog and recommended trying solutions engineering. Since it was a role that can utilize both her experience in business and her current skills in tech, she ventured into solutions engineering.

The Power of Blogging leads to many opportunities

Ever since Victoria started her blog, she has been able to build her community, network and personal brand. In a talk she has done for Showwcase: Benefits of Content Creation as a Developer and in this episode, Victoria explains how tech blogging causes a chain reaction of multiple opportunities for her.

From her career as a solutions engineer, her GitHub Star award, being a part of WomenWhoCode Singapore's leadership team to ragTech. She said how these turns of events feel surreal to her and something she would never have expected to happen. It all started from her passion of sharing knowledge and learning consistently that she was able to grow an audience in blogging.

Humble Beginnings

Victoria was not an exceptional writer in any way when she first started blogging. In fact, she recalled spending an entire month revising her first article before publishing it!

However, she eventually realized that "[she] was her own first audience" and focused on improving her writing through publishing more articles consistently instead of perfecting one article.

So what did she write about at first?

She started with a 100DaysOfCode challenge, and she would log her learnings, challenges she faced and how she overcome those in a blog post that she would write every day. Blogging became a way for her to record and share her learnings.

That was how more people discovered her articles and found them valuable. Some also kindly left feedback which helped her improve faster.

Once she gained an audience, she started writing more seriously and published series such as her Node.JS or GraphQL series, which are still valuable for people to read till today.

Screenshot from the episode where Vic is sharing how she's left with 9 fingers to work LOL

Conclusion

We hope you enjoyed our 2nd episode of ragTech: A Look into Solutions Engineering and Tech Blogging! Do leave your thoughts or any feedback in the comments below! What are some topics you would want us to talk about or cover? What are some areas we could improve on? Feel free to let us know!

✨Follow us on our socials so you don't miss the next episode!

• Instagram

• X

• YouTube

• Spotify

• More Links

What is this "tech industry" like really? Whether you are working in a non-technical industry or not, technology is at the forefront of our lives in this era.

This article is a summary of our first episode of ragTech! If you want to get the full experience listen on Spotify or watch on YouTube!

Welcome to ragTech!

Hi everyone! This is ragTech. We are a team of ragtag individuals who are passionate about content creation and you guessed it - tech! Hence, ragTech is born! Yes, it is in camel case~

Meet Our Team

Victoria Lo

In the first episode, you'll discover that Victoria's journey in tech began with game development using Visual Basic! She's also a tech blogger who constantly engages with her readers to empower them on their own journeys.

As shown in the first episode, she adores cats and can't resist petting Natasha's feline companions.

Natasha Ann

Natasha is extremely knowledgeable in the tech industry. As someone with experience in the software engineering field, she provides valuable insight into many of the topics discussed in this episode. Her profound understanding and expertise truly shine through!

It was thanks to Natasha that our first episode recording was done super smoothly, and be sure to spot Natasha's cats, Pip and Po, in the video!

Saloni Kaur

Being the most experienced in the tech industry within this team, it is easy to learn a lot from anything that Saloni shares. She has mentored a lot of people getting into tech and believes that "Teaching is the best way to learn".

In the first episode, she revealed that she starts her tech journey with game development too, on Flash (ActionScript)! She has dabbled into robotics as well and entered micro-mouse competitions!

Check out our 2 secret team member's bios on our Instagram!

Myths

"People in tech earn a lot"

In reality, it's more of a spectrum, and it differs based on region. And the scaling depends on the company and the area you are in.

"You must learn the latest tech"

FOMO is often seen in tech because of this, but it really actually depends on whether your work requires it and the use case. If you don't need it, why learn it? If you don't use it, you lose it. Also, it can make the code unnecessarily complex.

"All people in tech know how to code"

Some people who work for tech companies can call themselves "working in tech" and people tend to think they are programmers. This is not the case because there are plenty of those who know little to no code like data analysts, etc.

Key points

1. ragTech is here to simplify tech for everyone

A lot of things in tech seem very intense and serious. We want to talk about tech in a more casual tone. Our first episode is a prelude to all the possible topics we want to explore more deeply in upcoming episodes. We are keeping things light and general before actually expanding on a lot of the things we talked about in this episode.

2. Tech is not just about software engineering, there are plenty of areas to explore

Most people would think that the path in tech is a one-way track to software engineering or AI. What about hardware? What about cybersecurity?

In this episode, our team lightly addresses this topic, resolving to increase the visibility of the various areas of tech that will be featured in future episodes of ragTech.

3. Career path in relation to passion vs. money

We talked about the balance of choosing a career in tech for the passion or the moolah. There are a lot of cases we see of burnout happening when the primary motivation to be in tech is simply for the pay.

We have also seen employers filtering resumes for those without side projects, as they deemed applicants as "less passionate" about the career. Of course, at the end of the day, it's not just about your GitHub commit history. We plan to explore more on this topic.

Conclusion

We hope you enjoyed our first episode of ragTech! Do leave your thoughts or any feedback in the comments below! What are some topics you would want us to talk about or cover? What are some areas we could improve on? Feel free to let us know!

Follow us on our socials so you don't miss the next episode!

• Instagram

• X

• YouTube

• Spotify