jmchuster

Rules 2 and 3 would be great for interacting with humans as well (figure 1: US politics)

They don't need to because that's usually not what the job calls for, but I would think most people who call themselves software engineers believe they would be able to work at a job where they wrote FORTRAN instead of Python. It's just another programming language, you just have to spend a month to learn it. Assembly is just another programing language. Opcodes is just assembly without syntactic sugar. But of course that's not what my job calls for today, but if it did, it's not really any different in my mind from any new job where I'm doing something different, but just applying my software skills slightly differently.

My criteria is very simple, could you handwrite the code if you needed to. Could you write this code without the LLM writing it for you. Could you write this code without the IDE auto-completing it for you. You could take it all the way to, could you write the assembly if you needed to. Of course, the complexity of the ask and the timeline has to be commensurate with the power of your tooling at each level.

That first sentence already uses a ton of jargon that non-developers don't use, "web development", "new webpage", "good design", "best practices", "big block",

I only just now realized

pg cat

pg dog

What's he going to name the next version?

pg emu ?

I guess that tokenmaxxing phase has served its purpose, of forcing people's brains to go from "i will never use AI, it's scary and new and useless" to "i must learn to use it, this is the new normal, otherwise i'm getting fired".

And now they're able to move to the phase of "let's now learn to actually use it effectively".

> Famously, the first iPhone was actually expensive trash: no apps, no 3G, couldn't even cut and paste text.

Also famously, while the tech elitists complained about all of its shortcomings, the broader consumer market fully embraced it and it single-handedly drove an entirely new generation of consumer electronics.

What's the fastest way to get promoted to a manager at a fast food chain -- show up on time and do your job. If anything, the managers are workers who cared enough to do a decent job.

> I understand what the author means, but I think that in any human-2-human interaction, we are all entitled to at least basic courtesy.

This only holds up for the "small" number of human interactions the average person gets. If my neighbor comes and rings my doorbell to say hello, I'm fine answering and shooting the shit, maybe invite them in for a quick coffee.

If every 5 minutes a strange comes in and rings my doorbell, I'm not getting up and answering it. And some people visiting will get angry and start pounding on the door and coming to my window and pounding on it glaring at me inside. And say, hey, I drove all the way from hours away to come visit you, the least you could do is open the door and say hello.

For them, it's their first human-2-human interaction that day, with someone they slightly admire even, and they're expecting basic human courtesy. To me, they're just the 42nd doorbell ringer today.

The term is 漢字. It's written the same in both Japanese and Chinese, with the Japanese pronunciation being "kanji" and the Chinese pronunciation being "hànzì".

> 7.css is a CSS framework for building interface components that look like Windows 7. It is built on top of the GUI backbone of XP.css, which is an extension of 98.css.

Just an absolutely lovely line of text.

Other countries have just been doing this by hand. For example, in Japan, they will open up bags of trash from the dumpster, find your address from a discarded envelope, sort out what you should have recycled, then bag it and leave it at your door, with a stern warning and instructions on how to properly sort your trash next time.

The interview he does on the Odd Lots podcast is a lot more in-depth, and I found it a great listen:

https://open.spotify.com/episode/5gJazFZZaZ0OGKf516XpeO

And light truths are visibly open in modern dna

Where does your intuition for how long actions take in a cockpit come from?

I'm not a pilot, so i have no idea. But from watching vasaviation on youtube, it always seems to take like 5-10 minutes between when they first radio the control tower there is an emergency, then they go through their checklists and stabilize things, and then they're ready to talk to the tower for the next step. Now add more back and forth and the time to actually fly to get back to a regular path, and 15 minutes might even seem too short a period of time before you've finished resolving everything and can now kick back and tell the passengers the end result.

Even if docker is the most popular build tool used across all professionals [1], that usage number is still only 59% of professional developers.

[1] https://survey.stackoverflow.co/2024/technology#most-popular...

I see it analogous to asking, "How much is access to the internet boosting real-world programmer productivity?" Are you really 5-10x more productive being able to google something? Couldn't you have just looked it up in the manual, don't you have peers you can ask, that's such a small portion of the time you spend coding.

But we've now lived it so much that it sounds ridiculous to try to argue that the internet doesn't really make _that_ much of a difference.

There are lot of points in time that don't have a location, such as a historical event. Then it's most accurate to store in UTC, then convert to the timezone you want only at display time.

The author actually made the point in the beginning of the article.

> When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say.

But what if you're not actually storing "a point in time" but actually storing a "time at a location"? The trick is to follow the Stack Overflow advice, but just in the opposite direction. You store the time as a "wall time", and don't store a timezone or an offset, and convert it to UTC (an actual point in time) at the last minute possible.

For a given location, what timezone or daylight savings rules it's going to follow, are always up for change, so the only thing you know for sure is the "wall time" and the "location". Waiting till the last minute maximizes the chance that you've got the latest time library with the latest rules, so it follows the same principle as the Stack Overflow advice.

Now, my opinion might also be colored by experience working in the rental car industry, because the primary goal there is what the customer experiences. Because in their mind, they set up their rental in Phoenix, AZ to start at 9am, so when they're at the counter, and it says 9am on the "wall", the car better be there. They don't want to hear that time zone rules for Phoenix changed in the 6 months since they placed the rental, so "technically" their rental doesn't start until 10am. So in our database, we actually just store "07/23/2024;0900;Phoenix". It's actually incorrect to even store a timezone or an offset, because there's no guarantee those won't change, only the location won't change, so you have to do the lookup for the timezone and the rules for the given location at the very last minute, maximizing your chances of having all the latest time library updates.

The 2008 mortgage crisis is now 16 years old, and the stock market had recovered by 2011. So presumably anyone who entered the work force afterwards might have little sense of it, which would be anyone under the age of 31 (or 35 if you count college).

On climate change, it already did work once with the hole in the ozone layer.

People ask why they don't hear about it anymore -- oh, it's because we listened and banned CFCs and fixed the hole.

> What does Altman bring to the table exactly. What is going to be lost if he leaves.

If Altman did literally nothing else for Microsoft, except instantly bring over 700 of the top AI researchers in the world, he would still be one of the most valuable people they could ever hire.

It's probably helpful to first get a sense of how much work it is to gather customer feedback. As an example, Qualtrics was getting single digit percent response rates, on a simple NPS survey (https://delighted.com/blog/average-survey-response-rate). If you're asking people to give you more detailed feedback, I'd imagine the hit rate might be even lower. Another data point, people who gather feedback professionally often offer customers $100 for an hour of their time.

New grad talent is a huge pipeline for Google or any other FAANG, and they'll recruit at every well-rated and large engineering program they can find, the large majority of which aren't just MIT. And tons of engineering programs that aren't those, though they may just do all their recruiting through the colleges' online resources, since they have a limited number of humans to physically travel.

From the provided wiki link, it doesn't mean to refuel the car, it means to "step on the gas."

Supporting ie6, ie7, and ie8 separately while developing on firefox just so we could use firebug.

It's the scale of it.

"Here is a vaguely understood problem, that might take 2 hours to solve."

"Here is a vaguely understood problem, that might take 2 years to solve."

Though if you're used to the latter timescale, you might not consider the former as all that "vaguely" understood.

I would never claim that our setup uses microservices. Probably just more plainly named "services".

And yes, that is correct, we agree that once we expose a view, we won't remove columns or change types of columns. Theoretically we could effectively deprecate a column by having it just return an empty value. Our use cases are such that changes to such views happen at an acceptable rate, and backwards incompatible changes also happen at an acceptable rate.

Our views are also often joins across multiple tables, or computed values, so even if it's often quite close to the underlying tables, they are intentionally to be used as an abstraction on top of them. The views are designed first from the perspective of, what form of data do others services need?

if service B needs some new data from the view that isn't being provided, then you first run the migration on service A to update that view and add a column. Then you are able to update service B to utilize that column.

If you don't need the new column, then you don't need to do anything on service B, because you know that existing columns on the view won't get removed and their type won't change. You only need to make changes on service B when you want to take advantage of those additions to the view.

For us, we started off with a world where each service communicates to each other only via RabbitMQ, so all fully async. So theoretically each service should be able to be down for however it likes with no impact to anyone else, then it comes back up and starts processing messages off its queue and no one is the wiser.

Our data is mostly append-only, or if it's being changed, there is a theoretical final "correct" version of it that we should converge to. So to "get" data, you subscribe to messages about some state of things, and then each service is responsible for managing its own copy in its own db. This worked well enough until it didn't, and we had to start doing true-ups from time to time to keep things in sync, which was annoying, but not particularly problematic, as we design to assume everything is async and convergent.

The optimization (or compromise) we decided on, was that all of our services use the same db cluster, and that if the db cluster goes down, it means everything is down. Therefore, if we can assume the db is always up, even if a service is down, we consider it an acceptable constraint to provide a readonly view into other services db. Any writes are still sent async via MQ. This eliminates our syncing drifting problem, while still allowing for performant joins, which http apis are bad at and our system uses a lot of.

So then back to your original question, the way that this contract can break is via schema changes. So for us, since we use postgres, we created database views that we expose for reading. And postgres view updates are constrained that they must always be backwards compatible from a schema perspective. So then now our migration path is:

- service A has some table of data that you like to share

- write a migration to expose a view for service A

- write an update for service B to depend upon that view

- service B now needs some more data in that view

- write a db migration for service A that adds that missing data, but keeping the view fully backwards compatible

"Yes, of course i am. What are you, a f--ing idiot?"