As a consultant, how do you handle a potential client's risky software setup? In this episode we detangle red flags from opportunities; and work through the legal and ethical need to do more than just do what the client asks. We cover the questions and discussions consultants need to protect themselves, their business, and their customers.
If you've ever wondered if you can, or should, help a client with a risky setup, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Once upon a time a Software Engineer and a Mechanical Engineer needed to lift the leg of a table and slide a carpet underneath. The Software Engineer, being younger, offered to lift the table with his hands. This would create enough room for the Mechanical Engineer to slide the carpet under. They would repeat the process for each leg.
The Software Engineer lifted with all of his might, but could not raise the table. “The worker is not powerful enough”, he declared. “I will call in some more people. By scaling out the number of workers, we will reduce the amount of power each worker needs. When we have sufficient parallel workers, the table leg will rise.”
The Mechanical Engineer replied, “Get me a 2x4 and a brick.”
And so the edge of the table was lifted. “I estimate that the lever gives me about 20:1 leverage,” the Mechanical Engineer said, holding the table up with one hand.
Are communication gaps tech debt? Do they cause tech debt? Can they be worse than tech debt? Austen Tucker joins us this week to ponder communication's role in building software.
If you've ever wasted weeks writing great code that never got used, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Can changing jobs be a rewrite on your career? In this episode we work through the similarities and differences and see if changing jobs is a Rewrite, and if our mantra of Never Rewrite still holds.
If you've ever thought about getting a new job because you hate your current one, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Giving constructive feedback on software is difficult. You need to approach it with empathy for past developers, context on the problem, and separation between the code and the developers who wrote it.
If you've ever given feedback that was not only ignored, but made the developers mad, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Tech debt is a nebulous concept to anyone who hasn't worked as a developer. Yes, tech debt makes things harder and slower, but why? What is it like? In this episode Isaac and I offer a useful analogy: Tech Debt is like construction on an old house.
If you've ever struggled to explain why tech debt is so difficult and unpredictable, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Are bad practices around testing and releasing cultural or technical? "Bad" changes as a company grows and matures, and what was bad for a startup may not be bad for more established companies. Similarly, holding on to startup practices to long can have a devistating impact on accountability.
If you've ever wondered why your company can't kick bad habits, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Welcome to “Your Edge Case is Showing!” In this series I discuss real world software edge cases that happened to me. The goal is to have a constructive analysis of the problem, the thinking behind it, and why it probably hasn’t been fixed despite being broken in production. As a general disclaimer - I’m using the software because I like the company and I’m a customer.
—---------
I do most of my grocery shopping at Jewel Osco, they have mastered the number one most important consideration: They are the closest grocery store to my house. They also have a really good selection of apples, are cheaper than their competitors, and they are open late. What they don’t have is a good mobile app.
After placing my latest online order I noticed that they were sending a receipt to [my phone number]@dummy.com
My shopping app account is based on Jewel’s rewards program, and I signed up for the rewards program with my phone number. I have never given Jewel my email, mostly because they never asked!
My guess is that email is a required field in the app’s data model. So the developers handle the missing data using what they have, my phone number. Adding “@dummy.com” to make a technically valid, but obviously fake email address.
Why Doesn’t It Get Fixed?
The app has a LOT of problems. It’s unstable, it’s slow, and it apparently sends receipts to anonymous domain owners in the Bahamas.
I can imagine managers prioritizing stability and pushing edge cases like email receipts to the side. After all, if no one can use the app, it can’t leak any data! Fixing bugs is also much easier than changing fundamental data constraints. I wrote a whole series of articles on the topic!
Wildly discounting the cost of privacy leaks is a common mistake!
I have submitted a bug report. Fingers crossed this is not what it looks like, or will be fixed very soon.
Start small, get feedback, and keep going! This week, Day Martin, founder of Swayday, shares her company's iterative journey. Swayday began with motion games aimed at causal gamers and has iterated to their current mission of using motion games to improve educational outcomes for children with ADHD.
If you've ever wondered what it is like to iterate as an entreprenuer, this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
Project failures are an inevitable part of a software developer's life. While failures are inevitable, learning and recovering value from the wreckage is entirely optional. In this episode Isaac and discuss ways to learn more, reuse more, and minimize the scope of project failures.
If you've ever had a project fail and wondered "now what?", this is the episode for you!
Watch on YouTube or listen to it at Spotify, Apple Podcasts, or your favorite podcast app, and let us know if you have ever been involved in a rewrite. We would love to have you on the show to discuss your experience!
