Several years ago I wrote about how researchers are skeptical towards numerical models and their results. I understand where this comes from. How do you convince people that you didn’t just tune the inputs of your model until it matched empirical data or yielded some other result you wanted?

I encountered this frequently during graduate school, from informal meetings to conference talks. I show a result, someone questions it, I suspect they think the result isn’t very good, until they finally reveal that they have the opposite concern: the model looks too good.

This is a fair question that should not offend you.

The solution is simple: Share your code or simulation input files. My thesis included an appendix with a Python script for generating material model inputs as well as the relevant material definition blocks for all major finite element models I ran. I am considering posting the entire model definitions once all the papers are submitted.

So the next time you are giving a scientific talk and a listener is concerned that your results are too good to be true, simply point them to where you have made the code or simulation files publicly available, and invite them to verify your inputs and play with your model.

Otherwise, what are you going to say? “I really really promise these numbers are legit!” ?

Even though I usually prefer another tool, Excel is part of my life as an engineer. Jeff Davis writes about an unconventional way to comment Excel formulas. There is some interesting functionality discussed in this post that I didn’t know about (the N-function), but I still feel like except for simple, tabular data processing, Excel is not a transparent way to communicate with collaborators.

How many times have you tried to decode a spreadsheet created by someone else, clicked in a cell to see the underlying computation, inadvertently clicked on another cell outside the current focus, and overwritten part or all of an expression? You can undo, but that isn’t exactly a selling point, is it?

This is exactly why I prefer simple Python scripts. They are transparent, plain text, and it’s much harder to accidentally delete the flow of logic.

(by way of Ben Brooks)

It’s no understatement to say that Instapaper transformed my reading life. But I run into trouble when life gets busy because I start throwing any link that looks interesting into Instapaper. When I finally get around to reading my Instapaper backlog, I have an overwhelming list of random links to read, most of which I can’t remember why I saved in the first place. I regularly delete everything and start over.

The best way solution I know to this problem is this: Never “blind add” an article to Instapaper. If I see a headline that looks interesting, I open that article long enough to skim it and make sure it’s something I want to read. If I’m still intrigued, it goes into Instapaper. If not, I forget about it and move on. I don’t know how to measure the impact of this, but qualitatively I think it’s greatly reduced false positive interesting articles. Like a lot of things, the solution is in the human filter layer.

Matt Mullenweg, in a post that I can only interpret as a blatant attempt to troll me with jealousy, has posted a photo gallery from a jaunt to the top of one of the cables of the bay bridge. I would do this in a heartbeat.

bucket_list_items = bucket_list_items + 1

→BAY BRIDGE CABLE WALK (76 PHOTOS)

Yesterday I flipped the switch and moved this site to a new domain. If you’ve been considering something like this, it is a very straightforward process. Here are a few details I picked up along the way that I want to point out. There are some tools that will automate the migration for you, but I wanted more control and also wanted to make sure I got a few things exactly right.