> Please provide your salary requirements or range.
I feel frustrated when I see that you haven't listed a salary range for your open positions, yet expect applicants to provide this information. I think it puts prospective employees at a disadvantage. Also it can waste applicants' time if you'll never pay as much as they need or expect.
I think your mission is valuable. I want public services to serve the public well. I hope you consider being more open about potential salary ranges because people like me would feel more comfortable applying.
I will say its a good place/company for starting your dev/design/tech career.
Employers can't ask candidates their salary history, but they can definitely ask the candidate for salary expectations.
[1] CA Labor Code Section 432.3 (c) An employer, upon reasonable request, shall provide the pay scale for a position to an applicant applying for employment. For purposes of this section, “pay scale” means a salary or hourly wage range. For purposes of this section “reasonable request” means a request made after an applicant has completed an initial interview with the employer.
The reality is many people aren’t at the liberty of strictly choosing employers; and labor laws help raise pay for everyone at the detriment of corporations and investors b
Personally I do not even bother looking at a job unless there is a salary/day rate stated.
Or you could just apply and say "1 Billion dollars".
Permanent roles don't state salary. Exception being a few companies like government that have a fixed band (way below market).
It's not just US that fails with these kind of projects. In Sweden we have seen many expensive government IT infrastructure projects that effectively flush tax money down the drain. The users find them horrible to work with and they are riddled with security issues.
As a developer in Sweden I feel very frustrated about this. If I knew of a similar company in Sweden I would seriously consider joining it.
It could be done so much better. But how did you do it?
Edit: And I'm thinking not so much about the technology part of the problem but everything else, since finding competent developers that can solve the problem once you have a clear direction and decent financing seems like the easier part?
Edit 2: It feels like one of those things that could make a really eye opening documentary given the right direction.
Good IT firms are busy working on free-market projects where they have to deal with 10% of the bureaucracy. It's not worth competing against established players who know how to play the government contractor game much better than you, especially if bidding rules may force the government to pick a contractor that they know will deliver a subpar product because it's cheaper/because their bid is written by someone who knows exactly how to write them.
I suspect that if you want to compete in the market, you need to have a "bureaucracy" team that's at least as big, if not significantly bigger than, your actual software development team. Even in an ideal market that's going to drive prices up.
Edit: It seems like in this case, this quagmire was avoided by having the government build a skilled team in-house, avoiding all the overhead of an army of government bureaucrats interfacing with an army of contractor bureaucrats (which is necessary due to the processes that ensure fair contract awards).
Oh, this has been my feeling of how to solve the issue as well. Government in-house projects seems to have better quality overall in Sweden too.
Open-sourcing hasn't cultivated much in the way of public engagement with the projects, but it's done a lot in terms of making development easier for the range of contractors + VA employees we have, and (IMO) nudged toward better decision-making with the underlying knowledge that everything we do is publicly viewable.
Other federal agencies routinely come to VA asking to learn from their digital modernization efforts, and I suspect the open-source stance has been a big part of that.
(I also work at Ad Hoc. It's great!)
[1] https://department-of-veterans-affairs.github.io/va.gov-team..., repository links at the bottom
However, despite being a critical, successful piece of open source software that had massive investment over decades, it's being abandoned for a commercial system, Cerner, in a $16bn project.
https://ehrintelligence.com/news/va-cerner-implementation-co...
In my opinion none of them were capable of designing a user facing application. It was also built as a client/server desktop application. Not really a good choice in my opinion. Sure there were no offline PWA at the time, but by contrast if your SAP backend dies all the local applications in a hospital e.g. writing the release report also dies.
Needless to say given it's immense complexity it was also impossible to use this monstrosity elsewhere.
But replacing it with Cerner in a $16bn project is just sad.
It was a truly open source project within the VA with programmers customizing this national patient record software in cooperation with doctors (to meet their needs) locally and sharing the modifications nationally. Perhaps its greatest technical challenge (besides complexity arising from decades of evolution) was finding programmers to work with the MUMPS language that it was written in. FYI MUMPS is a language with an integral db -a concept which was out of vogue for some time.
Political challenges are another story[4].
[1] https://sourceforge.net/projects/worldvista/ [2] https://www.hardhats.org/history/hardhats.html [3] https://worldvista.org/AboutVistA [4] https://www.politico.com/agenda/story/2017/03/vista-computer...
Why Cerner? I don't know.
> Open-sourcing hasn't cultivated much in the way of public engagement with the projects, but it's done a lot in terms of making development easier for the range of contractors + VA employees we have, and (IMO) nudged toward better decision-making with the underlying knowledge that everything we do is publicly viewable.
To gunsch v.
* Frontend - https://github.com/department-of-veterans-affairs/vets-websi...
* Backend - https://github.com/department-of-veterans-affairs/va.gov-cms...
Paul's company is working on this project too (whom I work alongside with but with a different company)!
The U.S. Digital Service is really a big factor in this, see the playbook, specifically play 13:
> If the codebase has not been released under an open source license, explain why.
source: https://playbook.cio.gov/#play13.
So, see how this is now flipped. It is now "hey, you need to open source this by default, and if not, you need to explain why you didn't." and not the other way around!
Update: See Andrew Gunsch's comment in this thread too!
A better approach might be to just budget for and pay a team of good developers a market wage to make it better.
So paid developers work on, but the end result is publically avaliable.
“At the time of the Heartbleed attack, the OpenSSL website listed just 15 active developers, most of whom contributed to the project on a volunteer basis. But not all changes to the OpenSSL software are written by these 15 people. Rather, these developers help to filter and organize suggested changes from a larger community of people who make occasional contributions.”
https://www.vox.com/2014/6/19/18076318/heartbleed
If you want the government to have more competitive Federal salaries for developers then write your Senators.
As a note, I’ve seen some truly awful software written by highly paid devs, so, just paying more won’t necessarily fix the problem.
High pay is necessary, but not sufficient.
With high pay, you MAY get a good product — if you attract competent people on all levels.
With low pay, the mind-numbing godawfulness of the end result, if it's ever delivered, is practically guaranteed.
[ EDIT ] And, contra to your apparent contrasting of "open source" and "paid developers", gov.uk is both.
In this case it's the government which technically doesn't have to actually make money (budgets, tho), but it can work in non-governmental situations too. Maybe via consulting/support on the technology, grants/donations (OpenSSL, now), maybe just making it open to foster contributions and long-term maintenance[0]. Maybe the actual software isn't the company's main focus and open-sourcing the code is just a way of ensuring accountability and quality. IME, people are actually far more conscientious when they know they code/docs could be read by anyone for all time... even if it probably won't.
[0] I'll grant that this is probably quite rare. That's not the point... the point is that there are many potential reasons for open-sourcing.
https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/Resources
And how about well supported? How resilient is the technology going to be in 15 years and how easy will it be to find developers? How much are those resources going to cost versus say .NET, PHP, Java, etc.?
Compare that to other languages (from the top of my head, don't pin me down on details or inaccuracies please):
- Java: Added generics, annotations, lambda expressions and streams, new date/time libraries, modules, switch expressions and multiline strings.
- PHP: Added classes, types, null coalescing operator, etc
- Javascript: Classes, ES6 features (arrow functions), imports, and offshoots like Flow, Typescript.
- Obj-C / Swift; ARC, Swift itself (4 versions), I haven't been up to date with this much.
TL;DR, most languages really shift over time, often 'borrowing' features from other languages, but Go resists these changes because it's intended to still be read and compile in ten, twenty years' time.
Personally, I'm working on a management interface for a network application; the existing UI has been around since 2012, I'm trying to build this to last at least as long, probably longer, and I think Go is a great choice for it. The old application was built in PHP 5.2, which is vastly outdated now (and updating is challenging because on the one hand, the versions of RHEL used in production don't supply newer packages, and on the other there's 65K lines of badly written PHP that would likely need to be updated).
Conversely, the new Go back-end is standalone and self-contained, I try and maintain the habit of updating the Go version and all dependencies monthly; so far I've never had to make any code changes or had to rethink my architecture because of Go adding a new (architectural) feature. (I probably have the benefit that it started after `context` and the module system were in place though). I feel a lot more confident in its future proof-ness. And I feel confident that anyone looking at the code can maintain it, although that said I'm cautious about the more magic parts like GORM, which I should probably swap out with lower-level SQL at some point but I don't really want to.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
That is already pretty fast, and I guess the difference in practical scenarios would be even smaller since external systems like DB's won't change their speed if you call them with another programming language and because production code is not always as optimized as benchmark code.
Also, the ecosystem is very young so you don't know which libraries will still be around in 3 or 5 years. You might find yourself reworking large parts of the code for betting on the wrong horse.
I've also found that most libraries in go hold up well over time. In fact, I just recently needed to write a go program that could use some code i wrote many years ago and haven't touched in nearly as many years which used a few external libraries. I literally copy and pasted my old code into my new project and it just worked.
This is precisely my concern. It's all good and well that we have these "Google level engineers" taking over government projects. But when the boredom runs out (or they go back to the private sector), who takes over?
I suspect the first people who wrote gov't applications in COBOL felt the same way...and you know how that story ends.
That said, we should perhaps not have Google engineers live the meme of bringing their flavor of complexity everywhere they go, but I feel that having permanent FTE positions within government agencies specifically for bolstering up the competency and cost-effectiveness of information technology projects is overall a good thing.
My suspicion is that the majority of the projects that agencies like the GSA undertake (through its TTS arm, of which 18F is a constituent part) are ho-hum boring business IT projects, where most of the complexity comes not from the technology itself but from having to deal with getting a handle on the meandering specifications laid down by stakeholders (read: the plebiscite via representation in Congress).
I further suspect that the engineers that are recruited by 18F and the USDS tend not to go into the weeds on immediately building out, e.g., systems like Chubby and Stubby and D/GFS and Bigtable for the sake of it but rather tend to focus on trying to solve the problem at hand. I feel that the requirement to submit timesheets (and, hence, justify time spent) every week tempers that "every problem is tempting" feeling. Anecdotally, it did for me when I worked at a similar three-letter organization, albeit in the private sector, for the better part of half a decade.
Go is an entirely different beast. The language, libraries and whole community is really worshipping simplicity in a way Java never did.
Just look around a bit at the standard library. There are pretty much no setters and getters. No inheritance hierarchy to speak of. Not even constructors most of the time.
It is not without reason that Go angers a lot of people that think they know how to do software. It breaks all the rules they have kept sacred, that they think all “real” programmers should follow.
Think about it this way. If Java is SLS assembled in a clean room never getting done, then Go is more like SpaceX assembling a rocket in open space with guy who normally weld water towers. It isn’t how it is supposed to be done but it works and they get shit done 20x faster.
Isn't that because it's essentially "new"?
Java, on the other hand--at least when you control for the confusion around whether "Java" referred to the JVM, the language, the base class library, or the security model--was looking to take on C++ and the kinds of software people were looking to write in 1996 in C++.
You can write line of business software in Go, but that doesn't really feel like its purpose in life. The language fights you a little bit when you try to do that.
I think this is a rich space for practitioners to comment on. We are in the midst of a mass conversion of the delivery of government services into digital channels. It's important that we approach it as if it were physical infrastructure, for a host of reasons.
Later, and over time, key components of HealthCare.gov were redesigned and rebuilt. Rails was used for some, Go for others, and there is still some Java from the original design.
Government contractors often have postings for multiple contracts or positions and not all may have this requirement.
edit: "quite literal" is absolutely worthless. It would be "quite literal" to post a job saying "You will definitely be paid", and it would convey no information at all.
It is worth noting that, 7 years later, almost all of HealthCare.gov has been rebuilt, and substantial parts of it are in Go. This is in part what the company I co-founded after the rescue has been up to. (If this kind of thing -- building modern, reliable digital infrastructure for government -- seems appealing to you, [we are hiring][1].) This is a pretty interesting story in its own right.
[1]: https://adhoc.team/join/