josephmosby

(not the author, but here's how I think about it)

Assuming that you're not a commodity product, it all kinda nets out in the end. If you have a competitive market, you have proof that people want your product at a good price, else no one would be in the market. If you execute better than all of your competitors, then you can theoretically take every last penny of that market.

I don't think the competitive pressure changes the decision whether there's revenue to be made in a certain space, though it may change the personal decision if the operating tactics required in a competitive market are personally fun for you the human being.

Wholeheartedly agree.

Personas are useful for developing a general character that you can refer to. But you still have to be able to say "Alice Robertson, who is a demand-gen marketer at $CUSTOMER, is a prime example of this persona and someone we should talk to during product research." If you can't speak to an actual human and validate your ideas, then you are at risk of creating a fake persona who sounds just plausible enough to convince you to make wrong decisions.

Spiritually, there is a dichotomy, but it is (as most things) perhaps more nuanced than you've laid out here. This dichotomy is also commonly referred to as "top-down vs bottom-up" or "strategic vs tactical" or "big picture vs in the weeds."

On places where I agree with you: there are some people who naturally think about the big narrative, what could be done, the vision, and the way the hero will progress through their journey. There are also people who think through the day-to-day, less about the hero's journey and more about how the hero will get from Town A to Town B in two days. Great pairings come from having both; this is one of the reasons that co-founder teams are often so much more successful than individuals. They complement each other.

On the places where I disagree with you: some of your statements refer to reactions when the scenario requires thinking that is different than natural strengths. A successful "narrative" person understands and respects that someone needs to be thinking through the day-to-day, and a successful "facts" person understands that someone needs to be setting the big goals. They recognize weaknesses in themselves as strengths in another.

For example, a fully-aware "narrative" person won't think it's wrong to pierce a valuable story with contrary facts. They will respect that their story should be updated. And a fully-aware "facts" person won't put their foot in their mouth by saying things at the wrong time. They'll respectfully listen to others and chime in when it's appropriate to build up the group. None of us are perfect, so we will all make mistakes here, especially under stress.

There are a couple of buried pieces in here.

The first two examples are founders who moved from Europe to San Francisco. Given the entrepreneurial ecosystem in most mid-to-large U.S. cities and more favorable ways of working, I would imagine that you could get a win by moving to any U.S. geography with >1M people versus being a software entrepreneur in a EU regulatory environment. San Francisco is one of the examples... but Chicago probably is, too.

And if you're a founder, there are all sorts of things you need for your business beyond software engineers. You need access to capital, and most VCs are based in the Bay Area and would prefer you be there too. You need access to talented advisors, and later on, experienced hires. Those are also often in SF. It's not impossible to do elsewhere, just more challenging.

Neither of those examples make the case that it's better to hire your engineering team in SF, or that your rank-and-file employees should be there. Yet the article jumps to imply that's the case.

This has happened before. From 2000-2004, this was the world. Companies were going out of business or cutting headcount to the bone, and the folks with 7+ years of experience were getting picked up (often at a discount). If you started your first job coding in 1999 and then got laid off half a year later, sucks for you.

2004 both Salesforce, Google, and Blackboard (they were big then!) IPO, and Facebook comes screaming onto the scene. Greenspan monetary policy had already made capital nearly free, and the 2008 financial crisis kicked us into 0% interest rate territory. It costs us nothing to invest in talent, so why not? If we invest in 100 startups, each with 100 employees at $150K salaries, and just two of those unicorn exit, we've made our money back, and it costs financiers nothing to wait.

2004 kicked off the simultaneous rise of "software as a service" and "social media," both of which were highly lucrative. But not only that - SaaS allowed traditional (think General Mills or Procter and Gamble) to have high-quality, cutting-edge software products without needing to employ a lot of engineers to run them. They could just pay a line item to Salesforce and let them concentrate the devs.

Just like in 2004, I think we will have a major industry shift that unlocks jobs for lots of these junior folks. I don't think it will be AI - just feels too obvious. I suspect it'll be something to do with climate change.

For early stage growth companies (say <100 employees), I think in-person will come back unless you're planning to take a massive pay cut.

Middle stage (anywhere from 100 to 1000 employees), I think there's a lot of space for remote. You're competing for talent with everyone at that point, and you're not cash-rich... the amount you spend on office space could also be spent on another engineer or couple of salespeople.

Large stage, I feel like Stripe's hybrid approach will be the model. There will be in-office roles in key geographies where pay is better, and there's an expectation of being in the office at least a few days each week. There will also be a "remote" option, and entire teams will be remote. Salaries will probably be a bit lower and promotions beyond a certain level will be tougher.

What's influencing my perspective: I'm at a mostly remote company with ~500 employees, and while ICs are generally remote all the time, there's some expectation on managers and above to occasionally travel into the office. And I've got some friends working at Salesforce in Denver who see it's tough to get beyond manager level in any non-hub office, and the few Directors are regularly traveling to SF. No VPs based in the non-hub offices.

+1 to statsd. We've moved from SignalFX to Chronosphere, all using statsd and without having to change any of our application metrics-gathering code.

At best, the primary reasons companies do unlimited PTO is that it's just not worth it to invest in official rules and some sort of tracking system. Just say "take what you need" and move on.

But at worst, companies don't pay attention to the psychological impact.

If you're a manager or leader in this sort of environment, I suggest telling your teams something like "I consider 4-6 weeks of PTO to be a healthy amount. You should take somewhere around that. If you need to take more, I'd appreciate it if we talked about that. And if you still feel pressure to take less, let's talk about that too so I can help you feel more comfortable."

taking no PTO isn't mentally healthy. I've never felt like we got "more done" over the course of a year because no one took PTO. Eventually it was just burnt out employees grinding through the days.

We have an alternative path that works for us: get a terrible, ugly, but functional version of the feature up as quickly as possible. Preferably, the uglier the better. Skip the tests for now. Put it behind a feature flag or some other way to "get it into production" without any real users able to see it.

This lets you try the feature out end-to-end. Click buttons that call APIs and see if the right actions occur. Fix all the stuff that breaks when you first try this out.

Then show it to a friendly. Product manager maybe, engineering manager, another developer... whatever. Someone who understands you're just looking for someone to try out this feature with you.

It works now? Great. Put unit and integration tests around it. Make sure that this happy thing you have running won't accidentally break. Now make it pretty. Give it the design product actually asked for. They'll have feedback, which you can now incorporate safely because you have tests.

As a suggestion for finding mentors, maybe just track down some senior software engineers at OpenAI and the like and drop them a cold email explaining that you're curious and would love some time to chat about how <some new tool they're working on> works?

If you email ten, at least five will probably ignore you, three will say they're too busy, but two might be up for a chat. You lose nothing by asking, and if someone's "offended" or something because they received a cold email... well, that's their problem.

That's the start of a mentoring relationship. The first two probably won't be good AI mentors but you'll have learned something cool, and maybe they're curious about distributed systems. But maybe the second or third or fourth time you repeat this process, you find someone you really click with.

The word "soccer" started in England as a slang of "association," which became "assocc" and then "soccer." Americans learned the word from the English.

It may also surprise you to learn that water closets are called restrooms in other countries that speak English.

Reading up on the stuff that's actually coming out of the can, it doesn't look like there are particles that are small enough to actually aerosolize into the air. They tout wool and mohair as candidate things that can be sprayed.