danabrams

It also struggles with my NYC-area accent, which is only medium thick.

There are four stages to any successful companies lifecycle and Bending Spoons's model is to maximize what they can get in the final stage of decline.

There's nothing wrong with that, but if you're a user of one of these services you might take it as a hint to find an alternative.

This is not sustainable forever unless their hypothetical usage is realized, and eventually the bill will come due.

Meanwhile, component makers will surely be spinning up more capacity, some of them in a foolhardy manner, and if the bubble does burst, 3-6 months later we'll be seeing fire sales on components and component makers going bankrupt (or getting bailouts, if considered of national importance)

I have one. I got it so I could have something small to slip in a small bag for when my toddler went to a playground. The thing that makes it's unusable is the trackpad. A better trackpad and I would think this was fine and great for the size.

ios Native App > web app > android app > anything made with a cross platform toolkit like react native or flutter.

I would much prefer a really well-crafted ios Native App with extensive attention to detail than anything, even a web app made with similar detail (in most cases). And also ios apps are far more likely to receive that level of attention than just about anything else.

I read what the author is saying as “time is fixed, so I adjust the scope.” The problem is when product or management is demanding both fixed time and fixed scope. “Here’s a list of requirements (which are under defined and we will change without giving you a chance to estimate) and a set of figmas you must implement for those requirements (and also we will look at the finish product and decide not to give you any extra time to make changes we want or build a breakpoint not defined by the Figma that we demand), no how much time with this I’ll-defined, fixed-scope take?”

Fixed time and fixed scope is essentially impossible, except in trivial cases. What I read the author saying is that he chooses to make it fixed time and has flexibility around scope in his work, because the requirements are more like loose descriptions than a description of exactly what a product should do, while ignoring edge-cases. That sounds like a nice situation. And a perfectly fine way to manage an engineering team. But it also sounds a bit to me like an abdication of responsibility to the engineering team by product, to allow the engineering team to decide what exactly the scope is. Again, that’s a perfectly good way to do it, but it means that product can’t come back and say “that’s not what I was expecting, you didn’t do it.”

I don’t think the author really tackles estimation here, nor the reasons why estimation is a hard and controversial issue, nor what junior engineers are looking for when googling “how do I estimate?”

The real reason it’s hard in this industry is that in general, product controls both scope and time, which are the two major dials by which delivery is managed, but abdicate responsibility for them by going an ill-defined but nonetheless more fixed (and unyielding) scope than described in this article, then demanding engineers give them specific date estimates to which they’ll commit, and work free overtime if they turn out to be wrong.

The author correctly defines a way to resolve this conflict: give engineering more say over scope—but fails to recognize that the root cause is not poor estimation, but rather that product or management denies engineering much say over scope past the initial estimation, and then demands they set fixed dates they commit to before enough is known. Death march projects, in my experience, are generally a failure of product, not engineering.

Oftentimes, broadly accessible services are lower quality than more personalized ones, to the consumer.

As an example in US government bureaucracy, government software teams digitizing forms at one point weren’t allowed to utilize features like autofill or automatically filling fields based on previous answers because it would relatively disadvantage users using paper forms.

Government capabilities do need to serve everyone, and from the perspective of the whole society that is beneficial, but they are often are of low quality to the individual consuming them for this very reason.

Let’s exclude taxes, because obviously many people would hate them under any circumstances. Does the government do a good job providing the other services people interact with regularly? Do people love their visits ti the DMV? Are they satisfied with their interactions with the police? Heck, in my town, just renewing a dog license is a pain.

The author talks about how software creation processes at large organizations are an artifact of how large organizations operate, but in all 3 of the 3 cases, I would ask “why does the large organization need to be that way?”

Most obviously, why do executives need to be the proxy to customers? Why can’t development teams simply talk to real customers? This isn’t just an abstract idea in agile, it grew out of actual Japanese product development practices practiced at large organizations: Toyota, Canon, and others, and documented in “The New, New Product Development Game” HBR review article that was so influential to early agile.

The point that in large organizations, most of the work is coordination, again demands the question, why? It’s been understood since at least World War I by some military planners (with organizations far larger than Google) that coordinating dependencies was far more complex than reducing or minimizing them. Goldratt wrote about it when designing a project management system for Theory of Contraints (indeed, you could argue this is a fundamental learning of ToC). And one of my favorite software conference talks of all time is Mary Poppendeck’s excellent “Tyranny of the Plan,” where she notes that as computer systems have been used in planning, we seem to have become more confident but no more competent in coordinating, rather than focusing on flow, in large-scale projects.

Finally, on the importance of software created at large organizations, I agree, something that will have millions of users on day one has a greater responsibility, but that doesn’t mean that loads of bureaucracy and checking are the pathway to quality software. First of all, does anyone believe that highly scrutinized and bureaucratic functions are general high quality services? The often provide access to even the most extreme edge cases, but they do so by reducing the quality of service to everyone else. Anyone who’s ever filled out their own tax forms in the United States knows that it covers every base of possibly income, but 80% of people really only need to be concerned with 2-3 common forms, and 99% could simply be asked about 10 forms or so. Instead we have to answer questions for “directors of foreign corporations who also happen to be Us citizens,” instead of just requiring those people to fill out an additional form. And, of course, to (probably badly mis-)quote Deming, “you can’t check quality into a product.”

I would turn it around in the author: yes, the software practices operate this way in large orgs because large orgs are structured differently—but why do large orgs need to be structured that way? Is it inherent when absentee owners with low domain context (shareholders) pass ownership over to a manager? Is it because hierarchies insulate good but not great managers from genuine value creation as long as they play politics well? Is it because these are first order ways to understand complexity, and again, low-context absentee owners aren’t going to do the work to understand the more complex dynamics at play?

For enterprise mobility venues like a commercial aircraft or a cruise ship it costs far more.

Maduro, Castro, and Saddam Hussein are/were bad. Castro and Hussein, at least, committed murders to maintain power and Maduro pulled a coup after he lost an election.

Whether they were worth removing is another question, but if you could flip a switch and magically replace them with something better (with no cost and a guarantee the replacement would not be a murderous authoritarian) you would of course do it.

I’m old enough to remember not having an iPhone and not feeling sexy.

Two types of sales philosophies: 1. It doesn't matter what you're selling, it's about the sales technique. 2. Develop deep domain and customer expertise.

The former is the scammy type, the latter is the type we love to work with.

But the same is true in any industry. Too many of us in technology are doing the technology equivalent of 1--becoming experts in C++ or React--instead of becoming deep domain and user experts.

Here's a theory...

Although illegal now, San Francisco used to have a widespread practice of "key money"--a bribe you paid the landlord to choose you to rent the apartment that due to rent control or other factor was priced below market demand.

Because the landlord was capturing the extra value directly, a cultural practice of high broker fees never developed there, while it did in the east, where bribes were less common. Thus someone other than the landlord captured the excess value.

It's also entirely possible that the broker's fee is being illegally passed as "key money" to the landlord in a way that's harder to detect/litigate in NYC because it's not direct from the tenant.

The author leaves out what to me is the most compelling argument against static types: it is somewhat at odds with interactive development with a running system, as seen in smalltalk and lisp.

Now, not a lot of developers are really doing this. But it's still a good reason for those who are.

I’m reminded of Alan Kay’s observation that software is a pop-culture.

Simplicity is great, how can we combine it with the 17 other frameworks we saw on HN this week and have to use?

Sorry, there was a typo. Astro is more focused on SSG than SSR. This is what happens when trying to comment on a phone keyboard first thing in the morning.

You wouldn’t use Astro with NextJS, but you absolutely would with react.

Astro is an SSR more tuned to generate static sites than SSR with hydration. It uses the islands architecture instead of full page re-hydration. So if you’re generating a static site with a few react components sprinkled in, it’s a good thing to use.

Because of the islands architecture, you can also mix and match component libraries. So one component can be react, one can be vue, one can be svelte, etc.

Next and remix are both less focused on SSG than Astro. A lot of people are making very content driven sites using react or Next—sites that aren’t really or shouldn’t be SPAs—and this is a great tool for content driven sites that don’t benefit from SPA-level interactivity (which is probably most sites using SPA frameworks)

From context they are almost certainly referring to the city of Washington (DC), which is part of the northeast corridor described, and not the state of Washington, which is on the west coast.

Do I have any sources that systemic racism is real?

I mean, there's a large body of evidence (I personally like the economics methodology of this study, which has been repeated many times: https://www.shrm.org/hr-today/news/hr-magazine/pages/0203hrn...).

But just like many will never be convinced that vaccines are safe and the earth is round, many will never be convinced that racism in the US is real, I suppose.

For 350 years of US history africans and their descendants were enslaved. Native Americans were ripped from their land and relocated, often with genocidal levels of casualties.

After that, these two groups were substantially discriminated against in law, and other races were added to the mix to be given less rights than others.

Today, there are huge disparities between outcomes for different races in large part due to this historical discrimination. There's also an ingrained culture of stereotyping and discrimination that's hard to lift. It doesn't matter if you're the first generation of Americans descended from African immigrants who came in the 1980s... you still are impacted by this legacy.

The concept of affirmative action was to specifically counteract the effects of these negative, historical circumstances and provide a countervailing effect.

I can't speak to other countries, but in the US, it is definitely the case that poor people of color have a harder time getting ahead than equally poor white people. (I suspect it's similar elsewhere, but we are also a pretty racially diverse country, so the effect is larger)

The complaint that at ideal viewing angles, the resolution will only be 720p is silly.

720p is fine for watching movies, even if it's not home theater perfect. But it's absolutely fine and way better than the alternative of watching on a terrible IFE seatback (which probably gets the aspect ratio wrong)

Since the link won't open for some, here's the relevant bit (the first two lines of the abstract of the paper linked to):

"MVC was conceived in 1978 as the design solution to a particular problem. The top level goal was to support the user's mental model of the relevant information space and to enable the user to inspect and edit this information."

It's a pdf. It opens for me when clicking. Are you on a browser that can't easily open PDF?

One of my ideas is that if you were to log the behaviour of a program with timestamps and implement a program that implements the same log, then its behaviours are identical.

This sounds a lot like event sourcing.

There’s no reason your model can’t have an abstraction layer that contains the business logic and a concrete layer that has the persistence (indeed, if it’s complex at all it should).

Yes absolutely. Reenskaug has stated that MVC was designed for simple operations (and co-designed DCI as an architecture for more complicated ones). And a number of the early OOP people including Alan Kay, have said something to the effect of “Erlang is the only true OOP language.”

I did a deep dive reading the early papers and watching the lectures from the 70s, 80s and 90s on this a few months ago. The early Xerox employees developing smalltalk seem to have originally thought the idea of encapsulation would compose at all levels. That as object interaction got more complicated, you would simply group a few related objects together inside a larger object, and the rest of the application would use that encapsulating objects interface, and you could go infinitely deep that way while managing the complexity. Later, in the 80s, Kay would talk an about writing objects in smalltalk then gluing them together with a glue language (usually Mesa C), because he felt smalltalk worked well for programming in the small but not the large.

Again, I think erlang got a lot right here, using a different model for programming the small (functional) vs programming in the large (actors/otp).

But to hear the OOP pioneers talk about objects, they consistently describe the objects not in terms of data but in terms of behavior, similar to Erlang actors being processes. Each object is supposed to represent a “computer” and the network of objects is supposed to work like a distributed system.

I know which mental model I like better, but objectively, it’s a very different concept from what most developers think of as OOP today (although very similar to microservices).

Source: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

The source is Trygve Reenskaug, the originator of the idea.

I agree, and I wonder if this is just what happened as an accident of history or so much a tendency of human nature that we couldn’t have done it any other way. Maybe simple data models is the mental model of computing that couldn’t be easily changed.

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing?

How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persistence would be necessary, of course, but an implementation detail. Models were smart and mapped to human perceptions of a thing, rather than dumb data persistence layers.

These kind of business logic operations have often been moved into controllers, which couldn’t have been further from the original intention.

MVC, smalltalk, OOP we’re all about stopping and thinking about the way humans think while interacting with computers. It was about designing nice interfaces for interaction based on human expectations, not database requirements. Internal object schemas and data persistence were implementation details of an object that could—if you did it right—be easily changed without changing the interface.

But we can’t help ourselves, and instead OOP today is a world of getters and setters with a little bit of data validation (if we’re lucky) and models are just a schema plus a generic data persistence interface (maybe an orm). And the business logic exists in the controller, the least important, least reusable component of the architecture.

Julia Evans's writing is just so much fun.