pbecotte

That's like- the whole point. If you as a manager set a goal, those three choices are all the choices the people under you have to meet the goal, and you often set it up so that the preferred choice (actually make things better) is impossible. Its saying that decision makers need to be aware of this and adjust your behavior.

Like you said, if they don't, the people dealing with it have no choice- so, it'd be impossible to offer advice for those people, since they have no way of actioning it (unless its convincing the decision maker of that point)

JVM can run apps _compiled_ for it. WASM has the _exact same_ limitation.

Someone put in the effort to get Postgres to compile for WASM. That's great :) Maybe someday every application will compile to WASM as the preferred choice over the linux interface.

Compiling apps for different targets is VERY MUCH not a simple, low effort task though. Something like a database that must have an incredible number of optimizations in the way it makes syscalls, will have to a full stream of work to keep each target running well.

It can be done. But if "one of these thigns is not like the other" with your three things- Docker is the odd duck out.

It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task.

There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"

I don't think the statement "fairly simple to compile an arbitrary program" hasn't been true for any ecosystem, ever.

no, you're right. Terraform/Pulumi are much more focused on provisioning resources, while Ansible has its sweet spot in configuring a machine once its running.

Was a generator technician before I got into programming. Even the 2 megawatt systems could start up and take full load in 10-20 seconds. It sounds basically like starting your car with your foot on the gas.

The "when" shouldn't really matter- Diesel engines aren't a new thing. Warming them up isn't really a thing either- they'll have electric warmers hooked up to the building power to keep them ready to go.

The weird thing is- it could be a scam that is not actually a scam. If they have somehow acquired the legal right to use the author's name to release books, they don't need to swindle the ghost writers- they would probably be able to actually sell a decent number of books. The victim of the scam would be the author and her publishing company.

The author of the article had a great point. Developers often DO treat me as an IT person. The number of times I've taught a developer what an SSH key is or how to install a python virtualenv on the dev box blows my mind.

On the other hand, everything else he says is wrong. Devops isn't "ops gets out of the way and lets developers do crap and nobody owns it when it breaks" its... dev and ops WORKING TOGETHER. If you don't know what their app is doing YOU ARE NOT DOING YOUR JOB. (On the same note, if they don't know anything about how the system is deployed or the like, they're also not doing their job). The rest of the article is literally about complaints about that. The point that you can't monitor an app you don't understand, and developers don't want to push out crappy code, is the whole reasoning behind devops. The people no longer being in their own silo, but instead working together as a more holistic team to own the thing from end to end. If you stay in your silo but add automation, you are 100% going to have pain. There is another pattern they could try, thats the platform model. In that case ops can stay in their little silo and present a platform with apis that developers can build on. Its what you're talking about here, and that can ALSO work. But its a different model. The old style of ops they would do as they were told, while trying to restrict anyone from changing anything. As a platform team, now they're delivering a product. They should be talking to users, and judging throughput, and iterating quickly, and being customer focused... basically, acting exactly as the developers are supposed to be. I am a strong beliver that the platform team should have product owners and customer metrics the same as the developers- heck, if they like QA, they can come up with a QA process. But yeah, I've seen a lot of low effort finger pointing in orgs that pretend to do devops from inside their functional silos. That point, the one in the title, is a great one.

Even in 2016, I had been running production services in Docker successfully. Its interesting to me that they see the problem "Docker isn't designed to store data" without also seeing the solution "the docker copy-on-write filesystem isn't designed to be written to production- but volume mounts are". I hadn't seen docker crashing hosts (still haven't) - but I'm guessing that was caused by using the storage drivers.

The complaints about their development practices are valid (and haven't really improved), but even then the technology worked well so long as you understood its limitations.

A little. The thesis behind 'trickle down' sorta makes sense if you think about it. Less taxes = more money to invest = more investment = more economic activity. I did kind of expect to see SOME impact, though have felt for a while that the financial markets have become so disconnected from actual investment behavior that the impact would be marginal...and looks like this study concludes its even less then that.

Just because a company has SOME open source software, probably doesn't mean that all of their software is.

Yeah, I'm all on board with trashing the company. Those emails were terrible.

The emails from the company make it clear that at least one party to the dispute believed that they did use Replit's internal design decisions. Commercial companies approaching the same problem certainly would offer similar feature sets. But an employee reading the source code and then starting a git repo that makes a working version of the product freely available is a pretty big deal. It doesn't have to be copy-pasted to be valuable intellectual property. (though, I do agree that THIS was unlikely to actually be valuable IP haha)

This wouldn't be an issue of non-compete, but of intellectual property - and I can't imagine there was no intellectual property agreement signed. I've never had a job that didn't have one...

I...am on the side of the company here? wierd...

An employee of a company left, and then made an open source clone of the company's software. The fact that the software was easy to clone or that others had done it previously doesn't seem really relevant. Several times I have left a company, and I could replicate a good percentage of it in a couple days too, not because it was easy, but because the months/years of experience I had building it the first time.

Whipping out the lawyers and bragging about his funding is idiotic and childish, but I think asking for the project to be taken down is completely reasonable. (on that note- I kind of think at this point that you have to be a megalomaniac to be a funded startup founder)

Guessing you didn't read the article? This article is saying that when Tesla made those complaints, Edmunds reran the test the way that Tesla suggested and got the following results. Sure, maybe its not a big deal that the cars come up a few miles short of the advertised range under these conditions, but the Tesla ones were the _only_ ones to do so, which is at least interesting.

I've certainly never been bottlenecked on date parsing :) However, many/most of the high performance python libraries are built in C code, and compiled down into something the python interpreter can use directly. There are lots of python bindings written in c++ to native c libraries as well, I know I have used ZeroMQ pretty recently. Rust is done the same way- the code is compiled down into objects that Python can use directly- its not like running a javascript interpreter in your code.

If you already have all of that working, why would you change? Containers are valuable for a couple things-

1. Packaging and distribution- it's very easy to set up a known good filesystem using docker images and reuse that. There are other solutions- dpkg plus ansible would be an example.

2. Standardized control- all apps using 'docker run' vs a mix of systemd and shell scripts can simplify things.

3. Let's you tie into higher level orchestration layers like k8s where you can view your app instances as a single thing. There are other solutions here as well.

4. Can use the same image on dev machines as prod instead of needing two parallel setup schemes.

If you already are happy with your infra, certainly don't change it. I think once you know containers they are a convenient solution to those problems, but if stuff is setup they already missed their shot.

I dunno what the law says. However, it is very easy to imagine a situation where someone LEGITIMATELY cannot decrypt the device. Is indefinite detention without even a criminal charge a valid punishment for that? We can make analogies all day "is it testimony? Is it like the code to a safe?"... But there is a real concrete fact that the government wants to be able to imprison someone indefinitely, without a jury trial, for claiming not to know something when there is certainly a reasonable doubt about them knowing it.

So, whatever they have to do with the analogies, this decision cannot go the way the prosecutor wants it to.

But... we understand EXACTLY why developers are paid so well. Economics (the same reason EVERY profession is paid the way they are). There are two factors that come into play for employee pay- 1. Supply/demand: When demand outstrips supply, prices rise. The demand for software so vastly outstrips the ability to produce it that salaries are being driven very high because 2. The marginal value that an employee can produce. This is a hard cap on the salary that any profession can charge, and is the primary driver for demand. So long as 2 is higher than the prevailing salary, demand will continue to rise, which will apply upwards pressure on salaries.

Of course, high salaries will attract more supply over time, which will put pressure back down on salaries. The current dynamic is SO out of whack though- there is a ton of slack in the system.

This isn't a boom/bust thing either. There is SO MUCH business value that could be had if there were programmers available to build the software. I don't think we're even scratching the surface of everything that could be profitably built yet. I think betting on a big bust in software engineer salaries would be a bad move.

Even when they do, there is a problem. They specialize in DB code. AWS specializes in infra... and can just take the DB code as well. That is a pretty huge competitive advantage (while the db company has to develop that second specialty). Even worse, there's the further monopoly advantage that companies can just role it into their AWS bill instead of doing another vendor evaluation. The fact that Amazon has almost all the competitive advantages for offering someone else's code it what seems unfair.

(the one they don't have is the ability to offer super specialized support and modifications for their customers, which is where a lot of the database companies have made their money - on consulting)

If the accepted wisdom was true, that you can trade quality for speed, then you shouldn't write tests.

I do not believe that to be the case. I find the biggest value of tests is being able to change the code more quickly. Running tests is MUCH faster than a regression script.

There is a scale where you'll never have to change the code enough for the tests to pay off. Personally, I think that scale is quite small, maybe a week of development work.

However, it takes some experience to get good enough at the tests that you feel that benefit. If you're not there, the answer is probably different. However, if your startup scale is non trivial, I'd bet that the payoff if learning that skill and building some testing framework from the get go would be worth it.

If you have taken enough VC that the only way to get any value at all is through a huge exit, this statement is true. If you run a normal business, it is not true :)

So yeah, React may go away in three years. Do you think you would have been better off during those three years continuing to use jquery? Do you think the hours spent learning the new thing were more or less then the hours saved my the new thing having a better api?

(now, of course, you I may be wrong on the cost benefit analysis here. I don't think I am, and the ubiquitousness of the new stuff implies that most of the industry agrees... but no matter the answer, that is the way to think about whether learning something is worth it)

I mean, if I hire a contractor that I got through a staff augmentation agency, I have to pay a fee. That is part of the agreement with the agency. This seems the same?

This is only true in the limited case where you never have to share your code with anyone. If you want to share it, setting it up so others can get going without having to figure out which packages are missing is necessary. In that case, you should probably use that same tool yourself to make sure that your environment works the same as you expect others to use it.

Yeah, I feel weird about the book. The devil's advocate stuff about climate science is NOT helpful or intellectually honest...but I find the broader argument about the media living from crises to crises very compelling.

(Also, the actual plot of the book was super annoying haha)

Something I have thought privately for years is that lowering the "cost of money" is the best way to reduce inequality. It is beginning to look like we may find out as that cost keeps going lower.

The AWS docs annoy me SO MUCH. As others have noted, there is a LOT of them, and they cover every feature. But I cant think of any of them that explain how stuff works. There will be three different versions explaining how to set some option with cli, sdk, and console versions...but they never explain what that option actually does. The examples are always at the tutorial level (there are so many * in IAM permissions in their docs). For something that is so very much a professional product where the details are important, their docs should really have the more in depth details. Like what are the tradeoffs with Aurora? How exactly do the load balancers handle connections and scaling? What does the "certificate" option in codebuild do?

With the way the internet works and the tech they have built, it's harder not to collect stuff. All of these companies have all sorts of stuff they shouldn't, and I wouldn't trust anything they say about opting out.