5 ms·

Anaesthetists are required to undergo days of retraining per year because the field, and the safety numbers, keep moving. To do this researchers publish findin

Anaesthetists are required to undergo days of retraining per year because the field, and the safety numbers, keep moving. To do this researchers publish findings and professionals aggregate those into useful training materials Who / where is the useful training materials for software devs? It really cannot be just blogs. That’s a VC investment that has ROI across the industry - tell a16z how to measure that and we are quids in

tialaramex 2y ago
Anaesthetists also undergo many years of training prior to taking post. Typically they've got say 10 years training before they actually do the job, much of it specialised to this job in particular (and the rest in general or intensive care medicine) If you're lucky a Software Engineer has a three year degree in CS, and probably only a semester at best was studying "Software Engineering" and even that might focus on something you don't care about, such as formal methods. It is entirely possible that your junior engineers have never maintained a sizeable codebase for more than a few weeks, have never co-operated on software with more than a handful of other people, and have never used most of the common software libraries you use every day, regardless of whether these are in-house (so how could they) or widely available. For example maybe you do lots of web apps fronting SQL Server databases in C#. Your new hire has six months of C#, they half-remember a course doing SQL on an Oracle database, and all their web knowledge is in Javascript. Do they know version control? Kinda. Have they used a test framework before? Well, they did in Java but never in C#. The "All Your Tests Are Terrible" talk begins by pointing out that probably they're strictly wrong because you don't have any fucking tests. All of the rest of the talk is about the hideous tests that you're unhappy to find because you forget that somebody could just not have bothered to write any tests at all.
- globnomulous 2y ago
  Hey, I resent and agree with this!
- simoncion 2y ago
  > All of the rest of the talk is about the hideous tests that you're unhappy to find because you forget that somebody could just not have bothered to write any tests at all. At many times in my professional "career", I've found myself wishing that whoever wrote the test I'm staring at just hadn't bothered. "Tests that say and/or look like they test one thing, but test something entirely different." [0] and "Tests that actually test nothing at all and never fail when the code they claim to test is changed out from under them." are two of the many categories of tests I wish folks would just never have wasted their time writing. [0] To be clear, I usually find tests of this type to claim to be testing something useful, but actually be testing something that's not worth testing.
simoncion 2y ago
> Who / where is the useful training materials for software devs? It really cannot be just blogs. Why can't it be blogs, books, and word-of-mouth? If you're a programmer (as your HN profile suggests that you are), you already know how little formal training we receive.
- lifeisstillgood 2y ago
  I think I am saying we should fund more training materials and spread the word on where they are to be found. Maybe But something !
mrkeen 2y ago
"nulls should not be in your language" is my version of "doctors should wash their hands" "Immutability-first, with mutation-as-a-special-case" is my "accountants should not use erasers" "make illegal states unrepresentable" is my "hospitals should sterilise their operating rooms and equipment" As a field, we are very far from reaching broad agreement on the left side (which I consider the basics). So what would the training materials teach?
- feoren 2y ago
  Lately, "nulls should not be in your language" sounds like "reality should be simpler". Queue angry fist-shaking at the complexities of real life and a wistful longing for a logical, functional, mathematical world. In reality, sometimes out of 8 questions, you only know the answer to 7, and the missing answer could be any of the 8. So you can: 1. Prevent the user from doing anything until they go find that 8th answer, which cascades into your tool not helping anyone until they have a complete, validated, full, historical data set. 2. Subdivide those 8 questions into having independent existence, which cascades into your entire application being a giant key/value store, and all the difficulties of null are simply replaced with the difficulties of "this key/value pair does not exist yet". 3. Add a sentinel value for "I don't know this yet", while feeling good about yourself because that sentinel value is not technically null, while introducing all the same exact issues that null causes, plus a bunch of infrastructure you have to write yourself. Basically: reimplement null, but worse. 4. Make the answers nullable. It'd be like claiming that an IDE should simply not allow syntax errors to be entered at all. Errors would be completely impossible! Except at some point your user needs to actually write the thing, and you've just abandoned the idea of helping them. So they write it in some other editor, and then paste it into your IDE. Or you embrace the fact that incomplete work is OK. Yes, nulls are generally way over-used. But disallowing them entirely is a fool's errand. Source: I've been that fool. In before: "You should just be using Maybe<> everywhere" -- "Maybe" is just another word for "nullable". The only difference is the level of support you get from the compiler / type-checker. So that argument is "the compiler should help you get null right", which I completely agree with! There's still work to be done getting type checkers better at null. But that's a far cry from "null should not be in your language" and equating the use of nulls to a doctor not washing his hands.

tialaramex 2y ago

Anaesthetists also undergo many years of training prior to taking post. Typically they've got say 10 years training before they actually do the job, much of it specialised to this job in particular (and the rest in general or intensive care medicine) If you're lucky a Software Engineer has a three year degree in CS, and probably only a semester at best was studying "Software Engineering" and even that might focus on something you don't care about, such as formal methods. It is entirely possible that your junior engineers have never maintained a sizeable codebase for more than a few weeks, have never co-operated on software with more than a handful of other people, and have never used most of the common software libraries you use every day, regardless of whether these are in-house (so how could they) or widely available. For example maybe you do lots of web apps fronting SQL Server databases in C#. Your new hire has six months of C#, they half-remember a course doing SQL on an Oracle database, and all their web knowledge is in Javascript. Do they know version control? Kinda. Have they used a test framework before? Well, they did in Java but never in C#. The "All Your Tests Are Terrible" talk begins by pointing out that probably they're strictly wrong because you don't have any fucking tests. All of the rest of the talk is about the hideous tests that you're unhappy to find because you forget that somebody could just not have bothered to write any tests at all.

globnomulous 2y ago
Hey, I resent and agree with this!
simoncion 2y ago
> All of the rest of the talk is about the hideous tests that you're unhappy to find because you forget that somebody could just not have bothered to write any tests at all. At many times in my professional "career", I've found myself wishing that whoever wrote the test I'm staring at just hadn't bothered. "Tests that say and/or look like they test one thing, but test something entirely different." [0] and "Tests that actually test nothing at all and never fail when the code they claim to test is changed out from under them." are two of the many categories of tests I wish folks would just never have wasted their time writing. [0] To be clear, I usually find tests of this type to claim to be testing something useful, but actually be testing something that's not worth testing.

simoncion 2y ago

> Who / where is the useful training materials for software devs? It really cannot be just blogs. Why can't it be blogs, books, and word-of-mouth? If you're a programmer (as your HN profile suggests that you are), you already know how little formal training we receive.

lifeisstillgood 2y ago
I think I am saying we should fund more training materials and spread the word on where they are to be found. Maybe But something !

mrkeen 2y ago

"nulls should not be in your language" is my version of "doctors should wash their hands" "Immutability-first, with mutation-as-a-special-case" is my "accountants should not use erasers" "make illegal states unrepresentable" is my "hospitals should sterilise their operating rooms and equipment" As a field, we are very far from reaching broad agreement on the left side (which I consider the basics). So what would the training materials teach?

feoren 2y ago
Lately, "nulls should not be in your language" sounds like "reality should be simpler". Queue angry fist-shaking at the complexities of real life and a wistful longing for a logical, functional, mathematical world. In reality, sometimes out of 8 questions, you only know the answer to 7, and the missing answer could be any of the 8. So you can: 1. Prevent the user from doing anything until they go find that 8th answer, which cascades into your tool not helping anyone until they have a complete, validated, full, historical data set. 2. Subdivide those 8 questions into having independent existence, which cascades into your entire application being a giant key/value store, and all the difficulties of null are simply replaced with the difficulties of "this key/value pair does not exist yet". 3. Add a sentinel value for "I don't know this yet", while feeling good about yourself because that sentinel value is not technically null, while introducing all the same exact issues that null causes, plus a bunch of infrastructure you have to write yourself. Basically: reimplement null, but worse. 4. Make the answers nullable. It'd be like claiming that an IDE should simply not allow syntax errors to be entered at all. Errors would be completely impossible! Except at some point your user needs to actually write the thing, and you've just abandoned the idea of helping them. So they write it in some other editor, and then paste it into your IDE. Or you embrace the fact that incomplete work is OK. Yes, nulls are generally way over-used. But disallowing them entirely is a fool's errand. Source: I've been that fool. In before: "You should just be using Maybe<> everywhere" -- "Maybe" is just another word for "nullable". The only difference is the level of support you get from the compiler / type-checker. So that argument is "the compiler should help you get null right", which I completely agree with! There's still work to be done getting type checkers better at null. But that's a far cry from "null should not be in your language" and equating the use of nulls to a doctor not washing his hands.