Everyone Struggles. Do You?

Introduction: The Truth Behind Success Stories

In the world of software engineering, success often steals the spotlight. But behind every polished product or software lies hours, sometimes days or weeks of frustration, debugging, and trial-and-error.

If you’ve ever felt stuck, lost, or inadequate while working on a project, here’s the truth: you’re not alone! Everyone struggles. Yes, even the most seasoned engineers have stared at a screen, completely baffled, wondering if they’ll ever figure it out. That tech lead who seems to have all the answers? They spent three hours yesterday tracking down a missing semicolon. That senior developer whose code always looks elegant? They scrapped and rewrote their last feature four times before it felt right.

“Programming isn't about what you know; it's about what you can figure out.”

— Chris Pine

This quote encapsulates a fundamental truth about our field: software engineering isn't a destination but a journey of continuous problem-solving. The most valuable skill isn't memorising syntax or knowing every design pattern. It is the ability to break down problems, research solutions, and persist through challenges.

So, let me ask you: Do you struggle? Because if you do, congratulations! You’re learning.

Struggling Is Universal

Let’s debunk a myth right away: expertise doesn’t mean a lack of struggles. It just means the struggles evolve. As a software engineering graduate from ALX Africa, currently an intern at Debian, I’ve had moments when I thought I wasn’t cut out for this field — when a single bug consumed my day or when I couldn’t grasp a concept others seemed to understand effortlessly.

Here’s what I’ve learned:

• Beginners struggle with the basics: Syntax errors, program structure, debugging, and understanding frameworks.

• Experienced engineers struggle too: Designing scalable systems, optimising performance, or integrating complex technologies.

Everyone, at every level, faces challenges. What separates great engineers from the rest isn’t the absence of struggles but their persistence in overcoming them — everyone struggles, remember that.

Personal Struggles

Two weeks into my internship at Debian, what a privilege it is to contribute to Free and Open Source Software, right? It’s an honour, no doubt. But as rewarding as this experience is, it hasn’t been without struggles.

The Asynchronous Bug (Outreachy Contributions Stage)

I remember vividly, during the Outreachy application process (specifically the contribution stage), I was full of confidence in my Python skills. With a solid understanding of the language and past projects under my belt, I felt ready to tackle anything. So, when I started contributing to the Automatic Indi-3rd-party Driver Update Project, I jumped in headfirst.

My first task was straightforward, and I completed it quickly. While my solution worked, I realised it wasn’t as efficient as I wanted. Motivated to push myself, I decided to tackle the next task using Python’s asynchronous programming with asyncio and aiohttp.

I had read about the benefits of async programming, particularly for I/O-bound operations, and was excited to implement it.

Initially, everything made sense. I reworked the code, introducing async def functions, using aiohttp for non-blocking HTTP requests, and placing await calls where needed. The prospect of improving both my skills and the project’s performance looked great.

However, things quickly turned to a mess. My code stopped behaving as expected — await calls stalled, data wasn’t being returned, and the program’s flow became chaotic. What initially seemed like a clear structure turned into a tangle of confusion. I felt stuck and overwhelmed.

At this point, I faced two options: revert to the simpler synchronous implementation or dive deeper to figure out what went wrong. I chose the latter, determined to learn from the experience.

To debug the issue, I adopted a methodical approach:

1. Tracing Async Calls: I carefully followed the flow of each async function from start to finish.

2. Adding Print Statements: I logged what each await call was waiting for and the values being returned at every step.

3. Revisiting Documentation: I reread the Python asyncio documentation, focusing on event loops, coroutine behaviour, and common pitfalls.

This process revealed the root cause: one of my async functions wasn’t returning the expected data, causing subsequent await calls to hang indefinitely. Once I corrected this, the rest of the program began to work seamlessly.

Filtering Relevant Debian INDI Packages Based on Defined Criteria

After the asynchronous battle, I gained a new level of humility when approaching technical challenges. This mindset proved invaluable as I began working on a task that involved developing a program to filter relevant INDI 3rd-party packages from the Debian Astro Team and produce a curated list of those packages. This task was a core component of the Debian Automatic INDI-3rd-party Driver Update Project.

On Salsa (Debian's instance of GitLab), the metadata for these packages is described in their debian/control files. These files contain essential information such as package names, sections, maintainers, dependencies, and descriptions. This metadata serves as the foundation for categorising packages and distinguishing which packages belong to which group or category.

The primary goal was to parse the debian/control files for all packages and extract only those that met certain criteria. This required matching specific fields or text patterns using regular expressions. While the concept sounded simple, the reality of working with real-world data brought some challenges:

• Variations in Metadata Structure
  Although debian/control files follow a defined structure, minor variations made parsing non-trivial. For example:

  • Field Variations: Sections like science, contrib/science, libs, and non-free/libs appeared inconsistently.

  • Missing Dependencies: Not all INDI packages correctly declared libindi-dev in Build-Depends.

• Complexity of Matching Criteria
  To identify relevant packages, the filtering criteria varied for:

  • INDI Packages: Prefixed with indi-, categorised in science or contrib/science.

  • INDI Libraries: Prefixed with lib, categorised in libs, non-free/libs, libdevel, or non-free/libdevel.

Additional fields, like Homepage and Build-Depends, required validation using precise patterns.

• Large Dataset
  Parsing the debian/control files and filtering a large number of packages efficiently required careful optimisation of both regex patterns and the overall program structure.

Defined Criteria and Regex Patterns

The filtering criteria were implemented using tailored regex patterns:

1. Section field

For INDI packages.

r"^Section: (science|contrib/science)"

For INDI libraries

r"Section: (libs|non-free/libs|libdevel|non-free/libdevel)"

2. Homepage field

Ensure packages are pointed to a valid INDI 3rd-party repository:

r"^Homepage: (https://github\.com/indilib/indi-3rdparty\S*)"

3. Build-Depends field

Validate that the packages listed libindi-dev as a build dependency

r"\blibindi-dev\b

Lessons Learned from Struggling

Struggling has taught me some invaluable lessons that I carry with me every day.

• Embrace Patience

  Progress isn't always visible day-to-day, but consistent effort compounds over time. Sometimes the most significant breakthroughs come after periods of apparent stagnation.

• Reframe Failure

  Every bug, error, and failed attempt provides valuable feedback about where to focus your learning. They're not setbacks, they're stepping stones.

• Value Collaboration

  Fresh perspectives can illuminate blind spots in your thinking. My mentor's insights about which fields to use as filtering criteria proved invaluable.

• Develop Systematic Problem-Solving

  Each challenge strengthens your ability to approach problems methodically, identify patterns, and work through solutions systematically.

Looking Back

Now, two weeks into my Debian internship, I realise struggles like these are not setbacks, they are stepping stones. They teach us resilience, problem-solving, and the importance of persistence. The bugs, the errors, the endless hours of debugging — these aren’t signs of failure, but markers of progress. They are proof that we are learning, growing, and evolving into better engineers with every challenge we face.

I used to think that successful developers didn’t struggle as much. I thought they had everything figured out. But as I’ve grown in my journey, I now see that the most successful engineers are the ones who embrace their struggles and keep pushing forward. They’re the ones who view every failure as an opportunity to improve. And that’s a mindset I strive to adopt.

The Takeaway: Keep Pushing Forward

So, the next time you find yourself stuck, frustrated, or feeling like you're not making any progress, remind yourself:

• You are not alone. The struggles you’re facing right now are part of your growth. They’re a sign that you’re pushing boundaries, expanding your skills, and moving towards becoming a better version of yourself.

• Struggling is universal. It’s part of the process. And as you continue to work through your challenges, you’ll emerge more resilient, more capable, and more confident in your abilities.

The truth is: success isn’t just about overcoming challenges, but about embracing them, learning from them, and persevering through them. If you’re struggling right now, you’re on the right path. It means you are getting out of your comfort zone, and that can be rewarding.

Keep pushing forward. The best is yet to come!!