Why I Love Flutter for Mobile Innovation
Exploring Flutter's capabilities for rapid prototyping and cross-platform development.
Read ArticleAC
Crafting user experience...
Crafting user experience...
Key insights about collaboration, communication, and leadership gained during my internship experience.
Aime Claudien
Full-Stack Developer
Teamwork & Collaboration
When I started my internship at Ikigugu, I was focused on one thing: writing good code and proving my technical abilities. I thought that would be enough. I was wrong—and grateful for that lesson.
Over three months working with an incredible team, I learned that technical skills alone don't make you valuable in a professional environment. What truly matters is how you work with others, how you communicate, and how you contribute to a team's success.
This experience fundamentally changed how I approach software development and my career. I want to share what I learned because I believe these lessons will benefit anyone starting their professional journey.
Lesson 1: Over-communicate, not under-communicate
On my first significant project, I spent three days working on a feature without saying a word. I thought I'd surprise everyone with a complete, polished implementation. When I finally showed it, my tech lead had to ask me to restart because I'd misunderstood the requirements—things we could have clarified in 30 minutes.
That was humbling. I learned quickly: better to ask "dumb" questions than waste days going in the wrong direction.
What changed:
- Daily standups: I started being specific about blockers, not just listing tasks
- Slack messages: Before diving into complex features, I'd outline my approach for feedback
- Code reviews: I welcomed feedback instead of being defensive
- Documentation: I documented decisions, not just code
The impact:
- Reduced rework by 60%
- Built stronger relationships with team members
- Became someone people trusted with important work
Practical tips:
1. Write clear daily updates—make it easy for others to help you
2. Ask questions early when you're confused
3. Give context in your communication—not just "I need help" but "here's what I tried"
4. Use the right channel—some discussions need synchronous conversation, not Slack threads
Communication isn't a soft skill—it's a technical skill that directly impacts delivery speed and code quality.
Lesson 2: Your team's success is your success
I noticed early on that the senior developers at Ikigugu invested significantly in helping junior developers (like me). They'd pause their own work to explain concepts, review code thoroughly, and share knowledge freely. I initially felt like I was slowing them down.
One day, my tech lead said something that shifted my perspective: "I'm not investing time in you because it's nice—I'm doing it because when you level up, our entire team becomes stronger."
That reframing was powerful. It meant: - Helping a teammate isn't "lost time"—it's an investment in team capability - Asking for help isn't weakness—it's accelerating collective progress - Sharing knowledge multiplies its impact - Your growth enables others to focus on what they do best
This changed how I work:
- I ask for help when stuck (after genuine effort)
- I explain my thinking during code reviews, not just the code
- I document patterns I discover
- I celebrate others' successes as genuine wins
Real example:
A teammate was struggling with a complex state management issue. Instead of staying siloed, we spent two hours pairing. We solved the problem together, and now that teammate understands the pattern for future use. Net result: both of us learned something, and the codebase became more consistent.
The paradox:
Ironically, focusing less on personal achievement and more on team success made me stand out more—because I became someone people wanted to work with.
Lesson 3: Feedback is a gift, not criticism
Early on, code reviews felt intimidating. Someone was going to find problems with my work. My initial reaction? Get defensive. "But I thought..." or "That works because..."
The turning point came when my tech lead reviewed a PR and left 12 comments. My first instinct was dread. But then I realized: they spent time on my code because they cared about my growth. That 12 comments meant 12 opportunities to improve.
**The transformation:**
BEFORE (Defensive mindset):
"Why is my approach wrong?"
"This works, isn't that enough?"
"I'll do it differently next time"AFTER (Growth mindset): "What don't I understand about good design?" "How can this approach fail in production?" "What's the principle I'm missing?"
Specific changes:
1. Read feedback completely before responding
2. Ask "why" instead of "why not"
3. Implement suggestions fully, then ask questions if needed
4. Thank reviewers specifically for their time
5. Track patterns in feedback (if multiple people mention it, pay attention)
The results:
- My code quality improved dramatically
- I developed better instincts about design patterns
- I became more confident because I understood the reasoning behind best practices
- Most importantly, people wanted to review my code because I was receptive and responsive
Lesson within the lesson:
The best developers I worked with weren't the ones who wrote perfect code—they were the ones who continuously improved based on feedback. They asked questions, were curious, and weren't attached to their initial solutions.
Lesson 4: Responsibility without isolation
Early in my internship, I took on a feature that seemed manageable. As I dove in, I realized I was in over my head—architectural decisions, performance concerns, unfamiliar patterns. But I didn't want to ask for help because I'd said I could handle it.
This almost became a disaster. The deadline was approaching, I was stressed, and the code quality was suffering.
My manager noticed I seemed overwhelmed and pulled me aside. "Taking ownership doesn't mean doing everything alone," she said. "It means being responsible for the outcome, which includes getting help when needed."
What I learned:
- Ownership = responsibility, not isolation
- Knowing when to ask for help is a sign of maturity, not weakness
- You can be accountable for a task while not doing all of it
- Getting stuck and seeking help is more responsible than struggling silently
Practical approach:
1. Take ownership of outcomes, not just tasks
2. Set realistic timelines based on your experience
3. Flag risks early (including "I might need help with X")
4. Share progress regularly, not just at deadlines
5. Celebrate the team that helped you succeed
The better version:
If I had flagged the architectural concerns early, we could have:
- Had a senior developer help design the solution
- Saved days of rework
- Learned patterns more efficiently through pairing
- Delivered better code on time
That experience taught me that great teamwork means knowing when to lead and when to follow, when to push forward and when to ask for support.
Lesson 5: You're not just joining a company, you're joining a team
One thing that struck me about Ikigugu was the intentionality around culture. It wasn't just "be nice to each other"—there were actual practices that shaped how people worked together:
Weekly knowledge shares: Every Friday, someone presented something they learned. No PowerPoints required, just sharing knowledge. This created an environment where learning was valued and normalized.
Blameless postmortems: When things went wrong, the focus was on systems and processes, not blame. I saw senior engineers own mistakes and learn from them. This meant everyone could take risks and be transparent.
Mentorship expectations: Helping juniors was explicitly part of senior developers' roles, not an extra. This meant they actually invested time in growth.
Psychological safety: People could say "I don't know" or "I made a mistake" without fear. This made it safe to be learning while doing.
Why this matters:
These practices weren't nice-to-haves—they directly impacted code quality, velocity, and how long people stayed engaged. I learned more in three months at Ikigugu than I would have in a year at a place without this culture.
Taking it forward:
Now when evaluating opportunities, I don't just ask "what's the tech stack?" I ask:
- How do they handle mistakes?
- Do people help each other grow?
- Is learning valued in practice, not just words?
- Would I want to be on a team with my would-be teammates?
Culture isn't superficial—it determines whether your technical skills can flourish or atrophy.
1. Communication multiplies your effectiveness
Clear communication prevents rework, builds trust, and makes you invaluable to a team. Invest in getting better at it.
2. Lift others as you grow
The best career trajectory comes from building a reputation as someone who makes their team better. Help others succeed.
3. Feedback is accelerated learning
Every piece of feedback is a shortcut through years of learning by trial and error. Embrace it with curiosity.
4. Ownership means accountability, not isolation
You can take responsibility for outcomes while asking for help. In fact, knowing when to ask is part of being responsible.
5. Culture determines whether you can do your best work
No matter how talented you are, a poor culture will grind you down. A good culture will amplify your abilities.
Bonus lesson: None of these lessons are obvious until you experience them. The fact that you're reading this means you're already thinking about growth. That's the biggest advantage.
My internship ended, but these lessons continue to guide my work. I carry them into every new project, every new team, every new challenge.
Three months ago, I was anxious about whether I could "make it" as a developer. I thought it was about technical prowess.
Now, I know it's about being someone who communicates clearly, lifts others up, welcomes feedback, takes ownership responsibly, and contributes to a positive culture.
For anyone starting their career:
1. **Technical skills are the price of entry**, not the differentiator
2. **How you treat people and communicate is what builds your reputation**
3. **The best opportunities go to people others want to work with**
4. **Growth comes from feedback, collaboration, and environments where that's encouraged**
The internship at Ikigugu taught me that software development is fundamentally a team sport. The code is just the manifestation of human collaboration.
I'm grateful for every person on that team—the challenges, the feedback, the knowledge shared, and the culture they created. That three-month internship reset my perspective on what it means to be a professional developer.
If you're early in your career, find a place and a team that invests in your growth. The technical skills follow naturally—but the character and habits you develop in a good culture? Those are with you for life.
Here's to teamwork, growth, and finding your people in tech.