But somewhere along the way, I started wondering what was holding those beautiful creations up.

Even before I knew the term “T-shaped engineer,” beadwork was already teaching me valuable lessons. I began exploring beyond the UI, diving into APIs and data handling with Firebase (Firestore for storage, Storage for file uploads, and Hosting for deployment). I drew inspiration from Figma Community and Behance, recreating real products as practice. One of my earliest experiments was building a replica of Hashnode for my AltSchool capstone project.

That curiosity, sparked by the same mindset I use when crafting with beads, marked the beginning of my journey toward becoming a T-shaped engineer.

A beaded emoji wearing a baseball cap

A landing page for apartment booking web appliaction

Who is a T-Shaped Engineer?

A T-shaped engineer has:

• Deep expertise in one area (the vertical bar of the T)

• Broad knowledge across multiple areas (the horizontal bar)

For me:

• My depth is frontend development.

• My breadth now includes APIs, databases, system design basics, product thinking, and DevOps.

Recently, I built a full invoicing application from idea to production, and I’m currently working on a color sketch application. These projects pushed me to think beyond pixels and consider the entire product lifecycle, lessons I first learned through beadwork.

My Vertical: Frontend as My Foundation

Frontend development has always been my strongest area. I focus on building accessible, intuitive, and scalable user interfaces using tools like:

• React / Next.js

• Vue

• React Native

Beyond writing code, I obsess over user experience, information architecture, and real-world usability. For me, frontend isn’t just about making things look good it’s about creating experiences that feel seamless and inclusive. Just like carefully selecting and arranging beads, every detail matters.

My Horizontal Growth: Expanding Beyond the UI

Beadwork taught me that beauty alone isn’t enough, the piece must also be strong and well-connected. That same principle pushed me to look beyond the interface.

I started asking questions I used to ignore:

• Where is this data actually stored?

• How is it structured?

• How does deployment really work?

• What happens after a user clicks that button?

Instead of always relying on service providers or other team members, I wanted to understand the mechanics under the hood. This curiosity led me to explore backend concepts (APIs and databases), system design basics, closer collaboration with product and design teams, end-to-end debugging, and DevOps practices like deployment and hosting.

The path wasn’t linear; it was messy and frustrating at times, but deeply necessary.

The Turning Point

The real shift happened when I stopped treating “not a frontend problem” as a dead end.

I remember working on a feature where user profiles weren’t loading properly. My first instinct was to check the API response. The data was nested three levels deep and messy. In the past, I would have simply flagged it for the backend team and waited. Instead, I dug in.

That investigation taught me about database normalization and how a simple join could have prevented the nesting issue entirely. It showed me how much time I had been losing by not understanding the root cause.

From that moment, I started tracing problems end-to-end, from data flow in the backend all the way to how it renders on screen. I stopped thinking in “frontend vs. backend” and began thinking in complete systems. Beadwork had already trained me to see how individual pieces connect to create something stronger, now I was applying that same thinking to software.

What Changed After Becoming T-Shaped

Becoming more T-shaped didn’t pull me away from frontend rather it made me significantly better at it.

Here’s what changed:

• I no longer wait passively for backend fixes; I can investigate and often resolve (or clearly explain) issues myself.

• In my invoicing app, understanding deployment and data structure helped me quickly fix a critical export bug that would have otherwise delayed launch by days.

• I communicate more effectively with backend, product, and design teams because I now speak their language.

• I’ve become far more independent and confident as a developer.

I now think beyond individual components, I think in interconnected systems. Just like a well-made bracelet that’s both beautiful and durable.

Before

After

The Challenges

This journey wasn’t smooth. Growing horizontally while protecting my frontend depth brought real friction.

• Burnout from trying to learn too many new concepts at once.

• Time pressure when client deliverables clashed with my learning goals.

• Context switching that sometimes left me mentally exhausted.

There were weeks when I felt stretched thin, jumping between optimizing a React component in the morning and debugging a Firebase security rule in the evening, all while needing to ship features on time. Those moments were tough, but they also forced me to get better at prioritizing, setting boundaries, and learning more efficiently.

Final Thoughts

I still proudly call myself a frontend engineer, that’s my foundation and my first love.

But thanks to the lessons from beadwork, I’m no longer limited to just building interfaces. I now understand how systems connect, how products come together end-to-end, and how to solve problems that span the entire stack.

If there’s one thing I’ve learned, it’s this: start with depth, but don’t stay confined there. Expand thoughtfully, explore curiously, and keep connecting the dots.

I still love the craft of crafting a beautiful, pixel-perfect interface just like I love weaving colorful beads into a bracelet. But now I also care deeply about what makes it durable, how it connects to the larger system, and whether it truly solves the right problem for users.

That’s the difference between making something that simply looks good and building something that actually works well in the real world.

Becoming a T-shaped engineer has changed how I think, build, and grow; and I’m still evolving.