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.
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
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.
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.
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.
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.
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.
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?
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.