You need to accept one truth – every shop is messy and every app has its skeletons. Period.💀
🦄 You don’t think that Google, Apple, Meta, or others have some skeletons in their development closets? They do. Every project starts with rainbows and sunshine and ends up being held up by sticks and glue – requirements change, deadlines get shorter, people leave, and documentation gets outdated. There are a billion things that change during any software development.
And everyone in IT knows this little secret.
🔥 Whenever some big company does a release, you might think they have it all figured out and release properly tested products with zero bugs on a reasonable timeline. They’re the pinnacle of software development, and we should aspire to be like them. Uh-uh.
If everything goes well on the release date – It’s more of an exception than a rule. You can bet that there’s a team running around with their asses on fire putting out fires during Apple’s presentation of a new product.
🚀 Every team is messy, every release imperfect, every product filled with unknown bugs. That’s just how it is in the IT world. That company that you think is imperfect and you’re not good enough to join is probably just barely keeping their app running. EVERY product has its skeletons that only they know about.
You don’t go around telling people that your automation is a few bash scripts that are run manually or that your product breaks if a few weird conditions are met. There’s always something.
✅ But being messy is efficient. The processes born in messy shops though not perfect, work smoothly, circumventing and adapting to bureaucracy as the product grows. Cutting corners to focus on the stuff that matters is ok; not having everything in order is also ok; returning to re-do parts of the software is also ok.
🤖 As long as the public is not aware of how many fires you put out per week – it can be considered a well-oiled development machine. Who cares if your automatic deployment fails and you need to do it manually. Do it manually, and focus on fixing more critical parts.
Your users want their needs met. They don’t care if you do it on a Kubernetes cluster or two toasters tied together. As Paul Graham said — do things that don’t scale first, and improve later.
Other Newsletter Issues: