mcmancini

> 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?

At what point did the system go awry? When did postdoc go from being a training position to cheap labor? Was it with the doubling of the NIH budget?

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.

Partially, regulatory compliance.

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?