closeparen

Also true of human-written unit tests. You probably also want to have integration or UI automation tests that cover the end-user scenarios in your product requirements, and invariants that are checked against large numbers of examples either taken from production (sanitized of course), in a shadow environment, or generated if you absolutely must.

Please make remote development work well in the IntelliJ-based IDEs. It's very difficult to get corporate employers to continue supporting their toolchains locally when VSCode Remote is "good enough" and disposable cloud VMs are so much easier to support/secure/manage/scale.

The development experience in IntelliJ-family IDEs is incomparably superior, but you have got to figure out how to run the code indexing on the remote server and the UI locally. This quasi VNC thing isn't it.

Here's a really simple way to get a cycle.

Service A: publish a notification indicating that some new data is available.

Service B: consume these notifications and call back to service A with queries for the changed data and perhaps surrounding context.

What would you recommend when something like this is desired?

It’s too bad that there does not seem to be a comparable provider with datacenters in North America.

There's a saying in live audio: I mix for free. I get paid to haul equipment.

I code for free. I get paid to deal with JIRA, Zoom meetings, and the Bay Area.

Working from the office was of a completely different nature in 2019 when your coworkers were also there. By scattering headcount around the world, tech executives have fully committed to distributed teams that communicate by video call. The question now is whether you join video calls from home, or from a "hub" that hosts a minority (or perhaps none) of their other participants.

There is no sign of a return to 2019 levels of Bay Area or even US share of headcount.

I doubt it. A company that is doing RTO is also a company that is aggressively offshoring and expecting you to spend your early mornings/late nights on IST friendly calls. It's just a general turn against US-based software engineers as belts tighten and the balance of power in the labor market shifts.

It's mystifying, but pretty much the entire tech leadership class has a deep conviction that taking Zoom calls on Airpods from your desk or a random corner of the office is the ideal way of working.

Americans have the right to marry and thereby grant status to foreigners.

You are demanding that their American spouse either divorce them or spend the rest of their life in another country. Of course it’s crazy and cruel.

Driving on public roads carries a responsibility to respond reasonably in all kinds of stressful situations. People incapable of handling a traffic stop should not be licensed.

Okay, and? As long as crime is below its peak level, there’s no need to apprehend criminals?

Stealing cars (often at gunpoint) and driving them recklessly is an entertainment activity for young men with poor impulse control and little regard for human life. This kind of person makes decisions of comparable quality elsewhere in life that are probably incompatible with being middle class.

These are trivial matters in that the penalties are minor, not that they are optional.

International airports count.

You could simply ban targeted advertising, since that's what everyone is actually upset about, and not create insane collateral damage for non-adtech operators who happen to have network services and databases.

Modern internet company backends are very complex, even on a good day they're at the outer limits of their designers' and operators' understanding, & every day they're growing and changing (because of all the money and effort that's being spent on them!). It's often a short leap to a state that nobody thought of as a possibility or fully grasped the consequences of. It's not clear that it would be practical with any amount of money to test or rule out every such state in advance. Some exciting techniques are being developed in that area (Antithesis, formal verification, etc) but that stuff isn't standard of care for a working SWE yet. Unit tests and design reviews only get you so far.

> TCP/IP-based one-way

What would it mean to have one-way communication over TCP? Don't you need to send the acknowledgements back?

If you work in the Bay Area, want to raise kids in a house you own, and don't own one yet, then "can report to a Bay Area office" isn't going to work as your competitive advantage for much longer anyway.

I think people have been finding more compelling use cases for the fact that information systems can be multi-player now than for marginal FLOPS. Client-server is just a very effective way of organizing multi-player information systems.

I do not think it is righteous or enlightened when the American government flexes control over the tech sector. I can see how Europeans might have thought this about the EU when it was just GDPR, but subsequent developments have recast all of this as being about government control and keeping the tech industry “in its place” rather than a commitment to privacy and freedom in and of themselves. I think that ought to temper the righteousness.

The same EU that's doing Chat Control?

I disagree. The point of code review (and indeed, software engineering) is to get at the difference between code that works for its intended purpose (as far its author knows) and code that it's reasonable for us to be responsible for collectively and in perpetuity. That includes things like working in the way you would expect, minimizing surprise, using names that make sense, etc. which are fundamentally subjective and human factors. It's expected that a new team member bounces off some "not the way I'd have done it" type comments for a while until they're socialized into the way that the team or project does things and can reproduce it themselves the first time. Formatters, linters, and documentation can speed up this acculturation process but there is an irreducible degree of "good taste" which you just have to cultivate over time.

That said, it's also important the reviewer feels equally responsible for getting the work done and is willing to make pragmatic tradeoffs taking into account timeline pressure, how contained something is, how likely it is to actually cause trouble, how hard it is to change later. Cross-team and cross-org reviews are more likely to involve pure gatekeeping, which is death.

VMWare was for sale in the first place because it is obviously not going to be the case in 10 years that every dentist’s office and car dealership needs 3-10 instances of Windows Server in the closet. It makes sense to sell to someone who can extract as much value as possible from it on the way to zero.

Exactly. There should be no problem having tens of thousands of stateless, I/O bound database-transaction-wrapper endpoints in the same service. You're not going to run out of memory to hold the binary or something. If you want to partition physical capacity between groups of endpoints, you can probably accomplish that at the load balancer.

Having the latent capability to serve endpoint A in the binary is not interfering with endpoint B's QPS unless it implies some kind of crazy background job or huge in-memory dataset. Even in this case, monoliths normally have a few different components according to function: API, DB, cache, queue, background worker, etc. You can group workloads by their structure even if their business purposes are diverse.

There is a point in commit throughput at which finding a working combination of reverts becomes unsustainable. I've seen it. Feature flagging can delay this point but probably not prevent it unless you’re isolating literally every change with its own flag (at which point you have a weird VCS).

Unfortunately the thought pattern “modern software development is way too complex, we need something radically simpler… I know! I’ll use Scala!” is not a thing.

>Modules cannot call each other, except through specific interfaces (for our Python monolith, we put those in a file called some_module/api.py, so other modules can do from some_module.api import some_function, SomeClass and call things that way.

This is a solution to a large chunk of what people want out of microservices. There are just two problems, both of which feel tractable to a language/runtime that really wanted to solve them:

1. If the code implementing the module API is private, it must all be colocated in one package. If it is public, then anyone can import it, breaking the module boundary. You need a visibility system that can say "this subtree of packages can cooperate with each other, but code outside the subtree can only use the top-level package."

2. If a change module A has a problem, you must roll back the entire monolith, preventing a good change in module B from reaching users. You need a way to change the deployed version of different modules independently. Short of microservices, they could be separate processes doing some kind of IPC, or you need a runtime with hot reloading (and a reasonably careful backwards compatibility story).

Culturally, America wants manufacturing back in order to increase the prestige of non-college men. Some amount of spillover to engineers might be tolerated, but if the pay, benefits, and authority are seen to mostly accrue to high-SAT-scoring engineers (just like in Silicon Valley) then a manufacturing renaissance will be considered an abject failure.

I give more of my attention than I'd like to admit to Twitter these days. But before that it was Hacker News, and before that it was Reddit, and before that it was Digg + Gawker-family blogs like Lifehacker.

I think the impulse to scroll is a feature of my own psychology, not something inculcated in me by Tech, and small web properties with simple feed algorithms are capable of feeding it perfectly well, often better than Big Tech and its data science armies.