I was rejected from a recent YC startup for basically saying I am not going to put unnecessary nights and weekends. And after recently having a kid I definitely am never going to ever put unnecessary nights and weekends as frankly I just can't if I want to continue having a family.
Though this seems to be a more recent phenomenon of hustle culture. My company has worked with a couple dozen YC companies over the last 8 years and most seem to have a work hard and intensely during business hours but take it easy outside of that mindset. Which I think is the right mindset to have.
The interview I just had (with the YC founder that inspired this post) also asked "Do you have kids?" point blank as one of his first questions - seconds after I met him on the video call. Should have mentioned that in the post as it's also pretty inappropriate. This was before he asked if I was okay working 7 days a week.
> work hard and intensely during business hours but take it easy outside of that mindset
I am all for a work hard/play hard mentality, and I embody that truly, even moreso in my 30s. I don't have a lot of family commitments and often work longish hours anyway (~8-7) but even in a 9-5 context there's something rewarding about seeing how much I can possibly get done before some milestone like lunch or the end of the day. I optimize the entire morning around time spent coding and in my head I've already solved the problem the night before, and am optimizing on my commute after sleeping on the solution. By the time I get there I jam through the code, hit a stopping point at PR or something else, and it's usually only early afternoon. Hit a second wind around 3-4, ending around 7. Meanwhile I'll see founders do nothing until 5, then half-work from 5-9 and pat themselves on the back for "staying late", and go so far as to ask why I'm not staying later than 7 like them (despite me building most of the product).
Even more than a 9-5, I love environments where I can say "waves are good this week, won't be at standups" and nobody cares because the work will still be done, and it will be higher quality work with better documentation and presentation because my lifestyle is still in tact - I'm happy - and you see it in my work. When founders focus intensely on breaking their employees' lifestyles, they're almost asking for lower quality work from less happy employees. Something only an inexperienced founder who doesn't care about financial success would be involved in.
I think to add to your point I don’t think a lot of recent YC founders have real world experience or have minimal real world experience outside of school. I mean what’s the point of getting a job when you can go from school to directly starting a startup especially when offered a significant amount of upfront capital for really taking on no risk other than getting accepted and a chunk of equity.
Unfortunately, this has a negative consequence of people who may think studying engineering at a top tier university with late nights and weekends are how you create a functional work environment.
> The interview I just had (with the YC founder that inspired this post) also asked "Do you have kids?" point blank as one of his first questions - seconds after I met him on the video call.
I believe this would be considered hiring discrimination and is illegal.
Yeah, just not sure what to do about it though. They are based here in SF but the founder was in Toronto when I took the call, he probably is not an American citizen.
Helps at least just sharing it here and having people like you echo that it's not legal and founders should stop asking.
As that cocky beginner who went in to Jiujitsu and ran out of breath after 30 seconds in a 6 minute roll and had to tap out 15 times in the next 5 and a half minutes against a smaller opponent, it is repeated because it is true. A huge part of beginner training is basically slow down and getting yourself into positions where you can perform the moves.
I had a son in the last year. I wanted to be a young dad around 26 but had him at 36. The turning point to having him was when my wife’s friends started having kids. After having a kid she realized how much we love having him. But a delay in that is that the 20s are a critical period for both sexes to built their career. Even though I wanted to be a young dad I did not want her to give up her career over it. Even as a dad who tries to take on a bunch of workload the amount of work that goes to the mother is just significantly higher than the dad.
But as a corollary to delaying having kids is that biologically we are not made to have kids so late and my wife and her friends have all experienced complications dues to it.
I don't want to own a car at all. I like using public transit and car sharing occasionally.
Minivans are available for car sharing, but are way more rare
I have been running a DevOps agency for the last 8 years and while each Clouds basically offers the same things at this point the two things that always trip me up are networking and IAM.
Some things I noticed as I have done work on AWS, Azure and Google in terms of IAM:
- Azure seems to have so many different types of IAM permissions it is sort of hard to get your head across each one as they seems to be imported from Azure, Active Directory, etc.
- Google differentiates between service accounts and user accounts which takes a bit of getting used to as each is different and the specific service policies that need to be granted are much harder to figure out than AWS.
- AWS now has three different IAM configurations including IAM, AWS IAM Identity Center, and roles. The complication is that AWS was not built with the Google nomenclature of projects in mind so it is a weird add on that causes all sorts of weird issues.
In terms of networking:
- AWS for me the simplest to grok but I have also been doing it for the longest so there may be a bias here. Everything is tied to a VPC. It also seems that AWS provides the lowest level primitives for networking versus the other providers which tend to abstract away quite a bit.
- Google's VPC (i.e network) is global across all regions which is nice for data locality as you can use the same VPC and put subnets across regions.
- Azure is similar to AWS but does seem to have a lot of hidden features that you need to read the docs to enable espcially around AKS+video streams.
IAM is the biggest miss that all of the cloud providers suck at. I think Google's is the best, but it really isn't a great experience. This seems like something that is so critical it should be rock solid and extremely clear, but too often I see things that get into these weird situation that's hard to predict exact access rules.
I’ve done lots with AWS and really only ever used GCP to configure Google SSO. I was really surprised by how much button clicking is required in GCP vs. AWS. In AWS, you create the root account, provision a service account, and then all AWS resources are managed through terraform. In GCP, you have to verify a domain via CNAME records, etc., in order to create a root account, and then manipulate the organization policy to provision the service account. While you can create the IAP brand within terraform (as long as you use the root account and not the service account), you can only externalize the brand by clicking buttons in GCP. Laughably, there is an open issue/ticket from more than a decade ago requesting a programmatic way to externalize a brand.
Really good answer in terms of how they "feel" to use.
Just one note, since there's a design decision Google and AWS made differently that feels nice but makes availability more precarious:
> "Google's VPC (i.e network) is global across all regions which is nice for data locality as you can use the same VPC and put subnets across regions."
It's also not uncommon seeing your entire global footprint go down when there's a network plane issue.
AWS — for the longest time — was fanatical about keeping services uncoupled across regions, leading to far fewer "global" outages.
Sadly, many customers complained, wanting services to be cross region, instead of having to replicate environments across regions. Fifteen years in, AWS is accommodating, allowing you to build services that span a couple regions and go down if either region is down.
If uptime is critical to you, in AWS leverage at least 3 AZs in each of at least 2 regions, and be sure you're using region-only services or a cross-region service that's really single region with a consistency scheme. You'll stay online through most regional issues.
Also note that the three define "region" quite differently. The AWS definition generally includes a variety of availability and resilience constraints, such as at least 2 AZs with enough physical separation to survive local physical outages. Looking closely comparing across them, you'll find AWS's resilience story is more stringent, the other two are somewhat more oriented to putting a pin on the map and call things regions that may be more like single POPs (points of presence).
All that said, it's becoming "less true" in both directions, as large customers complain when any two CSPs don't work similarly. The "voice of the customer" is asking for feature parity rather than exploiting the differentiation.
From our point of view, they're still differentiated enough a firm should consider using each for what it's best at, say AWS for lego blocks, Azure for business integration, and Google for scale-out analytics feeding ML/AI. Again, each is trying to shore up what the others already have in their DNA, but it's harder to copy something when it hasn't been your in-house bread and butter or you didn't invent it.
In about 5 years the baby boomers will have all hit retirement age. With social security and Medicare there will likely be a significant amount spent on healthcare taking care of this generation.
I wrote a scraper that downloads 10-Ks from the SEC and then built a simple analysis based on high dividends/stock buybacks and a discounted cash flows analysis. It found some pretty undervalued companies that ended up doing fairly well over the last year, but not as well as the tech stocks.
As others noted the datasets are not really standardized even with the SEC Edgar data so there is a lot of massaging you have to do.
Every one of my customers uses message queues either Redis, SQS and rarely Kafka using Celery, Sidekiq, etc. If anything it is boring and works and just part of the default stack everyone uses.
There is Linus Torvalds quote I really like which goes, “There are people who point at the moon and say I want to go there. I look at the pothole on the road and I want to fix that before I fall in.”
What I found is if you start looking for societal potholes there are a whole lot of them from climate, immigration, healthcare, etc. However, don’t go into these alone. Find other people and organizations who are already charting the path and figure out how to help them.
I had a related thought recently as I was trying to set up a new staging environment for $MEANINGLESS_PROJECT at $CORP and was struggling with various packaging errors - wouldn't it be much nicer if instead of working on the project, I could use spend my time on fixing these open source tools to actually work out of the box?
reply