I'm a software engineer working with scientist-turned-programmers, and what I've experienced is also exactly the opposite of the author. The code written by the physicists, geoscientists and data scientists I work with often suffers from the following issues:
* "Big ball of mud" design [0]: No thought given to how the software should be architected or what the entities that comprise the design space of the problem are and how they fit together. The symptoms of this lack of thinking are obvious: multi-thousand-line swiss-army-knife functions, blocks of code repeated in dozens of places with minor variations, and a total lack of composability of any components. This kind of software design (or lack of design, really) ends up causing a serious hit to productivity because it's often useless outside of the narrow problem it was written to solve and because it's exceedingly hard to maintain or add new features to.
* Lack of tests: some of this is that the scientist-turned-programmer doesn't want to "waste time" writing tests, but more often it's that they don't know _how_ to write good tests. Or they have designed the code in such a way (see above) that it's really hard to test. In any case--unsurprisingly--their code tends to be buggy.
* Lack of familiarity with common data structures and algorithms: this often results in overly-complicated brute-force solutions to problems being used when they needn't have and in sub-par performance.
This quote from the author stood out to me:
> I claim to have repented, mostly. I try rather hard to keep things boringly simple.
...because it's really odd to me. Writing code that is as simple as it can be is precisely what good programmers do! But in order to get to the simplest possible solution to a non-trivial problem you need to think hard about the design of the code and ensure that the abstractions you implement are the right ones for the problem space. Following the "unix philosophy" of building small, simple components that each do one thing well but are highly composable is undoubtedly the more "boringly simple" approach in terms of the final result, but it's a harder to do (in the sense that it may take more though and more experience) than diving into the problem without thinking and cranking out a big ball of mud. Similarly reaching for the correct data structure or algorithm often results in a massively simpler solution to your problem, but you have to know about it or be willing to research the problem a bit to find it.
The author did at least try to support his thesis with examples of "bad things software engineers do", but a lot of them seem like things that--in almost every organization I've worked at in the last ten years--would definitely be looked down on/would not pass code review. Or are things ("A forest of near-identical names along the lines of DriverController, ControllerManager, DriverManager, ManagerController, controlDriver") that are narrowly tailored to a specific language at a specific window in time.
> they care too much about the quality of their work and not enough about getting shit done.
I think the appearance of "I'm just getting shit done" is often a superficial one, because it doesn't factor in the real costs: other scientists and engineers can't use their solutions because they're not designed in a way that makes them work in any other setting than the narrow one they were solving for. Or other scientists and engineers have trouble using the person's solutions because they are hard to understand and badly-documented. Or other scientists and engineers spend time going back and fixing the person's solutions later because they are buggy or slow. The mindset of "let's just get shit done and crank this out as fast as we can" might be fine in a research setting where, once you've solved the problem, you can abandon it and move on to the next thing. But in a commercial setting (i.e. at a company that builds and maintains software critical for the organization to function) this mindset often starts to impose greater and greater maintenance costs over time.
> Lack of familiarity with common data structures and algorithms
This part I 100% agree with. I adapt a lot of scientific code as my day-to-day and most of the issues in them tend to be making things 100x slower than they need to be and then even implementing insane approximations to "fix" the speed issue instead of actually fixing it
>"Big ball of mud" design
Funny enough this was explicitly how my PI at my current job wants to implement software. In his opinion the biggest roadblock in scientific software is actually convincing scientists to use the software. And what scientists want is a big ball of mud which they can iterate on easily and basically requires no installation. In his opinion a giant Python file with a requirement.txt file and a Python version is all you need. I find the attitude interesting. For the record he is a software engineer turned scientist, not the other way around, but our mutual hatred for Conda makes me wonder if he is onto something ...
>I think the appearance of "I'm just getting shit done" is often a superficial one, because it doesn't factor in the real costs: other scientists and engineers can't use their solutions because they're not designed in a way that makes them work in any other setting than the narrow one they were solving for.
For the record my experience is the exact opposite. The crazy trash software probably written in Python that is produced by scientists are often the ones more easily iterated on and used by other scientists. The software scientists and researchers can't use are the over-engineered stuff written in a language they don't know (e.g. Scala or Rust) that requires them to install a hundred things before they are able to use it.
> The mindset … might be fine in a research setting
A vast amount of software is written for research papers that would be useful to people other than the paper’s authors. A lot of software that is in common use by commercial teams started off in academia.
One of the major issues I see is the lack of maintenance of this software, especially given all the problems written in your post and the one above. If the software is a big ball of mud, good luck to anyone trying to come in and make a modification for their similar research paper, or commercial application.
I don’t know the answer to this, but I think additional funding to biology labs to have something like a software developer who is devoted to making sure their lab’s software follows reasonably close to software development best practices would be a great start. If it’s a full time position where they’d likely stick around for many years, some of the maintenance issues would resolve themselves, too. This software-minded person at a lab would still be there even after the biology researchers have moved on elsewhere, and this software developer could answer questions from other people interested about code written years ago.
> Because the music of the past was written in a notation that’s different from that used today, it’s necessary to translate and input every mark of the original score – notes, dynamics and other expressive marks – into a music notation software to produce a modern score that can be easily read by today’s musicians.
I guess the key word is easily read. That score looks perfectly readable to me, although modern musicians might find the spacing somewhat cramped
Yeah. There is a whole academic and performance culture around historical music, and it's taught at music conservatoires and colleges. My wife for example plays and teaches music from the medieval, renaissance and baroque period extensively so I'm actually typing this in a room with shelves and shelves of facsimilies of scores from those periods all in original notation. With a bit of practise and training, people read this stuff just fine. From the Renaissance on there are lots of surviving treatises so we have a very good idea how they were performed etc and can in many cases be pretty confident that we're performing things pretty close to how they were done in the time.
Yep - beat me to that .. and I wanted to dive in as I once used Ingres before Postgres became a thing!
I came to Postgres just before the GIS range filters were added and chipped in on the backend as a project (very old now) needed a DB with GIS capabilities.
Well the titular "whistleblower" of the article has claimed the U.S. recovered a saucer from World War II dictator Benito Mussolini on a tip from Pope Pius XII. Sorry but that's firmly in tinfoil-hat territory.
https://popculture.com/trending/news/vatican-helped-recover-...
> [he] described an expanding and self-replicating bureaucracy that is growing ever more expensive to maintain
This seems to me a key piece of the problem. Rises in tuition have massively out-paced inflation while salaries for tenured professors have not seen anything even close to that kind of growth in the same time period. In fact most institutions actually employ fewer full-time faculty than they did 20 or 30 years ago. The answer to the question "where is all this money going?" doesn't have a mono-causal explanation, but an ever-expanding self-perpetuating bureaucracy is a significant factor. And it's not just academia; I've heard similar concerns from physician-acquaintances about healthcare. The astonishing growth of middle and executive managers at Johns Hopkins has been an ongoing topic of discussion with department-chair friend of mine for years.
I think we've barely begun to reckon with the costs the MBA-ification of major institutions has had on the overall welfare of the US public.
Yes, a wok is a somewhat strange choice for that dish. I'm not really an "expert" on Pinoy food but my partner is Filipino and I've seen this made many times by him, his family, or even friends of his when we have visited the Philippines and never once did a wok come into it. Either a dutch oven our a large saucepan is what I've seen used, since you really want to cover it so it braises evenly. The sauce is always fairly thin as well, nothing approaching a caramel-y consistency.
When he did the video for it I think he was using drumsticks, so I guess his idea was that the sloped sided wok allowed you to minimize the amount of braising liquid needed, since the drumsticks can lay meat-side down in the middle and have the bones stick up out of the liquid.
But since I mostly use boneless chicken thighs anyway, that didn't help too much. They needed to be uniformly covered.
Well in the spirit of a friendly flame war, I'm going to put my stake in the ground and say that Carabao mangoes from the Philippines and specifically the Galila, Tablan, and Fresco varietals from the island of Guimaras are the best in the world. Twice I've been lucky enough to end up in Guimaras--a tiny island off the southern coast of Panay--once I ended up there during the annual Manggahan Festival just by lucky happenstance. And my god, are the mangoes amazing: perfumey, floral, intensely sweet; they're the Sauternes of mangoes.
They are quite delicate and my understanding is that almost all the exports from there end up in Japan. I've certainly never been able to find them on either coast of the US. They've somewhat spoiled me for mangoes now as everything you can get here is rather insipid by contrast.
Interesting, I've just had a massive Mango year (one of the silver linings of COVID I guess), and these are varietals I haven't seen before. I'll keep a look out for a chance to snag them.
It sounds like a rare variety to find though. Is this the case?
I don't get the sense that those varietals will only grow in Guimaras, but the locals will tell you that it's not just the varietal but also the specific soil, micro-climate, and cultivation methods of the island that makes them special. I have no idea to what extent that's true, but while I've had lots of good mangoes all over the Philippines, the ones from Guimaras were definitely the best.
You managed to perfectly put into words something I was trying to articulate in my own comment on this thread about the limitations I kept running into with open source notation tools as alternatives to Sibelius. They always felt like they traded control for simplicity, which ultimately made them feel like kind of a "toy" rather than a professional tool.
> I'm reticent to mention specific engraving problems for fear that a neophyte will take my 10 seconds of examples as a complete set
I could not agree more. Correctly engraving music is hard! If someone wants to get a sense of all the things that a professional-grade tool would need to handle, Gardner Read's "Music Notation: A Manual of Modern Practice" is kind of the gold standard here. 453 pages that solely cover how to correctly notate music. I've been doing this for years and I still consult it fairly regularly.
I've stubbornly stayed on Sibelius 6 for years, but it no longer works on OS X Catalina, so I was pondering biting the bullet and upgrading to 8. But after seeing this...
Does anyone have any recommendations for a _real_ alternative they've used?* I took a look at MuseScore a couple of years ago and the impression I got was that it was fine for casual usage and for producing fairly simple scores, but lacked a lot of features. (I found that to be the case LillyPond as well.) Dorico looks more promising, but I'm curious what people who've used it heavily think.
I didn't even know that Finale was still around, but that was the first notation software I learned. Ironic that the reason Sibelius was able to trounce Finale in the marketplace so many years ago was mainly because the UI was so much easier to use and more intuitive. And now it's succumbed to the same problems.
*Features I'd like to see: parts generation, graphical score options, midi-based entry, and something that offers good default engraving behavior out-of-the-box but also lets you tweak everything to your liking. I typically sketch things out on on paper first, so I care less about "composition features" and more about being able to produce scores that are correct and that allow me to notate everything I would want.
With exception to graphical score options, Dorico is by far the best out there now. Especially for orchestral/band scores where one stave normally has multiple parts (2 flutes, etc), Dorico can handle that natively now.
Dorico has great out-of-the-box defaults and the people behind it genuinely care about great engraving.
Perhaps Dorico has better graphical score engraving by now, but it didn't when it came out. I personally don't have much use for that, so I haven't followed.
Give it a read, maybe it will change your mind. Organizations like BLM were formed to organize concerted protest and political pressure at a community-wide level. That is to say, it’s a direct result of people doing what you suggest they do: “people should care about what they do with themselves, their family, and their community first.”
* "Big ball of mud" design [0]: No thought given to how the software should be architected or what the entities that comprise the design space of the problem are and how they fit together. The symptoms of this lack of thinking are obvious: multi-thousand-line swiss-army-knife functions, blocks of code repeated in dozens of places with minor variations, and a total lack of composability of any components. This kind of software design (or lack of design, really) ends up causing a serious hit to productivity because it's often useless outside of the narrow problem it was written to solve and because it's exceedingly hard to maintain or add new features to.
* Lack of tests: some of this is that the scientist-turned-programmer doesn't want to "waste time" writing tests, but more often it's that they don't know _how_ to write good tests. Or they have designed the code in such a way (see above) that it's really hard to test. In any case--unsurprisingly--their code tends to be buggy.
* Lack of familiarity with common data structures and algorithms: this often results in overly-complicated brute-force solutions to problems being used when they needn't have and in sub-par performance.
This quote from the author stood out to me:
> I claim to have repented, mostly. I try rather hard to keep things boringly simple.
...because it's really odd to me. Writing code that is as simple as it can be is precisely what good programmers do! But in order to get to the simplest possible solution to a non-trivial problem you need to think hard about the design of the code and ensure that the abstractions you implement are the right ones for the problem space. Following the "unix philosophy" of building small, simple components that each do one thing well but are highly composable is undoubtedly the more "boringly simple" approach in terms of the final result, but it's a harder to do (in the sense that it may take more though and more experience) than diving into the problem without thinking and cranking out a big ball of mud. Similarly reaching for the correct data structure or algorithm often results in a massively simpler solution to your problem, but you have to know about it or be willing to research the problem a bit to find it.
The author did at least try to support his thesis with examples of "bad things software engineers do", but a lot of them seem like things that--in almost every organization I've worked at in the last ten years--would definitely be looked down on/would not pass code review. Or are things ("A forest of near-identical names along the lines of DriverController, ControllerManager, DriverManager, ManagerController, controlDriver") that are narrowly tailored to a specific language at a specific window in time.
> they care too much about the quality of their work and not enough about getting shit done.
I think the appearance of "I'm just getting shit done" is often a superficial one, because it doesn't factor in the real costs: other scientists and engineers can't use their solutions because they're not designed in a way that makes them work in any other setting than the narrow one they were solving for. Or other scientists and engineers have trouble using the person's solutions because they are hard to understand and badly-documented. Or other scientists and engineers spend time going back and fixing the person's solutions later because they are buggy or slow. The mindset of "let's just get shit done and crank this out as fast as we can" might be fine in a research setting where, once you've solved the problem, you can abandon it and move on to the next thing. But in a commercial setting (i.e. at a company that builds and maintains software critical for the organization to function) this mindset often starts to impose greater and greater maintenance costs over time.
[0] https://en.wikipedia.org/wiki/Anti-pattern#Big_ball_of_mud