Extreme Sciencing

There are a lot of ways to make presentation better. And we should, since since is at least 75% presenting and talking about our work. Here some recent ideas from discussion reported by @AcademicChatter:

My rule of thumb is: "If you don't explain it, don't put it on the slide."

Anyone else have PPT advice they want to share?#phdlife #phdchat #AcademicTwitter @AcademicChatter https://t.co/gNIhdzJQg5

— Fay Lin (@xiaofei_lin) April 24, 2019

Don’t be afraid to repeat slides! If you find yourself saying, “now if you remember the graph on slide 6”, just copy slide 6 and put it where you want to refer to it again.

— Eric Mills (@cartoon_physics) April 24, 2019

Have backup slides. You can anticipate or will experience common questions or follow-on detail/data that audiences will ask. Have those slides/data prepared and ready to go after your formal presentation.

— Luis Martinez (@TULuisMartinez) April 24, 2019

I always tell students not to put things on slides they can't explain (because it could be a question) , and that the audience may listen to you, read your slides but rarely do both

— Prof Rebecca Ritchie (@rebeccahritchie) April 24, 2019

And a sad investigation when slides go wrong

A story from @mcdreeamie of how wordy PPT literally killed seven people.
Spoiler alert: It took @EdwardTufte expertise to sort out ALL the ways they went wrong. https://t.co/cYQ4IGqUUu

— Academics@Work (@workingacademic) April 24, 2019

This page describes set of principles we try to follow in our day to day science job. These ideas are stolen from many areas, mainly from software development practices.

We try to follow these methods ourselves and implement them in our teams

Latest version can be found and forked on Github: https://github.com/aandreev0/extremesciencing

Key elements

• Agile: main goal is successful research, not following some sort of “best practices” list
• Rapid: We aim to move swiftly through the project, figuring bottlenecks as soon as possible
• Responsible: We acknowledge that mistakes will be made and proactively look for ways to lower risks

Notes on research

Result of sciencing is clearly presented high-quality scientific results. It can be delivered as statistically significant observations of nature. It can be delivered as novel useful experimental protocols or data analysis tools that help discovery.

Notes on engineering

Central idea for engineers is that they design and deploy products, something tangible that will be used by other people. This could include microscopes, behavioral experimental setups, analysis and control software, data management solutions, and other elements of research environment.

This means that projects should be treated in such a way that:

• Development should be based on written specification, result of constant conversations between users and engineers
• Final product includes evolving documentation
• Final product includes documented way to track issues and users’ requests for new features, as product will contain bugs, but also evolve

Notes on people

• We acknowledge that being people is hard and painful.
• We acknowledge that talking to people is hard and painful but it is the only thing that ever moved complex projects forward sustainably

References and reading

• Agile manifesto: http://agilemanifesto.org/
• Google SRE Book: https://landing.google.com/sre/book.html
• Peopleware: https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams
• Mythical man-month: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
• Making things happen: http://scottberkun.com/making-things-happen/
• Scalable Meatfrastructure: Building Stable DevOps Teams: https://www.usenix.org/conference/lisa15/conference-program/presentation/goldfuss
• LabScrum: adaptation of Scrum method to academic research https://labscrum.org/

Contributing authors:

• Andrey Andreev (me@aandreev.net)