duwease

Bad Pharma is truly an eye-opener as to the extent of the troubles faced in getting truth out of medical research. It's going to take many, many, different group combining foresight, technology, and good-old-fashioned political clout to even start fixing it.

John Ioannidis' work is fascinating in that respect as well.. not just in the medical field, but science in general.

The worst part is, to collect your winnings you need to email your account details to the deposed prince..

First off, I try and rank the pieces of the project by complexity.. there's almost always a simple CRUD interface that it needs somewhere that I can start with.

I always start out getting a book, which I then don't read the majority of (although that is a luxury of moving from web language to web language instead of something more drastically different). I'll read how to get the project setup, and skim basic framework object structure (this is where having a book you can easily skim back-and-forth in is handy). Then I'll just start. Most simple stuff (syntax to traverse a collection), I'll just Google quickly. Inevitably I hit a framework aspect that's unique or in-depth enough to merit study, and then I'll read that section of the book completely.

If you're using a third-party library with source, stepping through some of the logic is generally something you end up doing anyway, but it's pretty useful to do right away to get an idea of some of the optimal structural tricks the more familiar devs use. Maybe follow a couple of API calls for a step or two to see how they arrange things.

Once you've done enough to feel comfortable (maybe the first couple chunks of complete functionality in the bag), it's good to Google around for things like "Common Mistakes/Pitfalls in X". You'll probably have run afoul of a couple of those, and will now be familiar enough to understand and remember them. You can go back and clean up the little bit of code you did then.

I would have rules for how I judge documentation, but I see it so rarely that "any documentation at all" is the highest honorific.

Amen. When I think, "I love my job", I'm generally thinking about the "easy" part, where the tools are all under my control and well known, and I just have to build something with them using my knowledge of algorithms and architecture.

However, the reality tends more often to be: - Frantic Googling trying to figure out the magic code to pass to a black box 3rd party component that will prompt it to spit out exactly what I need - Banging 3rd party components together to see what happens to be compatible - Trying to figure out how to work around the limitations of an API without being too inefficient or complex - Spending 4 times longer on conference calls discussing a problem than actually fixing it

Isn't this just a continuation of Microsoft's recent-years strategy of waiting until other peoples' innovations created a market, and then trying to drop their entry into it? Zune, Xbox, Windows Phone, Windows Tablet, etc.. hell, didn't Ballmer explicitly state that was his strategy?

The Enterprise code brings back awful memories of working with a framework architected by someone who had obviously read the Design Patterns book and had the take-away of "Use these as often as they can be wedged in to have a better system."

God forbid I needed to add a single boolean field to a single screen. By the time I submitted the DB change request, then changed the abstract factory interface, then the abstract factory class, then the factory interface that generated, then the factory class, then the abstract DAO interface that generated, then the abstract DAO class, then the parent DAO interface, then the parent DAO class... pauses to catch breath ...then the child DAO interface, then the child DAO class, then the controller object interface, then the controller class, then the actual page, then the unit test, it was 4AM and time to go to sleep.

Let this be a cautionary tale to any future architects out there.. remember that flexibility is a MEANS, with the ends being less time and money spent coding and maintaining code. It's not an ends to itself, and can even be a hindrance to the ends.

Considering the large and growing bank of research that highlights areas where the brain's output is flawed or plain wrong when compared to the consensus "optimal solution", I think I'm with the "AI establishment" as it's painted by this article. It doesn't seem self-evident to me that the inner workings of the human mind are the only or even optimal implementation of intelligence for every task.

If anything, the human mind seems to me to be a particular algorithm that is flexible, but trades that flexibility for capability in certain problem areas. Using a transportation metaphor, it's like walking versus air travel. Walking is incredibly flexible when it comes to where you can go, but air travel is by far the optimal route to get from coast-to-coast, although you are limited to travelling between airstrips. I feel like focusing on the human brain as the "true" intelligence is like claiming that walking is the only true transportation, instead of focusing on optimal routes for each problem.

I don't know that the conclusion that pre-reform candidates were more moderate and/or effective is as self-evident as he seems to believe. It's hard to brush off the fact that our opinions of them are not only colored through the lens of history books, but also through a vastly different culture.

In addition to the distortion of perception through second-hand accounts versus perception through actively participating in the modern scene, I'd argue that no small part of the perception of modern presidents is affected by the proliferation of media sources and the formation of specialized media outlets with a particular ideological audience that didn't exist as widely in the past.

I do think it's important to note that they're generally wrong in the same direction.. they tend to be overly positive, not overly negative (or an even mix of both). That particular skew is more likely to implicate the "publish or perish" incentive system as the culprit than the other two.

Let me ask a question from a different angle.. since the rationale for classifying these was "to protect national security", how many actually met this criteria, crime or no?

What can be done? Build more housing I guess, but who's to say the most desirable still won't be bought by those looking to pay the most?

Not to be dismissive of the impact to those who have up to this point been able to afford it and now must change their lives.. but I don't know if there's any 'cure' for people wanting to sell a scarce resource to the highest bidder.

Amen. Just amen.

I've worked on at least a couple of open source projects now that have a strong and active core team building everything, and who are talented enough to write great code. But when it's almost time to launch v1.0, the call always goes around: "Who's willing to write the documentation?" And the response is always silence. Documenting just isn't as "fun" as coding, I guess.

But it is, arguably, at least as important if not more, if your goal involves popularity. I recommend open source software projects to groups who are looking for an open source solution, and the ones with an active support community and good documentation, but some sloppy code, win every time over the expertly coded masterpiece that can only really be understood by stepping through the code in a debugger.

The Watchmen.

But wait, who watches..

You're right, I don't want to give the impression that it's never warranted. Just that it's important to give thought to if a simple description or even a graph might be more efficient in each case.

I try to stay mindful of the limits of short term brain storage.. if there's over 7 unique variables or interval indicators, it might be tough for someone unfamiliar with what's going on to pick it up without wasting extra time noodling on it. When you've got a sum over 'm', a sum over 'm,n', a product sum over 'n,x' and another over 'x', etc.. sometimes it's just easier to bite the bullet and give a visual aid so the reader's not trying to envision all these overlapping regions in his head while still trying to remember what each is supposed to represent in real life.

I understand mathematical notation, but I do think it generally is best only used when necessary in day-to-day work. Whenever something is of sufficient complexity, trying to keep track of the 10+ variables in a mathematical notation is generally harder than just reading a description.

For a recent example, my thought process yesterday: "So let's see, it says to multiply all of the 'F' functions, from 'm' to 'n'.. 'F' is, what, the base array? OK, so that makes 'm' and 'n'.. hmm. Let's come back to that. OK, so we multiply the product of those 'F's times the product of all 'alpha's of 'm,n' over 'm'.. so alpha is, let's see, the.. message? And... uh.."

Long story short, I finally deciphered it just meant "Multiply the base array of values by the value of each message that comes in that shares a parameter," only it took about 5 minutes instead of 10 seconds.

If it was me, I'd keep cranking out superior databases, selling them for a billion, and starting on the next one as fast as they'd buy em :)

I've been bitten by open-source AND closed-source applications recently, from different angles.

Once when using an Adobe application that was behaving erratically, and I was unable to see what was happening internally for myself (and obviously the behavior wasn't documented). Incredibly frustrating, and no recourse except to hack around it and hope it didn't mutate.

More recently, I've been bitten by a fairly popular open source application that I intended to use without modification (just configuration). But the documentation was so awful that I couldn't even figure out how to configure it. Ultimately, I had the recourse of stepping through the code to figure it out, but when you're trying to build adoption of your application, it would make sense to make it usable for its main purpose without setting up the actual source code in a debugger.

One interesting generalization I see is that the user-friendliness and documentation of the open-source app correlates quite often to the language used. PHP and Ruby projects seem to be built with an eye towards helping the eventual users use it. The Java projects, while often more competently written and complicated, seem to often be presented as code-only, take it or leave it, user-friendliness be damned.

I just keep wondering why he was picking her up by the ankles in the first place..

You would have made a better point and found greater comment thread success if your footnote markers weren't so clunky. People on the verge of joining your cause are thinking, "Why should I believe this guy, he can't even keep his footnote markers under control!"

Luckily, our Footnotify* software is here to help! For only $99USD a year, your internet arguments will be changing minds from Amazon to Zombo.

*not to be confused with FootNotify, the foot soaking timer app, property of Scholls, LLC

It is refreshing to see something not pretending to be all things to all people whose drawbacks are only widely known after the Hype Curve starts the downwards portion..

Still down here, over 12 hours at this point. This is probably the second time we've been hit with something on AWS in the last three months -- and you have to pay them to talk to someone about it. We're definitely moving to Linode ASAP..

I did get a laugh at the blogger's predator being Apple

Are the companies pushing the lucid dreaming glasses nowadays the same people that sold them in the old "Johnson-Smith Things You Never Knew Existed" catalogs when I was young? I distinctly remember wanting to buy those, but I always blew my money on the other stuff in the catalog (fake dog poop, a "Hoof Arted" t-shirt)

This used to drive me nuts, since I only play online sporadically -- having to sit on the phone for 15 minutes to cancel was ridiculous. They've changed it now, but there's still the mild trick of re-engaging the auto-renewal every time you sign up again for a month.

These are definitely something to keep an eye on.. the market is wide open for anyone to grab once the turning point comes.

Yes, the first thing I thought after "ooh, neat" was "Are there any portal communities for HTML5 even close to those for Flash?"

I was hoping for an analogy to explain how difficult it is to estimate long-term programming work due to unexpected "black swan" details popping up as you get into the work that add considerable effort to the project. It's a situation I find I need to explain often, and in layman terms, so a perfect analogy would be great...

Whenever I hear about instructors complaining about student procrastination, it makes me think back to when I implemented/managed a system for academics to make a certain type of submission.. and over half of the submissions were always after the deadline during the "last second extension". Physicians, heal thyself :)

I suggest the book "Wrong: Why experts* keep failing us--and how to know when not to trust them" by David H. Freedman, the author of that Atlantic piece. It's a book length treatment, and very damning in many ways.