Episoder
-
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.
-
Manglende episoder?
-
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 - Vis mere