Wisdom over Waves

Wisdom over Waves focuses on enhancing sustainable software delivery by navigating beyond technology hype. It addresses common pitfalls such as bad coding practices, fear-induced inefficiencies, and the quest for productivity, while advocating for foundational methods like CI/CD, agile principles, and understanding timeless computing laws.

Software Development Practices Coding Practices Technology Trends Developer Productivity Agile and Agile Mindset Continuous Integration/Continuous Deployment (CI/CD) Technical Debt Problem-Solving in Software Development Software Quality and Feedback Computing Laws

The hottest Substack posts of Wisdom over Waves

And their main takeaways
79 implied HN points 21 May 24
  1. Focus on the problem first: Understand the core issue before jumping into solutions. This can lead to more innovative and effective outcomes.
  2. Avoid getting lost in the technical details: Developers should balance focusing on implementation with considering broader business needs and goals.
  3. Collaborate and empathize: Work closely with other teams, seek feedback, and put yourself in the shoes of the end user to improve problem-solving and innovation.
219 implied HN points 31 Oct 23
  1. Companies can get stuck in bad coding loops due to shortcuts taken to meet deadlines and lack of focus on code fitness, leading to slow progress and accumulation of bad-quality code
  2. Two loops of bad coding involve creating technical debt with more code and lowering hiring bar due to pressure, resulting in slower progress and accumulation of bad code practices
  3. To break out of these loops, companies can freeze code hotspots, raise hiring bar, upskill developers, and reduce technical debt through mission-critical task forces
159 implied HN points 14 Dec 23
  1. Hyrum's Law emphasizes that with a large number of users, system behaviors will be relied upon, regardless of what was promised.
  2. Hofstadter's Law points out that tasks often take longer than expected, even with buffers, so it's beneficial to shorten estimation cycles for better planning.
  3. Parkinson's Law highlights how work expands to fill the time available, showing the importance of constraints for creativity and efficiency.
159 implied HN points 16 Nov 23
  1. Fear in software delivery negatively impacts metrics like deployment frequency, lead time for changes, time to restore service, and change failure rate.
  2. Introducing processes due to fear can slow down innovation and reduce efficiency, leading to delays in deployments and unnecessary quality gates.
  3. Delays in software delivery caused by fear can result in increased work in progress, introduction of bugs, lower deployment frequency, longer mean time to resolve, and a negative impact on DORA metrics.
Get a weekly roundup of the best Substack posts, by hacker news affinity:
139 implied HN points 30 Nov 23
  1. ShuHaRi model involves following rules, breaking away from them, and creating your own rules.
  2. Transition from valued practices to rigid processes can lead to loss of dynamism and creativity.
  3. It's important to adhere to the spirit of practices, not just the letter, to avoid destructive outcomes.
79 implied HN points 08 Feb 24
  1. Estimating software development work and productivity is tricky due to the unknowns and constant changes in the software development process.
  2. The desire to measure developer productivity stems from the human need for clarity in transactions, like buying software products, despite the complexities and uncertainties involved in software development.
  3. It's time to change the perception of software developers as mere code generators and start recognizing them as creative problem-solvers who bring unique value to the development process.
39 implied HN points 20 Apr 24
  1. Achieving a flow state is crucial for peak productivity. Minimizing interruptions like emails, popups and delays helps maintain focus and enhance performance.
  2. Reducing cognitive load is essential. Providing clear domain knowledge and simplifying technical aspects contribute to better understanding and productivity.
  3. Establishing a fast feedback loop is key. Faster identification of issues, learning from failures, and making data-driven decisions lead to better performance and quality.
59 implied HN points 28 Dec 23
  1. Adding more people to a late software project can make it even later due to various factors like onboarding time, increased coordination needs, and additional deployments causing outages.
  2. When a measure becomes the target, it loses its effectiveness, leading to actions like renaming variables or engaging in practices that prioritize metrics over true code quality.
  3. The structure of the software often mirrors the communication structure of the organization that designed it, showcasing the impact of company dynamics on software architecture.
39 implied HN points 21 Feb 24
  1. Productivity is essential for success, and it varies from individual to market level.
  2. Measuring individual productivity involves achieving flow state, quick feedback, and managing cognitive load.
  3. Team and organizational productivity rely on factors like cross-functional teams, reducing work in progress, automation, software development practices, and software architecture.
39 implied HN points 31 Oct 23
  1. Technology trends may focus on the latest and greatest, but essential concepts are sometimes overlooked in the marketing hype.
  2. Years of experience can bring insight into the importance of foundational practices like writing test cases and implementing CI/CD.
  3. Wisdom in software engineering lasts longer than fleeting technology trends and can withstand ecosystem changes.
3 HN points 06 Mar 24
  1. The bulk of a work item's lifecycle in software development is often spent waiting in queues, not in active development or QA activities, highlighting inefficiencies in the process.
  2. More planning and parallel tasks do not necessarily lead to increased productivity; streamlined processes and effective collaboration are key for true productivity.
  3. Individual busyness does not equate to team productivity; focusing on removing bottlenecks and promoting collaborative efforts leads to faster project timelines and meaningful progress.
0 implied HN points 25 Jan 24
  1. Quality is proportional to the quantity of feedback - more feedback means better quality.
  2. Batching is inversely proportional to quality - more batching leads to lower quality.
  3. Decreasing batching can be done through an Agile mindset, automated Continuous Integration/Deployment, feature toggling, early testing, breaking down large features, using MVP approach, and improving team communication.