Bad Software Advice

Bad Software Advice is a substack that explores the pitfalls and misconceptions in software development. It discusses anti-patterns, ineffective practices, and how to recognize and avoid them, aiming to stimulate creativity, problem-solving, and a deeper understanding of the software industry by learning from mistakes.

Software Development Anti-Patterns Workplace Dynamics in Tech Code Review Practices Team Management System Design and Architecture Technical and Managerial Transition Software Engineering Books and Learning Technical Debt Software Development Metaphors Business Domain Knowledge Software Debugging Automation in Software Deployments Software Development Process Product Roadmap Development Career Development in Tech User Empathy and Feedback Database Design Vacation Policies

The hottest Substack posts of Bad Software Advice

And their main takeaways

How to create a perfect software development process that does not work

2 HN points • 23 Aug 23
  1. Ideally, a software development process should involve clear communication and understanding between all parties.
  2. Implement changes and tweaks in the process when steps fail, rather than blaming individuals.
  3. Constantly strive to refine the software development process until you find what works best for your team.

How to point stories

1 HN point • 06 Nov 23
  1. Agile process involves admitting not knowing, learning, making excuses, and repeating until work is done
  2. Agile shops use Fibonacci point system where less knowledge means more effort instead of time
  3. Developers use a script to determine story points based on factors like complexity and understanding

How _not_ to onboard a new developer

2 HN points • 02 Aug 23
  1. Ensure new developers have a positive and supportive onboarding experience
  2. Provide necessary guidance and resources for new developers to succeed
  3. Maintain transparent communication and support for new hires

How to Create a Product Roadmap

2 HN points • 26 Jul 23
  1. A product roadmap should be stable and not change often.
  2. As a product manager, your work is crucial and should be reflected in the roadmap.
  3. A well-formatted roadmap should be treated as a sacred document that only accepts compliments.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

Commentary: How to be really bad at fixing problems in software

0 implied HN points • 01 Jan 24
  1. Engineers need to understand the context of a problem before designing a solution
  2. Problem-solving in software involves continuously adapting to changing contexts
  3. Stagnation in fixing software problems can be avoided by constantly reassessing and adapting

Commentary: How to treat the people that built the system you work on

0 implied HN points • 26 Feb 24
💼 Business Management Workplace Systems
  1. Show respect for the accomplishments of the people who built the system you work on.
  2. Appreciate that the system you work on exists and has provided you with a job, despite other systems from the same era no longer being functional.
  3. Recognize that every job or contract related to maintaining or replacing a system signifies finding a quality solution to a real problem and building a business around it.

Commentary: How to become a senior engineer too early

0 implied HN points • 11 Dec 23
  1. Focus on managing your career for both short and long-term success.
  2. Be aware of the potential trap of being too valuable to just one employer.
  3. Balancing your skills and value between one employer and multiple is crucial in a software development career.

Commentary: How to write a post-mortem that always blames Terry

0 implied HN points • 18 Mar 24
🕹 Technology Software Engineering Incident Management
  1. In incident management, avoid blame and focus on process and organizational factors. Blameless post-mortems are crucial.
  2. Consider power dynamics in post-mortems. Allow a separate group to handle incidents to prevent bias and promote improvement.
  3. Incidents rarely have a single root cause. Embrace a more complex root cause analysis to understand the multifaceted reasons behind failures.

Commentary by Post

0 implied HN points • 14 Sep 23
  1. Learn how to make programmers work harder
  2. Understand how to avoid burning out in tech industry
  3. Discover tips for getting into developer heaven

Bad Software Advice : Three Interesting Links

0 implied HN points • 09 Oct 23
  1. The Eight Fallacies of Distributed Computing offer valuable insights in the tech world.
  2. Kent Beck's advice on time management can help in prioritizing work effectively.
  3. Considering the larger context is crucial for senior tech professionals to solve business problems.

Commentary: How to treat programming with illogical seriousness

0 implied HN points • 27 Nov 23
  1. Software developers are often placed on a pedestal by society.
  2. The influence and importance of techies is magnified in today's culture.
  3. It's important to treat your work seriously, but not take yourself too seriously.

Library for Subscribers

0 implied HN points • 14 Sep 23
  1. Recommended books for understanding how to build software and teams correctly
  2. Access 7-day free trial to read more posts and full archives on Bad Software Advice
  3. Existing paid subscribers can sign in to access more content

Commentary: How to create an insecure, privacy-blind startup

0 implied HN points • 04 Oct 23
  1. Creating an insecure, privacy-blind startup can be compared to going on a hunting trip in bear country without taking proper precautions.
  2. Over time, the perceived risk of security issues may decrease if no immediate problems are visible.
  3. Consider subscribing to Bad Software Advice for more insights on startup challenges.

Resources for Subscribers

0 implied HN points • 14 Sep 23
  1. Paid subscribers unlock additional content on topics with extra commentary.
  2. Subscribers get access to a resource library with advice on better software practices.
  3. Discounts on books are available for subscribers.

Commentary: How to do a full rewrite

0 implied HN points • 20 Sep 23
  1. Consider caution before doing a full rewrite when working on a new system
  2. Joel Spolsky's 'Things You Should Never Do, Part I' explains the risks of full rewrites
  3. Explore Joel Spolsky's writing and insights for more valuable information