randombytes6869

> . We seem to do stuff that's out of the normal experience (Python to create thousands of individual reports on thousands of rows of postgres data per report)

Sounds like you need somebody that knows Python and SQL, should be easy to find. Everybody thats been in the business for a while has done reports. However everybody also hates doing reports, so you might have to pay more than you want to, or hire interns to do it.

> A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly

I would just look for somebody experienced then, maybe 3 years +. Its going to cost more though, especially if the codebase is ugly and most of the work is reports.

> I've been largely responsible for hiring developers (usually on contract)

Hiring on contract is unlikely to get you desirable hires. Good devs have a lot of options.

My somewhat generic advice is to have a coding assignment. Some people won't do them but its the best way I've found to screen candidate quality. Equally important is to have a good developer look at the submissions. The quality of code as rated by good devs has always correlated strongly with the quality produced once hired, at least from what I've seen.

Advice for your situation specifically is to offer a lot of money and don't do contract-to-hire. Reports suck, your codebase sucks. Good developers can find another job within weeks and won't stick around unless you make it worthwhile. Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already.

You can nab good people for a lucklustere job without paying a premium if you're willing to give rare concessions. Fully remote work, flexible hours, part time, 4 day schedule, relative autonomy, etc. If you can't do that or pay well turnover will remain high.

You're not in a good spot right now. If you're open and honest about the job "writing reports in a crappy codebase" you won't get many interested hires and those you find will ask for more money. If you lie/deflect you will hire more but turnover will be insane. Your best option may be to hire interns. They will expect the job/code to suck and ask for little money. Turnover will remain high and quality will be all over the place, but at least it will be cheap.

I heard lack of effective management structure was a far worse consequence of Valve's unusual structure. Heard influence became based on connections and favors, not good results or ideas. Heard many good projects died, even ones that would make sense to a third grader (HL3 L4D3). Hearsay but its all over internet if you're curious

We have found H2 in Postgres mode to be the fastest way to test db stuff, at least in Postgres and Java. In Go you might lose most of the speed advantage since its not running "in JVM". It also doesn't support many of pg's advanced features

Java meets your requirements. It gets a lot of shit but there's reasons why its so widely used.

The standard libraries + community are larger than Go, you can find a library to do anything. Standard library is huge and mostly great.

Compilation time is a couple seconds even for huge projects. You can do automatic reloads using Gradle.

Its very cross platform, including one of the only good cross platform desktop UI's.

You can build smaller binary distributions using JLink or a multitude of third party tools.

Single binaries are overrated. Any app that's widely distributed uses an installer or package management anyways (brew,choco,apt)

> There would be no A bomb without this, for example, nor US moon missions. These were mostly German weapons scientists brought to the US near the end of WWII. The alternative was being sent to Russia. Russia was brutal to PoW's so given the chance everybody tried to surrender to US and European troops. Not really regular brain drain that time.

Brain drain always happens from poor to rich countries. Those able to move to greener pastures will, I don't blame them. This is even happening within the US in Illinois. High taxes and precarious government have led to massive migration away from the state. Highest percent of college students going out of state, and average person moving to Illinois makes nearly $25,000 less than average person leaving.

You can't blame people from wanting a better life for their family. In the end it does concentrate wealth, but maybe it will eventually just concentrate the population? This seems to be happening in China, with massive migration to megacities. Rich or poor, the countryside is being abandoned, so there's not many being hurt by the migration, just empty buildings

> I seriously doubt this was ever an existential in the sense of the shipping cost itself destroying a business.

I've read many e-commerce blogs with US sellers lamenting that they can't compete with China on $5 items because shipping costs are 5X as much within US. Maybe not killing businesses, but definitely keeping many out of the market.

> China is simply able to produce cheaper things because they have lower labour cost and so on, and that is actually good for American consumers

Lower, but not nearly as low as it used to be. Minimum wage in China is almost 1/2 of US now.

There's real instances of shipping cost offsetting lower labor. Manhole covers are a somewhat famous example. They're still made in USA because shipping offsets increased labor and materials. Would it be the same for ecommerce? I'm not aware of any studies but to me, the increased cost and shipping time make it plausible

Its not just a Rust problem, I've run into the same thing in Java and I'm sure it exists elsewhere. The only answer I can come up with is to keep your app cleanly divided into modules. There's some cognitive overhead but its usually worthwhile.

I recently divided a 100k line Java app into 5 different modules and it compiles 4 times faster. The new boundaries have encouraged better code as well. Suddenly we have things like interfaces and IoC. Before, people just stuffed things wherever.

Conspiracy, but I don't think the US ever stopped researching nuclear propulsion. There's too many advantages. They built a few working and miniaturized test engines in the 60's but never put them on planes? I don't believe that. They put nuclear weapons on planes all the time and thats not much safer. More likely, they never told anybody they put them on planes, for obvious radioactive reasons.

An aside, the strange craft reported recently with the famous jet fighter videos had "impossible performance" and were all filmed over the ocean. The ocean would be the only safe place to test nuclear drones. And their performance would be quite unmatched by anything else. The pilots even reported that they submerged, sounds like a great failsafe if your super secret black project gets seen. I doubt you would submerge a jet turbine, but nuclear propulsion could easily work under water

Very true. IMO many people that hate XML config files just haven't used an IDE that validates schema. Its super nice to have auto-complete and property validation on config files, something not offered by JSON or YAML. A good reason to stick with XML for complicated configs.

Its one of reasons I don't mind maven. Yeah there's 1000+ line XML config file, but maven DTD is so tight nearly any syntax issue will be flagged. Something easy to appreciate when you're used to giant config files that don't get validated until runtime.

Very Java-esque name for the largest Java project there is. I like it. "Eclipse AdoptOpenJDK Adoptium" has a good ring to it. Reminds me of the SharedSessionContractImplementor I worked on last week for our Hibernate interface.

You can probably just check the referrer header and display a giant nag message to people coming from that business listing.

"This website is not associated with company X which have been misrepresenting themselves by linking to my site from their maps listing."

That's far too optimistic about storage. For small off-grid systems, you need ~5 days of battery capacity to ride out lack of wind/sun. On a large scale you'll need less because you can move power from place to place.

But still. Sun is down half the day and wind speeds can be low in areas hundreds of miles wide. Its obvious they will need at least a day of battery capacity, probably more. Not hours.

Solar and wind are great. Many areas in the US have hours long periods during the day where power is 100% renewable. But batteries are way too expensive and I don't like when politicians make laws based on predictions 15+ years in the future.

To those lamenting that they're scraping... Google is the biggest scraper of them all. Facebook, Amazon, Google, Microsoft. All the big boys scrape voraciously, yet try their best to block themselves from being scraped. Scraping is vital for the functionality of the internet. The narrative that scraping is evil is what big companies want you to think.

When you block small scrapers from your site but permit giants like Googlebot and Bing all you're doing is locking in a monopoly that's bad for everyone

Java is very similar to C++. Its boring in the sense that most things have been around forever and really old code is terrible but you still have to deal with it because backwards compatibility is so good. If you don't consider Java boring I wouldn't consider C/C++ boring either.

That doesn't make Java a bad choice for building new things