Further along your research career, you will move from working exclusively on research project to managing several research projects at various stages of development.
One metaphor that is useful for managing these projects is thinking about your research as a garden. Not everyone idea will flourish, but tend a good research garden and you will have a fruitful research career.
Let’s start with a simple pipeline view of a garden: Seeds, Planting, Growing, and Harvest. We start with seeds, and hopefully harvest a result at the end.
Seeds. You might have thousands of ideas — like seeds, they are cheap and easy to hold on to. But, you only have limited room in your garden for growing. Furthermore, seeds might only be viable for a few years before they expire. …
Creative and open-ended tasks, new features to a product, and research tasks seem like they should be simple. You think of a goal, you start your work, and with a lot of effort, you will be eventually be done. But something awaits.
The reality is that an invisible and sinister force lies in wait to distract and dissuade even the brightest from their journey: The Forest of the Infinite.
While technical interviews have many problems, see: https://blog.usejournal.com/hiring-is-broken-what-do-developers-say-about-technical-interviews-21821141ca71. One reoccurring theme is the feeling of anxiety and stress associated with coding under the surveillance of the interviewer.
In a recently accepted paper, “Does Stress Impact Technical Interview Performance?” by Mahnaz Behroozi, Shivani Shirolkar, Titus Barik, and Chris Parnin we found that rather than assessing problem-solving ability, technical interviews may simply be a procedure for identifying candidates who best handle and migrate stress solely caused by being examined by an interviewer (performance anxiety).
We also found a simple fix: The private interview. …
We read tens of thousands of Hacker News (HN) comments, so you don’t have to. Read on for a summary of our latest research results [pre-print].
Let’s begin with a technical interview problem. Consider the following coding question from LeetCode, an online platform for preparing software development candidates for interviews:
You can solve the problem interactively. The provably optimal solution to this question — called Kadane’s algorithm — is described in Bentley’s 1984 column, Programming Pearls. The column presents various solutions to this question with cubic, quadratic, and linear time complexities. …
Years of research can be wasted by failing to write a paper introduction that convinces a reviewer to read on. Writing a great introduction could take weeks, even after years of practice. But that’s not the goal of this post. We will strive for a more simple goal:
Lessen the chance that a reviewer will go from an accepting mindset to a rejecting mindset.
In an accepting mindset, the reviewer seeks to “trust but verify”. They generally believe the argument and results described, but will verify them and hopefully point out some ways to improve the work. In a rejecting mindset, the reviewer has already decided the paper does not meet the bar for acceptance or is just not as good as all the other papers already in the accept pile. …
I make sure I allocate time every week to work deliberately on an important goal. I have used for the following work schedule for the past one year. Productivity methods are drawn from ideas such as Deep Work and Getting Things Done. As a result of this work schedule, I’ve been able to publish 12 papers, and submit 12 grants this past year.
How do I select a goal? At the moment, tenure is my primary goal. As such, I currently select tasks that directly support that goal, such as writing research papers or grant proposals. Occasionally, I will use the time to work on coding infrastructure for a project or a course. Due to family and personal constraints, I am only able to work from 9:30am–5pm during the week (no weekends). …
You have 30 minutes to do a task. Really, just 30 minutes. Because in 31 minutes you have a presentation that you have no slides for.
20 minutes into the task, you realize you have been fiddling with a diagram on slide 2. You rush to finish the last bit of slides, showing up 10 minutes late.
Sometimes we need to be able to effectively timebox on a task. But this does not always mean extreme timeboxing. Sometimes we have plenty of time, but do not use it effectively.