danielrhodes

The value of this largely depends on what you're optimizing for. If your constraint is you need a lot of cheap bandwidth but don't care that much about latency, there are many places to find it (find a cheap host, set up Varnish, you're good to go).

However, a lot of people use CDNs because they are fast. They want the latency to be ultra low and they want it to be reliable. This is where the author's solution falls short: CDNs can get premium quality bandwidth because they have more scale than their customers. Sure you can find servers from various hosts in lots of different data centers, but you might not get the latency or quality of bandwidth you were looking for. This can be critical for some applications like streaming or serving images.

If your constraint is speed, you almost have to go with a CDN (even if you are huge). If it's volume, you are in a better position. If your volume is small, you might as well go with something off the shelf like Cloudfront or Cloudflare. If you are ultra huge like YouTube or Netflix, then you have to peer directly with ISPs.

From reading your comments, it appears like you have confused having a competitive advantage with anti-competitive practices. Just because YouTube has access to cheap resources by its parent does not prevent a competitor from existing in or entering the market. Facebook, Instagram, Tik Tok are doing just fine without access to Google's resources. There are other practices that Google does which might fit the bill (e.g. ranking and prominence in search results, Android, etc.), but this isn't one of them.

Before it would appear Microsoft was pricing the API based loosely on their expected search ads CPM - essentially their opportunity cost. This pricing seems different: Microsoft doesn't want anybody using Bing's API to create LLM-based products that compete with Sydney.

People have gotten way too religious over SPAs, SSR, etc.

Should you use X? Maybe it depends. I have been burned by using SSR when the complexity of the app increased and suddenly doing SSR was getting in the way and now I was uncomfortably mixing JS with server rendered pages and struggling to maintain state. I've also been on the other side, using React and creating more complexity than was needed.

The point is: don't be dogmatic. Get requirements, extrapolate what could happen in the future, use first principles, weigh decisions against team capabilities, ask yourself if your decisions are for your own personal reasons or have significant positive user/business impact.

Engineers who rush to use one technology over the other without doing their homework are just doing bad engineering. It has nothing to do with "fighting the good fight".

There are obviously stupid loopholes in tax law that serve no wider benefit, but that's not the case here. This was very intentional and not crazy at all.

The whole reason this tax credit exists is to promote more R&D. If you are doing heavy R&D you can pay less income taxes. It's an incentive for companies to not hoard cash but to put it into creating new business and opportunities and stay competitive. They still have to pay payroll tax, which is a substantial portion of the tax companies pay to the federal government anyways. But even that too is an incentive for companies to run more efficiently: the fewer people you have on payroll and the more R&D you do, the more your company is an innovation machine - that ends up being good for the economy.

There are obviously lots of cases where American companies use loop holes to not pay taxes (especially on international income). That's a separate debate. But if you see a big company (like Amazon) not paying income taxes, it could mean they heavily invest in R&D. That's why when I hear politicians whining about this, I know they are not always doing so in good faith.

This is typically what happens unless the users of the software really need it. For example the concept of folders is really outdated, but good luck getting people to use a good tagging system to replace it.

Law firms are heavy users of a DMS, especially versioning. Insurance companies use it too, but probably not versioning. So there are customers, but quite specific.

Most people have only interacted with file management systems, which are far more basic in their functionality.

In orgs where this need is usually present, the data can be massive and it takes some time to understand how it all fits together. There is also the issue of optimizing around indexes or writing queries that are cost efficient (especially if you using Athena/Presto/Big Query). Mistakes here can cost a lot of money or lock up the system so others can't use it.

I love this demo, but I feel like it would be better with a human in the loop because these edge cases can be so severe.

Tech work is now seasonal you say?

Right. As much as people want to complain about Apple forcing WebKit/View on everyone, what it has enabled them to do is build specific hardware level optimizations in for JS and page rendering, which means you can get really good desktop-level performance even with an otherwise limited CPU/battery. Given Chrome's horrendous issues on MacOS, they are going to drain the battery as fast as possible and then blame it on Apple. Chrome users will then blame Apple for bad battery life.

More or less, yes. Because you have more opportunity to maintain state locally on a mobile app (which isn't done as much in browsers), you will see more business logic. But it's largely very similar to web dev. Again though: depends on what you're building and how much you need a remote backend.

This is where things get interesting in React Native. The answer is: yes you can have smooth animations. However, the animations have to be driven at the native level and not in JS.

The reason for this is: React Native is on a run loop. And on each loop, new state is shared over a bus from the JS side to the native side. So if you manage the frames of an animation over this bus, it's going to be very slow. If the native side manages the animation, you don't have this overhead.

The same goes for touches. If you touch something, the native side gets the event and then this goes over the bus and RN picks it up. But if RN then responds to that touch by highlighting a view, that means another message has to go back to native - lots of overhead. For that to happen without a perceptible delay you have to have these events handled on the native side.

Another thing that can happen is too many things in the view change at once: you then have a traffic jam on the bus and the UI slows down or becomes unresponsive. This can happen if state changes too quickly.

You can get decent performance out of React Native (especially on tables, which is otherwise a dark art in iOS), but you have to know where the bottlenecks pop up.

If you can get away with it, it's not a bad option. But it's still early days. If you run into compatibility problems or bugs with libraries being used, you could be in trouble.

React Native is much slower on Android than on iOS, sometimes by orders of magnitude. You can get things usable on a lower-end Apple device, but on a lower-end Android an optimized RN app is still unusable. Part of this is due to the JS interpreter available on Android (which FB has tried to replace). But I think it's also due to architectural issues in Android itself and the natural overhead that RN has being too much in a constrained environment.

You can use C++/C to do this but depending on what you're doing it probably won't save you much time. You could also use JS to share code since both platforms have JS interpreters you can run arbitrary code in - but the ergonomics of this would likely be sup-optimal. For most apps, the vast majority of the work in mobile is the front-end - so sharing code this way would just end up being a headache.

I don't see why this would be a copyright violation anymore than somebody learning something from multiple sources and reformulating what they learned into an answer to a question. As long as it isn't explicitly reciting its training data, there shouldn't be an issue of copyright.

They weren't wrong. They are one of the biggest cell carriers, backbone, and broadband providers. I'm not sure what role they imagine they would take, but it is similar to the role they have had in the past.

You can find the etymology on Wikipedia. https://en.wikipedia.org/wiki/Boilerplate_text

It was a term used in printing presses for text/content that could be reused.

> "Boiler plate" originally referred to the rolled steel used to make boilers to heat water. Metal printing plates (type metal) used in hot metal typesetting of prepared text such as advertisements or syndicated columns were distributed to small, local newspapers, and became known as 'boilerplates' by analogy. One large supplier to newspapers of this kind of boilerplate was the Western Newspaper Union, which supplied "ready-to-print stories [which] contained national or international news" to papers with smaller geographic footprints, which could include advertisements pre-printed next to the conventional content.

The same can be true of boilerplate code, which in the same article is defined as

> the sections of code that have to be included in many places with little or no alteration

It seems unreasonable to dictate the way your colleagues work because it doesn't match your own value system. If the culture of the company/team is fast paced or long hours, maybe it isn't the right fit for you.

Generally speaking though, companies should value output and results over hours. Easier said than done. Additionally, value should be placed on what one commits to do and delivers on. So if somebody is constantly having to pull late nights to complete work, they may be overcommitting. It's also possible a manager will consistently push people to overcommit: this is a problem because that can indicate poor boundaries, bad planning, poor resourcing, and so on.

This article dances around some of the important stuff.

Maintaining engineering velocity is about adapting your culture to focus on the right things. At the beginning, engineering velocity is driven by low communication barriers and fast decision making and lack of existing tech debt. But this doesn't scale.

For engineering velocity at scale you need the following:

- Maintaining a high quality bar: You need to properly manage and prioritize tech debt and infrastructure complexity. This also means keeping dependencies low. The more engineers you have, the more code you're going to have. If this catches up with you, your velocity can be severely impacted.

- You need to have good change management: things like database migrations or big code changes should carry the least amount of risk possible. Documentation is important. You quickly get into hot water if you get stuck here.

- A culture of continuous improvement: teams should be data driven in measuring their performance and motivated to maintain and improve that performance over time. That means, for example, tracking sprint completions, bugs, etc. Each team needs to own this. The goal: ship high quality code faster.

- A close connection with the business and customers: When you focus on what the business needs and what the customer needs, it prioritizes things in such a way that your teams are dialed in to work on only what is needed. You can waste a lot of engineering time on things which don't matter.

- A culture of coaching and personal improvement: hiring good people is key, but ultimately it's how they play together as a team which is the most important. People need guidance on how they can be the most useful in that context. Sometimes people don't work out, so having fast feedback and showing people the door when they don't work out is necessary. Not doing this is a great way to demotivate other team members, at the very least.

- High amounts of ownership. This has sort of become a trendy topic in management philosophy, but ultimately it comes down to: can teams make autonomous decisions and own outcomes in the greatest way possible. This is all aimed at reducing decision making and communications overhead. It is also about making sure people with the greatest context can make decisions rather than somebody higher up with less context.

I'm sure I'm missing other stuff, but if you apply these principles things start aligning themselves in a direction where velocity is constantly improving.

However, I think talking about engineering velocity can sometimes miss the mark. What you really want is consistency.

Engineering lives within a broader organizational structure and other parts of the business need to be able to rely on you for certain things. When you can say: "Yes we can ship this feature by this date" and then hit that, you enable a lot of things. So yes, being fast is great. But you won't get there without being consistent.

Having contributed to a project that needed to apply these principles in a previous role, it can’t be understated how important it is to understand these concepts.

One thing I found interesting though is that one feature of double entry accounting is creating a paper trail where some lost data can be reconstructed if necessary with redundancies. For example if you lose the physical pages detailing a transaction, you can figure out what happened based on data contained in another page. A problem we ran into was how to reconcile that methodology with how this would be solved in code (e.g. DB backups).

At a previous place I worked, the company was not even aware this information was being shared with Equifax. The payroll provider would share this data by default unless it was explicitly turned off.

There's a reason people use everything apps in other countries:

1) It reduces the number of apps you have to download, which in countries where data is expensive for the average person, is a big deal.

2) The proliferation of internet enabled services is still relatively new. So from a branding perspective, it is easier to communicate one service rather than many different services. The US saw a similar phenomenon in the everything app known as AOL back in the 90s.

For the benefit of receiving less robocalls, I support this.

However, what interested me is the ability of the FCC to govern who can interconnect with whom. Could the FCC say that network providers aren't allowed to carry traffic originating from certain IP addresses or hosts? That would certainly have a profound cooling impact on the internet if they could.

Bad code doesn’t matter. It’s clearly making money in spite of the bad code. But engineer efficiency matters, especially if it’s blocking the future. So your goal should not be to rewrite anything, but to find ways to increase productivity. You’ll find that when viewed through that lens, some parts of the code and processes will have to change but other parts simply don’t need to be changed (even if it makes you cringe). The better bit though is that you’ll be more aligned with the business, whereas rewriting for the sake of improving bad code is not aligned with the business.

Made a relatively complex React Native app last year, and gained a lot of perspective on it.

I don't think Airbnb made a bad choice at the time they did it. They tried embracing a technology that was at the time half baked. When you are operating at the scale of Airbnb where there are lots of engineering hurdles and a high quality bar, it's challenging to absorb nascent tech.

Since then a couple things have happened:

- Devices have gotten much faster and this has covered up a nice chunk of the performance tax that existed previously

- The framework has gotten more mature and performant

Having said that, there are still a number of rough patches so it really depends on what you need. Shopify, for example, seems to be quite happy with it. But as usual, it depends on what you're making. If you want something with heavy animations, lots of gestures / high touch responsiveness, really fast startup time, etc. - RN might not be the best choice (but still way better than it was before because of lots of great work). If you're creating something that is more on the CRUD side, RN is more than suitable and a great choice.

In a previous place I worked, we were programmatically using Box to store files. One day we were presented with a case study in Murphy's Law: a script went awry and deleted everything (10s of thousands of files). There was no clear way to recover these files, they were gone from what we could see. It was a disaster. We got a Box support person on the phone and described what had happened. There was a pause, some mouse clicking and then: "Ok, those files will be back in your account in an hour."

It was 100% our fault. But soft deletes saved us that day. If you're in a situation where you or your customers could benefit from the same, it's wise to not only embrace them but also make sure they work.

Being unable to effectively use foreign key relationships is definitely a downside of using soft deletes. But it's also worth asking if these types of behaviors, which would also include a feature like triggers, really belongs in a database or whether it's better to have at the application level (or at least at a layer above the data layer). I'd argue that ultimately you probably don't want these things at the DB level because you get into a situation where you're sharing business logic between two (or more places).

For 1 - this is spot on. There are tools to dump PDF text, but they are quite flawed because you don't know how the text is laid out. In many cases the text can come out quite jumbled, for example if there are columns of text. Therefore, for OCR it's better to convert the PDF to an image and let OCR handle it. Google's OCR for example will understand and output columns properly.

I haven't used Copilot extensively, only for fun. But I find it interesting that people are questioning the price.

Given that the cost of a software engineer's time is so high, $10/mo. seems very reasonable if Copilot saves you more than that in time per month. So in a vacuum assuming all dollars are spent with equal productivity, if I take the equivalent of $1000/mo. in time writing boilerplate, and I can reduce that to even $989 with Copilot, it becomes a good deal.

For sure. AWS and any other cloud provider will negotiate with you. Obviously the bigger your spend the better leverage you're going to have. What they may ask for though is something like a commitment of 12 months, co-marketing, or something like that. But they would rather keep you on as a customer with a smaller margin and your company survives and grows rather than go to another cloud provider or go under.