I can't give a comprehensive answer as to how we hire, but I can offer my personal experience: I was able to finish my last year of part-time law school when I started at 18F. I was working full time, and everyone was very respectful about having a life outside of work.
In the shorter term, do check out https://micropurchase.18f.gov. It's where we post very short term contract opportunities ($3,500 or less, and tasks typically take up to a week). I also happen to be a dev on this project, so feel free to reach out here or at micropurchase@gsa.gov if you have any questions.
18F is hardly the only group within government using OSS to build websites. Also hardly the first (CFPB was at it before 18F existed), I'm sure there are more way before CFPB.
According to https://www.govcode.org/repos, there are about 1,300 U.S. government repos on GitHub that do not belong to 18F.
I can't say that I have experience building government websites. The focus of my previous role was to field and support the POR (Program of Record) systems under MARCORSYSCOM Combat Camera.
Establishing an ATO for end user systems, specifically hardware/software that is intended to connect to the military tactical networks comes with a very high barrier of entry.
Being an OCCFLD made up of media specialists (ie photographers, videographers, illustrators, reproduction specialists); they have requirements for hardware/software that fall outside the generalized platform/support provided by G-6.
Overwhelmingly, they prefer Apple/OSX but building Apple-based systems that support the wide range of security scanning, observation, and auditing requirements simply isn't possible. AFAIK, nobody has established a baseline for Darwin and the cost/risk to do so within the schedule of the systems lifecycle is too high. As a result, Windows is only option.
The systems I supported directly included laptops running a custom configuration (ie Adobe, etc) as well as tactical deployable media production studios that provide print, media, large format, networking, and archival capabilities in the field. At one point we added VLC (ie due to it's superior playback format support) but had to nix it after discovering that it had a CAT I CVE.
Things may be different outside the DOD but for the USMC specifically, MITSC are the 'gatekeepers' for the Marine Corps when it comes to establishing an ATO baseline and meeting the requirements for ATC (Authority to Connect) to the MCEN-N (ie unclassified tactical network). Frequent scans, remote access, and auditing aren't recommendations so much as an absolute baseline requirement. Don't get me wrong, they do their job very well.
When it comes to fielding COTS systems, lifecycle sustainment is a huge problem. Depending on Windows based systems and Dell Enterprise networking hardware makes the problem much worse. Unfortunately, that's what everything is standardized on and systems that can't be bought with a long-term support contract are no-go. Diverging from the standard is a recipe for failure.
I didn't deal with the ATO process directly. Instead, I provided field support, user feedback, and maintenance of the systems.
I established a distribution channels and did my best to provide periodic updates to all the systems within my AOR to meet the requirements of the ATO/ATC. I even spent months trying to hack the bureaucracy -- with little success -- to get the systems connected and operating at their full capacity.
Throughout that process I discovered numerous missing prerequisites buried among a morass of policy and documentation. I'm no stranger to reading dull/dry specifications but the literature surrounding ATOs and their application is a minefield. One misstep can lead to the loss of certification so it's wise to be cautious.
I tried to raise the issue with my superiors but as the saying goes, 'shit flows downhill'. It's not really their fault, they don't know what they don't know. I've learned not to take it personally, life of a contractor in the field is one where you'll inevitably (and hopefully infrequently) accept fault for failures beyond your control.
What really bothers me is that the Marines have to go forward with limited/degrading technical capabilities and little/no support. No amount of effort, willpower, or policy will solve significant technical problems that require technical solutions.
-----
Just to be clear, the following isn't specific to COMCAM. If anything the leadership I had the privilege to work with made an exceptional effort to always do things the right way, despite some of the ridiculous barriers we had to face. This is based on a wider perspective gained from working with many organizations across many military installations.
The DOD doesn't suffer from technical debt so much as technical poverty. Any benefit I had from being good with technology going in became a weakness. The military is a black hole of communication and information sharing. Don't get me wrong, it was an amazing opportunity to 'level up' my people skills but seriously...
I often see people complain about rampant waste and the lack of transparency in government and the DOD specifically. I can honestly say from first hand experience, it doesn't come from lazy or malicious behavior. When limited time/resources restrict decision making to a gray area between doing things the 'right way' and accomplishing the mission, it's the duty and responsibility of our service members to choose the latter. Waste and opaque behavior is a symptom of systematic failure (ex lack of knowledge, communication, unnecessary bureaucratic barriers, etc) at a much grander scale.
I probably have a unique perspective. I went in with no prior military background and a strong technical background. The former makes it very difficult to accept 'broken' as norm, the latter provides a unique perspective of what can be done to fix it.
-----
I'm a huge proponent for OSS, having contributed and/or authored many projects. From what I've seen, breaking new ground and introducing OSS to the DOD on a larger scale is currently beyond reach.
There are pockets of exceptionally talented/capable individuals with the technical background required to make it possible. Except, they represent an extreme minority and are already over-taxed with supporting the existing systems. I'll spare you a the diatribe on why the alternatives consistently come up short.
I have read all of the literature 18F has to offer (except a few blog posts). 18F sets a very good example for others to follow. Unfortunately, the platform is limited to internal use and the organization's capabilities are limited to serving the latest 'hot button' issues within the DC political spectrum.
Much like SV represents an extreme monoculture fueled by exceptional technical ability and a flood of VC funding. DC represents its own extreme monoculture fueled by the concentration of power/influence and a flood of taxpayer funding.
Beyond the bubble the state of things is much messier, broken, and in need of help.
It's been pretty well established that needlessly (male) gendered language makes people feel excluded. Actually, that's too nice. That kind of language excludes people. Period.
It communicates that the speaker does not contemplate a non-male audience. I do not know about the communities that you moderate, but constantly assuming a male audience at a place like 18F is wrong factually and is disrespectful.
I've triggered the slackbot by using "guys" many times and I've never felt that this was aggressive in any way. It's usually a chuckle-worthy experience for all involved. And that's why I love the bot. I do understand concerns over "policing" language. No one wants to feel pestered into writing/talking in a way that feels unnatural to them. However, instincts should not be above criticism. And a silly bot[0] is a great way to gently, politely, and humorously help people unlearn behavior that excludes.
[0] We have other silly bots, too. The one we probably love to hate the most is angrytock (https://github.com/18f/angrytock), which will remind us to submit our time cards (using our open source time tracker, Tock. https://github.com/18f/tock).
This is turning into a debate, so let me apologize; it was meant as a one-off comment on how silly and counterproductive it is (imv) to write a bot for such things.
If this bot isn't actually negatively affecting anybody, more power to you. I certainly won't be the one to tell you what you can and can't do within your company.
Putting myself in those shoes, I would personally find it incredibly rude, and I highly doubt I'm in the minority holding that view, which means in my mind it's highly likely that other people at your company hold the same view (loudly or silently), which will contribute to making communications worse.
Putting passive-aggressiveness aside (which is a real problem)... I never contemplate "male-only" audiences, regardless of what I say. A somewhat-recent example: I've had some insecure guy come up to me being offended at my usage of "us gamers", as if saying "gamers" somehow excluded women.
There is something that really bothers me in such cases: The person is assuming ill-intent on behalf of the speaker. To me, it is extremely discriminatory to assume I don't include women when I speak. Why wouldn't I include them? Because they're women? Isn't that exactly the type of backwards thinking feminists are against?
shrugs I better just stop here. Whenever political correctness gets brought up, people on here seem to forget all logic and act completely irrationally - feminism really is the "for the children!" of the tech sector. I see even your post got downvoted for whatever reason; I brought it back up...
> The person is assuming ill-intent on behalf of the speaker.
This is where these kinds of issues typically go off the rails. With male-gendered language as the default, I doubt very many people intend to do anything wrong. It's how I learned to speak and I'm sure it's how many others did, too.
A silly nudge from a Slack bot, is just that--not an accusation or a judgment of character.
I was thinking about this a bit more last night, and I thought of another reason why the bot is great: it doesn't discriminate. It doesn't matter if you are in leadership at 18F, a guest user in our Slack, an employee who started two weeks ago, male, female, or something else. The bot doesn't care.
There's a bit of politics to how people get "called out"--e.g. who wants to pull the boss aside and correct their behavior? The end result is likely to be that certain employees get corrected and other employees don't. A bot avoids all of this.
I've been thinking about it a lot and there's something seriously off in this "prevention-based" approach to political correctness.
People can get offended at all sorts of things. Maybe some girls will be offended at people saying "guys" gender-neutrally. A lot of women won't.
Are you going to write bots to prevent all possible verbal offences? What if some of those bots offend people themselves, what do you do then?
I find it interesting you mention the nondiscriminatory aspect of a bot as a feature. To me it's one of the most disturbing parts, and it's what creates the "passive aggressiveness" I was talking about. If you have a problem with the way I say something, you can be upfront about it with me and I'll change my behaviour. Writing a bot for it is quite a backhanded way of getting me to do something, with less chances of succeeding (and if anything, more chances of continuing out of spite).
Like I said though, all this is personal take. Maybe everybody at your company is fine with this. However, I did show this little post around and got a near-unanimous reaction similar to mine, which reinforces what I thought before: It is highly likely there's people at your company who think this is far more than "a silly nudge", and the bot would then have a completely counter-productive effect to its original intent.
My objection isn't to the cuteness of the bot - it's to the waste of taxpayer's money. Could you really look an elderly taxpayer in the eye and tell them that building slackbots with their bottom dollar is a great idea without feeling a tinge of guilt?
Employees who are happy and feel included are going to produce better work (and a better return on the invested tax dollar) than those who aren't. I'd also expect second-order benefits such as helping us recruit from a wider, more diverse pool of applicants.
Of course there are boundaries to the happiness-increases-productivity dynamic, but quickly coding up a Slack bot seems well within the safe range.
Tech is pretty insular, isn't it. Like how your site uses "gov", a top level domain for the whole WWW restricted to be used by government-specific entities in the UNITED STATES (of America)[1]. Moreover, "The U.S. is the only country that has a government-specific top-level domain in addition to its country-code top-level domain." (Wikipedia)
[1] The point isn't that other governmental entities should be able to use "gov", though. Since English is not a universal language.
This is really neat! For work, I've found myself from time to time exploring the tech around PDFs. I find this tech strangely fascinating. It's like a shim on top of something old and ugly that enables integration with much more modern systems.
Some quick feedback (and a shameless plug):
The CLI interface should output JSON. It would be nice to combin with a CLI JSON parser such as jq[0].
Shameless plug: I've been working on a PDF CLI aimed at making it easier to programmatically fill out PDF forms: https://github.com/adelevie/pdfq. It provides an interface and some wrappers on top of the main pdf form-filling tool, pdftk. For example, you can get json out of a pdf form like this:
pdftk hello.pdf dump_data_fields | pdfq
Or you can generate FDF from a json file:
cat hello.json | pdfq json_to_fdf
You can also fill a pdf without touching an fdf code:
PDF is less proprietary than most people think. It is an ISO standard after all and it is a bit complicated but it does solve the problem of making "printable" documents produced by all sorts of tools available online.
In the shorter term, do check out https://micropurchase.18f.gov. It's where we post very short term contract opportunities ($3,500 or less, and tasks typically take up to a week). I also happen to be a dev on this project, so feel free to reach out here or at micropurchase@gsa.gov if you have any questions.