Learning from our search history
This article is originally published at https://lcolladotor.github.io/
Origin of the idea
Recently the team I work with has had a few new members and I’ve been thinking lately of ways we could try to help them. The team leader was traveling this week, which gave me the opportunity to come up with a new type of session and test it out. That’s the origin of this learning from our search history idea. We tested it today and I’m quite happy with the results so far, so I thought it would be useful to document what we did and share it with others.
As I show in the slides below, in our group we follow the you must try, and then you must ask framework although with a little different interpretation. The basic goal is to search independently for a period of time (say 15 minutes), but then ask others for help if you are still stuck beyond that point.
In other words, you have to be able to find some answers yourself since that’s part of our job using resources that range from Google Search, to the Bioconductor Support, to the RStudio Community, among other websites. However, we also acknowledge that some questions have difficult answers. Maybe a Stack Overflow thread has multiple answers and not necessarily the top voted question has the answer you are looking for. So instead of spending too much energy, we also tell our members to avoid getting into a rabbit hole for hours. That’s where asking for help comes to play. And you can ask for help from any community you belong to: those involved in the project through Slack, our full team, other scientists in our university, communities we belong to like the rstats community on Twitter, the Bioconductor users community at large, etc.
I did mention that it’s ideal to think about the person who will be helping you answer your question. Small reproducible examples, versions of the software you used, sharing your code on GitHub 1, the commands you used and the order you used them in can all be valuable for resolving different types of problems. Jenny Bryan has talked much more about this subject, for example in this 2018 webinar.
Trying for a while then asking for help is all good in practice. However, asking for help is very challenging. It’s scary, you open yourself because you show what you don’t know to other people, and sadly historically many questions have been met with negative feedback on the Internet. Thus, they can make you feel dumb, stupid and many other negative emotions.
I do think that asking for help can be worth it and even wrote a previous blog post on this subject. Some reasons why it’s worth it include being able to move on with your work 2, you might learn something new, and if you follow the strategies for helping others help you, you might even figure out the answer yourself.
Now, we all ask for help regardless of how long we have been writing code. Here’s an example tweet that conveys the same message. There are thousands of such tweets online.
I conduct approximately 3948234 programming-related Google searches per day. So does every other developer I know, whether they have 5 weeks of experience or 5 years. Help normalize this practice by tweeting your daily searches with #devgoogle! https://t.co/XfNVUZlhC5— Lyzi Diamond (@lyzidiamond) January 15, 2019
We are diverse
The team (shown as of May 2018) we work at is very diverse because we all:
- have different backgrounds,
- have acquired different skills,
- are at different career stages (from rotation student up to associate professor),
- have different interests,
- use different operating systems (from Fedora to Ubuntu to macOS to Windows)
- use different tools (mobaxterm vs putty, TextMate vs RStudio, …).
But also because we seek help in different ways 3 and we learn differently.
This means that we have a lot to learn from each other ????????.
Learn from each other exercise
At bit.ly/learnfromsearch you can find a copy of the Google Spreadsheet with the information you need for your team.
First, we need to make sure that everyone will feel save to ask questions. That’s why I:
The idea is that you pick a problem you solved recently and share:
- what you were trying to solve,
- the actual text you searched for in Google or elsewhere 6,
- the link of the website where you find your answer or that guided in this process.
We improved the steps as we were testing this! ????????????
Once everyone has contributed their information to the spreadsheet, we then proceed to go around the table showing and explaining our search use cases.
Ultimately the goals of this exercise are to
- empower ourselves with the knowledge from our teammates,
- learn from how we all find help,
- build a supportive environment where we feel comfortable asking for help.
Thus in the end, we are enabling our team to fully follow the you must try, and then you must ask framework.
The first and only session so far went approximately like this:
- Min 0-5: get settled in the room.
- Min 5-22: presentation about the idea to get members to buy into it.
- Min 22-26: demonstration.
- Min 26-33: members prepared their information to share with the team.
- Min 33-58: members presented their problems, the searches the did, and the solution(s) they found.
- Min 58-60: quick wrap up.
My search example
At bit.ly/learnfromsearch I left some examples (anonymized). Mine was about increasing the point size of the output of a plot made with
scater::plotReducedDim() which returns a ggplot2 (Wickham, 2016) object. Hence why I searched in Google for
ggplot2 increase point size which lead me to the
geom_point() reference website. I then tried using
+ geom_point(size = 20) but that broke the color mapping. I was about to dive into the GitHub code for scater (McCarthy, Campbell, Lun, and Willis, 2017) as this my go-to behavior for many similar quests, but I decided to check the help page using
… Additional arguments for visualization, see ?“scater-plot-args” for details.
The documentation for
... lead me to
?"scater-plot-args" where I finally found the
point_size: Numeric scalar, specifying the size of the points. Defaults to NULL.
and that solved my problem.
So what used to look like this:
library('scater') library('SummarizedExperiment') plotReducedDim( sce, dimred = 'PCA', colour_by = 'my_cluster_variable', theme_size = 20 )
now looks like this:
plotReducedDim( sce, dimred = 'PCA', colour_by = 'my_cluster_variable', theme_size = 20, point_size = 5 )
Other examples involve different websites and showcase the diversity of questions we have as a team.
I hope that you like this idea and try it out yourselves. Maybe some of the lessons you learn trying it out could be useful to us as well. Ultimately, the information stored there could be useful for new team members as well as for current members since the spreadsheet becomes like an informal FAQ or team wiki.
I was strongly encouraged by the feedback two members gave me individually after our trial session. Maybe this is not for everyone as we realized that it’s quite hard to be anonymous while participating 7. This idea could evolve into something else, but at least for today, I’m happy with the amount of people that bought into the trial and participated in it. We’ll see what happens next.
This blog post was made possible thanks to:
- BiocStyle (Oleś, Morgan, and Huber, 2020)
- blogdown (Xie, Hill, and Thomas, 2017)
- ggplot2 (Wickham, 2016)
- knitcitations (Boettiger, 2019)
- scater (McCarthy, Campbell, Lun, and Willis, 2017)
- sessioninfo (Csárdi, core, Wickham, Chang, et al., 2018)
- SummarizedExperiment (Morgan, Obenchain, Hester, and Pagès, 2019)
I would also like to acknowledge the general inspiration I’ve gotten from Alison Hill’s educational work. Once the
rstudio::conf(2020) videos are available, check the work her intern Desirée de Leon showcased which is related to the following tweet.
Ever seen a giraffe that can fit in a teacup? Time to share the first draft of the R and stats project that Hasse Wallum and I have been working on for some time. More to come! #rstats ???? https://t.co/SOlBzop8vz— Desirée De Leon (@dcossyle) August 14, 2019
P.S. dinámica in Spanish is used for a set of exercises that have a specific purpose in mind. I now realize that dynamic doesn’t hold the same meaning. Oh well ????????
 D. J. McCarthy, K. R. Campbell, A. T. L. Lun, and Q. F. Willis. “Scater: pre-processing, quality control, normalisation and visualisation of single-cell RNA-seq data in R”. In: Bioinformatics 33 (8 2017), pp. 1179-1186. DOI: 10.1093/bioinformatics/btw777.
 M. Morgan, V. Obenchain, J. Hester, and H. Pagès. SummarizedExperiment: SummarizedExperiment container. R package version 1.16.1. 2019.
## ─ Session info ─────────────────────────────────────────────────────────────────────────────────────────────────────── ## setting value ## version R version 3.6.2 (2019-12-12) ## os macOS Catalina 10.15.2 ## system x86_64, darwin15.6.0 ## ui X11 ## language (EN) ## collate en_US.UTF-8 ## ctype en_US.UTF-8 ## tz America/New_York ## date 2020-02-12 ## ## ─ Packages ─────────────────────────────────────────────────────────────────────────────────────────────────────────── ## package * version date lib source ## assertthat 0.2.1 2019-03-21  CRAN (R 3.6.0) ## beeswarm 0.2.3 2016-04-25  CRAN (R 3.6.0) ## bibtex 0.4.2.2 2020-01-02  CRAN (R 3.6.0) ## Biobase * 2.46.0 2019-10-29  Bioconductor ## BiocGenerics * 0.32.0 2019-10-29  Bioconductor ## BiocManager 1.30.10 2019-11-16  CRAN (R 3.6.1) ## BiocNeighbors 1.4.1 2019-11-01  Bioconductor ## BiocParallel * 1.20.1 2019-12-21  Bioconductor ## BiocSingular 1.2.1 2019-12-23  Bioconductor ## BiocStyle * 2.14.4 2020-01-09  Bioconductor ## bitops 1.0-6 2013-08-17  CRAN (R 3.6.0) ## blogdown 0.17 2019-11-13  CRAN (R 3.6.1) ## bookdown 0.17 2020-01-11  CRAN (R 3.6.0) ## cli 2.0.1 2020-01-08  CRAN (R 3.6.0) ## colorout * 1.2-1 2019-05-07  Github (jalvesaq/colorout@7ea9440) ## colorspace 1.4-1 2019-03-18  CRAN (R 3.6.0) ## crayon 1.3.4 2017-09-16  CRAN (R 3.6.0) ## DelayedArray * 0.12.2 2020-01-06  Bioconductor ## DelayedMatrixStats 1.8.0 2019-10-29  Bioconductor ## digest 0.6.23 2019-11-23  CRAN (R 3.6.0) ## dplyr 0.8.3 2019-07-04  CRAN (R 3.6.0) ## evaluate 0.14 2019-05-28  CRAN (R 3.6.0) ## fansi 0.4.1 2020-01-08  CRAN (R 3.6.0) ## GenomeInfoDb * 1.22.0 2019-10-29  Bioconductor ## GenomeInfoDbData 1.2.2 2019-10-31  Bioconductor ## GenomicRanges * 1.38.0 2019-10-29  Bioconductor ## ggbeeswarm 0.6.0 2017-08-07  CRAN (R 3.6.0) ## ggplot2 * 3.2.1 2019-08-10  CRAN (R 3.6.0) ## glue 1.3.1 2019-03-12  CRAN (R 3.6.0) ## gridExtra 2.3 2017-09-09  CRAN (R 3.6.0) ## gtable 0.3.0 2019-03-25  CRAN (R 3.6.0) ## htmltools 0.4.0 2019-10-04  CRAN (R 3.6.0) ## httr 1.4.1 2019-08-05  CRAN (R 3.6.0) ## IRanges * 2.20.2 2020-01-13  Bioconductor ## irlba 2.3.3 2019-02-05  CRAN (R 3.6.0) ## jsonlite 1.6 2018-12-07  CRAN (R 3.6.0) ## knitcitations * 1.0.10 2019-09-15  CRAN (R 3.6.0) ## knitr 1.27 2020-01-16  CRAN (R 3.6.0) ## lattice 0.20-38 2018-11-04  CRAN (R 3.6.2) ## lazyeval 0.2.2 2019-03-15  CRAN (R 3.6.0) ## lifecycle 0.1.0 2019-08-01  CRAN (R 3.6.0) ## lubridate 1.7.4 2018-04-11  CRAN (R 3.6.0) ## magrittr 1.5 2014-11-22  CRAN (R 3.6.0) ## Matrix 1.2-18 2019-11-27  CRAN (R 3.6.2) ## matrixStats * 0.55.0 2019-09-07  CRAN (R 3.6.0) ## munsell 0.5.0 2018-06-12  CRAN (R 3.6.0) ## pillar 1.4.3 2019-12-20  CRAN (R 3.6.0) ## pkgconfig 2.0.3 2019-09-22  CRAN (R 3.6.1) ## plyr 1.8.5 2019-12-10  CRAN (R 3.6.0) ## purrr 0.3.3 2019-10-18  CRAN (R 3.6.0) ## R6 2.4.1 2019-11-12  CRAN (R 3.6.1) ## Rcpp 1.0.3 2019-11-08  CRAN (R 3.6.0) ## RCurl 1.98-1.1 2020-01-19  CRAN (R 3.6.0) ## RefManageR 1.2.12 2019-04-03  CRAN (R 3.6.0) ## rlang 0.4.3 2020-01-24  CRAN (R 3.6.2) ## rmarkdown 2.1 2020-01-20  CRAN (R 3.6.0) ## rsvd 1.0.2 2019-07-29  CRAN (R 3.6.0) ## S4Vectors * 0.24.3 2020-01-18  Bioconductor ## scales 1.1.0 2019-11-18  CRAN (R 3.6.1) ## scater * 1.14.6 2019-12-16  Bioconductor ## sessioninfo * 1.1.1 2018-11-05  CRAN (R 3.6.0) ## SingleCellExperiment * 1.8.0 2019-10-29  Bioconductor ## stringi 1.4.5 2020-01-11  CRAN (R 3.6.0) ## stringr 1.4.0 2019-02-10  CRAN (R 3.6.0) ## SummarizedExperiment * 1.16.1 2019-12-19  Bioconductor ## tibble 2.1.3 2019-06-06  CRAN (R 3.6.0) ## tidyselect 0.2.5 2018-10-11  CRAN (R 3.6.0) ## vipor 0.4.5 2017-03-22  CRAN (R 3.6.0) ## viridis 0.5.1 2018-03-29  CRAN (R 3.6.0) ## viridisLite 0.3.0 2018-02-01  CRAN (R 3.6.0) ## withr 2.1.2 2018-03-15  CRAN (R 3.6.0) ## xfun 0.12 2020-01-13  CRAN (R 3.6.0) ## xml2 1.2.2 2019-08-09  CRAN (R 3.6.0) ## XVector 0.26.0 2019-10-29  Bioconductor ## yaml 2.2.0 2018-07-25  CRAN (R 3.6.0) ## zlibbioc 1.32.0 2019-10-29  Bioconductor ## ##  /Library/Frameworks/R.framework/Versions/3.6/Resources/library
So you can link to specific lines and see things you changed through time that might be the source of the problem are among the main reasons why you should try to version control your code.↩︎
Potentially to a more interesting problem than the one you are stuck currently at.↩︎
For example, some use a particular project Slack channel, others the lab one, others through direct messages.↩︎
If you say that something is obvious or easy, you are telling the other person that it should be easy for them too, but we know that it isn’t the case and that’s why they are asking a question.↩︎
If we want to incorporate this exercise into our weekly meetings (maybe once a month), we need to make sure that our team meeting will finish on time.↩︎
The use of keywords can dramatically affect a search results, and this information is useful to convey among ourselves so we can learn to search for help more effectively.↩︎
Basically, you can only be anonymous for those not in the room at the time the question was discussed.↩︎
Please visit source website for post related comments.