Forem: daniel llach

LEGO Lessons in React: When My 5-Year-Old Made Me Rethink Component Design

daniel llach — Sun, 01 Dec 2024 23:48:16 +0000

Remember that feeling of opening a new LEGO set as a kid? The excitement, the clear instructions, the satisfaction of pieces clicking together perfectly. Now remember your last code review of a "flexible" enterprise component. Not quite the same feeling, is it?

After years of watching developers (including myself) struggle with over-engineered solutions, I've learned that the best React architectures have more in common with LEGO than with the complex machinery we sometimes try to build.

The LEGO Principle: Simple Pieces, Infinite Possibilities

What My 5-Year-Old Daughter Taught Me About API Design

Last weekend, I watched my daughter play with her LEGO set. "Today we're building a dog park!" she announced excitedly. Without any documentation or "senior LEGO architect" guidance, she proceeded to create slides, sandboxes, a water area, feeding stations, and play zones for dogs. The next day? "Let's make cars!" And just like that, the entire dog park transformed into a fleet of vehicles.

This hit me hard. Here was my 5-year-old intuitively understanding something we often overcomplicate in software development: with the right building blocks, you can create anything, transform everything, and rebuild without fear. Each LEGO piece had one clear purpose, connected in obvious ways, and worked reliably every time.

Meanwhile, back at work, we had a "flexible" component that looked like this:

// The "enterprise-ready, flexible" approach
const EnterpriseDataComponent = ({ 
  data,
  configurationMatrix,
  transformationPipeline,
  errorBoundaryStrategy,
  optimizationHeuristics,
  // ... 20 more intimidating props
}) => {
  useEffect(() => {
    // 100 lines of setup logic
  }, [/* dependency array longer than my coffee order */]);

  return (
    // JSX that would make a senior dev cry
  );
};

Something was very wrong with our approach.

The LEGO Master Builder's Guide to React

1. Start with Perfect Bricks

// A basic LEGO brick - it does one thing perfectly
const Button = ({ onClick, children }) => (
  <button 
    onClick={onClick}
    className={styles.button}
  >
    {children}
  </button>
);

// A slightly more specialized brick
const ConfirmButton = (props) => (
  <Button 
    {...props}
    className={styles.confirm}
  />
);

2. Build Bigger Things from Simple Pieces

// Combining bricks into something useful
const ConfirmationDialog = () => {
  const { confirm, cancel } = useDialog();

  return (
    <Dialog>
      <DialogTitle>Are you sure?</DialogTitle>
      <DialogActions>
        <ConfirmButton onClick={confirm}>Yes</ConfirmButton>
        <Button onClick={cancel}>No</Button>
      </DialogActions>
    </Dialog>
  );
};

3. Hide the Complex Machinery

// The complex machinery is there, but hidden
const useDialog = (options = {}) => {
  // Level 1: The Happy Path (90% of developers only need this)
  const simplePath = {
    confirm: () => handleConfirm(),
    cancel: () => handleCancel()
  };

  // Level 2: Extended Features (9% of cases)
  if (options.advanced) {
    return {
      ...simplePath,
      onBeforeConfirm: handlePreConfirm,
      onAfterCancel: handlePostCancel
    };
  }

  // Level 3: Escape Hatch (1% of power users)
  if (options._superPowers) {
    return {
      ...simplePath,
      _internal: internalAPIs,
      _context: dialogContext
    };
  }

  return simplePath;
};

The Design System: Your Master Builder Kit

Think of your design system not as a collection of components, but as a LEGO Master Builder Kit. Each piece should be:

Instantly Recognizable

// Anyone can understand this
const Card = ({ title, children }) => (
  <div className={styles.card}>
    {title && <h2>{title}</h2>}
    {children}
  </div>
);

Predictably Connectable

// Pieces that work together naturally
const ProductCard = ({ product }) => (
  <Card>
    <CardImage src={product.image} />
    <CardContent>
      <ProductDetails product={product} />
    </CardContent>
    <CardActions>
      <AddToCartButton product={product} />
    </CardActions>
  </Card>
);

Safely Extensible

// Senior devs can add features without breaking simplicity
const withAnalytics = (WrappedComponent) => {
  return function EnhancedComponent(props) {
    useAnalytics(props.analyticsEvent);
    return <WrappedComponent {...props} />;
  };
};

// Still simple to use
const TrackableButton = withAnalytics(Button);

The Security Advantage: Fewer Entry Points, Better Control

When you build with well-defined "LEGO bricks", security becomes more manageable:

// One secure implementation, used everywhere
const SecureButton = ({ onClick, children }) => {
  const { validatePermissions } = useAuth();

  const handleClick = () => {
    if (validatePermissions()) {
      onClick();
    }
  };

  return <Button onClick={handleClick}>{children}</Button>;
};

// Developers can't accidentally bypass security
const DeleteButton = () => (
  <SecureButton 
    permission="delete:items"
    onClick={handleDelete}
  >
    Delete
  </SecureButton>
);

The Unexpected Benefits

After implementing these principles, we discovered some surprising benefits:

Junior developers became productive faster
- "It just makes sense" was a common feedback
- Less time reading docs, more time building
Senior developers found it easier to optimize
- Clear boundaries made performance improvements isolated
- Easier to implement advanced features without affecting basic usage
Code reviews became discussions about business logic
- Instead of "Why is this so complex?"
- We got "This is exactly what we needed"
Documentation practically wrote itself
- When your APIs are intuitive, you need less documentation
- What documentation you do write is focused on advanced use cases

The Master Builder's Wisdom

Remember:

If your components need a PhD to understand, you're doing it wrong
Complex features should be opt-in, not opt-out
The best code is the code you don't have to explain
Build for the many, extend for the few

Looking Forward

The future of React development isn't about who can build the most complex system. It's about who can make complex systems feel simple. Just like LEGO has been doing for generations.

Next time you're designing a component or system, ask yourself: "Could a 5-year-old understand how these pieces fit together?" (Okay, maybe not the code itself, but the mental model should be that clear.)

How do you keep your React components simple yet powerful? Share your LEGO-wisdom in the comments below!

How to Scale a Team from 6 to 25: Building Down to Move Up

daniel llach — Mon, 25 Nov 2024 00:45:24 +0000

Traditional career growth often feels like climbing a ladder — always reaching for the next rung up. But what I learned while scaling an Autodesk team taught me something different: sometimes, the best way to grow is to build downward, creating opportunities for others to rise.

Here’s how I transformed a 6-person development team into a thriving organization of 25 professionals across three specialized units, and the unexpected lessons about leadership it taught me.

What started as a team of four developers, one project manager, and myself as Tech Lead grew organically to 10–12 people during the first year, as we established our processes and culture. However, the real challenge emerged when we needed to scale rapidly: new projects demanded we nearly double our size, pushing me to rethink our entire structure and approach to leadership.

The Pivot: Breaking Down to Scale Up

With this rapid growth ahead of us, I proposed splitting the team into three specialized units, each with its own leader.

The restructuring plan was based on technological specialization:

React Base Project Team:

Focused on core React architecture
Handled foundational components and features
Maintained core project stability

Web Components Project Team:

Specialized in web component development
Created reusable, framework-agnostic components
Ensured cross-platform compatibility

Design Team:

Contribute to the design system team:
Ensured UI/UX consistency
Bridged the gap between design and implementation

This technical division wasn’t arbitrary — it aligned with Autodesk’s architectural vision and allowed each team to develop deep expertise in their domain while maintaining clear interfaces between teams.

The Key Innovation: Rather than maintaining direct control, I would:

Promote two developers to Tech Lead positions, each specializing in their respective technical domains
Elevate a UX designer to lead the design team
Position myself as a leader of leaders, ensuring architectural consistency across all three areas

Implementation: The Leadership Matrix

The new structure worked like this:

Benefits of this approach:

Created clear growth paths for team members
Reduced communication overhead
Enabled specialized focus for each team
Allowed for faster decision-making
Provided leadership development opportunities

Reality Check: When Growth Comes Knocking

While I’ve presented this scaling journey in a structured way, I should be honest: much of this happened faster than ideal. The reality of being a contractor means sometimes having to move at the speed of business rather than the speed of perfect planning.

Our big scaling moment came unexpectedly during a visit to Autodesk’s Portland offices. The news of a major project would require adding eight team members, while our existing projects needed five more developers and UX designers. This meant we would nearly double our size, going from 12 to 25 people. I had to present my team-splitting strategy the very next day. Fortunately, both the Autodesk manager and director loved the idea, and my Globant leadership supported it as well.

Did it work? Yes. Could it have been smoother with more preparation time? Absolutely. While we succeeded, I would have loved more time to train the new leaders before throwing them into their roles.

Learning Through Challenges

New Leaders’ Journey

Not everything was smooth sailing. One of our biggest challenges came from an unexpected place: my assumption that new leaders would naturally adopt my leadership style. I learned that leadership transition requires explicit knowledge transfer — not just about processes, but about leadership philosophy and approach.

Key Learnings from This:

Leadership styles need to be actively taught, not just demonstrated
Internal leadership processes need clear documentation
New leaders need space to develop their own style while maintaining team consistency

Words of Wisdom for Future Leaders

After this journey, here’s what I wish someone had told me at the start:

The Urgency Trap: Don’t let the daily urgent tasks prevent you from working on important, non-urgent matters. It’s tempting to focus solely on putting out fires, but that’s a recipe for perpetual reactiveness. Block time for:

Strategic planning
Team development
Process improvement
Identifying growth opportunities

Remember: If you’re too busy fighting fires, you’ll miss the chances to fireproof your house.

Investment in People: The time you spend developing your team members isn’t a cost — it’s an investment that pays dividends in:

Team loyalty
Improved performance
Reduced stress
More opportunities for everyone

Looking Forward

Now, as I begin my new role at Hilton account, I’m taking a different approach. Armed with these experiences, I’m investing time in the “Important but Not Urgent” quadrant from day one:

Identifying potential leaders early
Building scalable processes before we need them
Creating training programs proactively
Establishing clear growth paths ahead of time

The experience taught me that scaling a team isn’t just about managing more people — it’s about creating systems that allow others to grow. By building down, you create a foundation that allows everyone, including yourself, to rise higher.

What’s your experience with scaling teams? Have you found traditional hierarchical growth limiting? Share your thoughts in the comments below.

Photo by Nandhu Kumar on Unsplash

[About the Author: A Subject Matter Expert with 12+ years in IT, currently leading technical initiatives at Hilton and mentoring tech leads. Previously led teams at Autodesk and other major enterprises.]