eysquared

Seattle is a city of neighborhoods. Move a few block away and the experience would be completely different.

With that said, you visited what I would consider some of the worst places in the city to spend time with kids.

Being forced onto a schedule dictated by your kids is a choice parents make, not a necessity.

I never said I didn't have a car when needed, just that my day to day is much more enriched by not needing one (and being forced to get out of the house).

I will always choose to spend my time exploring the mountains with my kids, but if they choose soccer/baseball/etc then its just medium walk or short bus ride away.

I live in Seattle with a 2 year old and one more on the way. I can't believe I ever considered leaving the city to have kids. I can walk to a coffee shop 3 blocks away without taking 15 minutes to strap my kid in a car seat and the amount of parks we have access to in a short walk in incredible. We take the bus to the zoo and aquarium and my son loves seeing all the people and looking out the window.

Being out and about means I feel a real sense of community and have really gotten to know my neighbors.

When we see our friends from the suburbs its amazing how cooped up they are, how unlikely they are to leave the house, and how unattached they feel from their surroundings. Its too easy for them to play in their basement or yard.

Staying in the city has given me and my family a much higher quality of life.

I do just that between a web front end I own and a RN app. We write as much pure JS as we can so we can re-use the logic.

For sharing presentation, I'm hopeful for solutions like react-native-web.

I love that development model for internal platforms, but it sounds like you are isolating yourself from the pain points that your customers often face.

My current company casts a weary eye at third party software so the import process is slow and involved. This means we only take major versions, and usually not very quickly. When those versions then introduce regressions in our own products and in dependent libraries it only serves to strengthen the voices calling to ditch the external solution entirely. It'd be a different story if a major version seemed to be of consistent quality to squat on for a while, but each new version brings its own challenges.

To be clear this is all involved in life as a dev in a large software company. For my own personal use I'd rather see RN move as fast as possible. I'm fighting the good fight to keep up (and increase) adoption at work so I just hope that FB and the RN team keeps these things in mind.

Thanks for the additional insight here.

I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target.

You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.

The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can.

For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript.

I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.

Is this a new concept? Aside from interviews at Google which were 100% whiteboarding, I’ve always talked through a technical project or bug in interviews.

As an interviewer I always open with some form of this to loosen the candidate up, assess the validity of their resume, and sometime soon just to satisfy my own curiosity (tell me why you did x in z, compare framework a to b, how do you like working in z?).

>One startling finding in the report was that the hiring agents who were deemed most anti-black (according to bias testing) rewarded black referrals more than the nonbiased white employers

I don't have access to the study - is there any explanation of how they concluded if one was bias or not? Seems like this is a fundamental component of the study and yet their own results seem to contradict its outcome.

Thats because the team that wrote Groove Music (and Movies & TV) originated from the Zune desktop player and Windows Media Center. In fact it still used a lot of core code from the Zune days for things like library management and DRM.

Source: former dev on the team.

I think this largely depends on where in their career they are and how familiar they are with coding in the environment they just found themselves in (large org, small company, startup, tech stack, etc).

In general I find pairing a new hire with a less senior but relatively new hire to be a good way to get them ramped up quickly. Ideally this person has recently gone through the same process and can help get the new person unstuck. It also very much helps in the first few weeks to have a single point of contact to ask all the basic questions to get them up to speed before they feel comfortable reaching out to the larger org.

After this its all about knowledge transfer and task management. Helping them understand why things are the way they are, not just how. There is a tendency for new devs to come in and want to change everything to be "better" without understanding the reasons for the current state of the world.

Once they are up and running, giving them larger and larger tasks with less and less guidance will get them out of their comfort zone and needing to get better integrated into the team. They will need to ask for help from an area expert, sync with PM, and be responsible for something end to end (though likely already pre-defined by someone more senior).

If they've made it past that point they should start becoming more autonomous and a great candidate to be a mentor for new devs coming in. Once they hit this stage, I find giving them more responsibility and less guidance can help them grow, fail, and learn.

I could write a lot more about this subject but thats a general idea of how I look at the ramp up process. Getting to Senior is a whole different topic, but for context I've only ever worked at large tech firms so thats the only definition of Senior I know.