Guest Dustin Rea joins us to discuss the importance of aligning a company's standards and processes with its lifecycle stages. The discussion covers five key phases: the MVP phase, where the foundation is built; the Product User Fit phase, focusing on understanding customer needs; the Product Market Fit phase, solidifying the offering; the Scaling Up phase, managing growth; and finally, the Multi-Product Platform phase, where companies expand their offerings. Each phase presents unique challenges and requires different approaches to maintain quality and efficiency.

Jeffrey and Isaac discuss the inherent risks associated with software rewrites, emphasizing how rewrites push risk to the end of the development cycle. The discussion highlights the need for iterative development and the significance of delivering independent components to ensure project success, particularly within the SaaS model, which thrives on continuous improvement and customer satisfaction.

Jeffrey and Isaac explore the concept of 'musketeering' in software development, emphasizing the importance of collaboration in solving complex problems. They discuss the challenges of legacy code, the necessity of testing, and the strategy of 'divide and conquer' to tackle intertwined issues effectively.

Isaac and Jeffrey discuss the philosophy of continuous iteration in software development, emphasizing the importance of making small, incremental changes rather than large, risky updates. They explore the challenges of communicating the value of these trivial changes to non-technical stakeholders and the benefits of refactoring code for future development. The discussion also highlights the significance of storytelling in conveying the purpose and impact of these changes to a broader audience.

Isaac and Dustin Rea discuss the impact of perfectionism in programming, particularly how it can hinder project success. They explore the importance of launching minimum viable products (MVPs) to validate ideas in the market, the challenges of managing change in production software, and the balance between perfectionism and practicality. The discussion also highlights the significance of team dynamics and customer empathy in software development, as well as lessons learned from scaling and responding to customer demands.

Isaac and Jeffrey explore the complexities of error management in software development, particularly focusing on the significance of logs, the philosophical implications of ignoring errors, and the importance of proactive log management. They discuss how to differentiate between true errors and warnings, the role of telemetry in alerting, and the necessity of maintaining clean logs to enhance system understanding and customer experience.

Isaac and Jeffrey delve into the concept of resource engineering, emphasizing the importance of understanding cost implications in engineering decisions. They discuss how engineers often overlook financial aspects while focusing on technical solutions, leading to potential inefficiencies. The dialogue highlights the need for engineers to have greater visibility into costs, particularly in cloud services like AWS, and how this awareness can drive better decision-making. They also explore the balance between optimizing costs and developing new features, advocating for a more business-oriented mindset among engineers to enhance overall effectiveness.

Isaac and Jeffrey delve into the anxiety developers face when dealing with legacy systems they did not create. They explore the reasons behind the fear of fixing such systems, the challenges of refactoring, and the skills required to navigate these situations. The discussion emphasizes the importance of understanding legacy code, learning from it, and developing strategies to reduce anxiety when approaching refactoring tasks. Practical tips are provided for developers to build confidence and make meaningful contributions to legacy systems.

Jeffrey and Isaac discuss the fallacy of rewriting software to save money. They highlight that organizations end up running multiple systems simultaneously, resulting in increased costs. The conversation also touches on the challenges of maintaining multiple versions of a software system and the importance of continuous delivery and iteration. It concludes by emphasizing the need to prove the ability to migrate existing pages before starting a rewrite.

Jeffrey revisits The Joel Test, a 12-question test to determine if a software development team is set up for success. Jeffrey and Isaac discuss the relevance of each question in today's context and how the industry has evolved over the years. The topics covered include source control, building and deployment processes, bug tracking, bug fixing, project scheduling, specifications, working conditions, and tools. Show notes:https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

Isaac and Jeffrey discuss the importance of effective bug bashing and how to prioritize bug fixes. They highlight the need for categorizing bugs, understanding customer impact, and installing analytics to make informed decisions. They also emphasize the importance of writing tests and having a team member close to the customer to provide context. They recommend starting with backlog grooming and prioritization before diving into bug fixing. Overall, the conversation provides valuable insights for managers and developers dealing with bug backlogs.

Isaac, Dustin, and Jeffrey discuss different profiles for de-risking releases. They explore the perspectives of software engineers, project managers, product owners, and executives in managing risk. They debate the benefits of incremental releases versus giant functionality releases and the importance of user feedback in de-risking product changes. They also discuss the trade-offs between time, size, and change in managing risk. The conversation touches on the challenges of balancing risk and reward, the importance of lean strategies in startups, and the need to be prepared for success as well as failure.

Isaac and Jeffrey discuss the importance of aligning oneself with a company's risk profile. They explore the concept of risk tolerance and how it varies depending on the company's stage of development and industry. They highlight the need for a balance between security and other business priorities, as well as the importance of having conversations about risk tolerance with managers and teams. They also touch on the potential misalignment between managers and companies, and the implicit cultural risk tolerance that can lead to security vulnerabilities. Overall, they emphasize the need for understanding and navigating risk in the context of software development.

Isaac shares a story about a project where a quick MVP was built to send text messages to users. As the project gained more partners and volume, it became clear that the system couldn't handle mass texting at scale. A small change in the architecture caused some batches of text messages to be reprocessed multiple times, resulting in some users seemingly receiving an excessive number of texts. However, through many strokes of luck, each area where duplicate texts could have been sent was saved by a downstream setting. The issue was resolved, and the team learned the importance of implementing proper safeguards and architecture.

Isaac and Jeffrey discuss the peculiar failure of correctly predicting problems. Jeffrey shares his experience of being able to accurately predict problems in projects but failing to gain traction and prevent them. They explore the importance of buy-in from leadership and the need for a collaborative engagement structure. They also discuss the role of consultants and the difference between being diagnostic and being collaborative. The conversation highlights the challenges of convincing leadership and the potential consequences of not being able to prevent problems.

Dustin Rea, CEO of Red Hook Agency, discusses the challenges and considerations of bringing new products into an existing platform and splitting products within the same platform. The conversation covers topics such as authentication and authorization, merging different products onto a platform, reorganizing teams, and converting internal tools to SaaS. The speakers also touch on the importance of onboarding experiences for new and existing customers.

Isaac and Jeffrey discuss the feeling of anyone being able to make small, simple changes in code and question the value of their own contributions. They share anecdotes of fixing issues that others could have easily addressed but didn't, highlighting the importance of being the one to take action. They emphasize the value of iterative changes and the knowledge work involved in understanding the system. They also encourage developers to listen to complaints and pain points in order to identify opportunities for impactful improvements.

Isaac and Jeffrey discuss the myth of the Boy Scout rule, which is the idea of leaving code better than you found it. Isaac shares his experience of encountering problems when trying to follow this rule in a codebase with no test coverage. He explains how fixing one issue led to unintended consequences and a cascade of errors. They emphasize the importance of being cautious when making changes in old and tightly coupled code and the need for thorough testing. They conclude that while refactoring is important, it should be done intentionally and not mixed with other changes.

Isaac and Jeffrey discuss situations where software development teams are pushed to have fewer, larger releases. They highlight the challenges of big release-driven development and the need for careful planning and more QA before each release. They also explore strategies to make the problem less severe, such as minimizing the final push, using an API-first strategy, and feature flagging.

We check in with Dustin Rea, head of Red Hook Agency, to discuss where White Label CRM is with their 'turnaround story' - how they're handling 'bug hell', scaling issues, and what their trajectory is now.

Isaac and Jeffrey discuss the potential of AI-driven testing and code generation. They reference an article by Codium AI, which explores the use of AI to generate tests and increase code coverage. While the generated tests may not be perfect, they can serve as scaffolding for legacy code and help identify areas for improvement. The conversation also touches on the idea of using AI to provide business context and legal compliance guidance during code refactoring. Overall, the discussion highlights the potential benefits of AI in improving code quality and reducing risk.Show notes:Codium article: https://www.codium.ai/blog/we-created-the-first-open-source-implementation-of-metas-testgen-llm/

Isaac and Jeffrey discuss the mindset of writing your job out of existence. They explore the idea that being irreplaceable can be a trap and that making your current role disappear in a positive way is the key to career growth. They share examples of individuals who get stuck in repetitive tasks and fail to see the opportunity to transform their work. The conversation highlights the importance of reframing problems as opportunities for improvement and the need to overcome the fear of change. They also touch on the issue of intentionally not fixing problems to protect one's job.

Jeffrey and Isaac discuss how to get started with shadowing people and solving their problems. They share their experiences and strategies for shadowing, including reaching out to the people you want to shadow, observing their tasks, and identifying areas for improvement. They emphasize the importance of shadowing during the onboarding process and the value of asking questions and challenging existing processes. They also highlight the benefits of building relationships and earning credibility by solving problems for others.Takeaways- Shadowing people and solving their problems is a great way to learn and make a positive impact in a new role.- During the onboarding process, take the opportunity to shadow and observe how people work.- Ask questions and challenge existing processes to identify areas for improvement.- Building relationships and earning credibility by solving problems for others is crucial in the workplace.

Isaac and Jeffrey discuss the topic of doing full rewrites when it comes to architecture. They explore a case where a client needed to move from a single EC2 instance to a more stable system with load-balanced instances. They discuss the parallels between rewriting code and rewriting architecture, and the challenges and risks involved.

Isaac and Jeffrey discuss the 'two clock problem' as a metaphor for software rewrites. They explain that adding a new system doesn't improve understanding if you don't know how the current system is wrong. They also emphasize that rewriting a system without understanding the current system is costly and may not be worth it. Instead, they suggest spending more time understanding and documenting the current system to mitigate the need for a rewrite. Takeaways - Adding a new system doesn't improve understanding if you don't know how the current system is wrong. - Rewriting a system without understanding the current system is costly and may not be worth it. - Spending more time understanding and documenting the current system can mitigate the need for a rewrite.

Company culture can have a significant impact on the style of code delivery. A rigid and bottlenecked code review process can slow down code delivery and create frustration. On the other hand, a collaborative and open culture can lead to faster and more efficient code delivery. It is important to strike a balance between code quality and speed of delivery. Perfect code that doesn't solve the problem is not useful, while imperfect code that is easy to change and improve can be valuable. When considering a job, it is important to ask about the company's code delivery style and whether there is a culture of collaboration and openness.Takeaways - A rigid and bottlenecked code review process can slow down code delivery - A collaborative and open culture can lead to faster and more efficient code delivery- Striking a balance between code quality and speed of delivery is important- Imperfect code that is easy to change and improve can be valuable- When considering a job, ask about the company's code delivery style and culture

In our new series 'fulfilling Fridays', Jeffrey shares a fulfilling software project he worked on at Guaranteed Rate, a mortgage broker company.

Isaac and Jeffrey discuss falsehoods that programmers believe about projects. They explore the misconception that the project will solve the stated problem, highlighting instances where the delivered software did not actually solve the problem. They also discuss the importance of understanding how the user will use the software and the need for clear communication and feedback loops to ensure that the project is on track. They emphasize that the success of a project is not solely determined by the software, but also by factors such as the alignment of project goals and the availability of resources. Overall, they highlight the need for critical thinking and continuous communication to avoid common pitfalls in project development. Takeaways- The project may not always solve the stated problem, even if the software is delivered as requested.- Understanding how the user will use the software is crucial for building a useful and successful product.- Clear communication and feedback loops are essential to ensure that the project is on track and aligned with the user's needs.- The success of a project is not solely determined by the software, but also by factors such as project goals and available resources.

In this episode, Isaac and Jeffrey discuss falsehoods that programmers believe about projects. They explore assumptions such as projects having defined beginnings and endings, the role of priorities in project work, and the importance of clear communication and feedback. They also touch on the challenges of working on successful projects that transition into ongoing maintenance and the consequences of failed projects that continue to exist. The conversation highlights the need for programmers to question these assumptions and adapt their approach to project management.Takeaways- Projects often don't have defined beginnings or endings, and assumptions about their start and end dates can lead to confusion and miscommunication.- Relying solely on personal priorities to determine when to start working on a project can lead to conflicts and misunderstandings with others who have different priorities.- Clear communication and feedback are crucial in project work to ensure everyone is on the same page and to avoid missed signals and mixed signals. - Programmers should be proactive in sharing their expertise and insights on projects, even if they haven't been explicitly asked, to prevent unnecessary rework and improve overall project outcomes.- Successful projects often transition into ongoing maintenance and feature development, while failed projects that are not fully turned off can continue to exist and incur costs.- Questioning assumptions and adapting project management approaches based on the specific context and circumstances of each project is essential for success.

Isaac and Jeffrey discuss the flight to maintenance work as a safety option from the manager's perspective. They explore different perspectives on maintenance work and the value of taking on such work. They emphasize the importance of understanding the reality of the system and approaching maintenance work as an opportunity to solve real problems. They also discuss the role of accountability and changing the culture around maintenance work. The episode concludes with a discussion on the impact of not addressing maintenance work and the benefits of going slow to go fast.Takeaways- Maintenance work should not be viewed as a punishment, but as an opportunity to solve real problems and make teammates' lives easier.- Understanding the reality of the system and addressing maintenance work can have a positive impact on the team's morale and productivity.- Managers should create a culture of accountability and ensure that support and maintenance issues are fixed, not just mitigated.

In this conversation, Dustin Rea discusses the challenges faced by one of his clients who has a CRM. The CRM is built on a legacy codebase with issues in quality, scalability, and deliverability. The team has been working on improving the system, but there are still problems with emails, SMS, payments, and automations. The company is mission-driven and relies on the CRM to run their business, so rebuilding customer trust is crucial. They have made some improvements in infrastructure and email deliverability, but there is still work to be done. The conversation covered several topics related to database architecture and system design. The main themes include database optimization, handling heavy reads and writes, improving error handling and incident response, and enhancing observability. The speakers discussed the need for a purpose-driven database, implementing caching with Redis, tracking heavy queries, and addressing inconsistencies in the email service. They also mentioned the importance of logging and monitoring tools like Sentry and Grafana. Overall, the conversation highlighted the challenges and potential solutions for improving the performance and reliability of the system.Takeaways:- The client's CRM system is built on a legacy codebase and has issues with quality, scalability, and deliverability. - The team has been working on improving the system, but there are still problems with emails, SMS, payments, and automations.- Rebuilding customer trust is crucial for the company, as the CRM is core to their business.- Improvements have been made in infrastructure and email deliverability, but there is still work to be done.- Optimizing database performance is crucial for handling heavy reads and writes.- Implementing caching with Redis can help improve performance and reduce load on the database.- Tracking and optimizing heavy queries is important for identifying and resolving performance issues.- Improving error handling and incident response processes can help address inconsistencies and ensure reliable system operation.- Enhancing observability through logging and monitoring tools can provide valuable insights for troubleshooting and improving system performance.

Isaac and Jeffrey celebrate the one-year anniversary of the podcast. They discuss the challenges of maintaining a consistent schedule and reflect on the evolution of topics covered in the past year. They also talk about running out of failure stories and the importance of finding interesting guests. The hosts discuss the concept of forcing functions for successful rewrites and the risks associated with rewrites. They also explore the idea of the Ship of Theseus and how it relates to software development. Lastly, they discuss how rewrites can discourage learning about the current system. In this episode, the hosts discuss various themes related to software development and the process of rewriting code. They emphasize the importance of the investigation process and how it can be used to improve code quality. They also discuss the benefits of tidying up code and the value of iterative workshops. The hosts highlight the importance of understanding the business side of software development and the need for developers to develop human skills in the age of AI. They also reflect on past interviews with industry experts and invite listeners to participate in future guest episodes.Takeaways- Consistency and scheduling are key to maintaining a successful podcast.- Finding interesting guests and stories is important to keep the podcast engaging.- Forcing functions are often necessary for successful rewrites.- Rewrites can be risky and discourage learning about the current system. The investigation process is crucial for understanding code and improving its quality.- Tidying up code and making small improvements can make it easier for future developers to understand and work with.- Iterative workshops can be an effective way to transform and improve code.- Developers should strive to understand the business side of software development to make better decisions.- Developing human skills is important in the age of AI.

Jeffrey and Isaac discuss the concept of ‘doing more with less.’ They explore the initial visceral reaction to this idea and highlight the importance of doing less of things that don't matter. The impact of layoffs and the need to work smarter, not harder, are also discussed. The hosts emphasize the value of having honest discussions and creating a culture of transparency. They caution against burnout and advocate for trimming the fat responsibly. The episode concludes with a reminder to acknowledge mistakes and continuously learn.Takeaways- Focus on doing less of things that don't matter instead of trying to do more with less.- Layoffs can have a significant impact on workload and employee morale, leading to burnout and a potential death spiral.- Work smarter, not harder, by finding ways to be more efficient and effective.- Create a culture of honesty and transparency to address challenges and make necessary changes.- Trim the fat responsibly by evaluating and adjusting projects and resources.- Acknowledge mistakes and learn from them to improve future decision-making.

Jeffrey and Isaac discuss their stance on 'never rewriting' given the possibility of AI making rewriting faster, cheaper, and less risky. They explore the limitations of current AI capabilities and the potential benefits of AI-assisted refactoring. The conversation delves into the idea of using AI to write tests and improve code quality. They also discuss the challenges and opportunities of AI in language switching and high-performance code optimization. Overall, the episode highlights the evolving role of AI in the rewriting process and the potential impact it may have on software development in the future.Takeaways- AI is not yet ready for code rewriting, but it has the potential to assist in the process.- AI can be used to write tests and improve code quality, but human supervision is crucial for effective results.- AI can help understand code better when provided with business context and documentation.- AI may play a significant role in language switching and high-performance code optimization in the future.

Jeffrey and Isaac discuss how iteration can be a defense against micromanagement. They explore the reasons behind micromanagement, such as a lack of progress and fear, and how iteration provides observability and reassurance to managers. They emphasize the importance of breaking down nebulous projects into smaller deliverables and providing checkpoints to show progress.Takeaways- Iteration provides observability and reassurance to managers, reducing the need for micromanagement.- Breaking down nebulous projects into smaller deliverables helps show progress and alleviate fears.

In this episode, Isaac Askew interviews Ryan Cowan, a software engineering manager, about the perspective of managers on rewrites. They discuss the challenges of placating individual engineers who want to rewrite code, the role of managers in supporting engineers' ideas, and the frequency and success of large rewrites. Ryan shares a case study of data engineers rewriting a data pipeline and highlights the importance of understanding the root cause of concerns before deciding on a rewrite. They also discuss the difference between refactoring and rewriting and the expectations engineers have from their managers. Takeaways:- Managers play a crucial role in supporting engineers' ideas for rewrites and refactors. - Large rewrites are infrequent and often require significant buy-in from senior leadership.- The distinction between refactoring and rewriting is important, with refactoring being more focused on improving existing code and rewriting involving significant changes to the entire system.

Isaac and Jeffrey provide strategies for working with colleagues who are emotionally committed to rewriting old and flawed code at their companies.Takeaways- Validate the analysis and perspective of coworkers who are emotionally committed to doing a rewrite.- Consider the financial implications of a rewrite and align priorities with the business's goals.- Communicate the rationale for not pursuing a rewrite and document the reasons for future reference.

Jonathan Stark joins as a guest discuss the risks of hourly billing and the parallels between risk in a rewrite and in hourly billing. He explains how hourly billing puts all the risk on the client and leads to stressful relationships and arguments about hours and costs. Jonathan emphasizes the importance of trust and how it can be built through delivering on promises and becoming an authority in your field. He also provides strategies for pushing back against rewrites and making informed decisions based on cost and quality. In this conversation, Jonathan and Jeffrey discuss the importance of taking risks and understanding the business side of software development. They emphasize the need for developers to consider the financial risks their clients are taking on and the value they provide. They also highlight the benefits of speaking in terms of dollars and business outcomes rather than technical details. The conversation touches on the challenges of system rewrites and the importance of considering the cheap and easy options before diving into complex projects. They conclude by discussing the concept of value pricing and providing the best solution for clients.Takeaways- Hourly billing puts all the risk on the client, leading to stressful relationships and arguments about hours and costs.- Trust is crucial in client relationships and can be built by delivering on promises and becoming an authority in your field.- Pushing back against rewrites can be done by presenting multiple solutions and discussing the trade-offs between cost and quality.- Software estimates are important for budgeting and decision-making, and developers should be encouraged to provide estimates for different solutions.- Developers should understand the financial risks their clients are taking on and the value they provide.- Speaking in terms of dollars and business outcomes is more valuable than focusing on technical details.- Consider the cheap and easy options before diving into complex projects.- Value pricing involves providing the best solution for clients. Jonathan's website: https://jonathanstark.com/.Books mentioned (affiliate links): How to Measure AnythingThinking in BetsSuperstruct Manifesto

Isaac and Jeffrey explore the significance of maintenance work for developers, stressing its strategic value during uncertain periods like layoffs. They share personal experiences, highlighting how tackling these tasks can lead to trust, new opportunities, and a more impactful role within a team.

Isaac and Jeffrey dissect the flaws in the interviewing process and offer valuable insights for both interviewers and interviewees. They discuss the broken aspects of traditional interviews, highlight the importance of resume tailoring, and share anecdotes about handling past job experiences during interviews. The episode serves as a guide for interviewers to improve the hiring process and for candidates to enhance their chances by navigating the pitfalls and maximizing opportunities.

Jeffrey & Isaac discuss why understanding how your company makes money can help you build products that solve the right problems.

Jeffrey & Isaac discuss methods to clear out your recurring meetings and protect your time as new meetings get added to your calendar.

Continuing our F*ck-Up Friday series, Jeffrey has another humorous story where he went out of his way to fix functionality to match the name of its function...with expensive results.

In this humorous holiday episode, Isaac and Jeffrey discuss ways to be the worst possible teammate in ways that won’t get you immediately terminated by HR. If you didn’t make the naughty list this year and want to lock it in next time, this episode is for you!

Isaac and Jeffrey continue discussions around testing brownfield code, delving deeper into next steps and refactoring.Our ‘FlowSheet’ guide to help you with your testing and refactoring decisions: https://images.squarespace-cdn.com/content/v1/64127dab7e53173c1e7c39a1/9d699636-4625-4fc3-862c-a66907fd47dc/Getting+Started+With+Brownfield+Code.png?format=2500w

Brownfield code is existing code (rather than new code) that you might need to add tests for. Join us for a two-part episode on how to get started testing and refactoring existing applications.

Isaac and Jeffrey discuss ways to improve yourself outside of traditional means like college, courses, or reading.

A non technical story of deception, good deeds with terrible consequences, and weak HR.