The blog post "The curse of knowing how, or; fixing everything" explores the burden of expertise. Highly skilled individuals, particularly in technical fields, often feel compelled to fix every perceived problem they encounter, even in domains outside their expertise. This compulsion stems from a deep understanding of how things should work, making deviations frustrating. While this drive can be beneficial in professional settings, it can negatively impact personal relationships and lead to burnout. The author suggests consciously choosing when to apply this "fixing" tendency and practicing acceptance of imperfections, recognizing that not every problem requires a solution, especially outside of one's area of expertise.
Fly.io's blog post details their experience implementing and using macaroons for authorization in their distributed system. They highlight macaroons' advantages, such as decentralized authorization and context-based access control, allowing fine-grained permissions without constant server-side checks. The post outlines the challenges they faced operationalizing macaroons, including managing key rotation, handling third-party caveats, and ensuring efficient verification, and explains their solutions using a centralized root key service and careful caveat design. Ultimately, Fly.io found macaroons effective for their use case, offering flexibility and performance improvements.
HN commenters generally praised the article for its clarity in explaining the complexities of macaroons. Some expressed their prior struggles understanding the concept and appreciated the author's approach. A few commenters discussed potential use cases beyond authorization, such as for building auditable systems and enforcing data governance policies. The extensibility and composability of macaroons were highlighted as key advantages. One commenter noted the comparison to JSON Web Tokens (JWTs) and suggested macaroons offered superior capabilities for fine-grained authorization, particularly in distributed systems. There was also brief discussion about alternative authorization mechanisms like SPIFFE and their relationship to macaroons.
Summary of Comments ( 286 )
https://news.ycombinator.com/item?id=43902212
Hacker News users generally agreed with the premise of the article, sharing their own experiences with the "curse of knowing." Several commenters highlighted the difficulty of delegating tasks when you know how to do them quickly yourself, leading to burnout and frustration. Others discussed the challenge of accepting imperfect solutions from others, even if they're "good enough." The struggle to balance efficiency with mentorship and the importance of clear communication to bridge the knowledge gap were also recurring themes. Some users pointed out that this "curse" is a sign of expertise and valuable to organizations, but needs careful management. The idea of "selective ignorance," intentionally choosing not to learn certain things to avoid this burden, was also discussed, though met with some skepticism. Finally, some commenters argued that this phenomenon isn't necessarily a curse, but rather a natural consequence of skill development and a manageable challenge.
The Hacker News post titled "The curse of knowing how, or; fixing everything" (linking to notashelf.dev/posts/curse-of-knowing) generated a moderate amount of discussion with a variety of perspectives on the core issue presented in the article: experienced developers feeling compelled to constantly "fix" things, even when it's not their responsibility or the optimal use of their time.
Several commenters resonated strongly with the article's premise. One user described the experience of joining a new company and feeling overwhelmed by the number of things that "needed" fixing, leading to burnout and frustration. This commenter highlighted the tension between wanting to improve things and needing to focus on the assigned tasks. Another commenter framed the problem as a form of "yak shaving," where developers get sidetracked by seemingly small improvements that snowball into large, time-consuming projects. They suggested the importance of focusing on the bigger picture and resisting the urge to get bogged down in minor details, especially when starting a new role.
The discussion also touched upon the challenge of balancing improvement efforts with the need to maintain existing systems. One commenter noted the difficulty of justifying time spent on refactoring or improvements when there's pressure to deliver new features. They also highlighted the potential for well-intentioned fixes to introduce new bugs or regressions. This sentiment was echoed by another user who emphasized the importance of considering the potential risks and trade-offs before embarking on any "fixing" endeavor.
Some commenters offered practical advice for managing the "curse of knowing how." One suggestion was to create a dedicated backlog for improvement tasks, allowing developers to capture their ideas without derailing ongoing projects. This approach allows for prioritization and discussion with the team about the best way to address these improvements. Another commenter advised setting clear boundaries and communicating proactively with stakeholders about the scope of work and the potential impact of undertaking additional fixes. They stressed the importance of having open discussions about priorities and trade-offs to avoid misunderstandings and ensure alignment.
Finally, a few commenters offered alternative perspectives, suggesting that the "curse of knowing how" can also be a valuable asset. One commenter argued that experienced developers have a responsibility to identify and address technical debt, even if it's not explicitly part of their assigned tasks. They emphasized the long-term benefits of maintaining a clean and well-structured codebase. However, they also acknowledged the importance of balancing this with the need to deliver business value and avoid unnecessary disruptions. Another commenter pointed out that the "curse of knowing how" can be a sign of passion and a desire to create high-quality software, suggesting that it's a trait that should be nurtured, not suppressed. They emphasized the importance of finding a healthy balance between fixing things and focusing on the core objectives.