Hacker News new | past | comments | ask | show | jobs | submit login

Vis-à-vis A little knowledge :

One particular Ph.D who I worked with had created a much lauded database. It was done in MS Access. It stored natural numbers. Each sample contained a few gigs of natural numbers. Numbers could be anywhere form 0 to 99999. So each entry contained all possible numbers in increments of 0.02, with Null in all places where the sample did not contain that number.

This is what happens when people have never heard of foreign keys or a one-to-many relationship or a many-to-many relationship.

This could have been done so it's a lot smaller and faster to search. The place holder could have been a negative int, instead of Null, so that it would evaluate to something other then Null in searches. An infinity of things could have been done better.

But when you have Ph.D and you legitimately think of yourself as brilliant. AND you are used to doing a lot of HARD work, then heroics with MS Access just seem natural, right, that's what hard science is damn it. And this is why a little knowledge can be worse then no knowledge.

If that guy had instead hired almost anyone else to design the database, he would have been better off. It's hard to imagine anyone who could have screwed up worse AND had the tenacity to stick with it.

PhDs are not just smart, but they also are used to working hard so when things get hard they don't quickly perceive that as signal to try something else.

As to being computer illiterate:

A field biologists might get away with it, but anyone working in a lab will sooner or later measure something with an instrument entirely controlled by and accessed though a computer.

Let me say that again, a computer is the gate keeper.

And it's not enough to simply know how to use the GUI/API what ever. You have to also know at least something about the algorithms involved in the analysis. Because a lot of analysis of things that can't be seen with the naked eye is actually statistical inference of what's there.

Let me say that again, a whole of of stuff is not measured in the way a lay person thinks of measuring, it is inferred using fancy math.

But make your math a bit too fancy and you're just making stuff up now. Use a second order polynomial and you're good, use a 3rd or higher order and you can see anything you want. There's a reason we use cubic b splines for computer graphics, it's because we can fit them to any shape we want!

And oh yeah I've seen 3rd order polynomials used in science, no they were not used correctly.




"So each entry contained all possible numbers in increments of 0.02, with Null in all places where the sample did not contain that number."

OK. That is heinous. It makes me cringe. And if the person who made it thought that it was an example of brilliance, that's cocksure ignorance coupled with a needy ego.

___but___

There are a lot of biologists out there who run computers at the the level of how a business person deals with Microsoft Word: what the computer can do equals what paths are available through the GUI.

In the example you give, the biologist got the computer to do something it couldn't do before, something that made life in his domain easier, and presumably made science possible that would otherwise have been impossible.

Many biologists don't have the money or time to hire a consultant to do it right.

If a heinous kludge lets you do biology that you otherwise couldn't do, then by god that kludge has merit. You can make fun of the person for being proud of the kludge -- but you should admire them for their willingness and ability to make foreign tools do something new.

My work spans biology and CS, and unlike 99% of the other biologists I know, I have experienced what a well managed project feels like -- version control, a build process, bug tracking, etc. To me, the Mythical Man Month is not a novel concept; it's a given. The level of ignorance among biologists about how to get computers to do useful work in novel ways is stunning, and the biologists don't know how ignorant they are.

Again: ___but___

The computer scientists these biologists hire are often so averse to kludging their way forward, that the result is stasis. Adherence to notions of architectural purity, reusability, the 'right' libraries or platform, all result in long iteration cycles where the biologists get no feedback as to whether or not a given line of inquiry is promising or not. And the biologists don't get what's happening -- they can't say, "No, don't do a 'proper' object model and code a 'proper' solution yourself; instead, write a perl script to munge this other tool's backend XML to achieve a similar effect, so I can find out whether or not that functionality will be useful; and if it is useful, maybe then we can do it 'properly'." The biologist doesn't know what Perl is, and doesn't know what XML is.

And anyway, this approach is likely to be anathema to a good computer scientist. People don't get into computer science to make ugly kludges; they get into it to make things of beauty. Reusable libraries. Infrastructure. Clean GUIs. Excellent data structures. Etc.

So there's this huge tension between the biologist PI and the computer scientist he hires to build stuff, and neither one really speaks the other's language.

If a biologist knows a bit of computer science -- say, enough to understand his own limitations and ignorance, enough to communicate effectively with computer scientist employees or collaborators -- he can be tremendously effective. If he can write a little bit of perl and munge his own XML to find out if an approach is promising, he can show his computer scientist employee the kludge, and say, "Make this better."

So, a little bit of CS can be a very good thing. I suspect I'm violently agreeing with you. As you can tell, the topic is near & dear to my current life's work. :)


Indeed I think we are in agreement.

Definitely in the need for enough cs to understand your own limitations. That's actually quite a bit of cs, but then again obtaining a Ph.D. can take a while, so I'm sure a little more time for extra study can be found :)

And taking a look at your work... Are you really trying to create a high throughput electron microscopy workflow? Whoa! If you make electron microscopy even close to high throughput that would be awesome!

But how much of the brain structure are you able to preserve during sample prep? For that matter, how quickly does brain structure degrade after death? Minutes, hours, days, weeks, months? Are you imaging the sections in a light microscope first? Correlating the light and electron results of the same slice in software? Freezing the sample in liquid nitrogen so as to freeze it faster then ice crystal can form? Man science is fun, too bad it's not a good way to make a living.


"Are you really trying to create a high throughput electron microscopy workflow?"

Yes. We've increased acquisition rates by a factor of ~15-20x over what is available using commercially available TEM systems. We now have tens of terabytes of image data in the can, and when I'm not reading HN (argh!) I'm working on collating & analyzing these data.

Light level microscopy preceded embedding of the material for EM, the anatomy is correlated between the two modalities, and the sample preparation method (this is of mouse brain) is by perfusion with an aldehyde mixture, so there is essentially no deterioration of the ultrastructure.

So, I wonder what you do -- no home page in your profile -- but I do remember what it's like to make a living. I like biology better. :)


20x? That's awesome!

I used to work in a bioinformatics startup - tons of fun with cutting edge science. But the startup tanked, and I moved on to a high paying corporate software engineering job. But I hope to be back in bioinformatics before long.


Thanks. :) It's been a long road, hope to get a paper out in the next ~6 months or so. Shoot me an email (address on my home page) if you ever want to be in touch outside of HN.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: