Hacker Newsnew | past | comments | ask | show | jobs | submit | harshaw's commentslogin

Full disclosure: I am pretty sour on the current Amazon/AWS leadership as I think, well, they couldn't lead a company out of a paper bag (former manager at AWS). Is there data that Amazon/AWS is still hiring junior devs? I've heard it's very hard to get into student programs these days but I don't have the data. My grumpy position would be Garmin saying one thing and doing another.


Why? I look at this. I want engineers to use the tools on the stuff that AI is good at so we can do more high value work.


If it's obviously useful then people shouldn't need to be prodded into using it. Maybe there are actual downsides to rushing through everything with AI, maybe people can't actually work on the hard things 100% of the time.

I just don't understand this need to rush, software already moves fast without AI tools. Software developers already make a lot of money for their companies that their salaries are easily covered. Realistically people could develop software 10x slower than now and the world would still keep progressing.


It's measuring inputs instead of outputs. If AI is useful, it'll get used.


If I were to summarize how we attacked this when I was on AWS (different team)

formal methods. Some of this started a long time ago so not sure if it was TLA, TLA+, or something else. (I am a useless manager type)

fake clients / servers to make testing possible

strict invariants

A simulator to fuzz/fault the entire system. We didn't get this until later in the life of the service but flushed out race condition bugs that would have taken years to do.

We never got to replaying customer traffic patterns which was a pet idea of mine but probably the juice wasn't worth the squeeze.


"juice wasn't worth the squeeze" - adding that to my vocab


i'll bite. Please give me an example of questions that are scientifically validated.


"Tell me about a time when you had to work with a difficult team member"

Note that the above is the type of question my HR department tells me is scientifically validated. I have not read the research myself, nor do I know how to find it. As such if someone responds "that isn't" they might be right, you will have to judge their expertise themselves: I'm not qualified to know if they are right.


not quite true - there are some regions that have a different set of AWS users / credentials. I can't remember what this is called off the top of my head.


These are different AWS partitions. They are completely separate from each other, requiring separate accounts and credentials.

There's one for China, one for the AWS government cloud, and there are also various private clouds (like the one hosting the CIA data). You can check their list in the JSON metadata that is used to build the AWS clients (e.g. https://github.com/aws/aws-sdk-go-v2/blob/1a7301b01cbf7e74e4... ).


I think this is an astonishingly dumb take. Regardless of what you think of Musk, SpaceX is building a fundamentally important reusable lift technology that can be the underpinning of some many future developments. Who cares if China gets to the moon first? This is how NASA historically gets into a mess with its launch system - political pressure, conflated goals and requirements (see the Space Shuttle - does it launch people?, military payloads?, oh goodie - let's do it all). If anything I wish NASA would do more to make sure we have a decent starship competitor which its hard to see blue origin being anytime soon (but I am not an expert on this topic)


Yes, but there are several additional dimensions of perhaps-malicious idiocy that you didn't call the NYT on:

- The reason that NASA is stuck in this mess with Musk is that "their own" SLS, Orion, Lunar Gateway, & Co. program is a landfill of Congressional pork, trying to pretend to be a moon mission. And Washington has been talking smack about actually returning to the moon. And now China appears to be calling them on that cheap talk.

- Compared to the costs of SLS & Co., SpaceX's "one of his largest ever" contract for getting to the moon is small change. Has the NYT heard the old saying about "fast, cheap, and reliable"?

- Any manned Lunar mission must start with heavy lift to LEO. SpaceX utterly dominates that market. And has for years. On all 3 of the available, cheap, and reliable dimensions. Even if Starship could only do unmanned heavy LEO, having it operational would just make Musk an even-more obvious choice for that part of things.

- Musk has an available, reliable crew capsule - which is another difficult must-have for any manned Lunar mission. Vs. NASA's Orion capsule has been to orbit once, uncrewed, 3 year ago. And had major heat shield issues during the reentry.


Sounds more like an object system (immutable) with the veneer of a file system for their use cases. I sort of read the doc - sounds like data is replicated and not erasure encoded (so perhaps more expensive?).

I think many people have said this, but "file systems" get a lot easier if you don't have to worry about overwrites, appends, truncates, etc. Anyway, always interesting to see what people come up with for their use cases.


We do use Reed-Solomon codes, as the blog post explains.


Append-only is pretty much the only way to do robust replicated storage at scale, else you get into scenarios where, instead of a given logical block having two possible states (either existing somewhere or not existing anywhere), the block can exist with multiple values at different times, including an unbounded number of invalid ones, for instance in case a client died halfway through a block mutation. Immutability is just plain a very strong invariant.

It also does not at all preclude implementing a read-write layer on top of it, for instance with a log-structured FS design. That's however the solution to a problem these people are, it seems, not having.


I did Symbian programming back in the day. IIRC the Sony-Erricson P800. It was not developer friendly. The memory management model was hard to program and could crash easily. Also did some work with Nokia on the N60. I was working at Orange at that time and we had hired a contractor to integrate push to talk (because for some reasons Orange though push to talk would take off in Europe, lolol). I got a couple of free trips to Tampere to theoretically help Nokia debug this third party push to talk app. I seem to recall Nokia not being too enthused to work with some pushy American hacker who wanted to open a debugger and fix things. I remember that we had some nice reindeer dinners.

Early mobile is littered with dead operating systems. not really that surprising. PalmOS, Symbian, SaveJE, windows mobile, etc. not worth crying over.


As a Tampere native working with a lot of old Symbian folks, it's good that you remember the dinners :) Hope you liked the city in general, we certainly do!


Palm OS is better described as "undead, and slowly reviving itself". There are ongoing efforts to port it to diverse new hardware (a couple of new-parts ARM boards, and the Nintendo DS among other targets), an alive community that preserves old software and writes brand new software, and at least one reimplementation project (Pumpkin OS).


Development was unfriendly because S60 supported running without virtual memory, so you had to be really careful releasing memory. I.e. it was targetting small CPUs. The wonky "cleanup" was a big part of this.


My problem is that there is a reauth FOMA that gets copied with the most trivial of applications. A good example is the Electrify America charging app. It's job is to be available so you can charge. But they log you out frequently - and they want to do second factor with email. Guess what - that doesn't always work. My wife was trying to charge the other day, was logged out, and couldn't get the email verification to go through. So I had her login with my credentials and I answered the email verification and gave her the token over the phone. super annoying.

But more importantly- mobile phones already have good security mechanisms. It's like all these shitty apps copied web based auth mechanisms with timeouts when they could do something better (and probably are built on web technologies with cookies instead of using the trusted store on the phone).

There are precious few apps out there that tell you ahead of time that reauth is happening (Zoom does this - kudos). But even so - I don't think it's necessary most of the time.


I don’t need to charge often, but I’m logged out of every single one of my charging apps for that reason. They kick me out constantly.

If you want me to auth to make a payment when starting a session, fine. I’ll hate you, but whatever.

Nope. Can’t even get into the app. Want to see where their stations are? Too bad. Sign up, sign in, or hit guest mode and prepare to be annoyed.

I can stay signed into Amazon with a credit card set up for years at a time.

God forbid I ever want to charge a car.


This isn't so much about the Author's story but the space. He is correct that marketplaces are hell, and especially auto repair market places. I was one of the several devs that went through trying to make Openbay work (a US based market place for auto repair). We actually did have service providers signed up and we did have a way to acquire customers who wanted auto repair. So you had the illusion of product market fit - but the problem is that it's really really hard to get people to actually click "buy this brake job" and then, more importantly, they have no reason to come back to your app because 1) you don't need brake jobs all that often and 2) they can just go back to the service provider. And many shops are happy to still take phone calls as their default way of booking work.

The reason the company existed is the rich founder was upset that a shop wanted to charge him a fortune to get his BMW M5 repaired. He wanted better quotes. So we built a marketplace to get better quotes. But that's not what real customers want (because most people have Toyotas not M5s). And also we didn't do the customer development / research to understand how repair shops work. You want to know how my repair shop manages their repair schedule? They have a paper calendar and write down your phone number and the job. sure there are better ways to manage the work - but this paper mechanism has worked for them for years and why change it? And you know what - I go back to the shop all the time because I trust them. Ultimately people tend to have a fairly personal relationship with their local mechanic. You can build a leadgen product but the ultimate relationship is between the customer and the repair provider.

TLDR - everyone should understand the lean startup. /working backwards model and relentlessly focus on the customer.


> Ultimately people tend to have a fairly personal relationship with their local mechanic.

This is the money line. And it goes for all skilled trade work. Mechanics, plumbers, building contractors, roofers. Most of the people doing this work are just surprisingly bad at it, especially for how much they charge for it. It takes a LOT of time and effort to find someone good. I'd even lump doctors and dentists into this.

I don't want a marketplace to tell me who's the cheapest, I want a marketplace to tell me who's the best. And unfortunately there's no way to build that. (Why is a long story, but the short version is: because there's no way to build the correct incentives into it.)


> Most of the people doing this work are just surprisingly bad at it, especially for how much they charge for it.

A friend quotes a sometime co-worker of his: This is C+ world, and if you can do a solid B- you won't starve.


Yes, exactly! I keep telling my kids that literally just consistently showing up and doing the work you are asked to do will put you far ahead of most of your peers. I'm not sure they believe me now, but eventually they will.


The law of averages. Most in any field are going to be mediocre. It's unavoidable.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: