I stumbled on @eugenevinitsky.bsky.social 's blog and his "Personal Rules of Productive Research" is very good. I now do a lot of things in the post, & wish I had done them when I was younger. I share my "mini-paper" w ppl I hope will be co-authors. www.eugenevinitsky.com/posts/person... - ThreadSky

atabb.bsky.social • 74 days ago

I stumbled on @eugenevinitsky.bsky.social 's blog and his "Personal Rules of Productive Research" is very good. I now do a lot of things in the post, & wish I had done them when I was younger.

I share my "mini-paper" w ppl I hope will be co-authors.

https://www.eugenevinitsky.com/posts/personal-rules-of-productive-research/

Comments

oliverbatch.bsky.social•72 days ago

I’m maybe a 2/4 on this. Good at automation (1 script), and simple experiments.

But I’ve never been good at keeping notes, but this would probably help people I work with as most of the time they’re really struggling with details, would be nice to have notes to refer to.

oliverbatch.bsky.social•72 days ago

Much of this seems to relate to good software engineering practice in a different flavour…

Notes (documentation),
Simplest experiment (debugging/isolating the problem),
Single scripts (tests)

ducha-aiki.bsky.social•73 days ago

Great advice! The only thing I would recommend differently - I usually have "run all experiments" button, as they would likely took literal weeks (training, or inference), prefer to have a list of individual stage commands.
Also - a gradio demo, or simple script to run on user data (not dataset)!

ducha-aiki.bsky.social•73 days ago

*usually don’t have

ishan.khatri.io•73 days ago

Another thing I’d add, invest in visualization tooling as soon as you start the project. Loading data? Visualize it! New model? Overfit & visualize the results. If you invest in this loop early on, it saves so much headache tracking down bugs.

atabb.bsky.social•73 days ago

Ah yeah, this is something I do a lot, I have some functions to write the current state of some 3D thing as a .ply file and then I can see what is happening at different stages versus guessing at 3D geometry.

benoitrosa.bsky.social•73 days ago

Very good article! I would add one thing : set up automatic backups early on! This seems normal for most, but I'm always surprised at how little students actually backup their work. Not everything is in a git repo .. i know of people that learned that lesson the hard way with a stolen laptop :/

benoitrosa.bsky.social•73 days ago

Another thing i do is a variant of the mini paper. I write an early paper version when the theory/simulations are starting to take shape, in order to structure the experimental plan. It helps thinking about which data are needed, what kind of graphs i ideally would like to show, etc ...

philippbayer.bsky.social•73 days ago

The mini-paper helps especially students/ECRs SO MUCH. once you have the mini-paper, you have a todo-list.

Also: R-targets makes that '1 script' fairly straighforward.

atabb.bsky.social•73 days ago

👋 Philipp! (and yes, agree with your thoughts about the mini-paper).

philippbayer.bsky.social•73 days ago

Hi Amy:D I thought I was following you but apparently not! Welcome back!!!

eugenevinitsky.bsky.social•73 days ago

I feel we either all figure variants of these rules out or our research career spirals so I’m curious if you have habits that aren’t in here!

atabb.bsky.social•73 days ago

I don't have general things that are different from these -- the post is super, super good, and it covers the essentials that are common for many people. I laughed at the "simplest experiment first" section, because well, I've done those sorts of things (and regretted it).

atabb.bsky.social•73 days ago

I feel there's a tension between "this is small and I can play around for a while" versus "getting busy w documentation to avoid doing research". I have repos that are just ... shells of documentation with no content, b/c the idea was blah.

I do have a repo for each paper, and each presentation.

atabb.bsky.social•73 days ago

After that, I refine the process depending on context, like I write the .ply files so I can visualize what is going on, and I use a command-line flag, usually, to turn these writes on or off. The same with print debugging, a verbose flag so I can track it down bugs w new data.

atabb.bsky.social•73 days ago

Simulated data can be useful -- up to a point. For computer vision problems, using simulated images (even with noise) sometimes gives you a false sense of how a method works. So I usually have small 'easy' and 'hard' real datasets when I start working on something.

tedunderwood.me•73 days ago

📌

Comments

Posting Rules

Reply