Workplace Image Kickscale

Gerson Joao, Lead Front End Developer bei Kickscale

Description

Gerson Joao von Kickscale spricht im Interview über seinen Weg beim Software Development – angefangen in der Schulzeit bis hin zu seiner aktuellen Arbeit als Lead Front End Development – und gibt Tipps für Beginner.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In “Gerson Joao, Lead Front End Developer bei Kickscale,” Gerson Joao traces his journey from university internships and early exposure to programmers to studying software development and building a career in frontend. As a Lead Front End Developer, he prioritizes customer closeness and uses monitoring tools to verify whether features are understandable and solve problems, while collaborating tightly with his team using React, TypeScript, and Figma for specifications. His advice: build solid web fundamentals (React/Angular), stay curious and learn by doing, and apply creativity in visualization so users enjoy the product.

From Internship to Lead Front End Developer: Gerson Joao (Kickscale) on Customer Proximity, Team Culture, and Creativity in Frontend

A clear path into frontend leadership

In “Gerson Joao, Lead Front End Developer bei Kickscale,” we heard a refreshingly grounded devstory: early internships spark curiosity, a focused degree builds fundamentals, and a role at the product’s edge combines customer proximity, tight teamwork, and creative responsibility. What stands out most is how Gerson frames frontend as the living interface between people and product. His compass is simple and demanding at the same time: understand whether customers like using the product and whether they find it understandable—and examine whether new features solve problems or unintentionally introduce new ones.

From a DevJobs.at editorial perspective, three themes define his approach:

  • Customer proximity as an anchor: By staying close to users and employing monitoring tools, Gerson continually checks whether the product is understood and valuable.
  • Shared evaluation in the team: Close collaboration—supported by clear specifications in Figma—raises the odds of shipping the right solution.
  • Creativity as a core skill in frontend: When you visualize data, you design experiences. Creativity shapes whether people feel, “I genuinely enjoy using this.”

How it started: early exposure, steady learning

Gerson’s path begins in school with multiple internships at a university. There he meets programmers, hears first-hand what software development involves, and discovers a strong interest in the field. After finishing school, he begins a degree in “Softwareentwicklung Management,” deepening his understanding step by step.

What we appreciate about this part of his journey is its consistency: no shortcuts, no theatrics—just steady learning. As he puts it, he “step-by-step learned more and understood more about software development.” That mindset—build understanding, seek real practice—later becomes a defining trait of how he operates in frontend.

The role: Lead Front End Developer at Kickscale

As a Lead Front End Developer, Gerson shoulders responsibility where product value becomes visible. He wants to know whether customers like using the product and whether it’s understandable for them. These two questions anchor his work.

  • “Like using it”: How does the interaction feel? Is the app accessible, fast, and smooth? Does it fit daily tasks?
  • “Understandable”: Can people reach their goals easily? Are naming, flows, and visualizations intuitive? Do they set the right expectations?

At its core, Gerson ties frontend closely to product thinking: visualization isn’t just about UI polish; it’s expressing data and functionality in a way that empowers people—and makes the impact of a feature observable.

Customer proximity, both qualitative and quantitative

Gerson grounds his role in customer proximity. Part of that is direct understanding: conversations, feedback, and a close look at how people experience the product. The other part is monitoring tools. His aim is to see how customers are doing on the platform, whether new features are comprehensible, and whether they solve problems or bring new ones.

This pairing—qualitative closeness and quantitative observability—turns frontend work into something testable. Rather than relying on hunches, the team examines how the product is actually used. The recurring question, which he emphasizes, is powerful in its simplicity: “Do we solve a problem—or bring one?” It keeps features anchored to real needs.

Collaboration that multiplies insight

Gerson describes teamwork that’s genuinely close-knit: the team exchanges ideas, helps one another, and builds on internal and external feedback. This isn’t a footnote—it’s a method. Multiple perspectives surface assumptions earlier and push solutions toward reality.

He also highlights a cultural foundation at Kickscale: everyone works in one office, they talk frequently, know what the others are doing, and can contribute input. That proximity aligns well with frontend’s needs: collective understanding of the problem and context, short feedback loops, and quick iteration when a solution needs adjustment.

Tools for clarity: React, TypeScript, and Figma

Gerson mentions the tools shaping his team’s work: React and TypeScript in the frontend, and Figma for specifications. The point isn’t tools for their own sake, but the jobs they do:

  • React and TypeScript structure the frontend—from components to type safety—supporting maintainability and clarity.
  • Figma provides the specification that the team evaluates internally: Can this design address a real customer problem, or will it introduce new friction?

The critical habit here is shared evaluation. Instead of treating specifications as a handoff to be “implemented,” the team probes whether the spec truly answers the problem—and keeps that core question in view: problem solved, or problem created?

“Solve problems—or bring problems”: a frontline heuristic

Gerson’s phrasing is disarmingly simple and surprisingly forceful. It turns product work into a loop:

  1. Observe the problem: Customer proximity and monitoring tools surface needs and gaps in comprehension.
  2. Form a solution hypothesis: Use Figma to make assumptions concrete.
  3. Evaluate together: Team review tests whether the solution hits the problem—or introduces side effects.
  4. Roll out and observe: After release, usage reveals whether the feature is understandable and valuable.

That loop becomes a shared language between engineering, design, and product. Above all, it keeps the focus on the people using the software.

What “visualization” really demands in frontend

Gerson explicitly describes his work as being “in visualization.” While that may sound technical, it’s fundamentally about making data and functionality understandable. Visualization shapes whether navigation is logical, whether representation motivates, and whether interactions match expectations. In other words, it’s the bridge between software logic and human perception.

This is where creativity becomes a first-class skill, not decoration. Creativity structures information so it makes sense. In frontend, that means designing experiences that help people succeed—and lead them to say, “I like using this.”

Learning by doing—one step at a time

Gerson’s move into the field is an argument for continuous learning. He advises building solid basics in web development and specifically mentions familiarity with React and Angular. Equally important is genuine interest: curiosity sustains effort, and effort leads to learning by doing—in small steps that eventually add up to the knowledge a developer needs.

That attitude fits the pace of frontend. It’s a domain that changes quickly. Thriving in it requires curiosity, persistence, and a willingness to sharpen thinking through feedback—inside the team and from the outside.

Creativity as the underestimated lever

Gerson is notably clear on creativity’s role. In frontend—which visualizes data and shapes experiences—creativity is a key lever. It helps people enjoy the product and feel that it “makes sense.” Importantly, in his framing, creativity is not separate from customer proximity. The best ideas are those that elegantly solve real problems while staying intuitive.

His practical yardstick is simple: if people say “wow, I really like using it,” the frontend has done something right. That isn’t vanity; it’s a measure of product quality.

Teamwork as safety net and quality engine

We appreciate the normalcy of how Gerson describes collaboration: exchanging, helping, and giving feedback. That normalcy is a quality engine. Constructive feedback—from colleagues and from external users—surfaces blind spots faster and raises the bar for solutions. In frontend, where misunderstandings show up immediately in the interface, this is essential.

That Kickscale operates from a single office amplifies this benefit: conversations happen more often, questions are asked earlier, and everyone knows what others are working on. For a team that jointly evaluates specs and closely watches whether features are understood, that proximity is an advantage.

How Gerson’s approach plays out—our key takeaways

From “Gerson Joao, Lead Front End Developer bei Kickscale,” we distilled practical principles that teams and individuals can apply:

  • Operationalize customer proximity: It’s more than good intent. It needs regular conversations and monitoring tools that show how people are “doing” on the platform.
  • Treat specs as hypotheses: Don’t just implement Figma designs; discuss them together. Do they truly address the real problem?
  • Collect feedback systematically: Internal review and external customer input belong together when assessing clarity and impact.
  • Use tools as means, not ends: React and TypeScript bring structure and safety; the real test is whether the result is understandable and enjoyable.
  • Champion creativity: Visualization is design. It takes creative thinking to make data and interactions intuitive.
  • Make learning a routine: Interest, experimentation, and step-by-step practice build the knowledge base frontend demands.

Guidance for aspiring frontend developers

Gerson’s advice is straightforward:

  • Build fundamentals: Get comfortable with widely used libraries—he mentions React and Angular—and strengthen web development basics.
  • Nurture interest: Genuine curiosity fuels persistence and turns effort into learning.
  • Learn by trying: Small projects, prototypes, experiments—practice builds understanding.
  • Take creativity seriously: Visualization is an act of design. Blending function and form raises the chance that people truly enjoy the product.

These aren’t flashy tips, but they’re reliable—and precisely because of that, they’re credible.

A decision compass for features

The most memorable line in Gerson’s account doubles as a decision compass: “Does the feature solve a problem—or bring one?” You can ask it before, during, and after development. It curbs over-engineering, guards against misunderstandings, and sharpens focus on clarity and usefulness.

  • Before development: What exactly is the observed problem? How will we know it’s solved?
  • During specification: Which parts of the solution might introduce friction?
  • After release: What do monitoring tools show about comprehension and usage? What signals do we hear in direct customer conversations?

This loop keeps teams responsive, enables quick adjustments, and protects product quality.

Why Gerson’s devstory resonates

Because it shows how mindset and craft reinforce each other. Gerson talks about a start through internships, a degree that grounds fundamentals, and a day-to-day practice where customer proximity, monitoring, tight teamwork, and creativity are the decisive levers. He names tools without fetishizing them, and he highlights collaboration and feedback culture with a constant eye on user impact.

For us, that’s the essence of modern frontend: product-oriented, human-centered, and verifiable. Work done this way doesn’t just build interfaces—it builds experiences that people understand and enjoy.

Conclusion: Frontend as bridge—and responsibility

“Gerson Joao, Lead Front End Developer bei Kickscale” offers a practical compass:

  • Proximity to users is foundational, not optional.
  • Monitoring makes impact visible—and adjustable.
  • Teamwork and shared evaluation improve decisions.
  • Specifications are starting points, not finish lines.
  • Creativity is a first-class skill in visualization.
  • Learning in small steps builds resilient expertise.

When frontend is practiced this way, UI becomes the bridge between complex software and the people who use it. That’s where value is created—and that’s where Gerson shows up every day.

More Tech Talks

More Tech Lead Stories