> It's not so much that there is a shortage of people capable of applying who "kind of" meet the requirements, but truly capable engineers in this field who could pick up the work required are definitely in short supply, PhDs or no.
Maybe I'm reading this wrong, but you're saying that you're failing to find people who are ready to work on day one without additional training?
> And lastly, no one has been offered the position and then rejected it because of the pay. The last 3 offers given out were immediately accepted.
Why would they when there's no meaningful difference in pay between postdoc positions? What would happen if they tried to negotiate for something approaching an industry equivalent salary/benefits?
No quantitative idea, but as disgusting as the salaries for football coaches (N.B., depending on the school, it may be a budget separate from the academic enterprise), university presidents, &c. are, I would be willing to bet that they are dwarfed by the army of bureaucrats handling what I termed regulatory compliance.
On the research side, off the top of my head you've got grant administrators, institute review boards, research integrity office, postdoc affairs. You've also got "Title IX administrators". Accepting federal funding takes a lot of work.
The worthiness of the services the bureaucrats are providing I leave as an exercise to the reader, but I think it's problematic that the people making the regulations are not the ones paying the bills when it comes time to comply with the regulations.
> ... it feels like a bunch of nosy document-writers pointing down at software engineers saying "you're all shit, and we're going to tell you why".
I was under the impression that SEI has a pretty good reputation among people working on safety-critical systems like aerospace, automotive, and the DoD. Of the two authors with visible profiles, one led "software development projects and software process improvement efforts for the E-2C Hawkeye Program", and the other was "developing and maintaining nuclear engineering and scientific software for 14 years" before coming to SEI. I don't see that there's much basis to say that they are uninformed on software engineering.
> First, I reject the premise that software is poor quality when compared to other engineering disciplines.
If we're talking software on safety-critical systems, that may be true. I think NASA is a great example of software assurance done right. Outside of the SC area, I don't see how you can come to that conclusion: take the perceived decline in Apple's software quality as one example.
> The space shuttle, commonly referred to as the most complex machine ever built, has around 2.5 million parts. The Linux kernel alone has over 16 million source lines of code. It's an order of magnitude more complex than the SPACE SHUTTLE!.
I think this is a nonsensical comparison, but if you want to go with it, consider that each of the Space Shuttle parts has multiple steps going into it's creation. It'd be slightly more fair to say that the Space Shuttle has 2.5 million functions and compare that to the Linux kernel, but it remains a nonsensical comparison.
>Anyone who's ever done software development, will tell you that the order for these is something like: 2b, 2a, 2b, 2d, 2c, oh - someone's asking for sizings, better do some 1 - 2d, 2c, 2d, 2b, 2a, 2d...
Anyone who's done work in a regulated environment will tell you that while your suggested process may happen in the conception stage for preliminary testing, once you're under design control you follow formally documented procedures in the order that they are specified.
> There's got to be a better way to codify what we actually do when we develop good software. Not what we think we do, or wish we did, or claim we do to sound impressive.
Plenty of groups work in this area besides SEI: ASQ, IEEE-CS, ACM, &c. Did you have something specific in mind?
As others are saying, I think you're misjudging the target audience for this document, which I would say is Software Engineers (as in the type that would have PE licensure or work in regulated industries). When you have a defined acceptable defect rate and need to deliver on schedule with proper documentation, then things like PSP, CMMI, &c. do work. It's overkill for a web app. That said, I think adopting some of the rigor and professionalism in Software Engineering as typified by regulated industries would be an overall improvement to software development as it is generally practiced.
> Science is important, but science reporting (especially medical reporting) seems awful.
I don't think it's limited to science reporting. The more I learn, the easier is is to see the numerous errors made by journalists across all areas. Take Vox, it's an older link but they have been criticized for poor accuracy in reporting (and failing to prominently note corrections).[1]
The Royal Society has it right with their motto, nullius in verba: the news media, much like Wikipedia, is not a reliable source for facts.
I seem to recall one could damage a computer easily by interfacing through the parallel port without isolating correctly... Doesn't look like this guide covers the pitfalls.
Packaging is hard. I'd like to additionally nominate cables (as in wire harnesses) and strain reliefs to the list of things that make my life miserable.
How does the requirement to relocate to SF work for companies with a wet lab or specialized capital equipment requirement? And outside of mentoring/networking (can YC provide in the biotech space?), how is YC a better deal than an SBIR/STTR?
It's true that Ti rings are harder to cut, but the equipment to cut them is standard in American ERs. It still takes longer though. Even worse are the newer cobalt chrome rings, those take forever to cut off even with the right equipment. Safest of the alternative materials is probably the tungsten carbide or ceramic rings, since those can be fractured off with a pair of common vice grips. Don't know what happens when you're traveling in an area with a less developed medical system. If you aren't at risk for anaphylactic swelling, don't work with your hands, and don't travel in undeveloped areas, the risk of this sort of situation might be low enough to not worry too much about.
A more practical problem with alternative materials is that they can't be resized (some jewelers will resize Ti a little, but it's challenging). The alternative materials are cheap enough that you can buy a replacement that's the right size, but if you're sentimental (and a wedding band seems like something one might be sentimental about) it's a problem.
There's nothing wrong with alternative materials, it's just that sometimes the drawbacks are overlooked while being dazzled by the advantages.
I guess I don't understand what you mean by a PE not being government-regulated licensing? If you mean that a software engineering PE isn't mandated for work, then I agree that's true but I think that's short-sighted in view of the trends for safety-critical projects. Regardless of government mandates, I see it as problematic from a liability standpoint to sign off on safety-critical projects now that the cat is out of the bag.
Bringing it back to the top of the thread, I think that willful ignorance is a bad recommendation, would not help in a legal situation, would be negligent, and would be contrary to a professional code of ethics. Maybe you feel that a consultant or someone working on areas outside of the safety-critical domain doesn't need to follow a professional code or act in a professional manner? Completely disagree if that is the case.
As far as IEEE-CS and ACM being "obsolete trade associations", agree to disagree. I'm not aware of a better trade organization than those two.
Honestly, I don't understand the backlash against professionalism.
Sorry, but I would argue that not reading patents relative to your project is practicing negligence. Maybe that gets you out of trebled damages for willful infringement, but it opens you up to other liabilities and is against professional ethics.
FDA requirements mostly target the SDLC: risk analysis, change control, documentation, v&v, &c. Companies are afforded a surprising amount of flexibility in implementation. Basically, you must have a documented process that you follow, but you're left to your own devices in creating the process. Deviations from voluntary industry standards (e.g., TIR 45) is permissible since they're not specifically required. The DoD, aerospace, and automotive industries have in comparison far more detailed and strict regulatory requirements.
Maybe I'm reading this wrong, but you're saying that you're failing to find people who are ready to work on day one without additional training?