Beyond the First Few Years

To be a human in nature is to be vulnerable and uncertain and messy and weird and a bit lost, same with leaving my first job.

December 19, 2019 -

Disclaimer: title inspired and shamelessly stolen from Practicing Developer.

Turned out leaving my first job is much harder than I expect, yeah not easy at all. Especially if it’s the one where you’ve been lingering for a while, going through some ups and downs, battles and glories, step by step earning that trust to build stuff with both larger scope and more unknowns - and eventually at some point you kinda have a sense that “Hmm this feels good. This is something I’m really good at”, though it’s probably an illusion.

My second job has a completely different vibe from the first one, given its scale on both developer and user bases. I feel lost when I can’t just do “pod install -> cmd+R in Xcode -> profit”, after spending half an hour cloning the repo and another half figuring out where the main function and AppDelegate are. I was like “wtf” when running into same problem we faced at previous company but seeing it’s solved in a kinda opposite way.

Clicking through code locating in different source pods just feels productive. You can’t really do it here. A calls B, but they’re in different libraries. Where’s B? You run a code search tool and it tells you it’s in a library X. Then you have to rebuild to incorporate that library. Then why bother reinventing the wheels? Don’t forget about those unproductive moments caused by incremental build taking forever even if you just change one LOC, not to mention those unpleasant surprises brought by each Xcode update. For a codebase with < 5 active contributors, it’s probably just some sand in the shoe, annoying but bearable. But with hundreds of cooks in the kitchen trying to be productive at the same time, that’ll trigger the smoke detector.

Ohhhh and you want to see two iOS engineers fight? Let them discuss if they prefer to use dependency injection framework or just do manual DI. Sounds no fun? Ask their opinions on stubbing and mocking in unit test. Respect the platform with vanilla approach or write code once driven by one platform? Move fast and break things or move purposely and fix things?

Sometimes I get stressed out by these options while sometimes I somehow just get peace with them, and myself. “I choose A instead of B, because of X, Y, Z”, the variables here could change dramatically for the same problem under different context and constraints. It’s a give-and-take which at least I’m glad to get a taste of why it goes the length it has gone.

“To be a human in nature is to be vulnerable and uncertain and messy and weird and a bit lost”. I think it’s probably :fine: .