Hacker News Reader

Comment by christophilus | Hacker News Reader

I spent two weeks or so working at a government contractor. I put my two week notice in almost as soon as I’d started, and I permanently swore off the industry.

There were some genuinely good, smart people working there, but the culture was such that I’d be very surprised if they shipped a working product in 5 years time. If they did ship it, it would be an awful thing to behold.

I don’t know how to fix this issue. But from what I’ve seen and heard, the best minds (other than the rare altruist) stay in the private sector. It pays better, and there’s just so much less BS to deal with.

View on HN

I made it a few years on the gov side of this equation and had to quit. Like you say, there are certainly lots of bright people…but just as many (if not more) lazy and willfully ignorant people punching the clock and keeping the money faucet turned on regardless of the quality of output, if only to pad their performance reviews (executed x dollars managing project of y size) and keep their budgets from being cut. This attitude is insidious too, as I found myself becoming guilty of the same apathy and laziness around the time I decided to break free and throw myself back into more challenging and meaningful work.

I know another government contractor whose idea of client responsiveness is to download the entire server database to the client browser on initial load

That's completely the right strategy for the scale most web apps operate at.

How much more expensive is 100KB of JSON compared to last year?

Moreover, most mobile apps, web or native, could suck A LOT less if they did just that, load all the data at start. I have taken that to the extreme of serving all the code and data in one file. Definitely will do that again if I ever make another app with similar and fairly common constraints. Never waiting for unstable network and zero bugs with some part of HTML/CSS/JS/data missing or out of sync is pure joy.

This works great until you have something that doesn't fit, and it can block new features as a result of that.

I worked on an application a number of years ago where it was trying to load all the comments and details about an internal bug tracker into memory. It must have worked fine at first, but after time it was a POS.

There is no "one size fits all" solution.

If the database fits onto client hard drive and the modifications are rare, preloading everything is almost always better.

If you have a dynamically changing system such as bug tracker, it is still possible to go fully local, but that would require considerable cooperation from server side. When the back-end does not have a fast, efficient API for sending diffs, you may get stuck waiting for it to be implemented. But that's a purely organizational problem.

Of course, all of above applies to actually saving data to permanent storage. Storing everything in memory is a sin by itself.

Until someone doesn't think twice and adds some column to the DB that contains PII.

For a sufficiently small database (that doesn't require more granular access control), that seems to be the right choice. A 1 MB initial load is cheap nowadays.

Are we using the term "database" loosely here to mean some limited subset of data? Because I think of the term as referring to an app's primary datastore, and I can't recall a single meaningful modern app I've seen for which the database is anywhere close to that small.

Think of small, in-house applications managing an inventory of a couple hundred to a couple thousand items.

"Hard discount" stores like Aldi are supposed to have <1500 SKUs, for example.

Got it. Thanks for clarifying. Thought there might be some kind of clever sharding or tooling I was missing.

No really clever tooling. But even where the database gets too big, you can still stay in a similar operating mode. For example, when the user requests the first page of items or performs a search (that you have to do server side due to the size of the whole data set) - why not send the first 100 actual items instead of just the visible data from the 10 rows forming the first page? Or send the first 10 immediately followed by prefetching the next 90?

Now the user will immediately get to see the full item and will be able to page through the results much more quickly.

I've definitely had cases where I had to process the data before sending it to the client, but I've also sent absurd amounts of data and rendered it client side. In fact, I think sending data embedded in HTML to the client is rarely a good idea, and once you've adopted that mindset, apps can look very different.

Having worked in government (although not in US), top fixes for me would be:

* Make it easier to fire incompetent people. A job that's in the service of the people should not be a cozy "I'm now set for life" type of gig.

* Pay semi-market rates.

* Stop going for the lowest bidder for contractors.

Why semi market rates? The whole problem is politicians win elections by promising low taxes and less spending, so the government pays less, and to offset the lower pay, they compensate by not firing people. Inevitably, this will attract an undesirable amount of people who want to coast, with no ability to get rid of them.

> Inevitably, this will attract an undesirable amount of people who want to coast, with no ability to get rid of them.

Yes, my point exactly. I think it's cheaper to pay people a reasonable salary and less job security. Otherwise it just ends up being a lot of dead weight throughout the organization. This dead weight leads to low productivity, which in turn e.g. leads the management to bring on expensive consultants to try and fix it.

My point was that you need to pay market rates, not semi market rates for that. The trade off of compensation for job security should not be occurring.

Aha, sure. My intention with "semi" was to indicate that it would still not be anywhere near FAANG-levels; but rather closer to a median "good" salary.

If it needs to be FAANG level to attract the workers you need, then it needs to be FAANG level. I do not see why there would be any arbitrary limit.

I remember when healthcare.gov was launched and the clusterfuck it was, and then a much of FAANG level employees had to quickly go and clean it up as charity.

Low wages make for more bribeable employees

Same reasons judges are paid a lot

US municipal is plagued by:

Private sector unions (making them impossible to fire)

Nepotism

Layers and layers of bureaucracy

That's not something unique to the US, I saw the exact same thing across the pond.

The single largest employer in North America, responsible for untold millions of jobs both direct-federal and government contracting, and you pegged the culture, nationwide, inter-agency, on day one. Pretty amazing insight from not much data. Perhaps you'd like to generalize in a more targeted manner?

Reply on news.ycombinator.com