[HN Gopher] An unsolicited guide to being a researcher [pdf]
___________________________________________________________________
An unsolicited guide to being a researcher [pdf]
Author : sebg
Score : 150 points
Date : 2026-03-19 10:00 UTC (4 days ago)
(HTM) web link (emerge-lab.github.io)
(TXT) w3m dump (emerge-lab.github.io)
| etrautmann wrote:
| This seems like a pile of generally good, and some non-obvious
| advice, that's also useful outside of the boundaries of ML (it
| would also apply to a PhD in Neuroscience for example).
| Zeratoss wrote:
| Except maybe the "aim for 2 papers a year"
|
| I wish !
| nxobject wrote:
| And, even if you're in the "real world", anyone who wants to do
| fun hobby projects with community on the side :)
| ashwinnair99 wrote:
| The best research advice is always unsolicited. The official
| version tells you how it is supposed to work, not how it actually
| does.
| the_arun wrote:
| Biggest drawback these days is funding (Govt. is not liking
| research with all fund cuts) and long term opportunities for
| folks doing research.
| woodson wrote:
| There are still opportunities, but they aren't paid nearly as
| well as less researchy positions in industry. US post-doc
| salaries at state universities aren't that high.
| linguae wrote:
| Indeed. It seems, at least in America (I'm less familiar with
| the situation abroad) that computer science researchers who
| want to do longer-term work are getting squeezed. Less funding
| means fewer research positions in academia. Industry has many
| opportunities, especially in AI, but industry tends to favor
| shorter-term, product-focused research as opposed to longer-
| term work with fewer immediate prospects for productization.
| This is a great environment for many researchers, but
| researchers who want to work on longer-term, "blue-skies"
| projects might not find a suitable position in industry these
| days.
| iLemming wrote:
| I want to watch the presentation, is there a recording, does
| anyone know? When the Overview slide starts with "Don't do
| overview slides, it's bad practice", I feel like I'm missing
| quite some context here.
| ebuyan wrote:
| Pretty sure Apple does not use slides at all, just briefs
| sigbottle wrote:
| As for the notebook part, it's fascinating because it genuinely
| is kind of like software design if you try and impose more
| structure onto it - how is it reusable for the future? Can you
| genuinely predict the space of possible writings that you want,
| or does it, in the authors words, homogenize?
|
| I've taken an approach where I treat the act of deep writing (or
| shallow writing, or any writing) as means in it of themselves.
| Not sure how absolutely effective this is but I can definitely
| say that my thinking changed.
|
| #1 step to writing is to stop giving a f and I didn't not learn
| that until I was 21. Too easy to get caught up in schoolwork and
| the "proper" way to do things I feel.
| highfrequency wrote:
| "Your objective is to find the weirdest niche possible that still
| has the potential to change everything."
|
| "Virality based social media is inherently homogenizing."
|
| Some nice nuggets in here!
| sockaddr wrote:
| > Also a lot of bullet points are bad
|
| > Slides should have maybe a sentence of text at most
|
| Proceeds to have slides with many bullet points and more than
| several sentences of text per.
|
| I don't find issue with the slides as they are but if you're
| going to make arbitrary rules why not follow them yourself?
| DonaldPShimoda wrote:
| I haven't seen the associated talk, but (a) I would imagine the
| author chuckled while reading this, because it's sort of a joke
| among scholars, and (b) the point is likely focused much more
| on the context of presenting research (e.g., at conferences)
| rather than a blanket ironclad rule for all presentations you
| ever make ever.
|
| While I think there's some validity to your point that the
| author's presentation suffers excess verbosity, I'm not too
| worried about it because the linked slides seem more meant to
| act as a reference document than an example of a good
| presentation, and the level of text is just fine for that
| purpose.
| eugenevinitsky wrote:
| Yeah I'm the author, this was a joke. I also wanted to convey
| to the students in the room that this was not a high quality
| presentation, more so text just converted into presentation
| form.
| magiclaw wrote:
| I always thought this was funny. We were taught this in grad
| school, but hardly anybody followed this guideline. "If there's
| too much text on the slide, the audience will be busy reading
| the slide, and not paying attention to you". I _try_ to have
| just the main point on the slide, then I can talk around it.
| The details should be in the slide notes, if you need
| reminders.
| jgeada wrote:
| There are presentations that you actually present to an
| audience, to which this point is valid.
|
| But lots of presentations, including this one I think, are
| merely used as a means of conveying information (yeah, not my
| favorite way of doing so, but being a contrarian doesn't do
| anybody's career any good), and those are indeed intended to be
| read and need to have explicitly all the information that you
| otherwise would be speaking and addressing.
| collabs wrote:
| My guess is probably there is a difference between slides used
| for presentation and slides used for reading myself alone
| fxwin wrote:
| > Why does anyone need to know what order you're going to present
| things in.
|
| I agree with the sentiment, and many talks do this really badly
| ("Here is our outline, we start with an introduction, and end
| with a summary"), but it is worth mentioning that the alternative
| isn't no structure at all, but trying to convey a bigger picture
| to your audience for them to anchor each section in once you
| actually start your talk. This could be done like the OP suggests
| ("Just tell people the key idea upfront"), but there are other
| ways: instead of telling people the end result, tell them the
| question you set out to answer, and present your talk as this
| journey. look at the same thing/topic through different
| lenses/perspectives. Present a rough outline of a proof you are
| going to go through, or a case study you are about to present
| before going through the details sequentially.
|
| > How does one become a good collaborator? The golden rule: Do
| not block.
|
| Not only is this great advice for effective collaboration, it is
| also a very nice habit to have in any place where people's
| impression of your ability determines your future (career)
| trajectory
| eykanal wrote:
| This is an excellent overview.
|
| * His points about collaboration are excellent. So many research
| students think that their brains are their best asset. There are
| many smart people. There are much fewer smart people who can
| communicate and collaborate well. Be one of those people.
|
| * His points about papers are completely on spot. There are
| simply too many papers, and many actually aren't that good. The
| light bulb moment for me was realizing that this author didn't
| write this paper to help me solve my problem, they wrote it to
| describe how they solved their problem. Finding the right way to
| measure whether "their problem [?] your problem" is key.
|
| * Do a lot of learning on your own. If you don't you're only
| hurting yourself.
| mathisfun123 wrote:
| > * Slides should have maybe a sentence of text at most
|
| proceeds to present slides which are walls of text lolol
| kenanfyi wrote:
| Some excellent advice there. I can also confirm them from
| hardware engineering perspective.
___________________________________________________________________
(page generated 2026-03-23 23:00 UTC)