3 ms·

You're generalising to win an argument. The lead may know less than them about some things. That's OK for us. But what's important is they know more than the t

You're generalising to win an argument. The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things. For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on. Sorry that contradicts the black-and-white world view you're holding. I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome. You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times. Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.

scarface_74 3y ago
> Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve. The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts. Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”. [1] My four experiences with dealing with mobile implementations 1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements 2. Railroad car repairmen in a rail yard 3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints. 4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.

scarface_74 3y ago

> Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve. The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts. Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”. [1] My four experiences with dealing with mobile implementations 1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements 2. Railroad car repairmen in a rail yard 3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints. 4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.