๐Ÿ’€ Every app has its skeletons

๐Ÿ’€ Every app has its skeletons

Newsletter Issues

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:



If you're interested in getting bi-weekly insights from me, sign up for the newsletter. Some of the topics that I like researching are: Growing a business, leading people, controlling chaos inside a startup. In general I write about being a good founder and a decent person.

๐Ÿ““ Newsletter
๐Ÿ‘‹ Feedback
Thanks for the feedback! ๐Ÿ“ฎ