https://federalnewsnetwork.com/pay/2020/01/more-top-career-e...
>But for a GS-15, step 10 in Washington, his or her salary should total roughly $185,509 in 2020. But due to the federal pay ceiling, that same GS-15, step 10 in Washington will make the limit of $170,800 this year.
And that's the absolute Max, after you go to the trouble of getting a security clearance, which you just don't need in the private sector.
Even government contracting involves so much red tape, more innovative engineers would probably just rather not do it.
They don't need industry-leading researchers, they need people who can build a maintainable business systems.
It's infinitely easier to make on 170k happen in the private sector, then as a federal employee. Unless the government wants to create like a special ops tech department which doesn't use the government pay grades, more money can be made in the private sector.
I'm only mid-career or so and I'm already at around 200. But I don't, at least on paper have the qualifications to architect out a whole system. And while we all want to act like we could whip up this entire thing with VueJs in a weekend, pretty sure there's some God forsaken legacy system it needs to hook into.
Since most engineers don't want to work with legacy systems for less than market pay, the engineers who end up working on this stuff tend to not be all that great.
That seems like a much better solution rather than rolling your own.
For example, I'd rate access to Blue Cross Blue Shield Federal Employee Program health insurance for you + spouse for life and kids through 26 as worth 2-3k per month, and invaluable if you or a dependent has a serious health condition.
Can you imagine how much better it would feel to work on important and needed systems than working on the 100th food delivery app or yet another social media facism incubator?
I work for Ad Hoc (one of these companies) on software projects at the VA, and I'm happy to chat with anyone who's interested to hear more about this kind of work. I left a cushy Google job to work on important and needed systems, and it does feel so much better!
One weird thing we've discovered working on VA.gov for the last five years is that we on the contractor side actually have retained a lot more institutional knowledge than the VA has. It's a problem! We think that knowledge should be on the government side, but the structure isn't there yet: USDS and 18F have rotational term limits that keep people moving through, and at the VA (not sure about other agencies) they're just in the last couple years building out an organization to do that long-term product ownership and institutional knowledge retention, even if implementation teams come through. It's moving in the right direction but it's slow, large-organization change, with a lot of extra slowness that's unique to government.
The top 2-5 layers of management tend to be the types who want solutions, and they don't care how it works, and they don't really want to be bothered with the details.
To the extent they expend thought at all on systems, they tend to be focused primarily on questions like, "why is all this stuff so confusing?" "who do I blame when this thing goes wrong?"
Where I work, they go through cycles; a higher-up will say "Hey let's build a staff of in-house developers." And they'll do that for 2 or 3 years, until someone reads an article in CIO magazine about how outsourcing is superior. Then they'll start unfairly purging and firing developers, writing code is now "bad", configuration is "Good." This goes on for several years, until the cycle starts over. So as a developer, after you survive your first purge, you begin to see that invisibility is the only way to survive.
It is difficult to explain but people tend to use the word "bureaucracy" as a catch-all for several dozen discrete problems that crop up in different combinations depending on what level of govt you're operating.
Typical examples might be :
-a developer not having the authority to work on a system
-a developer being ordered to work on a system, but not being given permissions to the necessary tools (even if they're available), or they may prohibit certain common-sense tools, or they may force you to use certain tools.
-a developer being ordered to work on a system where the design is severely irrational, maybe impossible, and but he or she has no authority within the hierarchy to push back on requirements
-a developer being ordered to work on a system that some powerful person wants to see fail
Imagine the "client from hell" that many of us have dealt with before, who doesn't know what they want. Now imagine that person is like 3 levels higher than you, calling the shots, and you're not even allowed to speak to them, much less push back against their crazy expectations.
TBH, I'm surprised we've never seen a proposal of the form "Federal employee salaries are not subject to income tax."
With a single line of legislation, that makes all federal job offers immediately 10-35% more competitive, without actually increasing salaries directly.
Once you get that as precedent, I could see it being used aggressively as a social tool: "We can't pay a public school teacher more than 60k, but we can pay them 60k tax-free, which is a little more competitive with a 75k private-sector position", for example.
Approximately 50% of American politicians are anti-government as an ideology, and use the argument of "cutting overpaid government salaries" as a plank in their economic policy, so having well-paid gov't staff is just "waste" in their minds.
As far as teachers go, they are not employed by the federal government. In most states they are county-level employees and the counties obviously do not have authority to dictate federal income tax levels.
It is already outrageous that government employees are exempt from social security taxes.
>In 2018, one-quarter of state and local government employees—approximately 6.5 million workers—were not covered by Social Security on their current job
I find this offensive because one of the main functions of SS is to subsidize the retirement of low earners at the expense of higher earners. As a private citizen, I don't get to opt out of this social obligation just because my 401k gets a better return.
Not only that, but as a tax payer, I will be on the hook for bailing out the public employee pension funds when they go belly up.
I came from a country where government tries to do all these things in house. It was bad. Paying premium isn't a big problem.
I work at one of the contractors in the space (Ad Hoc [1]) and get to work with people from USDS every day. Like others have commented here, the government salary ranges are a problem for them to hire enough. Our last COO had been an administrator at OPM, and would say things like "on the government side, I couldn't ever hire the kinds of software developers that we're able to here on the contractor side."
[1] https://adhoc.team/ -- we're hiring, full-time remote!
How much does it cost to get a qualified person to put up with all that though?
Now, you don't always have a choice, the expertise is sometimes there, or you need one of the big four to do a prior audit before a real audit from another big four. But be prepared to have a team of OK people who will spend a lot of time producing slides and organize unproductive meetings with lots of other people (including yours) to give out a false sense of "we're making progress here". You'll have to do the PM'ing and be extremely strict with what you want from them, and you'll have to be ready to collaborate heavily. What I mean by this is: don't wait for them to ask questions, you'll have to do most of the work of onboarding them, almost like they're your coworker except that they don't have connections with the folks they need to work with, they don't have access to internal stuff, they don't know how to get there.
There, they put you through a six week course in which you become a developer, and you’re then hired out for £800 a day as a technical expert.
Source: literally half the people I went to university with.
Fond memories of sitting at the kitchen table and trying to coach my flat mate through unfucking the air ground traffic control system that they were writing for BAA in VB5, in 2005. No idea if it ever went into production.
"There was no requirement that the whole thing should work. We can put in a change request and bill separately".
Also - the "no one has ever been fired for hiring IBM" syndrome among the higher management.
How was the code obfuscated?
That brings back memories of php obfuscator. What a strange world that was. I think there was even a deobfuscator that tried to rename the variables sensibly, or something.
At Scottrade, I was horrified to find a 5k or 10k line Date C++ class. They'd copy paste functions to handle each leap year individually. The function names themselves contained the specific year.
They also yelled at me for downloading the source code to `touch`.
It was nice to get to see the crazy side of software. Everyone was deadpan serious about it too.
That would result in a bug report. The bug report was that Joe Blow saw that outcome. In other words, the bug report didn't contain anything about the code itself.
They had an entire division of support people whose job was to track these bugs, and to fix them.
In order to fix the bug, they would manually edit the database, or do whatever was necessary to make sure Joe Blow saw the right value again. But they never changed the code; they weren't programmers.
Once Joe Blow was happy, they closed the bug report as "fixed."
Therefore, no tests were ever required.
It was ... impressive? I think? I couldn't mentally process what I was seeing at the time. But "impressive" is probably the right word. After all, the system worked.
But ... that logic doesn't work if you chase down the implications. And sadly I was both too shocked and too young to press my coworker for details. (He was a cool older fellow who seemed as amused with the craziness.)
Eventually I became a pentester at Matasano. During my one-year stint, I was parachuted into around 70 codebases. I got to see first-hand that Scottrade wasn't an outlier; they were the average. Most companies have similar WTFs, and the codebases are just as onerous.
The world is held together with duct-tape. That's why pentesting is so crucial.
> thinking about the customer, understanding the right technologies, designing for scale, etc.
If they were asked to design something for a customer then they're fulfilling what is asked - e.g., the bare minimum.
And this is how we get the 737 Max.
The point is the ask for the 737 Max wasn't a "plane that doesn't work." It was for a plane that does work. That was the deliverable. It wasn't met. That is not doing the bare minimum.
You could also apply this weaselly BS to Boeing. Their "ask", if there was one, was to make a plane that customers would buy and that would pass FAA review. Not "a plane that works".
No one's contract just says "make an X that works", even though that's what everyone wants. Because an X that works is hard to define. Fundamentally the system depends on honor and trust. Which is why we despise losers that just try to get paid and fuck the customer.
This isn't rocket science. Think.
If the CDC signed off on it, it isn't deloitte's fault. Sorry.
All you SV elitists do it, you just want to hoard the wealth for yourselves. It's not just deloitte, all the SVs do the same damn thing.
A good internal developer will notice that requirements are missing, or could be improved, and has the incentive to bring it up with the project manager and get it fixed.
That incentive does not necessarily exist for a consultancy developer, because as you say that means their employer loses money.
My conclusion: Use consultans for very well defined and testable problems that don’t require too much business-specific domain knowledge.
The car shop spends months of your time obsessing about the dimensions of the spoiler. Then the car is out of service for as much time and you start wondering what they have been doing.
Then the car arrives and there is a bunch of paint missing around the spoiler, the spoiler is completely unpainted an it falls off when you accelerate to 100mph.
So you ask, "WTF?" and they tell you that none of these things were specified in the contract.
That's more or less how it worked.
I have been contracted for a number of projects and I always assume some level of standard that my client would want me to meet.
For example, around 2003 I have been contracted by a publishing house to restore couple of their servers. Their employees made a mess they were not able to get out of, completely mangled Linux distributions, took out drives out of RAID5 and did not know what to do with them, etc. Drives had files with only copies of texts of books they had so it was extremely valuable to them.
So obviously I did what ANY sane person would do:
- I have discussed with responsible employees what exactly happened,
- We went out on a little trip to buy backup drives
- We made backups of every single drive involved in the mess (I keep saying we because I involved the guys in the recovery so they know how it works)
- We put together the drives and they worked
- We fixed OS-es which they mangled
- We tested that everything works
- We have discussed why they need some procedures and especially backup procedures
- I have showed them how to construct couple of these procedures so that they know how to do that.
I didn't have to do all that. I was already being paid handsomely for the recovery and would not suffer (other than lost pay) if I failed recovery. But I also recognize how important this data was for the company and so I took necessary precautions proportional to how important this.
If spoiler work fails instantly you can say it wasn't done properly, which is true. You then withhold payment, or sue.
Not that complicated. Not worth a damn novel post from you either.