This Hacker News discussion revolves around several key themes concerning the nature of software development work, team dynamics, and the balance between productivity and bureaucratic processes.
The Nature of Software Development Work: Bonding and Boredom
A significant portion of the conversation centers on the idea that software development, even when necessary, can often involve "dull work" or tasks that are not inherently exciting. This is contrasted with the desire for engaging and impactful tasks.
- "Or maybe, sometimes it's just flat out dull work. And it has to get done, you're the one with the capacity to do it, and you just have to grit your teeth and do it." - ian-g
- "who's working at a boring job nowadays as a software dev? everywhere i see devs are wearing like 10 hats bc we have the combination of being capable yet still at the bottom of the totem pole." - kbar13
- "I just landed a new job, and I thikn it's a boring one. At my previous job I was fixing Java's memory issues, migrating databases and riding Jira epics. At my new job I'm fixing button's padding/marging, deploying and deploying stuff on Vercel. Paycheck is the same, though; so I couldn't care less." - dakiol
Some users argued that even boring work can be meaningful and lead to great things if done consistently, while others emphasized that a constant pursuit of excitement or "tension" can be akin to chasing dopamine loops.
- "Boring work needs meaning, not tension. Some times boring, done consistently, is where the truly great things come from." - truelson
- "Tension is, imo, ephemeral. If you keep chasing it, you are chasing dopamine loops. Little good comes from this." - truelson
Team Dysfunction and Bureaucracy
A recurring theme is the prevalence of "dysfunctional" teams and organizations, particularly in enterprise software development, where rigid processes, excessive ticketing, and a lack of trust can hinder productivity. The discussion highlights the frustration of having to navigate these systems.
- "You can either laugh or cry about it. Laughing is more fun. This is nearly the norm for ENTERPRISE software development, and it's such a tragedy." - datadrivenangel
- "Unless you work on a dysfunctional team and any non-tracked work is forbidden, and any work you try and get tracked requires 6 pages of justification and takes 10 weeks to get prioritized enough for someone to work on..." - datadrivenangel
- "My team isnt dysfunctional but I always get hit on the head for doing work and not making a ticket. I don't get it, if I see something bad I'm not going to search which ticket would best fit this issue. Just reviw my PR !" - ramon156
The debate around ticketing systems (like Jira) is central here. Some argue for the necessity of tickets for audit trails, prioritization, and team visibility, while others find them to be an unnecessary overhead that slows down development and disconnects from the actual work.
- "Also, in some dysfunctional teams creating a ticket means it requires prioritization and you will most likely never work on it and ticket will be deleted five years from today when nobody you know with at the company anymore." - serial_dev
- "Believe me, no sane CFO (or include any person not in the dev team or product team) will look up your Jira ticket explaining why you wanted to refactor the GitHub actions because you had to update 10 files whenever there’s is a new version of a tool used in your pipeline." - serial_dev
- "DJBunnies: It takes like two seconds to write a ticket and then tag your commits with it. You get credit for fixing the issue, avoid giant fix-along-the-way PRs, and future credit for people (maybe even you) understanding why you those changes were made."
The conflict between doing necessary work and adhering to strict ticketing processes is a major point of friction.
- "Except then you can get your wrist slapped for starting work on a ticket without prioritization. A rigid enough process slowly kills everything." - datadrivenangel
- "But then if you cannot work on a ticket because of prio, you cannot either work without a ticket, isn't it? I thought the point here was doing work with or without a ticket." - dakiol
Trust, Autonomy, and Career Management
The discussion also touches upon the importance of trust between engineers and management, and how a lack of autonomy can negatively impact morale and career progression. There's a clear divide between those who believe in transparency and formal tracking for career advancement and those who advocate for a more agile, "ask for forgiveness than permission" approach to get work done.
- "In many companies, this creates a lot less friction. To put it a different way: it's better to ask forgiveness than permission. Creating a ticket is asking permission (as the project managers will see the ticket and start asking questions about why time is being spent on low-priority things). Just going ahead and pushing code is asking forgiveness - sure, someone might notice after the fact that you did some work that you weren't assigned to do, but by that point it will be considered irrelevant, as long as your other responsibilities were handled on-time. If you've never worked at a company where these political games are necessary - count your lucky stars!" - wavemode
- "why do you want to do work and not get credit for? One of the biggest career mistakes is doing things on your own that are not aligned and approved with the management chain. Even if makes 100% sense. They might look past it once or twice but you will get managed out eventually. Doesn't matter how good you are." - apwell23
- "I mean, finding a Jira epic/project where to fit my ticket is not the hardest part of the job tbh. Also, depending on the team and your experience, loosely fixing things here and there can be a red flag or totally the opposite (e.g., I've seen how juniors or people in general with less than a decade of experience get punished when they start fixing random things here and there. On the other side seniors or staff engineers get kudos for fixing also random things but in less volume and usually more tricky ones). Having a ticket to back up your work is never going to hurt you, though." - dakiol
The perception of whether "untracked" work is seen as a red flag or a proactive contribution often depends on seniority and the specific team culture.
The Role of Audit Trails and Compliance
The utility and necessity of audit trails and compliance documentation in software development are debated. While some acknowledge their value for operations, system evolution, and regulatory requirements, others argue that ticketing systems are a poor and often ignored mechanism for achieving this, especially for small, straightforward changes.
- "Also there is value in having an audit trail of who did what when and why, both for operations and system evolution, and for all the compliance junk. Not so much value that a tiny bit of cleanup needs a huge amount of overhead though." - datadrivenangel
- "The most important properties of real audit trails are that they are side effects of the actual work, created during or after the fact without interfering with how the work is done. The thing about work tickets is that they have none of those properties." - marcosdumay
- "Compliance guarantee is a different beast, that isn't improved in any way by work tickets, but may need more work than the audit trail." - marcosdumay
The Dynamics of Urgency vs. Importance
The tension between urgent tasks and important but non-urgent tasks (like maintenance or improving CI/CD pipelines) is highlighted as a source of conflict and decision-making challenges in software development.
- "I explain this to people as the tension between important urgent work. Some work is important but never（rarely) urgent. And if you ignore important work (like maintenance) it might become urgent at a very bad time." - schneems
- "Like, if you’ve got a tight deadline coming up, it’s not the time to spend a week making CI slightly faster." - schneems
The effective management of CI/CD systems, particularly caching, is presented as an example of where chasing minor improvements can lead to significant frustration.
- "The bane of my existence are CI/CD systems that get caching 99% right. Chasing down the problems from that last 1% of strangely busted...well, lets just say that if you want TENSION at work, good way to get it. :/" - eschneider
- "with github actions... often caching is slow as well" - arccy