HN user

asoplata

57 karma

Research Software Engineer for the "Human Neocortical Neurosolver" https://hnn.brown.edu/ . PhD in Computational Neuroscience, Boston University. Get in touch: https://asoplata.com or https://github.com/asoplata

Posts4
Comments18
View on HN

I briefly looked into this myself ( earlier in my life ) and decided that the "make a boatload and distribute it yourself" method really wouldn't help that much in scientific funding overall . Even if you made 10 million a year, and donated 99% of that, that would only help a handful of labs, which is something. Most science funding is orders of magnitude larger than that, and is on a scale that only nation-states can actually support. IMHO that translates to, if you want to have the biggest impact on science funding (including increasing the amount of funding), the best way would be to work in policy either at the NIH/NSF/etc. itself, as a congressional staffer specializing in science policy, an advocacy nonprofit (such as for a particular rare disease or a bigger, more popular one), or finally as a fundraiser/staff member at an independent science funding organization like the Wellcome Trust, Bill & Melinda Gates Foundation, or more specialized institutes like the Allen Institute for Brain Science.

I don't work in the science-fundraising space, but my gut tells me that now would be a good time to do the last option: with the Trump admin interested in trying to reduce the NIH's budget by 40%, researchers are increasingly looking to non-federal sources of money to continue doing their (expensive) research, like the private science-granting organizations mentioned above. At the same time, there's probably a lot of philanthropists who recognize how terribly shortsighted decreasing the NIH's budget is, and who are willing to contribute more to private science funders in an effort to fill the gap.

There's a small but growing amount of "research software engineers", people who attempt to bring professional-level software development to scientific research, and help scientists achieve their goals (example org: https://us-rse.org/ ). That's what I do as of recently (see https://hnn.brown.edu/ ): left my last post-doc, and switched to full-time development on a scientific computing package in my old domain (computational neuroscience).

Absolutely, yes. The other comments here have some fantastic reasons for doing this, and several do a good job of weighing the pros vs cons.

The paper alone is, almost always, never enough to fully reproduce the result. I've been bitten by this almost every time I've tried to implement someone else's computational model. It comes down to that only relying on your paper to explain your code leaves a LOT of room for errors. I've experienced all of these when trying to implement someone else's computational work without their code being published:

    1. Despite your best efforts, you include fundamental, result-breaking typos in the equations you write up to explain the math of what you're doing. This WILL happen to you at some point in your career, and in my experience, it's a problem in >>50% of computational modeling papers.
    2. There are assumptions in the logic of the code that you don't include in the writeup, since they're obvious to you, but you don't realize that someone else trying to understand your paper won't necessarily be starting with those same assumptions. This happens frequently with neural models that use complicated synapse-computation schemes.
    3. Your codebase may be big enough that you think code part X works a certain kind of way from memory, but you forget that you changed the logic late in the project to work in a different way.
    4. Publishing your code at the time of publication prevents "Which version did I use?" problems. It's very common for people to continue to work on their science code for new work, but they don't bother to save/tag a SPECIFIC version of their code that was used for the actual paper. This results in that even the author doesn't know what exact values were used for the results in the paper!
Any "competitive advantage" has to be weighed versus "positive exposure". If your code is the primary research object (as opposed to the data), then it's technically possible that someone may grab your code, extend it to do the next, interesting use of it, and then scoop you before you can do it yourself. However, even if this happens (which it probably won't), consider the following:
    1. You can't build a successful career out of just small extensions to the same piece of code, and so that codebase won't be the main kernel of your career, but rather your understanding of it.
    2. For every 1 person that tries to use that to scoop you, IMHO there's going to be at least 10 other people who see your code and reach out to you for help with it, or just to ask a question about it, or reach out for potential collaboration! In other words, depending on the field, if you publish the code, I think you're likely to gain new/future collaborators at a MUCH faster rate than people who compete against you. You'll be surprised at how many researchers on the other side of the planet are interested in your software!
    3. Even if someone scoops you with your own code, if they give any indication it came from you, you still get to count that as a publication that built off of your software work when you're applying to jobs :)
    4. At least with US federal government funding, it's gradually becoming required to do this anyways, and I believe/hope that it's going to become the standard anyways very soon.
Finally, don't fret about polishing/cleaning/organizing the code, especially style. For others trying to reproduce your results or just investigating how you did things, the main thing that matters is that your code runs "correctly", i.e. how you ran it to get the results that you did. One idea is to publish it "as is" for the CORRECTNESS of the paper, put a git tag indicating "original version", and THEN clean it up on Github/wherever. This helps prevent any new "organizing" of the code from potentially breaking something, which is counterproductive. This way, when people go to your code page, the first thing they see is a nicely-organized version, and gives you time to test that it works the same. Honestly, if you care enough about this at all, then your code is probably significantly more organized than 95% of research code out there; the standards of code quality in science are VERY low, which is completely different than private sector software engineering.

* edits are for markup

Bullshit Jobs 8 years ago

Why does working a Bullshit Job have to be about ritual or tribal identity or anything else, when the most important thing in that person's life is putting food on the table? Even if a job is bullshit, there isn't enough of a social safety net in most/all of the world to provide for one's needs without taking a job. For an employee with no financial cushion and trying to avoid homelessness/starvation, what the job does or its contribution to society is secondary to the income it provides that allows that person their basic necessities.

Similarly, if those basic needs were met a la Universal Basic Income or a Star Trek society, there'd probably be less bullshit jobs of people doing something, ANYTHING, just to earn enough to live and provide for their family.

Have you tried Pandoc[0]? It's the best, simplest solution I've been able to find for writing content in Markdown, and then almost trivially exporting that same content into PDF manuscripts, or PDF presentations, or HTML presentations, or more, without having to change the source content. It seems to be increasingly popular in academia for handling class notes/slides/papers all in one go. It can have good citation processing with cite-proc [1]. One of my favorite things about it is, if you know you're just going to be exporting to a specific filetype like HTML or LaTeX, you can just plain throw in code for that language directly into the Markdown, and Pandoc will run/include it.

(shameless plug alert) I wrote a super-simple Makefile script for using Pandoc, called acadoc [2]. It lets you call "make beamer", "make manuscript", "make html_presentation", etc., in a directory with Markdown files to turn them all into whatever presentation/manuscript/paper/etc. you want. The key thing, though, is that for LaTeX presentations/etc. it uses an intermediary "style/manuscript.tex" file to customize how you want your resulting LaTeX to look -- so if you want the same content, but decide the presentation looks better with white-on-black instead of black-on-white, you only need make a few changes and create a "style/manuscript_dark.tex", copy-paste that style in the Makefile, and now you can call "make manuscript_dark". It's meant to be quick and easy to use, and theoretically easy to add new recipes to.

If you want some more serious power about multiple document-type exporting, check out the links in the Acknowledgements section of Acadoc, shown here:

- https://kieranhealy.org/blog/archives/2014/01/23/plain-text/ - http://jeromyanglim.blogspot.com/2012/07/beamer-pandoc-markd... - https://github.com/timtylin/scholdoc - http://scholarlymarkdown.com/

(Yes, I know LaTeX styles/stylesheets are a thing, but I've never taken the time to learn them, nor figure out if they can do all the custom formatting a regular .tex stylization file can do.)

[0] http://pandoc.org/

[1] https://github.com/jgm/pandoc-citeproc

[2] https://github.com/asoplata/acadoc

That ComputerLanguages repo, wow! This is really awesome! And far, far superior to my own store/collection of helpful links by language by far :(. I may just stop altogether collecting helpful links on languages I may never, ever use, when there're such better lists and guides (like yours) out there that I can search if I ever need to. There are far more programming languages/ideas than there is time.

The last time I was at a crowded museum I spent roughly 20% of the time just trying to avoid getting in the way of people taking pictures. Everyone was taking pictures everywhere of all the installations. I considered doing so too, but realized 20 years too late that there are far better photographs of a work of art (or at least enough) by professional photographers with different takes/interpretations than I could do without decades of training (on average). If you like a piece, there's nothing to stop you from buying a print or downloading a picture. I get it that some people do it more for remembering "that time I saw it in person" instead of trying to capture the essence of a piece, and that's fine (that's why I used to take the pictures), but multiply the amount of time it takes to do that by every piece you come across, plus how much posting it on instagram/whatever/facebook removes you from "the zone", and I think it's just a different way of massively disrupting your attention when the MAIN reason you're there in a museum, for a limited amount of time, is to suck it all up. I'm sure many people don't get distracted by trying to take photos of all the art, but once I stopped and just focused on concentrating and nothing else, a trip became much, much more enjoyable, and even memorable.

I think it's at least very helpful in building emergent knowledge, knowledge of connections between things that, only after experience / long-term processing, you realize are instructive or related or at least similar or, very commonly, "Y is really just a special case of the more general X" idea.

It's still completely possible to learn some of the outgoing connections or equivalences after a specific search of the internet, but the more things you spend time ruminating on, the more connections/realizations seem to almost "bubble up" out of your subconscious/whatever. I think this is what [inspiration](https://en.wikipedia.org/wiki/Artistic_inspiration#Ancient_m...) is: the result of subconscious processing or drawing relationships between thoughts in your head that are memorized. That, I think, is what you wouldn't have anymore if you were to completely outsource your knowledge to the Internet. I have witnessed some brilliant statisticians come up with completely new ways for researchers to think of their data/analysis, without ever consulting Google...though that's a relatively poor example, and more related to developed Mathematical Intuition than anything else. I would argue that said developed intuition is a perfect example of drawing underlying connections between things by letting them stew around in your brain, connections that would be very much harder to find overtly.

The primary author is the central driver behind his own Rippe Lifestyle Institute [http://www.rippehealth.com/] who, turns out, partners directly with Coca-Cola [http://www.rippehealth.com/partners/index.htm], including "outreach" and "coordinat[ing] a number of symposia", which in all likelihood means paid speaking engagements. He and Coca-Cola may have honorable intentions, or he may be paid to advance their agenda. We don't know either way, but what we do know is they are connected to each other.

Another PhD student, in computational neuroscience (modeling of thalamocortical circuits). The difference between the level of code-sharing and code community between general purpose software and scientific software is just astounding. In computational neuro-modeling at least (as opposed to very intensive bio-analysis like genomics), there's incredibly little sharing of code or interchangeability, outside of [ModelDB](http://senselab.med.yale.edu/ModelDB/), although I've heard systems biology-modeling (like with CellML) is in a better state.

I love this site for many reasons, e.g. searching "site:ycombinator.com <search term>" is one of the best sources of finding modern opinions on languages, libraries, the state of coding in certain places, and most of all some of the best opinions on what can act as good introductory materials on anything software/langs (in addition to stackoverflow).

It's nice to have a finger on different tech scenes and where people, sometimes, are willing to call each other on BS. Oppositely, it's cool to see posts about a product/service and see that the actual company actively responds to comments here in a lively fashion.

One of the biggest reasons for me has been seeing whenever's the occasional open academia article or movement starting to spawn, whether it be open access, open data (e.g. [dat](http://dat-data.com/)), or my favorite, open code. There's an unbelievable amount of reinventing the software wheel that goes on with a ton of PhDs, and the FOSS community proves that doesn't have to be the case. Trying to take the lessons it's learned to the sphere of science is something that an increasing amount of people are thankfully interested in, and this site is one of the only ways I've heard about initiatives in that regard - most notably, [Mozilla Science Lab](http://mozillascience.org/)