My love/hate relationship with corporate software engineering

This post explores the duality of working in the tech industry—from the pure joy of writing elegant code and crafting meaningful solutions, to the creeping frustration of a corporate culture that expects engineers to be everything but engineers. These days, coding is just one slice of the pie. The rest involves navigating endless meetings, aligning with shifting product visions, performing stakeholder management, justifying every decision, and keeping up a performative presence. The technical creativity that once fueled passion now feels increasingly buried under layers of process, politics, and performance metrics.

Quality software engineering demands continuous learning and regular exposure to challenges—many of which are uncomfortable but vital for growth. Yet the corporate environment often strips away the time and space needed for reflection and experimentation. Engineers are now expected to stretch well beyond their core discipline. In many cases, it feels as though we're being asked to absorb the responsibilities of management—just to prop up performance metrics and keep KPIs afloat. I've witnessed what can only be described as 'delusional management,' where deadlines appear out of thin air, with no rationale or data to back them. When questioned, the usual response is, "it's just a date and can always change." But even so-called flexible deadlines get baked into forecasts, creating unrealistic expectations that compromise the integrity of the actual work.

It’s not just timelines that feel hollow—so too do the promises. The corporate line is that strong performance leads to reward, but after years of consistent delivery, one starts to ask: reward from whom, and by whose definition? Increasingly, being a "high performer" has less to do with engineering skill and more to do with how well one champions business goals. This isn’t inherently wrong, but it becomes problematic when engineers are forced to double as analysts, product strategists, and de facto decision-makers—especially when other roles exist to carry those responsibilities. In teams with strong Business Analysts, this expectation feels redundant, and more critically, exploitative.

Remuneration adds yet another layer to this discontent. Since the onset of the COVID-19 pandemic, salary growth has consistently lagged behind the rising cost of living. According to the Australian Bureau of Statistics, employee households experienced a 9.6% annual increase in living costs by June 2023, easing only slightly to 3.4% by March 2025. Despite this, many companies have continued to post profits—yet offer only modest pay increases in return.

In my own case, a standard 4% raise for meeting performance expectations has become routine. But what constitutes a real pay rise when costs have risen two to three times that? Across companies, I’ve heard the same refrain: "we’re following the standard." What that really means is—no matter how hard you work, you're unlikely to see that effort financially acknowledged. This disconnect between performance and reward creates a sense of stagnation, where excellence goes unnoticed and undervalued.

So does it truly pay to work hard in corporate tech? In theory, perhaps. In practice, not so much. While steady work helps pay the bills, the dream of climbing some mythical career ladder often dissolves into a loop of inflated expectations. The more you deliver, the more that delivery becomes your new baseline. And without clear boundaries, that quickly becomes the expectation—not the exception.

When engineers routinely go above and beyond, it conditions management to see extraordinary output as the norm. In turn, this breeds a culture where contributions are taken for granted, leading to burnout and a loss of clarity about what the role actually is. Instead of being valued for your expertise, you become valued for your flexibility—your ability to absorb pressure without flinching.

At this point, it’s hard not to look around and think: software engineering isn’t what it used to be. It’s no longer about building beautiful things, but about surviving the managerial circus. Directions float down from the top like a bad game of Chinese whispers—distorted, half-baked, and always landing in the engineer’s lap with a sense of urgency. Most managers couldn’t debug a toaster, yet they dictate strategy like they’ve just stepped off the keynote stage at a tech conference. My takeaway? Learn what you can while you're in the system—but what you build outside of it might just be your way out. Because in this corporate zoo, the only thing scaling faster than expectations is the ego of the ones calling the shots.