Location Boston, MA
Interests Programming, Photography, Cooking, Game Development, Reading, Guitar, Running, Travel, Never having enough time...
This Site Made with Astro, Cloudinary , and many many hours of writing, styling, editing, breaking things , fixing things, and hoping it all works out.
Education B.S. Computer Science, New Mexico Tech
Contact site at dillonshook dot com
Random Read another random indie blog on the interweb
Subscribe Get the inside scoop and $10 off any print!
Change at the Highest Level Is Impossible
Think about how hard it would be to get all of humanity to agree on and learn one language. It’s impossible right? Even if we made contact with aliens who told us they would destroy the planet unless we all learned one language it’s still not going to happen. Coordination at that scale is out of humanities grasp right now and even getting a group of people to agree on anything is rough.
When you get down to the size of large companies it becomes theoretically possible but still extremely difficult. Strong leadership and a large external pressure forcing a change improves the situation, but the social inertia takes a massive amount of time and energy to overcome.
The same is also true for changing anything in software!
The bigger the codebase, the bigger the size of the team is, and the more repetitions of a pattern there are, the harder it is to change. This is why it’s so crucial to establish good patterns early on in your startups lifecycle before the nasty parts get copy pasted everywhere.
All too frequently I’ve seen things like bad (or none) ORM setups, tedious multi-repo PR workflows that need synchronization, poorly typed inconsistent APIs, and auth checks repeated in every endpoint which just needed to be moved to middleware. None of these are painful enough to require immediate action when the company and code is small, so screw it, what’s the harm in copying it one more time? It’s definitely someone elses problem…
Then one of a few different things happens:
- The project get abandoned (always a chance)
- No one takes the time to fix any of the issues, they keep spiraling, it gets harder and hard to work on the project, then the project gets abandoned (or replaced)
- Someone has to take on the now daunting task of implementing a better way everywhere
But even in the best case of this bad scenario, you still gotta get everyone on the boat paddling in the same direction. The more people there are working on a codebase, the better you need to communicate the plan and zealously watch for any PR’s going against the grain. It’s not so bad when your team is small, but try herding hundreds of cats opinionated developers.
This is why it’s crucial to get a strong foundation before scaling your team
Otherwise you’ll have a big bowl of unseasoned & unsauced copy pasta, and no one wants that.
Want the inside scoop?
Sign up and be the first to see new posts
No spam, just the inside scoop and $10 off any photo print!