Ask HN: Are most corporate SWE jobs performative?

The recent Hacker News (HN) discussion titled “Ask HN: Are most corporate SWE jobs performative?” sparked a massive debate. It resonated with a lot of developers, particularly those working in larger organizations. While the question is broad, it's particularly relevant – and arguably more pronounced – within the finance industry (FinTech, investment banks, asset management firms, etc.). This article will explore why the feeling of "performative" work is common in finance tech, the unique pressures driving it, and what developers can do about it.

§The HN Debate: What Does 'Performative' Even Mean?

The core of the HN discussion centers around the idea that a significant portion of a corporate software engineer's time isn't spent on actual building and problem-solving. Instead, it’s consumed by:

• Meetings: Stand-ups, planning, refinement, retrospective, one-on-ones… the list goes on.
• Documentation: Often excessive, and sometimes for the sake of having documentation rather than genuine utility.
• Process: Navigating layers of approvals, code review bureaucracy, and rigid development workflows.
• Context Switching: Being pulled into too many projects, resulting in fragmented focus and reduced deep work.
• "Firefighting": Reacting to urgent (but often preventable) incidents caused by poor design or accumulated technical debt.

The accusation isn't necessarily that people are deliberately slacking. It's that the system itself encourages behavior that looks productive, even if it doesn’t result in impactful software. It's about optics over outcomes.

§Why Finance Tech Amplifies the 'Performative' Problem

The pressures and characteristics of the finance industry exacerbate these issues. Here's why:

• Regulation & Compliance: Finance is heavily regulated. Every change, every system, needs to be auditable, traceable, and compliant. This leads to a massive overhead in documentation, testing, and approvals. While necessary, it can easily tip over into excessive process.
• Risk Aversion: The stakes are incredibly high. A bug in a trading system can cost millions. This fosters a culture of extreme caution and a reluctance to experiment. Innovation is often stifled in favor of proven, albeit clunky, solutions.
• Legacy Systems: Many finance institutions still rely on decades-old COBOL or Fortran systems. Maintaining and integrating with these systems demands specialized skills and consumes a huge amount of developer time, often yielding limited value. Trying to modernize these feels like constantly pushing a boulder uphill.
• High Compensation & Visibility: Software engineers in finance are often well-compensated. This increased scrutiny leads to a need to demonstrate value, even if that value isn't always tangible. There's a perception (fair or not) that high salaries require high visibility.
• Non-Technical Management: Frequently, those managing tech teams in finance lack a deep understanding of software development. This can lead to unrealistic expectations, poorly defined priorities, and a focus on metrics that don't accurately reflect actual progress.
• Complex Business Logic: Financial instruments and trading strategies are inherently complex. Translating these into code requires a high degree of precision and accuracy, which can slow down development and increase the risk of errors.

§Common 'Performative' Tasks in Finance SWE Roles

Let's get specific. What do these "performative" tasks look like in a typical finance tech role?

• Endless Code Review Cycles: While code review is crucial, it can become ritualistic. Reviews focused on stylistic nitpicks rather than core logic or security vulnerabilities waste time and demoralize developers.
• Meetings About Meetings: Discussing the agenda for an upcoming meeting, followed by the meeting itself.
• Re-implementing Existing Functionality: Due to risk aversion, there’s often a preference for re-writing existing components rather than refactoring or improving them. This creates redundant code and wasted effort.
• Creating Extensive Documentation That Nobody Reads: Documents are produced to satisfy audit requirements, but lack practical value for developers using the system.
• Jira Ticket Treadmills: Spending hours meticulously updating tickets with status changes and minute details, rather than actually writing code.
• "Shiny Object Syndrome": Jumping on the latest tech trend without a clear business case or understanding of its impact on the existing system.
• Chasing Unrealistic KPIs: Being measured on metrics like lines of code written or number of commits, which incentivize quantity over quality.

§The Impact: Burnout and Disengagement

The constant pressure to appear busy, coupled with the lack of meaningful impact, takes a toll. The consequences are significant:

• Burnout: The relentless cycle of meetings, documentation, and context switching leads to exhaustion and emotional depletion.
• Disengagement: Developers lose motivation when they feel their work isn't valued or making a difference.
• High Turnover: Frustrated developers seek opportunities elsewhere, leading to a loss of institutional knowledge and increased recruitment costs.
• Reduced Innovation: A culture of fear and risk aversion stifles creativity and hinders the development of new and innovative solutions.
• Increased Technical Debt: When there's no time for proper refactoring or addressing underlying architectural issues, technical debt accumulates, further slowing down development and increasing the risk of errors.

§What Can Developers Do?

While the problem is systemic, developers aren’t powerless. Here are some strategies for mitigating the "performative" aspects of a finance tech job:

• Focus on Impact: Actively seek out projects that have a clear business value and align with your skills and interests.
• Challenge the Status Quo: Politely question unnecessary processes or documentation requirements. Suggest more efficient alternatives.
• Prioritize Deep Work: Block out dedicated time for focused development, free from interruptions. Learn techniques like the Pomodoro Technique. https://example.com/ – a good timer for Pomodoro.
• Advocate for Technical Debt Reduction: Make a case for dedicating time to refactoring and improving the existing codebase. Explain the long-term benefits of addressing technical debt.
• Document Strategically: Focus on creating documentation that is truly useful for other developers, not just for compliance purposes.
• Learn to Say “No”: Politely decline requests that fall outside your scope or distract from your priorities.
• Seek Mentorship: Connect with experienced developers within the organization who can provide guidance and support.
• Consider a Different Role or Company: If the culture is fundamentally resistant to change, it may be time to explore other opportunities.

§The Future of Finance Tech: A Shift Towards Value?

The conversation around performative work is forcing organizations to re-evaluate their priorities. There's a growing recognition that happy, engaged developers are more productive developers. As the industry matures, we may see a shift towards:

• Outcome-Based Metrics: Measuring success based on business outcomes rather than activity levels.
• Empowered Teams: Giving developers more autonomy and control over their work.
• Investment in Developer Experience: Prioritizing tools, processes, and a culture that support developer productivity and well-being.
• Increased Automation: Automating repetitive tasks to free up developers to focus on more challenging and rewarding work.

The journey won't be easy, but a future where finance tech is driven by genuine innovation and value – rather than just the appearance of busyness – is within reach.

§Disclaimer

This article contains affiliate links. If you click on a link and make a purchase, I may receive a small commission at no extra cost to you. This helps support the creation of high-quality content like this. The recommendations are based on personal experience and research, and are provided for informational purposes only.