danielrhodes

I've tried this before and I think this constraint is something that has to be kept top of mind for a designer not just the engineer. Most designs these days assume a single page app and there are interaction patterns that make plain HTML not suitable. But if you incorporate this in from the start and stick with it, there's no reason you can't do this.

Once again there seems to be this deep misunderstanding by engineers that all lawyers do is draft docs like an engineer writes code. And if you can automate the doc creation process, you have automated the attorney.

But this not true. It greatly depends on what type if lawyer it is. They can operate very differently.

When it comes to docs, lawyers try not to reinvent the wheel on every doc. It’s very risky. They want to use language that has stood up to the test of time. So they have templates and old contracts and they will piece together a contract from that - it takes no time at all. AI writing new stuff every time using new language doesn’t save much time and puts a client at risk because nobody knows how that language holds up in court.

Many attorneys have paralegals who do the actual work. Those paralegals are much cheaper. Efficiency arguments don’t often take them into account. Most legal tech companies don’t think about paralegals. But they are often the real workhorse in a legal firm. But automating them doesn’t really speed anything up: they do a lot of varied things and are not just mindlessly following some process like a factory worker.

So what do lawyers do? They advise clients, they project manage, they research, they talk with other lawyers, sometimes they go to court, they review work, they work on getting new clients, and yes sometimes they write legal docs. Then at the high end of things, they come up with legal strategies and solutions that AI has never seen before.

In corporate law, legal is often budgeted in. It’s expensive but it is often ROI positive. Legal mistakes are incredibly costly.

Having said this, are lawyers pretty slow to adopt new tech? 100%. Word processors replacing typewriters was seen with a lot of suspicion. Email too. The cloud too. I think AI will have a big impact on law - but it won’t be as simplistic as a little doc generator an engineer cooks up one night in his bedroom having never even met a lawyer. The law is quite gray and so even if you have found something impactful, attorneys manage risk by looking to see what others are doing. If there is social proof, they are more likely to accept it.

The reason Facebook is where it is now is that when it was novel there was a lot of engagement. But as the novelty wore off, it became clear that your friends were not going to be able to produce the amount of interesting content you’d need to stay engaged. Most people probably don’t have enough friends on FB making the problem worse. In addition, Facebook’s privacy model requiring a double opt-in friendship makes it hard to add more friends.

So they started to loosen things: you can follow others, posts can be public, your feed becomes a mix of posts in your network and friends posts, etc. Now it is resembling Reddit. Numbers go up!

That is to say: these pure friend social networks start off with the right intentions. But with a similar product and incentives, you’ll end up right around where Facebook is now. If you want a different outcome, you must start from a different place.

I think Tim Cook took Steve Job's vision and really took it to the moon. If you think about the last 15 years, Apple has really become the biggest possible version of itself without losing its values.

Tech in general has changed quite a bit though. I don't know how Steve Jobs would have reacted to AI, and I don't know where tech itself would be if Jobs were still around. But I do think the next evolution is due and yet to be seen. It's not clear that Tim Cook would be the one to effectively see that through. And so I think his timing is impeccable and probably aligned with what is best for Apple. I have a lot of respect here: time has shown that a lot of leaders don't let go until its too late.

Articles like this amount to a straw man.

People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years.

Have tests, do code reviews, get better at spec’ing so the agent doesn’t wing it, verify the output, actively curate your guardrails. Do this and your leverage will multiply.

It certainly looks like an Apple device. Ive's aesthetic is Apple's aesthetic, so if you hire Ive, that is what you are going to get.

I can see a car company who doesn't care about design stumbling into this outcome, but Ferrari doesn't seem like that kind of company. So the choice must have been intentional.

This is no surprise. We are all learning together here.

There are any number of ways to foot gun yourself with programming languages. SQL injection attacks used to be a common gotcha, for example. But nowadays, you see it way less.

It’s similar here: there are ways to mitigate this and as we learn about other vectors we will learn how to patch them better as well. Before you know it, it will just become built into the models and libraries we use.

In the mean time, enjoy being the guinea pig.

I think this is a genuine concern for prominent people. Like if you are Mark Zuckerberg, there is material interest in a bad actor installing malware on his laptop. But for a random person where you get low value data that may or may not let you better target some low value ads? That is much harder to justify. Would have to reevaluate as things change and the cost of compute goes down.

People seem to ignore the cost and accuracy aspects of a phone listening to you 24/7. At least with today’s constraints, it is highly unlikely to be happening.

First, the cost to transcribe audio is not free. It is computationally expensive. Any ad network or at scale service would not be able to afford it, especially in orgs where they are concerned about unit economics.

Secondly, the accuracy would be horrible. Most of the time, your phone is in your pocket and would pick up almost nothing. More over, it’s not like you are talking about anything of value to advertisers in most cases. Google is a money printing machine because people search with an intent to buy. The SNR of normal conversation is much much much lower. That makes the unit economics of doing this gets much worse.

Third, it would be pretty hard to not notice this was happening. Your phone would get hot, your battery would deplete very quickly, and you’d be using a lot of data. Moreover on iOS you could see the mic is being used and the OS would likely kill the app if it was using too many resources in the background.

So until we find an example of this actually happening, it’s not worth worrying about.

Maybe it’s because the movies aren’t good and the plot lines are stale. Just a thought.

San Francisco uses RCV, and it’s not much better, maybe worse. Yes you get run off elections and more candidates. But now voters have to use strategy in how they vote and it’s complex to understand the implications. There’s a higher chance of winding up with unpopular candidates simply because nobody actually wanted their second or third choice candidates.

This reminds me of when I went in to a Patagonia store to repair a jacket with a “lifetime” warranty. Turns out they define lifetime as the “useful” lifetime of the product, which is a couple years. They refused to help and instead tried to sell me a new jacket.

Yes, it seems cruel to push young doctors to the limit like this. But I’ll offer a counterpoint:

In an emergency, you want doctors who are used to making decisions under stress and who are aware of their impaired decision making abilities when tired. This is a rite of passage that means in a true emergency where they have to be making good decisions without adequate resources they can do so. You see a similar tactic when training military recruits.

For models of this size, the code used to train them is going to be very custom to the architecture/cluster they are built on. It would be almost useless to anybody outside of Meta. The dataset would be more a lot more interesting, as it would at the very least show everybody how they got it to behave in certain ways.

People take these kinds of things way too literally. There is no golden solution here. What gets repeated over and over continues to be true: teams should choose a system that works for them. And ideally that system is measurable, so the team can evaluate progress, improve its own performance, and align itself better with other teams and the business.

But in terms of scrum and points here's my take:

I've seen points work on some teams and not work so well on other teams. It's imperfect, but if you just accept that, you can make it work quite well.

The reason it's helpful to estimate complexity as opposed to time is that people with different experience levels would give different estimates based on their abilities. Complexity allows you to rally around a common understanding of a solution regardless of how fast one team member might be able to complete it versus another.

Does complexity have some relationship to time? Absolutely. Everybody knows this. That doesn't mean that we should be using time instead.

So how can a team estimate accurately? You will hear from some people that their estimates were wildly off or that it's impossible to estimate a project or they felt pressure to under-estimate. If your estimate is too broad, you need to do the mental work of breaking it down into smaller chunks that are easier to estimate. If you feel under pressure to ship on an unrealistic schedule, that's not a points/scrum problem. But the "it's done when it's done" is also not realistic either.

The idea that the estimate has to be 100% spot on is also not true. Again, it's imperfect and that is ok. But you'll find that the better a team knows their codebase and knows the product, the better they'll get over time at estimating. But if the work is too vague, the team should push back until they have enough information to more accurately break things down. This process makes for better software, especially when the team does it together.

Another missing aspect I see a lot is having a feedback mechanism. If you as a team are discussing why a task took longer than the estimate, or track metrics over time, you can all get together and figure out where problems on the team are. For example: maybe there are too many bugs that are hindering product work? Why? Maybe you're moving too fast vis-a-vis the expected quality bar. Some sort of feedback mechanism (e.g. retros) is crucial - the team as a whole should aim to deliver what it says it would and understand why it couldn't.

The whole point of these things is that as a team you can deliver consistently not more speedily. Consistency comes before speed. The other important thing is having a way to continually improve. You want to use each sprint as a way to measure the team so it can get better.

When I've seen teams that did this well, they were dramatically more productive than the teams that didn't do it well.

IMO, the solution is apprenticeships/probationary offers

Most companies would love this, especially startups. The problem is that desirable candidates do not love this arrangement - there's an opportunity cost and risk for the candidate here and if you're in demand you can get a solid offer from a company who isn't trying to hedge.

I’m not saying I would trust getting into a Waymo now in those conditions, but I also wouldn’t assume the same things that are difficult for humans will be difficult for self driving. I’m optimistic these hurdles can be overcome.

Your quote omits the qualifying part of that sentence, which is important. :-)

What does it mean to "last longer" when it comes to your own codebase? And why would web components help with that?

It seems like Web Components are ideal for libraries shipping pre-built components, which is probably why Mux finds it compelling. From Mux's point of view, they want the highest level of compatibility with the least amount of framework lock-in. For example, they don't want to have to ship a library for React and another one for Vue and another one for bare bones JS/HTML.

In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.

It's ridiculous. I'm curious what the way out of this clown show will be - governments aren't typically known for being good at cutting back bureaucracy and red tape.

I'd love to be corrected here, but my understanding is that the enterprise support and pro features model can be a pretty good business.

Big deployments generally need really good support and help to overcome scaling challenges. Who better than the library maintainers to offer that, and your customers have deep pockets.

Then on top of that, you run a business which basically creates proprietary Pro and Enterprise versions of a product which has tooling to operate the project at scale or in high uptime environments.

Then you offer your own cloud versions of the product as well (which I think Redis has been doing).

But in none of these cases are you creating a disincentive for anybody to use/adopt your product. You're simply creating value around the pain points.

That's because this is an org chart, not a cohesive product.

Yeah it's a total double dip, similar to ISPs trying to extort internet companies for access to their own customers.

Yes! There is a Staples near my house with a print center. Their prices for a job I needed done were so exorbitant that I bought a printer/scanner from the same store and broke even almost immediately. I have not returned to the store since. Their business model is pretty flawed when they sell something at low margin which makes the high margin thing they're selling obsolete.

The world would be a better place if we could all just be happy with standardized legal agreements: the pros/cons are easier to know ahead of time for both parties, you don't need much legal advice around them, and there isn't a lot of legal busy work that nobody really wants to do (even lawyers).

Having said that, the common answer from a lawyer of "it depends" is often true: there are often a lot of nuances that many people don't consider. For example you would think a mutual NDA should be pretty standard, but as it turns out it can be really complex.

"After some reflection, we just don't see how this could be a billion dollar business"

Telling a lie is not illegal by itself. Telling a lie with the intent of harming someone, especially their reputation, is another story.

Says the person leaving a comment on a forum which would likely not exist due to legal risks without Section 230 protection. :-)

I agree transmission should receive extra protection. But there is no case where moderating every piece of content that flies across the internet is economical nor even feasible given the volume and how insanely difficult it is to create repeatable one-size fits all rules. However, given the amount of public discourse that exists online now, we would only see a chilling effect from changing these rules. It gets even harder when you think about something like Mastodon.

Is the current state of the world ideal? By no means. It wasn't ideal before either when media and public discourse was controlled and channeled by only a few entities. And we should expect to see evolutions in the future as well - we haven't found the happy place yet.

At the very least, it seems reasonable if large public platforms were required to be more transparent about their moderation efforts and rules so at least we can see what is behind the curtain. The lack thereof has created a lot of distrust.

Isn't that delta partially based on the last keyframe? I guess it would be codec dependent, but my understanding is that keyframes are like a synchronization mechanism where the decoder catches up to where it should be in time.

The way Tailwind is setup, we may as well bring back the <font> tag.