Menu

Writing.

Thoughts on software, startups, design systems, creator tools, and the things I'm learning while building.

Why I Write
The themes that keep showing up in my work and curiosity.

Writing helps me think more clearly. Some ideas are too valuable to leave floating around in my head, so I write them down. This page is a collection of lessons, observations, experiments, and reflections gathered from building products, studying design, and navigating the world of technology.

Frontend Engineering
Design Systems
Product Design
Startups
Creator Tools
Building in Public
Technology
Culture

Latest Articles

Engineer, But Not an Engineer
Engineer, But Not an Engineer
May 30, 2026

When someone asks what I do, the easiest answer is simple: “I’m a Software Engineer.” It’s the title on the job description. It’s what I get paid to do. It’s what I’ve spent years learning and practicing. But if I’m being truthful, I don’t think I’m an engineer yet. Not because I doubt my abilities. Not because I’m looking down on myself. And not because I’m suffering from some severe case of imposter syndrome. I say it because the word “Engineer” carries a weight that I don’t think should ever be fully arrived at. To me, engineering isn’t a destination. It’s a commitment to continuous learning, improvement, curiosity, and problem-solving. It’s a craft that takes decades to refine. The moment I become completely comfortable calling myself an engineer may be the moment I stop growing as one. Every time I learn something new, I discover ten more things I don’t know. Every project teaches me that there are better ways to design systems, write code, communicate ideas, lead teams, and build products. The deeper I go, the larger the field becomes. So while I may work as a Software Engineer, I prefer to think of myself as someone practicing engineering. Someone learning engineering. Someone becoming an engineer. Because becoming never really ends. More Than Code Another reason I hesitate to let the title define me is that coding is only one part of what I love. I love design. Not just software architecture and database design, but visual design too. Web design. Brand design. User experience. The subtle details that make products feel intuitive, memorable, and human. I wouldn’t call myself a professional graphic designer, but design has shaped the way I think. It has taught me to notice details that many people overlook. A button that’s slightly misaligned. A color palette that feels inconsistent. An interface that technically works but feels frustrating. Design has given me taste. It has trained me to ask not only, “Does it work?” but also, “Does it feel right?” That mindset has made me a better builder overall. Because great products rarely come from code alone. They come from the combination of engineering, design, communication, empathy, and vision. The Danger of Titles Titles are useful. They help people understand what we do. But titles can also become cages. The moment we become overly attached to one label, we risk limiting who we can become. If I tell myself I am only an engineer, I might ignore opportunities to explore design. I might stop learning about business. I might overlook media, storytelling, community building, or entrepreneurship. I might start protecting an identity instead of pursuing curiosity. And curiosity is often where growth begins. Some of the most interesting people I’ve met refuse to fit neatly into a single category. They’re engineers who understand design. Designers who understand business. Founders who understand technology. Creators who understand systems. Their strength comes not from choosing one box, but from connecting many disciplines together. Forever a Student So yes, I work as a Software Engineer. I am grateful for the title. I have worked hard for it. But I try not to wear it too tightly. There is still too much to learn. Too many mistakes to make. Too many ideas to explore. Too many disciplines that inspire me. If anything, I hope I never fully arrive at being an engineer. Because the day I believe there is nothing left to learn is probably the day I stop becoming one. For now, I am content with something simpler: A curious person who happens to write software. A builder who loves design. A student of many crafts. An engineer, but not quite an engineer.

My 2026 Journey as a Developer: One Goal, Many Discoveries
My 2026 Journey as a Developer: One Goal, Many Discoveries
May 25, 2026

At the start of 2026, I made a simple decision that felt almost too vague to be meaningful. I didn’t set multiple goals. I didn’t break things into strict milestones. I didn’t try to optimize the year with a checklist of achievements. I set just one goal: Learn more. That was it. No specific roadmap of what I would learn, no fixed domain, no pressure to define the outcome too early. Just a commitment to growth, curiosity, and becoming better than I was the year before. At the time, I thought I might eventually narrow it down — maybe backend systems, maybe mobile development, maybe cloud engineering. But something unexpected started happening as the months went by. I found myself consistently drawn to something I hadn’t planned for. Design. The Shift I Didn’t Plan For It started subtly. While building projects, I began paying more attention to layouts than logic. I started noticing spacing before functionality. Colors started to matter more than I expected. The way users feel about an interface became just as interesting as how it works. At first, I thought it was just a phase — something every developer goes through when they get tired of backend problems or repetitive logic. But it didn’t fade. Instead, it grew. I started watching design breakdowns, reading UI articles, and observing how well-designed products feel effortless. I began to understand that design wasn’t just decoration — it was communication. And as I learned more, I realized something important: I wasn’t just interested in design. I was starting to care about it. Not Just One Type of Design The deeper I went, the more I realized design is not a single skill — it’s a spectrum. Graphic design taught me about visual storytelling. Web design showed me structure and layout thinking. UI/UX design opened my eyes to user behavior, empathy, and experience. Each layer added something new to how I think as a developer. Instead of just asking “How do I build this?”, I started asking: “How should this feel to use?” “Is this intuitive or just functional?” “Does this guide the user naturally?” These questions changed the way I approach my work. What “Learn More” Actually Became Looking back, my original goal — learn more — felt too vague at first. But now I see its strength. Because it didn’t confine me to a specific track, it allowed me to discover one naturally. It didn’t force me into a predefined identity. It gave me space to evolve into one. And right now, that evolution is pointing clearly toward design. Not as a side skill. Not as an optional extra. But as something I want to take seriously this year. Where I Am Now I’m still a developer. That hasn’t changed. But I’m also becoming someone who thinks more deeply about design. Someone who wants to improve visual communication. Someone who wants to build interfaces that feel intentional, not accidental. Someone who understands that good software is not just written — it’s designed. I don’t think I’ve “arrived” anywhere yet. If anything, I feel like I’ve just found a new layer of learning to explore properly. Moving Forward For the rest of 2026, my goal remains the same: Keep learning. But now I have more clarity about where that learning is pulling me. Design isn’t replacing my development journey — it’s expanding it. And I’m excited to see how far that combination can go. Because sometimes, the best goals aren’t specific directions. Sometimes, they’re just invitations: To stay curious. To pay attention. And to follow what keeps pulling you forward.

Mastering ReactJS: 10 Best Practices Every Front-End Developer Should Know
Mastering ReactJS: 10 Best Practices Every Front-End Developer Should Know
January 2, 2024

Introduction ReactJS has become the go-to library for building dynamic and interactive user interfaces. To harness its full potential, front-end developers need to adopt best practices that not only enhance code quality but also contribute to maintainability and performance. In this article, we’ll explore 10 essential best practices for ReactJS development that can elevate your coding skills and streamline your project workflow. 1. Component Organization and File Structure One of the fundamental aspects of React development is maintaining a clear and organized project structure. Learn how to structure your files and components for better readability and scalability. 2. Use Functional Components and Hooks Discover the power of functional components and how leveraging React Hooks can simplify state management and lifecycle methods. This practice not only aligns with modern JavaScript practices but also improves the overall performance of your React applications. 3. State Management Strategies Effective state management is crucial for building robust React applications. Explore different strategies, including local state, lifting state up, and using state management libraries like Redux for larger-scale projects. 4. Immutable Data and Pure Components Learn the importance of immutability in React applications and how it helps prevent unexpected side effects. Explore the use of PureComponent and memoization techniques to optimize rendering and boost performance. 5. Conditional Rendering and Ternary Operators Master the art of conditional rendering to create dynamic user interfaces. Discover how to use ternary operators for concise and readable conditional statements, enhancing the maintainability of your code. 6. Optimize Rendering Performance Uncover strategies to optimize the rendering performance of your React application. From lazy loading to code splitting and leveraging React’s built-in optimizations, these techniques ensure a smooth and responsive user experience. 7. Error Boundaries Explore the concept of error boundaries in React to gracefully handle runtime errors. Implementing error boundaries helps identify and address issues proactively, ensuring a more stable and reliable application. 8. Prop Types and TypeScript Dive into the world of PropTypes and TypeScript for effective type checking in your React components. Enhance the predictability and robustness of your code by enforcing the expected types of props. 9. CSS-in-JS or Styled Components Choose the right styling approach for your React project. Whether it’s CSS-in-JS or Styled Components, encapsulating styles with components ensures a maintainable and modular styling solution. 10. Testing Strategies Understand the importance of testing in React development and explore different testing strategies. From unit tests with Jest to end-to-end testing, ensure the reliability and stability of your React applications. Conclusion By incorporating these 10 best practices into your React development workflow, you’ll be well-equipped to build scalable, performant, and maintainable applications. Stay ahead of the curve and elevate your ReactJS skills with these essential guidelines for front-end developers. Happy coding!

More thoughts are on the way.

I’ll continue sharing ideas on software, design systems, startups, and product thinking.