A team at Veterans Affairs is my customer. They have been tasked to integrate with some AWS hosted intranet system. Other than points of integration, we know very little about it. This article seems to be a big clue.
How a 20-year-old kernel feature helped USDS improve VA’s network
61–66 of 66 posts
Re: How a 20-year-old kernel feature helped USDS improve VA’s network
#62The Jiffies root cause leads to an interesting idea: an Glossary of Magic Constants where all kinds of important constants, limits, and overflows are tracked to aid in debugging. You could imagine a search engine where "tcp connection drops after 5 minutes" lists every piece of software and firmware with 5 minute and 300 second constants.
So OEIS for programming? Largely seems covered by Google: punch in an oddly specific number and someone will probably have discussed it on Stack Exchange.
Re: How a 20-year-old kernel feature helped USDS improve VA’s network
#63Earlier quoted context omitted.
I think that startup mentality might bite them in the arse. I saw "React on Ruby" and winced. There is nothing wrong with that platform as a "We are in a market where things will change radically in two years" but for the VA? Where things might change once a decade, that's a recipe for pain. Look at where the Web was 5 years ago (hell React didn't exist) never mind 10. Angular is 7 years old, KnockoutJS is 7, jQuery…
I think that much of the reason for the existence of USDS is that government agencies like the VA should not be stuck with 10-year-old [1] technology. The idea is that U.S. citizens should be able to expect the same level of technology from their government that they get from Facebook, Twitter, Apple, or Google. They're explicitly trying to change the culture where you do things once for hundreds of millions of dolla…
Those kinds of inefficiencies are /everywhere/ in government. They tend to mirror the limited ways departments communicate (see: Conway's Law). Having structured data available isn't a given, nor is the ability to send it across networks that often predate the internet.
I remember an incident where a critical feature went down for days because a backhoe severed the only available link between two agencies. It's hard to overstate how unusual it is by government standards to operate the way modern startups do-- e.g., put everything in the cloud and let Amazon handle your availability problems.
Re: How a 20-year-old kernel feature helped USDS improve VA’s network
#64Earlier quoted context omitted.
Hmm.... I apply every 6 months or so and get the thumbs down. Not sure what they're looking for. I've got 30 years of every kind of experience (dev, DBA, network, security, product mgmt, analytics/data science, business mgmt, and more) with good credentials and they never bite. I wish I knew more what the ideal profile was; I'd love to help out!
I wonder if the environment of experience is significant? USDS positions itself like a startup (even their page has a section on "dress code" which mentions being like "any other startup"). Someone whose experience is primarily enterprise or BigCo might be less appealing. It would be interesting to see a roster of current USDS FTEs and their backgrounds (I didn't see a "Who's Who" on their page, but didn't look exten…
Hey, I'm the current director of engineering, so I'll toss in my 2 cents because I want to make sure this is really, really clear.
I could not care less about what which company/non-profit/agency/whatever you worked for. I just care about what you have stepped up and done in that environment. We will gladly consider a BigCo person, as long as they can demonstrate how they managed to get awesome stuff done at BigCo (e.g. ported a legacy system to a modern stack) because that is relevant to what we do. We have also passed on folks from FancyStartup.com because they show signs that they would struggle in an environment this complex.
Fundamentally, who we look for are people who can go into just about any situation and figure out a reasonable way to deal with it so that we can get services working for the people who need them. And we look for this in our designers, engineers, talent team, procurement specialists, and product and strat ops folks. See mbellotti's comment for great info on some engineering-specific tips.
The Federal government is a giant bureaucracy. I would actually love to see more BigCo applicants with experience succeeding in tough environments because that's what we do here. We need a good balance of people who know how to deal with things the way they are and people who know how to build things the way they should be. The best candidates are folks who can do both. We make the best decisions we can based on resumes and interviews, and it sucks when we may miss out on a super swell person. But it's bound to happen sometimes.
To be clear: I don't care how old you are, what company you worked for, what part of the country you're from, what school you went to (or if you didn't go to school at all), or any other artificial criteria. In fact, I'm really not interested in hiring the same profile over and over again. That's ineffective and honestly, boring. All I care about is finding people who demonstrate that they can creatively and scrappily solve the types of problems we tend to see in the types of environments/situations in which we tend to land. Period.
So if any of this sounds like you, consider applying. This country and it's citizens could really use your help. And make sure your resume shows us that this sounds like you. :)
Re: How a 20-year-old kernel feature helped USDS improve VA’s network
#65I really hope USDS can help introduce interdepartmental digital transfers within the federal government. To give an example of how frustrating it can be... I went through the visa -> green card -> citizenship process. No two departments talk to one another, and when they do they seemingly transmit information on paper which is then transcribed by hand introducing errors/typos. For example USCIS does not talk to the S…
> Why doesn't the federal government just have a big database?
Because that tends to end very badly. I've been in Fed MIS systems since I joined the USAF in 1981, and it's the same just about everywhere except for a few of the research labs.
Remember the OPM data breach, where the background check info for over 20 million people went walkabout? I was one of the lucky winners, and it's a result of the management-by-spreadsheet mentality that's everywhere in the government. On paper, they were fine. In actual fact, not so much.
If the security checklist says "you must have an audit system in place", and you have the system installed and running, you pass. Nothing is said about ever looking through the logs for atypical behavior that might indicate a breach.
You want to buy new software? If it's not Oracle or Microsoft, good luck. If there's not a contractual vehicle in place to use for the purchase, forget it. Whether or not the software is fit for purpose has no bearing on the matter.
Re: How a 20-year-old kernel feature helped USDS improve VA’s network
#66Earlier quoted context omitted.
Hmm.... I apply every 6 months or so and get the thumbs down. Not sure what they're looking for. I've got 30 years of every kind of experience (dev, DBA, network, security, product mgmt, analytics/data science, business mgmt, and more) with good credentials and they never bite. I wish I knew more what the ideal profile was; I'd love to help out!
"over qualified" a.k.a too old and will want a competitive salary.
[deleted]