In my time as a biochem undergrad and grad student, I had to memorize and regurgitate the Krebs cycle no less than four times. None of those romps through it addressed the question of how TF did those scientists figure it out.
There's the science of Karl Popper, where no statement can be considered scientific unless it is possible to devise an experiment to disprove it. And there's the science of education, where we memorize and regurgitate stuff.
Those two are stunningly different from each other. Yet, it's not possible to get to the mysterious work of actually doing Popper-level science without memorizing what went before. The critiques of this paper still ring true half a century on. I wish more students of science from primary school on up would pester their teachers and each other with the question, "how do you know?"
I sometimes sweep up broken glass from bike lanes in my community. I need gloves, a broom, a dustpan, and a trash bag. Not as efficient. Needs a car, not a bike.
Read about what to do: _The Fifth Discipline_ by Peter Senge. A bit dated by now, it's still good stuff about "systems thinking" . And you'll need a lot of deliberate systems thinking in your job, and you'll need to teach others to think that way.
Read about what not to do: _The Ultimate Question_ by Fred Reichheld. This book is about the notorious Net Promoter Score. (Would you recommend HN to a friend? Would you? Would you?) Reading it will give you insight into how bonehead MBAs with Cs in their marketing classes can convince leadership they've come up with a good way to measure customer satisfaction. (Net Promoter Score works fine for competitive businesses selling commodity products -- rental cars to individuals for example -- but not for many places where it is now used.)
It would be great to get a straightforward assessment of the improvements in reactor tech in this new plant. "Passive safety features" sound pretty good to my untrained ear. But how much of this is marketing bullshytt?
Cool! The 11/70 I worked on had a defective floating point unit for a while; when it overheated it would start garbling MUL results. I don't suppose this has that "feature" :-)
One wishes there were a version of this article for science journalists.
And, one wishes that a university class on scientific ethics asked students to read this article with a critical eye and figure out what they can learn from it.
Myths about human-health topics spread faster than truth sometimes. cf. stomach ulcers and "stress" vs. pylobacter. It's hard to stop that. But it's easier to stop if we're aware of the myths.
It has to be said, web dev got better when the Redmond Middle School science projects (Microsoft Internet Explorer and old Edge) went into the dustbin of history where they have long belonged.
Germany seems to have similar sorts of federal / state / municipal government issues and other bureaucratic constraints as the US. And, this article makes it clear it has the same sorts of opportunities for improvement.
Maybe it's time to establish Programmieren für Deutschland as a parallel org to Code for America.
XML and JSON are for serialization. zip and sqlite, and file-system files, are for lossless persistence. They're separate issues.
An app can go bananas with serialization and use, I dunno, binary JSON or Matroska / ebml or .mp4 containers or whatever, and still serialize any way it wants.
Ms. Pahlka crawls through some large-system horror stories, and some success stories. The horror stories share something in common: design documentation that outlives its usefulness, takes on a life of its own, and drives implementation decisions in harmful directions.
Brandow's article (the subject of this thread) emphasizes the usefulness of documentation. And it's certain that long-lived software systems (like his php example) need excellent documentation. That documentation is targeted at people like many of us. It answers questions like, "how do I use that blankety-blank IMAP module?".
But long-lived documentation is often misunderstood and misused. For an overstated example, some "non-technical" administrator might read the php docs and somehow infer that "systems developed in php MUST use the IMAP module, or it won't pass acceptance testing." Then, the developers -- employees of some contract development team -- will comply. They'll have to figure out some way to incorporate email store-and-forward systems into the product, even if it makes no sense to do that.
There's a danger inherent in extensive documentation: it WILL be misunderstood in the future, and those misunderstandings may turn out to be costly. More systematic documentation -- for example boilerplate "scope" sections at the beginning of docs -- are not a great way to mitigate that danger.
When I'm coding / debugging with a framework of some kind (nodejs, dotnet, jdk, wordpress, whatever I'm using to deliver value at the time) I sometimes "step into" the framework or a library to see what happens. (Of course, I need open source for the framework/lib for this to work.) It sometimes opens a window to interesting code to read that's relevant to what I'm thinking about at the time. And sometimes doesn't.
Lots of source these days has auto-documentation comments. Good IDEs present that documentation, which helps guess what might be worth diving into the Step Into rabbithole.
Often, from a high-quality framework / library I learn a bunch about handling weird edge cases and about writing code for long-term maintainability. And, I often learn some useful constructs and techniques. (And, it's possible to learn useful things from not-so-high quality code too.)
I would really like to see what Joel Spolsky and Jeff Atwood, the original creators of Stack Overflow, have to say about the current state of affairs. Their business model was recruiting by identifying people with specific skills, and it was effective. I hired and was hired that way.
(They sold it years ago to a South African private equity venture and made the pile of money they deserved.)
It has to be said, the order of columns in correctly designed multicolumn BTREE indexes is governed by the shape of the queries the indexes support.
So don't arbitarily reorder columns in your indexes to handle alignment.