HN user

ublaze

399 karma

@utsav_sha on Twitter

Posts46
Comments60
View on HN
www.softwareatscale.dev 2y ago

How Software Infrastructure Affects Sales

ublaze
3pts0
www.softwareatscale.dev 3y ago

Quadratic C.I. Cost Growth

ublaze
1pts0
h1bdata.info 3y ago

OpenAI salaries are not 800k

ublaze
3pts5
dropbox.tech 3y ago

Cloud storage abstraction with Object Store

ublaze
1pts0
www.softwareatscale.dev 4y ago

Systemizing Platform Strategy

ublaze
2pts0
www.softwareatscale.dev 4y ago

Building Zerodha with Kailash Nadh

ublaze
1pts0
www.softwareatscale.dev 4y ago

Migrating the Windows source code to Git [audio]

ublaze
1pts0
dropbox.tech 5y ago

Sharing our Engineering Career Framework with the world

ublaze
3pts0
engineering.atspotify.com 5y ago

Rethinking Spotify Search

ublaze
1pts0
www.softwareatscale.dev 5y ago

Mitigate Connection Leaks in Production with Proxies

ublaze
1pts0
www.softwareatscale.dev 5y ago

Manageable On-Call for Companies Without Money Printers

ublaze
5pts1
github.com 5y ago

Show HN: Send Me a Secret

ublaze
9pts0
utsavshah.com 5y ago

Reflecting on a Hundred Days of a Software Podcast

ublaze
1pts0
podcasts.apple.com 5y ago

Conversation with David Cramer, CTO and Co-Founder, Sentry

ublaze
2pts0
twitter.com 5y ago

AWS Lumberyard has a special clause for a zombie apocalypse

ublaze
1pts0
dropbox.tech 5y ago

Lessons Learned in Incident Management

ublaze
1pts0
www.softwareatscale.dev 5y ago

GUIDs Are Not the Only Answer

ublaze
86pts61
www.softwareatscale.dev 5y ago

GUIDs Are Not Enough

ublaze
4pts0
www.softwareatscale.dev 5y ago

Go for Internal Services

ublaze
1pts0
www.softwareatscale.dev 5y ago

Bharat Mediratta – The Story of Google Web Server (and More)

ublaze
2pts0
reliability.substack.com 5y ago

Software at Scale 003 – Bharat Mediratta: Ex-CTO, Dropbox

ublaze
3pts0
dropbox.tech 5y ago

Alki Cold Metadata Storage at Dropbox

ublaze
14pts0
reliability.substack.com 5y ago

Mitigate Connection Leaks in Production via Proxies

ublaze
1pts0
reliability.substack.com 5y ago

Prevent Connection Leaks in Production via Proxies

ublaze
1pts0
reliability.substack.com 5y ago

Go for Internal Services

ublaze
2pts0
reliability.substack.com 5y ago

Mitigate Connection Leaks in Production via Proxies

ublaze
2pts0
reliability.substack.com 5y ago

Run Python Applications Efficiently with malloc_trim

ublaze
76pts30
reliability.substack.com 5y ago

Go for Internal Services

ublaze
11pts0
reliability.substack.com 5y ago

Go for Internal Services

ublaze
2pts0
reliability.substack.com 5y ago

We frequently turn down ~30% of canary instances

ublaze
1pts0

ICF: Inertial Confinement Fusion

MCF: Magnetic Confinement Fusion

CFS is Commonwealth Fusion Systems - https://cfs.energy/

Q is the ratio between energy in and out in a fusion system. Q > 1 is the holy grail, which implies we have more energy out of the fusion system than in. CFS is aiming for Q 11 in its prototype reactor.

SPARC is the "Smallest Possible" ARC I believe. It's their prototype reactor that they're working on that uses magnetic fields through superconductors to contain Hydrogen as it heats up into plasma and goes through the fusion process.

ARC is the 400MW reactor that will be produced (aimed for within a decade) if SPARC succeeds - it's the scaled-out version of SPARC.

It has an impressive set of people working on it (ex-SpaceX).

And yes, ARC is named after the Iron Man reactor.

These are company reported base salaries for OpenAI members of technical staff. The base salaries look very similar to standard tech bands.

They could be underpaying immigrants, but that's unlikely, given that it's illegal and they have a lot of attention on them.

Yeah, large-scale systems are often boring in my experience, because the scale limits what features you can add to make things better. Each and every decision has to take scale into account, and it's tricky to try experimenting.

I think it has to do with the kind of engineer you are. Some engineers love iterating and improving such systems to be more efficient, more scalable, etc. But it can be limiting due to the slower release cycles, hyper focus on availability, and other necessary constraints.

I remember we migrated 2+ million LoC to being formatted by Black at Dropbox.

Our Livegrep instance with a custom Git blame implementation always crashed at the commit made to do the migration :-) We had to pause our merge queue because we didn't want to run into conflicts, and I remember the `git push` ended up taking a while.

There was only one change that we had to make to Black to get it working on our codebase - https://github.com/psf/black/commit/024c9cab55da7bd3236fd887...

Glad to see it's now stable.

Version skew is only an issue when there's cross service communication. One service deployed on two different codepaths (in this case, using a different library implementation) is completely fine.

I've been thinking about this with my software podcast too! (https://softwareatscale.dev). Was thinking of posting something similar here.

You already have more downloads than I do, so you can take my advice with a grain of salt.

- My written articles have done well and drove a bunch of signups to my newsletter. That introduces people to the podcast (substack lets me do combined newsletter/podcast). People are more likely to share and read articles, and the really interested ones tend to listen to the show as well.

- I use Descript to make YouTube clips of the show, and link to the full episode, where people can listen to episodes. I've found that a successful YouTube video doesn't drive that many sign ups/subscribers to the show, but drives subscribers on YouTube.

- Some influential guests on the show drive a "pop" when they retweet their episode.

- It took about 3-4 months to show up on Google when you search for "Software at Scale", but that drives some organic traffic.

- I get some of my new subscribers for the podcast by posting in relevant subreddits like r/programming. It's a struggle :-)

Vanta (YC W17) | Software Engineer | Full-time | San Francisco / New York | https://vanta.com

Vanta simplifies the complex, time-consuming, and tedious process of becoming SOC 2, HIPAA, or ISO 27001 compliant. So startups can focus on growing their businesses.

We have stellar product market fit (over a thousand business customers) and are growing very rapidly - here's a chart from our CEO: https://twitter.com/christinacaci/status/1353802993729118212

Vanta provides automated and continuous security monitoring. This helps companies sail through audits like SOC2 while actually ensuring that customer data stays safe. We run read-only checks against tools like AWS and SaaS tools like GitHub, as well as periodic configuration checks against company workstations and servers using an agent. There's tons of technical challenges due to the growing number of diverse customers and product complexity as we serve both CTOs and auditors.

Tech stack: NodeJS, React, GraphQL, AWS.

If you're interested in making companies more secure, and helping them unlock deals faster, reach out!

Email me directly at utsav [at] vanta [dot] com

It was really sad to see Motif shut down. That service was awesome. It's made me wary of trying new services for this, since their shutdown led to a bunch of shuttling around of portfolios from different, much worse services (Folio, finally Interactive Brokers).

I started using Telegram a couple of years ago to prevent my "online status" on Whatsapp being visible to everyone.

Just start using both, and convince a few close family members (spouse/parents) to start using the app. People cannot be forced into using a new product. On the other hand, they will automatically use the better product if their network is on both.

Now my parents and partner are comfortable with both Whatsapp and Telegram. They use Whatsapp more heavily than I do, but they can comfortably use both. Since Telegram is better (from a product perspective), they also use Telegram when talking to each other.

IMO we can't tear down network effects easily, especially when the negative consequences of using one of the products is seemingly non consequential. We just have to move brick by brick.

We have a pretty tight oncall (5 min response time).

I think the steps you can take are:

1. Make it clear to your manager this is unacceptable, and you will end up looking for alternate teams/jobs if this goes on

2. Make the same thing clear to your skip level

3. Quit / change teams, citing oncall as the issue

There's no point of doing anything else, in my experience. It's someone else's job to make sure that your oncall experience is prioritized. It sucks to leave an otherwise good job.

For extra credits - try to propose some solutions. Why are some issues not solvable by engineering? Would simply resetting expectations mitigate the largest issues/waking up at night?

Semi related: what kind of process do you have that makes you feel confident pushing 40x a day? Do you run some kind of automatic analysis that helps you automate the push completely? What if you know that HEAD has a regression that shouldn't be pushed?