I see doctors as being more stable in later career than engineering. I don't really have any data for it; that's just my gut impression.
Also you can be a doctor anywhere. Being an engineer in tech feels like you're geographically stuck unless you're willing to make other (career) trade offs.
Having personally been a couple of city council/planning commissions meeting for a few SV cities, I can tell you the fight isn't always that effective. And the argument against aren't about money, it's about traffic, quality of life, character of the neighborhood, etc.
There are other forces at play when these decisions are made. City councils have an incentive to balance their budgets... they see commercial properties as revenue generators and residential neighborhoods as cost centers.
Look at all the commercial properties that have been built. Most of the larger ones also had substantial objections from the residential neighbors. But that didn't stop them.
Consider this:
- If a city council (or whatever government body that allows/disallows development) is ultimately responsible to the voters...
- If most of the (eligible) voters are the "have nots" who face scarce housing
- Shouldn't this fix itself over time?
Yes, the model is more complicated that this, but I think you get the idea.
This is a long winded way of saying, it's not a case of existing homeowners vs not homeowners. There are other factors at play.
Things have changed in SV. I don't know if it is the higher interest rates or something else, but the market has cooled off quite a bit in the last 2-3 months. I bet you can find houses very near their asking price now. Days on market is going up.
What can a homeowner do to keep housing prices low? The only thing a homeowner can do is fight new development, but that isn't the only driver of cost. And depending on the area, fighting new development may not be all that effective.
Yeah I think this is problem with characterizations of "but this branch is telling lies." It's not; running tests reveals the state of the branch. And the coder also might have some idea of far away that branch is from merging to master.
Let's consider it this way:
Common starting point A, current master, where everything passed already.
Two people are working on their own mostly independent features on branches: B1 and B2.
So who's the next master? Well it depends on which of the two finishes first. If B1 tests their branch and they are the first to merge, well there's no double work. They tested what would be the next master.
Say B2 finishes next. If they run their tests now, they have a good idea if their own changes are the problem or not. If they wait to rebase and then test, they now need to consider two causes: (1) their own changes and (2) the combination of B1 and B2 changes.
Sure for a small enough change and good enough set of test cases, the combination of B1 and B2 won't be hard to figure out. But then the situation already is the team knows how to build big features out of many small changes. I would say that's not the majority of the developers out there IME.
Slow regarding build and running really depends... We've gone over to more test oriented coding because the automated tests help us do better than manual testing. A collection of tests built up over time tracks the gotchas/corner cases/etc.
If the developer were better at catching bugs without these test cases, then we would still be doing it manually. But I would rather wait 3 hours for my automated tests than spent 3 hours double/triple checking my code.
The specifics do matter; for some code bases the approach in the article may be right. But building and running some thing twice may not be the wrong thing. I think there's a failure to realize there's an engineering and process design/compromise to be made...
If I understand this correctly, it seems like they are only doing CI/CD on the master/main branch.
The question is why don't they test the feature branches in the same way as master/main? Assuming all their testing is part of the CI/CD system, it seems like that would provide a valuable signal and enable faster feedback as well.
Yes, I suppose there could be capacity constraints around this. But let's hold those aside for a moment.. let assume we have enough computers (IaaS) and testing is full automated.
In this case, I think argument for only testing master is to force the developers to integrate with master as soon as (or as frequently as) possible.
While I can see the benefit in that, I think there is a cost to developer productivity. If you had perfect change isolation and developers always knew how to implement features as a series of small changes this would work. But IME, this is usually not the case.
While you can try to get the developer to change, I don't think this is an easy transformation, especially in a team/org where there's larger diversity in skill set.
Even if that might be the right thing to from a "make everyone a better coder standpoint", I'm not sure it's optimal from a "help the people we have ship quickly and better" by letting them test (CI/CD) as soon as possible.
The cost of rebasing/syncing with master is also highly variable across codebases. Some codebases has pretty stable interfaces that don't change often and it's very easy to work within those borders. But if those interfaces are changing often, I can also envision tons of mental context killing rebases to keep up.
I think there's spectrum of possible outcomes here and the optimal/right choice will vary depending on the circumstances.
Depends on the relationship/partner goals. There are people looking for more short term situations which will probably keep them on the site.
But yeah for those interested in more long term relationships, that's what happens. I cancelled my subscription after I went exclusive with someone.
Consider the goals for a dating website. Finding "the one" is hard; there's just too many factors. Even if you could put all the data gathering on the web for that, how many people would want to do it?
However, if a site is enabling the user to meet more people (and the right kind), I think they're delivering the most value they realistically can.
Oh yeah I'm not saying the model is great, but if someone wants to discount the 1 to 4.3 ratio, that's the estimate I'd throw out there.
And if we take in the half rural estimate, that'd already put it at 1 to 1 today (with lots of room for growth).
Agreed that Chongqing is fairly different (since it's forced "urbanization" due to the Three Gorges Dam). But I've heard a lot of people say Beijing and Shanghai make NYC look "small" in comparison.
Even LA and NY have lots of parts that many Americans may not consider as living "meaningfully in the present" from the point of view being able to work on advanced projects like "Fifth Generation" computing.
While I don't have solid economic numbers (good luck with that in China), if I had a to guess it would make that ratio still one American to two Chinese.
Here's a model that I'll use to back up that idea:
Top 5 US CSAs: NY, LA, Chicago, DC, SF Bay Area: 70.8 million people.
Top 5 Chinese Metro Areas: Guangzhou, Shanghai, Chongqing, Beijing, Hangzhou: 149 million.
Do you encounter a lot of frustrated/unhappy older engineers?
It's worth analyzing why they plateaued (or why do you think they have).
If they gave up on learning, well that's a sad, but good explanation.
If they found themselves satisfied with what they were doing, that's not necessarily right or wrong.
Do you believe they were in an environment where they are well supported and well managed?
Moving to product is worth thinking about; but it's not a silver bullet either.
While you can pick up experience in tasks not typically done in engineering, the things that can limit a person's career is partially independent of their work experience (in terms of the task they are actually supposed to do).
IME if you are going to product for the "money", I think in the long run you're more likely to be disappointed than hit VP of Product. There's just fewer spots in product vs engineering. I think it's much more driven by chance and other factors.
But from an overall career experience, it will likely open new doors for you. Whether those doors are the ones you want remain to be seen.
I also think the vast majority of PM roles are just implementing some Director/VP of Product's wish lists rather than doing much strategy on your own. And hopefully you encounter good product direction, but IME that's few and far in between. Moving up has been much more about adherence to the company's vision/politics than good products/tech.
Plus there's also the interesting dynamic of overall eng/PM relationship within a company. Those can vary from very good to pretty darn toxic.
I don't mean to discourage you from trying. I learned a lot of doing it... but I think it's a tougher path. Depends on your personality and interests. Often it's much more a people job than a tech job, even for very techy products.
To be fair, the product role is also much more varied from company to company (than eng). You may find a place where it is more about the tech and less about company politics.
My bigger question for you is are you at the stage of your (personal) life where you can afford to take a chance on your career. Switching back may not be as easy as you think... especially if you truly embrace the product side (and also depends on what part of tech you're in).
While it may be okay at your present company, IME it's very easy to end up in a wierdo trap of having your feet on two different ships heading in different directions.
I've also got some funny stories about engineering managers who think I've been infected by some disease due to my time in product.
Source: I started my career as engineering IC for several years, moved to product for several, and have now returned to engineering IC for several.
If I get the idea behind it, we're going to eliminate/reduce parking requirements and give a density bonus. And the primary way this will be feasible is if (more) people take transit.
Then the thing about SB827 that doesn't make sense to me is why the bonus is only for residential development.
Yes, I understand that residential pricing is the problem. But, we're not just taking transit to our friend's house. We're taking transit to work and services.
Sure, I can see this working in San Francisco given the transit coverage and relatively centralized business core. (Scary though given the quality of service that Muni/BART offers presently.)
But in LA/SD/Greater Bay Area/Sacramento? I think there's a ton of jobs that aren't off transit lines. Doesn't seem to work well there.
Yes, I agree that things probably need to change in California. But SB827 seems to be about stirring the pot.
SB-827: Planning and zoning: transit-rich housing bonus [0]
Edited:
Nevermind, I see your other posts below.
Original:
I'm a urban California resident... (have been for a good chunk of my life). I'm don't see why this is a solution to the problem of why people are leaving the state.
Can you provide your thoughts on why you believe this to be the solution? Or links to material you've found to be compelling?
I keep hearing the foreign money story, but I can't really find much evidence of it. (I'm currently in SV; touring properties and talking to RE agents nearly every weekend.) I'm not saying it's 0% of the transactions, but I'd be really surprised if it were even 5%.
I'm going to temporarily ignore the "superexpensive" properties, which I'll arbitrarily define as over $4M in SV. That's a different market... for the "global jet-set." Or the people who were the first X employees at a startup with a real liquidity event (and their founders treated them fairly).
Down on the valley floor, $1-3M is within reach of a lot of people in tech, especially double techies. (If you've been here since before the last 2 booms, you've got even more going for you.) Most big tech companies (FANG) stock is way up... Take that as a downpayment... multiple it 2,3, or 4 times and voila.
Markets that have really been hit by foreign money are Vancouver [1] and certain neighborhoods in Los Angeles [2].
Having been to those places (for extended periods of time), I can say SV doesn't feel like those to me.
One last bit of anecdata: I know of one house in SV that received at least 7 offers in the past month. Only 1 of those 7 was all cash foreign money... but they weren't the high bid. 5 other "locals" with loans had higher offers.
1. Keep talking to people who've finished projects. Eventually you'll get to people who recommend their GC.
2. If you've run out of people to chat up, try going to your city's build permits department and see which builders have been getting permits in the last few years. Not a guarantee of quality, but gives you a list to interview.
3. Ask for referrals from your architect or engineer. And then ask the referrals for references.
But even if you do this, finding a good GC in Silicon Valley is very hard right now.
I tried getting contractors to bid almost a year ago. From 25 calls/emails, I got replies from about 8. Of those, half said some variant of "sorry, too busy to take on new projects right now."
I can't imagine how much crazier it'll be this year with the hotter housing market and the added demand for rebuilding after the fires.
California also has Proposition 60 (the property tax one, not the porn one) and Proposition 90 [0].
These allow a one-time transfer of the base year property tax values within the same county (and between some counties) for homeowners over 55 looking to change properties.
The rules are a bit more complicated, but it seems like it would apply to Ms. White's situation and prevent the issue you've brought up.
Also you can be a doctor anywhere. Being an engineer in tech feels like you're geographically stuck unless you're willing to make other (career) trade offs.