The Early Days in Software Development

Entering the software industry, I found myself as a novice coder, struggling with productivity. My workdays stretched to 12 hours, yet my contributions felt minimal. Rather than engaging in chatrooms or side projects, I was consumed by the looming deadlines. Often, during team meetings, I was targeted for delays, with my team lead assigning me an assistant—typically a group lead—who would guide me until I met the deadline.

The underlying issue? The status quo.

This group lead would take a portion of my performance rating, even though he contributed negligibly to the actual code. Once the project was delivered, I would reflect on my experience, realizing that I had only received the necessary information just two days before the deadline. I hesitated to voice my concerns during future assignments due to the rigid workflows dictated by the group lead.

The workflow was as follows:

• Day 0: Features or bugs assigned to developers.
• Day 1-N: Developers clarified requirements with the group lead, who acted as the intermediary between us and the client. Discussions about potential mock-ups were nonexistent, as neither the team lead nor the group lead understood this aspect of software development.
• Deadline -2: Dependencies were finally clarified, allowing us to begin coding.
• Deadline: Either we delivered or faced repercussions.

The group lead had orchestrated a system where no progress was made without his oversight. This level of micromanagement, combined with the chaos of dependencies, frustrated me. I felt trapped in a system that prioritized trivialities over meaningful work.

The group lead, who took client requirements, needed to justify his extensive billing hours. As a senior figure, he ensured that his role appeared indispensable, weaving a complex web of dependencies that left us feeling powerless.

Access to essential tools, such as source control and client-side bug tracking, was also contingent upon him, reinforcing his gatekeeping role. If a developer spotted an error in the specifications, they had to report it to the group lead privately, preserving his reputation within the team. It was frustrating to see my efforts diminished by this structure.

When assigned to a client site in the USA, I had the opportunity to meet more resourceful developers from competing firms. They demonstrated how a proactive approach could lead to growth and success.

At the client site, if requirements were incomplete, we could push back without repercussions, leading to improved versions. This environment fostered curiosity and collaboration, rather than competition.

Yet, despite this realization, I felt a deep desire to leave my job. As a contractor in a service-oriented company, my daily life was dictated by forces outside my control. My service company's management held the real power over my career.

To the outside world, I was just a programmer. But inside, I felt that programming was a title reserved for elite technologists—those who developed groundbreaking software or systems. I yearned to join their ranks, but the path seemed unclear. Pursuing a degree felt overwhelming, especially without a background in computer science.

During long walks around my client's picturesque office in Illinois, I pondered my career goals. It was never solely about the money; while financial stability mattered, my true passion lay in witnessing the impact of my work. I wanted to embrace programming fully, free from the constraints of the service industry.

In my quest for growth, I aimed to challenge the ineffective middlemen and aspire to the efficiency of my competitors, who could deliver features swiftly amidst shifting requirements. I wanted to master programming to elevate my role beyond that of a mere cog in the machine.

After seven enlightening years in the service sector, I made the decision to pursue a product-focused career path.

The Shift to Product Development

In my first product company, I faced the inevitable office politics, but the work was fulfilling. The code quality was high, well-structured, and adaptable to external tools. The luxury of time allowed me to explore design patterns and implement scalable systems.

Even after leaving that company, my passion for coding remained strong. I transitioned into freelancing and took on various roles in Nordic product firms. At first, everything seemed promising; developers were at the forefront.

However, the financial landscape soon changed. Companies faced acquisitions or client losses, revealing their failure to adopt sustainable practices or Agile methodologies.

Upon joining a reputable Agile-driven product company, I was initially overwhelmed by meetings—daily stand-ups, sprint planning, and retrospectives. The Agile manifesto claimed to empower developers, and I felt valued.

In this environment, developers interacted directly with product owners, eliminating the middleman. However, I soon realized that not all Agile organizations were created equal; some left developers with little support while others provided valuable resources, like design input and well-crafted specifications.

I was fortunate to be part of a supportive Agile organization. We worked on exciting projects, but coherence in features was often lacking. We frequently found ourselves assisting analysts, who were unable to reciprocate with coding support. While we could request more time, our timelines were often dictated by previous teams' deliveries, regardless of the complexities involved.

The analytics module, a neglected piece of code, posed challenges. Each team delivered impressive features quarterly, yet our ability to measure success was hindered by the lack of ownership over non-functional requirements.

Product owners, brimming with creativity, often overlooked these bottlenecks. They generated feature ideas that competitors capitalized on, neglecting the fundamental aspects of user acquisition and engagement, which required rigorous user feedback—something most companies struggled to obtain.

Despite the belief that developers held the key to Agile success, the reality was more complex. Developers could influence their deliverables but lacked the authority to prioritize essential features. The rigid separation of product and implementation roles hindered overall product success, even with capable programmers.

Consequently, despite robust business layers and innovative UI components, the final product often failed to resonate with customers. Developers dreamed of showcasing their work in popular tech blogs, yet the demands of their roles left little room for community engagement. Leadership showed little interest in tech evangelism, focusing instead on user acquisition metrics.

Good developers began to leave for better-paying opportunities, while product owners enjoyed substantial compensation.

Conclusion: The Future of Programming

Agile has shifted power from the middleman to the product organization, often sidelining developers. Despite validating my skills as a programmer without a formal computer science background, I now contemplate quitting programming altogether.

I am not concerned about losing my job to generative AI, as I work in a company that values developers. Yet, I feel a sense of helplessness. The Agile framework has transformed developers into mere instruments, controlled by product owners.

As generative AI evolves, the challenges for creative developers will intensify, potentially pushing them further into obscurity. My concern extends to those who may not have the capacity to start their own projects or assert their technical capabilities. The industry appears increasingly unfavorable for older coders, who may struggle to compete with tech giants.

I hope they remain employed, as the competition between humans and machines will likely favor younger candidates over seasoned developers. This reality looms large, and it has led me to consider stepping away from programming before it becomes a necessity.