Did you come into Python from a computational science side of things?
Were you just looking for something better than Excel and MATLAB and you got pulled in
by all that Python has to offer?
That's great.
But following that path often means some formal practices from software development weren't
part of that journey.
On this episode, you'll meet Martin Haru, who does data science in the context of academic
research.
He's here to share his best practices and lessons for data scientists of all sorts.
This is Talk Python to Me, episode 252, recorded January 30th, 2020.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter
via at Talk Python.
This episode is sponsored by Clubhouse and Linode.
Please check out what they're offering during their segments.
It really helps support the show.
Hey everyone, a couple of announcements.
First, I have a very exciting new course that we just launched this week.
If you've always wanted to solidify your programming foundations and get into Python, but you've
never had the chance to take a computer science course, I built a course for you.
It's called Python for the Absolute Beginner.
It's for absolute beginners because we start from the very beginning.
How to install Python?
What is a variable?
Why do we need loops?
And so on.
And then we go on to build some really fun projects that will teach you 80% of the Python
language.
Another challenge people run into when learning programming is having something to work on
that's not too big, not too small, but just right that'll actually teach them what they're
studying.
That's why this course is 50% video lecture and 50% hands-on exercises.
So if this sounds useful to you or to your colleagues, visit talkpython.fm/beginners to find
out more.
Another quick announcement.
Last week, we had a brand new sponsor, Springboard.
I'm super happy to have them supporting the show, but I did forget to mention something that
I think will be really useful for a lot of you.
If you want to take one of their AI or machine learning online career tracks, they're offering
20 scholarships worth $500 each exclusively to Talk Python listeners using the code Talk Python
to me, all one word, all caps.
And it only takes 10 minutes to apply.
So that's the thing I left out.
Use that code, get the $500 scholarship, Talk Python to me, all one word.
Just visit talkpython.fm/Springboard if you're interested.
And another announcement.
Recently, we've had to trim back our RSS feed length.
It had all 252 episodes in there, all the show notes and everything.
And as far as I was concerned, we were going to ship those to you all.
As long as we could.
I want to make sure that everyone can go back through the entire catalog and get everything
that they want.
And yet, because of the size, I think some of the players, especially in the Apple ecosystem,
started to go crazy and ship old episodes as if they were new and to not show the latest
ones.
And all sorts of weird things started happening.
So in order to fix this, or let's say rather in order to attempt to fix this, and it seems
to have worked, we've reduced our RSS feed to only show the last half a year of episodes.
Again, that's not because we don't want you to get the old ones.
That's because we want you to get at least the new ones.
So what a pain.
But I know that some of you are going through the entire catalog and learning as you go,
trying to go through the entire history of what we've done, which thank you.
That kind of blows my mind.
That's an incredible effort.
So what I've done is I've also made a separate RSS feed that is not part of the subscribe
at iTunes or subscribe at Google Play feed because that's where the problems were.
If the entire RSS feed works for your player, you're welcome to have it.
I put it up at talkpython.fm/episodes /rss underscore full underscore history.
You can get that in the links for your in this show in the show notes here.
And you can also get that on the footer of every single page at talkpython.fm.
So that's the easiest way to get it.
Just go to the bottom, look for the RSS full history link and put that link directly into
your podcast player if you want to get the full history.
If you're happy with the latest half year, just do nothing and make sure you're subscribed
as you have been and you'll keep getting the new episodes, hopefully without any hiccups
this time.
Martin, welcome to Talk Python to Me.
Hi, Michael.
How's it going?
Hey, it's going really well.
I'm happy to have you on the show.
Thank you very much for having me.
Yeah.
We're going to talk about the science side of Python, which I think is a really interesting
place to talk.
You know, if there's that famous, well-known article called entitled The Incredible Growth
of Python done by the data scientists at Stack Overflow.
And there's this super sharp inflection point around 2012 where the growth of Python, which
had been pretty stable, it was like a third, fourth tier rank language.
And then it just took off at that point and went up and up and up.
And I think my theory is a lot of people came in from data science, but I think that that
kind of overshadows that there are just a lot of people that started adopting Python for
this a little bit beyond Excel or the first, I just need to do a little coding or I just
need to do a little automation.
And I think people are just coming into this from so many angles.
And I think that a large portion of that probably is scientists.
What do you think?
I totally agree.
I mean, that's how I came into getting into Python was a transition from MATLAB, for example,
as a early first language for anybody who's interested in doing just that little bit of
automation, that little bit of something to go beyond Excel.
I think Python's perfect.
And now with the tooling and, for example, Anaconda, those types of things, it just makes
it so accessible.
Yeah, absolutely.
You know, my theory, the reason it's really popular is you don't have to take on all the
computer science ideas and concepts all at once.
You don't have to have a static class and a function with accessibility modifiers and
all that.
It's just like, well, just write the three lines you need here.
And then, oh, if you need this idea of functions, then you can learn them.
If you need classes, you can learn them and so on.
It's really, really approachable.
Yeah, no, I totally agree with that.
For sure.
And now, before we get too much into our topic, let's start with your story.
How'd you get into programming in Python?
Unlike some of your previous guests, I'm not your traditional path person.
I'm a physiotherapist by training.
And then after that, went on to do graduate work.
And it's after my master's, did a PhD.
And it's during the PhD that I learned two different languages that are very different
from each other.
One of them was LabVIEW programming.
And that was for my data acquisition and interface for data collection.
And that's, I guess you can call it coding.
Is it more of a visual type of day, like ETL type thing?
Yeah, and you connect your lines.
And one person, when they saw the back, not the front end, but the back end of my program
one said, it looks like a bomb diagram, which, you know, it kind of, I guess it does.
So it's all this spaghetti behind the scenes.
The logic is there once you understand coding, but it doesn't teach you how to program properly.
But then at the same time, my supervisor took on the task of teaching me MATLAB, which by
the end of my PhD, I was quite competent in.
And it was a great skill.
Those two together worked quite well.
And then I progressed, did my postdoc and continued that, a lot of MATLAB.
And then it was really, I'd heard of Python from a colleague that went to do some post-grad
work in San Francisco.
And I met her at a conference and she says, oh, the folks I work with use Python.
And so me being just curious, I went and looked at it, but that was probably, you know, 2007,
2008 or something.
And I kind of read on it, read up, I saw these tutorials on, you know, going to Python.
from MATLAB.
But the tooling still wasn't there, the how to install it, how to get the various packages.
I tried for a couple of weekends and then I just kind of gave up because obviously I was
proficient at MATLAB and I didn't, I'm not a programmer.
I just wanted to get my job done, my research done.
So, right.
And a lot of the stuff, the data science tools and libraries were just early seeds growing
at that time, right?
I think NumPy came out, it was created around that time and probably Matplotlib and Jupyter
wasn't around yet.
So there was a lot of support that wasn't there, right?
Exactly.
So for somebody who's, you know, in a sense, a non-expert, it was just too daunting.
And so therefore I went back to MATLAB and then it was just, finally, I'm a Linux person.
I started that in probably 2010 maybe and I've never looked back.
I've been using Linux the whole time.
So I'm quite...
What distribution are you on these days?
Linux Mint or Ubuntu kind of depends on pretty much how I'm feeling on the day that I install,
but it's between those two usually.
Okay, cool.
It's just what I've run on my computers.
I put it on my mom's computer so I can help her out from a distance because it's kind of
easy.
You can use older computers and just use it in the lab or for some of the experiments we
run.
We just need basic computers.
So I just thought it was a nice way to reuse some of the equipment.
And then with this open source kind of mind and that I had, Python started to be a little
bit more appealing and then I looked a little, again, revisited it, partly because I was looking
at the courses for software carpentry, which is this thing that teaches scientists that have
no computer skills, some of the basic skills and usually around either R or Python and you
get a bit of shell and you get some Git.
And so that really made me look again into Python.
And from there, that's all I've been using for the last maybe four or five years now.
Beautiful.
Yeah, the software carpentry stuff is pretty interesting.
I've had the folks behind that on the show before.
It's not a lot, right?
It's not a lot to get you started.
It's a couple of days, a little bit of, it's not even all programming.
It's here's how to use a shell and here's what source control is and so on.
But at least it plants the seed like, hey, these are things you should pay attention to.
Yeah, it's really, here's the landscape of a few things and it's a teaser.
But if you have some labs or some institutions, it's the culture.
They use R for example, if they do a lot of genomics, for example, everybody's using R.
And then it's okay because then you leave the course, the introduction, then everybody around
you can help.
But at our institute, I did run some software carpentry course.
And it's hard, the uptake, because we're so diverse in what we do because there's people
who do genomics at where I work.
And then there's other people who do really just kind of epidemiology type things.
And so the range is so difficult, different that the needs are different.
So it's a good format, but it doesn't apply for all.
That's kind of what I found along the way.
Yeah, for sure.
It sounds to me like reading some of the stuff you've written and looking through some of
the stuff you put out there that we've talked to data science folks and even scientific computation
folks who also have maybe some programmers around them or some kind of software stuff going
on as well, where most of their work revolves around code.
But it sounds to me like what you guys are doing, it's a little bit more like you're
scientists out there on your own.
And yeah, here's some stuff that you can learn and use.
But when you get stuck, you know, you're kind of alone on the internet sort of.
Is that right?
Pretty much it is that while it'd be nice if we had a big amount of funding to have dedicated
people to program and to automate some of our things, it's just not the case that the funding
is not all that great pretty much around the world.
But so if you're working in one of those places that has that, it's great.
But most of everybody else, we just have to, you know, figure it out ourselves.
And that's kind of how I learned is just by either I could continue to do this pointing
and clicking and realizing the mistakes I was making and not able to reproduce anything and
those types of things or teaching yourself.
But that's not easy.
It's a bit overwhelming, I think.
Whereas rather than having not enough resources, I think it can be overwhelming because there's
just so many resources for people.
And unfortunately, we're strapped for time.
And so that's a big stress on people at this more senior level.
They just feel they don't have the time.
And the students, well, they have a little bit more time.
But if their supervisors and the people above them aren't necessarily coding, well, then they
don't feel the need as much to learn it because obviously other people got by without it.
And so it's to try and for myself, it's definitely, as you have said on your show a few times,
it's my superpower, really.
It's things that other people just can't even fathom could be answered.
I'll just take the data and do a few things in Python and then get them the answer pretty
quickly.
Yeah.
They're like, I don't really even know if we can answer this question.
You're like, give me pandas and five lines of code and we'll see what we can do with this.
Right.
Exactly.
Yeah.
And part of it is actually not even just the fact that maybe they don't need to do it
or learn how to do it, but just know that it's possible.
Yeah.
And value that in terms of valuing it, I think that's what's interesting is that regardless
of what type of science you're doing, in the end, it's all based around computers.
It almost doesn't matter what field you're in.
You're going to be most of the time dealing with data.
And so to be able to do that in a repeatable, efficient manner, as you always say, computers
are really good at that, the mundane, repetitive tasks.
Yeah.
So why not automate it?
People are noticing.
And I think there's a push that even from the senior people, even though they might
not know, I think they see that, okay, that's, this is where it's going.
Yeah.
That's a little bit challenging when the incentives don't necessarily line up.
Right.
The, the experienced folks, they're busy.
They've got stuff to publish and research projects.
They'd like to learn, but at the same time, you know, they've got a job, they've got a family
or whatever.
Right.
They've got classes to teach or people to mentor in their field.
So that makes it really challenging.
I think as well.
Yeah, no, it's, it's, the pressures are very high and this whole publisher perish thing,
although some people throw it around as a joke, it really is true, unfortunately.
And it's in that model where, you know, rather than focusing on good science, that's reproducible
that, you know, that's what you expect.
When I was a kid growing up, these scientists are just, you know, these amazing people that
wear white lab coats most of the time you would think, and that are just extremely careful.
And I think we're just people trying to get by and, you know, the incentives make it that
we do have to do a lot of work.
And a lot of times we might cut some corners.
It's just the way it is.
We just have to get a lot out there.
And there's a lot of pressure to do that rather than take a bit of time and either do it carefully
or learn some new ways to make it last a little bit longer in terms of I can pass on
my data with the code and somebody else can reuse it.
Later on, my future self, I can reuse it or convince myself or convince others that, hey,
this was actually the real answer kind of thing.
Yeah.
I'm having a hard time even coming up with an example where you're doing research and there's
not a lot of data to be processed.
You know what I mean?
Yeah.
Like, what field is it possible?
Like, well, we have seven things.
We're going to study these seven.
I'll just put them on a line or like almost anywhere that people are doing research now,
there's so much data available that you can collect in whatever way, whether it be economics,
you can just go load up all the data about all the economies and all the purchasing and habits
and whatnot.
Or, you know, if you're doing neurology, you can, the amount of EEG data or whatever is ridiculous.
Right.
So it seems like programming is a really important skill just to almost be functional these days.
Well, definitely.
And I think that in this, for myself, it actually started with, first, it was a bit of electronics.
And I didn't know anything about that, obviously, being a physiotherapist.
And I ran into trouble.
And then I almost stalled my PhD for, was it six or eight months just because of a simple
wire, a couple of wires that needed to be soldered together and connected.
And nobody where I was from knew anything about that.
And it took a long time just to find the right person.
And I was like, never again am I going to have to be not self-sufficient.
So I taught myself electronics.
And then I think with programming, it was the same thing is that you can find the right
people.
But either it's going to take time and money.
And it's not always if they're not exactly in your field, they'll do their best.
And then it's going to be multiple iterations to get to the final what you would like.
And you don't even understand how it got there.
So I think this idea of learning just enough to get you by really is quite valuable.
And as you go, the learning curve, although it's Python and it's obviously easier than other
languages, if it's not your thing, it's a big learning curve.
The ideas of programming at the same time, you don't want to just learn programming.
You want your results.
That's number one.
So you're juggling all these things.
But once you get over that curve, the big learning is done.
And then it's just adding on for each new project.
You might learn a new technique.
You might learn, oh, now I'm going to use databases or now I'm going to learn Git and
now version control my code and things like that that come along.
So it's how to do it progressively, not get intimidated and not just say, oh, I'm going
to go back to my point and click programs because at least I can get the results quickly.
Exactly.
Or Excel.
Yeah.
Excel.
I try not to use that word and it's not my, I have a fear.
Yeah.
I have an allergy to be honest.
I walk by the people who have those screens open and I, oh, I just, yeah.
Yeah.
I don't, I personally have this thing about Excel and science.
It just really, for more than just a simple, you know, keeping a few numbers or doing some,
you know, basic adding or addition or stuff like that.
It's fine.
But it really, I mean, it just doesn't have a place in my opinion nowadays.
So, yeah.
Well, I think the problem is like, it's fine for the simple case.
Like I use Excel for accounting and the stuff that we do.
And it's, it's great.
It's got to take a few numbers.
It's got to add this column and it's got to divide by that and put, you know, 20% over
there.
I don't know what, something like that.
Right.
That's fine.
We did a whole episode on Excel with Chris Moffitt, episode 200, escaping Excel hell with
Python and bandas.
And that was a lot of fun.
One of the things that dawned on me that really makes these worksheets in Excel or any, you
know, could be Google sheets.
It's really no, no difference.
That makes it really tricky is it's kind of full of go-tos.
You know, when you, when you have a formula that's down here in like a 32 and then it says
add stuff over there and then make this decision and then take that from over here.
And then there's a formula over there.
It's like, there's no way to look at it and tell what order that it flows.
Right.
It's just go here and go there, then go back over there, then take some of this.
And yeah, it's just, it seems like it takes some of the worst practices when you try to
push it too far.
Yeah.
I think if it fits on a page and, and you've got a few pages, I think, you know, and everything
is self-explanatory.
I'm okay with that.
And, you know, even though I've done that for a survey that I published with one of the papers
that I wrote and it was the best way to present it.
But when you've got a lot of those embedded formulas, I, as a person opening it, have no
idea what's the flow of all of this and the bigger they get.
And that's, you know, there's research that's been done and people who've analyzed Excel spreadsheets
is that for every hundred things that you do in Excel, there's going to be approximately
five errors.
And the more complex it is, the more likely you're going to make these mistakes.
And I think the hardest ones are, for example, the one that came across in some of the data
that I was involved in, I asked to see it this, for example, take the average, because
we did three responses from somebody, take the average of the three.
But what happens is there's a missing data point.
Well, just by default, from what we did, Excel puts a zero.
So now you're averaging two numbers with a zero.
And it was just, but you had to search through it.
And it was like in, you know, page number eight on, you know, this II52.
And they're very difficult mistakes to find.
Whereas coding, if it's done, you know, if you choose your variable names well, and you
do a bit of documentation, it can almost read like a story.
And you can, even somebody who can't code necessarily can at least follow and kind of, or you could
just sit down with them and just tell them the story of the code.
And they might be able to say, that doesn't make any sense.
Yeah.
Wait, you're doing this wrong, right?
Whereas Excel is much more nebulous.
Yeah.
It's very vague.
This portion of Talk Python to me is sponsored by Clubhouse.
Clubhouse is a fast and enjoyable project management platform that breaks down silos and brings
teams together to ship value, not features.
Great teams choose Clubhouse because they get flexible workflows where they can easily customize
workflow state for teams or projects of any size.
Advanced filtering, quickly filtering by project or team to see how everything is progressing.
And effective sprint planning, setting their weekly priorities with iterations and then
letting Clubhouse run the schedule.
All of the core features are completely free for teams with up to 10 users.
And as Talk Python listeners, you'll get two free months on any paid plan with unlimited users
and access to the premium features.
So get started today.
Just click the Clubhouse link in your podcast player show notes or on the episode page.
So you wrote a blog post called Errors in Science.
I make them.
Do you?
Part one, two, three.
And I'll link to part three.
And one of the things I found amusing from there was you actually linked to an article which
talks about the 12 of the biggest spreadsheet fails in history.
Do you remember that article?
Yes.
It's pretty scary.
And I mean, in our case, well, I guess it could some of these mistakes, you know, they
lead to in science lead to retraction with the biggest problems would be that.
And that's kind of a big embarrassment and something we don't want to do.
Right.
And other people can write based their conclusions on a paper that then has retracted.
So it's kind of a bit of a house of cards as well.
Exactly.
You know, and unfortunately, some people, even though it's retracted, some people continue
citing the original one, which is, you know, you're not supposed to do, but people
haven't realized it's been retracted.
So it's a bit of an issue.
But some of the other ones that, you know, if you do this in the financial industry,
that there are some companies that, you know, very simple Excel mistakes have led to, you
know, millions and millions of dollars being lost.
And so, yeah, so that article just kind of highlights the some of the worst.
And the European Union actually has a whole kind of group that's working on this and dealing
with how can we improve these practices with regards to spreadsheets because the mistakes
are so costly.
Right.
I'll just read just a couple because I think they're kind of amusing.
Hans Alta, a Canadian company, made a cut and paste error in their spreadsheet and it cost
them $24 million where they caused them to buy.
They bought some U.S. power transmission hedge contracts at the wrong rate.
Fidelity, their Magellan fund, which is like an investment mutual fund type fund thing.
They had to cancel a $4 per share dividend because they had a missing minus sign.
So they thought they made a profit instead of a loss.
MI5, the British spy agency, actually bugged over a thousand wrong phone numbers.
There's just like all these weird errors.
Anyways, a really fun read for people that get, you know, sucked into that world.
So there's the drag and drop lab view type stuff, which is not that great.
There's some just not very much programming skills at all.
Maybe a little MATLAB.
There's trying to over leverage Excel.
A lot of these could be fixed by, you know, a little bit of Python, a little bit of pandas
or, you know, whatever library it is that works with the type of data that you're using.
Right.
Yeah.
And I think with Python, it's the fact that, and you've mentioned this yourself, it's just
the Swiss army knife.
It's that MATLAB has a license and its application is very, you know, engineer, math and science
focused.
Whereas Python, I had a master's student who came and finished with us.
And I kind of, his first study, he programmed with me.
Second study, he did most of it.
And I just looked over shoulder and made sure everything was okay.
But he went on now and he's working.
You know, in a sense, he's got a new superpower is that it's universal.
He can use it for such a variety of things.
That's not specifically for science.
So while it's obviously great, the learning curve isn't that steep if you've got a bit
of time and it's just so diverse rather than some of the more specialized languages.
So I think as an introduction, Python, I mean, it really, it's so simple, easy to read.
And it's a new skill.
That's kind of how I sold it to the institute where I work at here in Australia is they were
looking for ideas for almost like a vision for 2022 or what.
And I just said, well, wouldn't it be great if we could advertise that every student that
comes and does a PhD with us will have basic skills in at least one programming language
when they leave.
And they thought that was a great idea.
So that's how I pitched it that, you know, in this day and age, it's got to be part of the
education, not simply the, you know, sitting at the workbench or working with spreadsheets.
Yeah.
Something you just have to pick up in your spare time as part of your research project
or whatever.
Be better if it was more, right?
Because we have tons of spare time when we're doing our PhDs.
It's evenings and weekends.
And it's the few of us who are, you know, a bit silly enough to do it, bit hermits.
And we just do it on our own because we just feel the need to do it.
But yeah, a lot of other people, you know, sensibly don't do it.
And that's fine.
But I think in the long term, if it's become more acceptable and it's actually presented
right from the beginning that, hey, this is how it is.
You're going to learn a bit of programming to learn a bit of this.
It just becomes part of the learning process rather than when you just, it would be nice
if you learned it, but there's no structure.
We're not going to teach you and I'm not going to point you to any resources.
That's difficult for a lot of learners.
Yeah.
Well, I think it's a great service to offer that to your students, right?
To say, you're going to learn whatever it is you're here to study and get your master's
degree in or whatever it is.
And also you're going to have this programming skill in the context of that, because I'm sure
that if you go out there and apply for a job and there's 10 people, probably more, but let's
say there's 10 people apply.
Two of them also have good programming skills that are relevant to that in addition.
And all things being equal, like that's down to two candidates.
You know what I mean?
Yeah.
So it's really great.
Now, one of the things you did that I'd like to just chat a little bit about, I think is
interesting, is you did a survey around scientific computing at your institute, right?
Yeah.
So yeah.
So let's talk about that a little bit.
What was the survey trying to get at and what were some of the results?
Well, after I pitched this idea of training, obviously I have some ideas.
I'd done the software carpentry teacher training.
So I had my own opinion of how it all should work.
But again, who am I to say how everything should run and what are the needs of the people?
Especially because where I work, there's people who work on cells.
Some people work on epidemiology.
Some people work on human research.
And the fields are as different as schizophrenia, falls in balance, people with vestibular issues.
We study the gamut.
And so rather than impose what I thought people would need, I just said, hey, you know, we've
got these easy survey online things to do nowadays.
So how about I just create a little survey, get some information because I'm a scientist.
I like data.
So I just said, let me get some data so I can make informed decisions.
And also it allows me to track.
If I were to continue this over time, I'd be able to see how people are changing.
So it was a variety of questions based on, you know, what field are you in?
What's your level of training or education?
And currently, what are your current practices?
And then looking at in terms of what would you want to learn?
How would you want to learn that?
And those types of questions.
Right.
So I sent out the survey.
Our institute, I can't really say the number right now.
It's probably where we're now above 200 people for sure.
I think depends on how many of the students are present, but it's a biggish institute, but
not all that big.
But we had 80 people respond.
And it was nice because senior scientists replied, senior postdocs, postdocs, students, and a
few staff as well.
So the responses kind of reflect a bit of everybody.
And so that was kind of nice.
And yeah, it's good.
As you might expect, we're not, you know, it's not, it's not all that surprising that
pretty much everybody analyzes data with computers.
There's some that don't.
And I would have to say, well, it's possibly some of the staff and also some of the senior
people.
It's kind of why I don't want to become the most senior scientist, because at some point
you almost stop looking at the data.
You entrust the pyramid of senior postdocs and postdocs and students to handle the day-to-day
data.
And so they kind of don't do that.
But most people, as part of their job at some point, manage.
Some form of data.
So it is a useful, it's just become, this is what we do.
We manage with data.
And most people want some form of training or knowledge.
And I guess one of the unsurprising, as we were talking before about Excel, is that most
people, 80% or so, do stuff with Excel.
And that's okay.
But what's surprising to me, and I guess because Excel is even easier to pick up, is the fact
that nobody's actually got, most people, 20% only had actual training, had done a course
of some sort with regards to Excel.
Yeah.
I think people think Excel is easy.
In some sense, it is easy.
But that can be a really advanced tool.
When I was in college, I took a course on basically like spreadsheets.
And man, back in the day, it was like Lotus 1, 2, 3, and all sorts of random things that aren't
really around anymore.
But I remember learning, I felt like I can use Excel, I can load data, I can do formulas,
whatever.
Like, there's a lot to learn about stuff that you can do in there.
So that's, you know, that only one out of five get any real instruction on it.
That's surprising.
Yeah.
And, you know, I have a colleague who went off and kind of did an online course for Excel.
And, you know, he came back and everybody was really impressed.
And just, he was showing everybody new things.
And so, done properly, as he was doing it, I could see that, okay, it's not as bad as I
used to picture it.
But unfortunately, he's one out of, you know, everybody I've ever come across.
And so, really, the majority of people are just think it's just point, click, add some
numbers, try a few things.
But, yeah, there's not much education behind it.
And I think what's interesting also in the survey, I asked about other tools.
So, for example, you know, we do a lot of data management or statistics.
And there's obviously the typical point and click programs.
And a lot of those have the equivalence.
But for, you know, you could do that in programming, is that many more people were using point
and click programs.
than people who would program.
Yet the ones that programmed always had more training.
Just because, obviously, to learn it, they had to do some form of training.
This is the point and click.
It's the problem that it's just, it's deceptively simple.
And I think statistics is one of those areas that, you know, I think a lot of people have
allergies to for some reason in science.
I kind of like them myself.
I think they're important.
And you got to understand them.
But with this point and click stuff, a lot of people just kind of click some buttons,
think it's okay.
And then this big output comes out with sometimes some figures.
A lot of times these big tables.
And they're difficult to interpret.
And yet some people just say, oh, where's my p-value in there?
And then they're just like, great, this one worked.
And if it didn't, well, you know, maybe click a few different buttons and see if the answer
changes.
Which is obviously not great science, but it does happen.
Whereas with programming, it's, you kind of have to know what you're doing from the get
go.
And so there's a lot less chance of that just kind of what people would call p-hacking.
It's just searching for and trying permutations of it until you get something that, oh, that
looks better or what I was expecting.
Yeah.
Well, if you're going to wire stuff together and push buttons, like it's almost always going
to give you an output, right?
So yeah, well, there's the answer, right?
Well, in programming, you kind of got to really think through it and line it up.
Or it's not going to give you an output, it's going to give you an exception, you know,
a traceback or something, right?
Yeah.
And I think the value of programming, for example, in those contexts, and it's one of those things
I'd never even thought of.
Now I do it almost all the time is that if I'm using a new statistic or I'm using a new
program to analyze my data, why risk putting in my own data that I spent all this time putting
in and hoping that I'm doing it right to get an answer rather than generate, which is quite
simple nowadays, generate some data that I know the answer to.
So, you know, simulate the data and put in some artifacts or put in a certain trend.
So it will give me a statistical result, run it through.
And is it as expected?
If so, great.
Then I can apply that to my actual hard earned data.
And I can kind of trust the data and the results a bit more versus other than that.
I'm sure there's people out there who work with statisticians on a day to day basis.
There's other people who themselves are quite competent, but my experience has been a lot
of people, a lot of labs, not everybody, but a lot of us kind of just do that.
We just collect data, put it in the program, fiddle about with our own data, and in the
end, see what kind of comes out that makes sense.
And hoping in the end, it's a hope that, okay, I think I did it right.
Yeah.
But it's pretty risky in terms of, you know, this is science and we're going to publish
it, make it publicly available.
So yeah, it was a bit of an eye opener in terms of, but what was nice is that my survey
highlighted that, okay, this is what people are currently doing, but what do people want
to do?
Are they interested in it?
And yeah, there was definitely a big interest in learning these skills.
One of the questions was about, do you think how valuable is it to have computer coding as
a skill currently?
And the average was, it's important.
And then the next question was, how is it for the future as a young, as a young investigator
in the future career?
How important is it?
And it was very important.
So it's highlights the fact that there's this shift to even the fields that may historically
not have incorporated coding into their education of their students are now seeing that, yeah,
well, maybe I don't do it as a senior or a postdoc.
But I think that for the future, even those people are acknowledging that it's valuable.
But as you might expect, one of my questions was trying to understand what would they want?
But most importantly, in a sense, what are the biggest problems?
Why aren't you coding right now?
Why aren't you learning?
And what are the obstacles?
And some of them are addressable.
Like lack of institutional resources.
Like you could have more of that.
Or you could have more examples.
But one of the biggest one in that area that you got for your survey was lack of time.
And it's hard to help people make more time.
Exactly.
I wonder whether that's a real problem or it's a perception.
I think that for people who, like myself, when I first got introduced to coding, it's the unknown.
And you think, my God, that's going to take me, you know, a year of my time.
Right.
These are like the wizards of Silicon Valley that like create this magical digital world around us.
And it's like engineering plus with all the math and everything.
It seems so hard from the outside.
And then you do it.
You're like, oh, that's all?
Well, that was not so hard.
Right?
I just called this library.
Exactly.
With all the new tools, it makes it much simpler.
My one piece of advice to students or people who come and ask me about these things is just pick one task in your next study.
Don't do the whole thing.
Just pick one thing.
Whatever you, if it's about the acquisition of the data or if it's just making your figures.
Or cleaning up the data.
Yeah.
Just pick one thing that you can automate.
And if you want, I can help you along.
Just do one step.
And it makes it so different than if you're learning from a book that's giving you examples about, I don't know, leeches or the economy or some other problem that doesn't relate to me.
Whereas this one, I'm actually building, using my learning to actually help me out.
You're going to find a solution because in a sense you have to.
But it's not daunting because you're not going out and learning everything that you need.
I'm not setting up a web page to present my data or to do a survey or whatever it is.
Just pick a simple, biteable chunk and then on your next study, just add to that.
And then you'll see.
That's really good advice.
Yeah.
I think that's why the lack of time, I think, is they think they have to just stop and learn.
And that's just not feasible.
Right.
I got to redo the way I do everything.
We're going to rewrite this whole thing.
Yeah.
Yeah, exactly.
Like, there's a bunch of little steps.
You know, I would say, what is the step that makes you the least want to work on this project?
You know what I mean?
Like, what is the most not fun thing you do?
Could you automate that?
Yeah.
And I guess the other one I've done for myself, actually, one of the big pushes to do Python,
especially for data acquisition, for some of the research I do, is a lot of taking responses
from other people.
And we do these perceptual illusions to know where your body is in space.
And we always have to get the answer.
And for me, it was after we were done these studies, the first few times I participated
in them and helped out, is once you look at the data and there's an outlier or a few points
that you're just like, that can't be right.
But then what do you do?
You go back and it's a piece of paper.
And then it's a number that I wrote.
And then I'm like, well, did I write it wrong?
Or did the person, you know, did I not understand what they were saying?
Or their accent might have been different.
And then you try to follow the chain and you're always, and I hated that because I had no real
reason to exclude the data based on a known error.
And that just frustrated me.
And it happened enough that I kind of built this system around testing these things that,
you know, it's all computer.
It's built around, well, Python with a bit of Pygame on top for the interface.
And in that way, now the data goes straight into the computer.
Each response is verified with the person who's given me the answer.
It shows it to them and says, is this actually what you answered?
And it's just saved so much trouble.
And now our study we just did had zero data that was even in question.
And so we've gone from a lot of stress and possibly a few data points that were wrong to now I live in peace that after the study is done.
And, you know, we get good, surprisingly, as experimenters.
If you do it over and over, you kind of, it's less stressful to run the experiments.
I can kind of think on my feet.
But when it's the students and it's their first time running an experiment, they're pretty stressed out.
There's a lot to think about.
And you could see how easily they could forget to, you know, to check something or to write something down that's not correct.
And then they go and, you know, copy paste that into the computer.
There's so many levels of errors that can happen there.
So for myself, part of it was early on the lowest hanging fruit.
But that one was one I had to tackle because I was just so insecure.
I didn't feel good about the fact that I just don't know.
I mean, I think, let's say, 95% of my data is right.
But can I get it to close to 100?
And I think we're nearing that.
And I think it was a big undertaking.
But now the system's there and we've used it multiple times over.
And, yeah, so you have to pick what's most important or, as you said, what's the most annoying job that you have to do.
And data entry for us was one of the huge ones.
Nobody wants to do that.
That's boring.
And so, yeah, just do it on the fly.
And then the computer does it perfectly every time as long as you, you know, again, test your code and make sure it's doing what you expect, which is a whole other story that we might get into.
Yeah, we should get into that as well.
But at least, you know, it's as long as the software is working right, it's the foundation, right?
Your data is the foundation of your research, which is the foundation of your papers and your work.
And you definitely want that to be right.
So if you can automate that.
This portion of Talk Python to Me is brought to you by Linode.
Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale that you need to take your project to the next level.
With 11 data centers worldwide, including their newest data center in Sydney, Australia, enterprise-grade hardware, S3-compatible storage, and the next-generation network, Linode delivers the performance that you expect at a price that you don't.
Get started on Linode today with a $20 credit and you get access to native SSD storage, a 40-gigabit network, industry-leading processors, their revamped cloud manager at cloud.linode.com, root access to your server, along with their newest API and a Python CLI.
Just visit talkpython.fm/Linode when creating a new Linode account and you'll automatically get $20 credit for your next project.
Oh, and one last thing.
They're hiring.
Go to linode.com slash careers to find out more.
Let them know that we sent you.
I do want to come back and ask you a question about this importance of learning computer programming for the future grad students and whatnot.
One of the things I think is interesting here is probably that means people are seeing more and more data that they need to work with.
That's probably one angle I would suspect that's pretty straightforward.
I wonder another one about just almost like sort of grant money angles as well.
Because when you're a new grad student or postdoc, maybe you don't have a grant yet.
Maybe you don't have a lot of resources.
And with things like Python and the SciPy space and whatnot, you know, it doesn't matter if you have money or not.
You have some of the best computational tools in the world.
Those ones that people used to find black holes and work from the Higgs boson and whatnot.
And you get those tools for free as well.
What do you think about that angle?
Yeah, well, I mean, for us, it's actually that's the truth is that there's things that I wouldn't have been able to do.
Some of it is going data mining on our own data that we've accumulated.
And I'm about to do the same thing with a colleague of mine that I write a blog with.
We're going to go data mine three different data sets that have just been laying there that have a piece of information that would be really useful together, especially.
That, you know, doing it by hand or by Excel, which is I think it's an insurmountable task.
But programming makes that possible.
And then the other thing is, as you mentioned, a lot of this move for all of science and funding agencies, especially, are asking people to make their data public.
Some journals also ask to put your code public.
So now, really, you have access to all these things that maybe I can't collect this data.
Maybe I can't do this, but I have access now.
I can download it.
I can search through it.
I can ask new questions on old data.
Right.
Get their Jupyter notebook and their data, and then you can start thinking from there, right?
You can start exploring and changing it and slicing it differently and trying to make discoveries, right?
Yeah.
And I think that's the whole push towards open data is when you do clinical studies, for example, clinical trials to see if an intervention works.
Well, that's important.
But then, really, it's the meta-analysis, the thing that puts it all together.
And so that push for people to present the data in their papers in a way that could be useful for scientists who do science on science.
They analyze all the studies, put them together and say, overall, the evidence is this.
Well, similarly, I think this is where coding and open data can help is let's not reinvent the wheel.
And some of these data sets can be combined or they can be just searched.
And by people who have completely different ideas that you'd never thought of, but somebody is going to go out there and just either contact you or just themselves, just move on with that data.
And I think just progress will happen a lot faster and more efficiently.
And that kind of research, as you're pointing out, doesn't really need any grant money.
I mean, you can work on a fairly cheap machine and just get the data and try out a few things.
And I think that's where it's going to, definitely.
Big data, but big collaboration as well.
Right.
It needs time, but it doesn't need money for resources potentially, right?
Yeah.
It's a culture change because of the incentives.
There's a lot of incentive to be exclusive.
I own this data set.
I'm the one who collected it.
And my group pushes these results out.
And I don't want to be scooped by anybody else, for example.
Some of that I can understand.
Right.
There's still discoveries to be made in this data.
And here's our first one.
Yeah.
But we're hanging on to it for the rest, right?
Which is, yeah, I understand that.
That might be a hard thought to get that.
Yeah.
And so I think it's a culture change that way.
It's a gradually, I think, that people will be more transparent.
And hopefully, you know, and you can see putting an embargo saying, you know, we'll make it public,
but in a certain amount of time.
But at some point, but the competition for these things is quite high.
So therefore, you can see why some people like to kind of hoard their data a little bit and
not necessarily make it publicly available.
But the move is for a lot of the top journals to require people to put their data in some
form on public repositories.
So the move is there.
And if you're funded, actually, a lot of funding agencies in Europe, and I think the NIH has
some of these policies, is that if you're funded by us, well, you're going to make your data
available to others.
Right, right.
This is ultimately paid for by the taxpayers.
This is not yours.
So share.
Exactly.
Right.
Similar for open publication is that, you know, we're giving you the money to do this.
Therefore, when you publish, you have to publish in open source journals, or you're going to
pay the fee to make it an open publication within that paywall journal.
So those are similar in terms of the move towards open science.
Sure.
Well, one of the interesting things that you've written about, and I think it comes back to this
sort of, which comes first, but one of the challenges is the life cycle and the openness
or the lack thereof of the data and the algorithms and the libraries for science is not necessarily
the same as for random software project by software developers, right?
Say versus Flask, right?
You talked about some of the important lessons that people in the science space can take from
the computer science side of things, things like GitHub and issue tracking and whatnot.
Do you want to talk about that a bit?
Well, it's computer science.
And I was always thought, why is that called a science?
Really?
Aren't they just, you know, nerds or geeks on the computer?
And I had that false perception, obviously.
And now I'm kind of one of those people myself to some extent.
But when I was starting out, it was all just, isn't it just a mishmash of they're just typing
and there's no rhyme or reason about it.
And to be honest, it's kind of interesting.
I coded MATLAB for the longest time and I had so many misconceptions.
My code was, my PhD code was two scripts that were, you know, and I thought it was cool
that I had like 3,000 some lines of code.
Yeah.
I had so much copy and paste.
It was very embarrassing.
I don't want to go back to that because I just didn't know any better.
And the people who taught me didn't know any better.
Right.
Nobody said, what are you doing here?
They're like, well, that looks like mine.
So this must be fine.
Exactly.
Yeah.
So it's just an inheritance.
It's just this, unfortunately, the natural selection is in the wrong direction in this case.
So gradually, you know, I read up more about it.
Software carpentry pointed me in a good direction.
And then I read some books.
I fell upon your podcast and then Brian Hawkins as well.
And I started realizing that all this stuff has already been figured out, which obviously
is obvious.
People have figured this out in, you know, a long time ago in the 70s, 80s.
And up till now, it's just so much simpler.
The workflow, all the things like GitHub with making suggestions or changes and all those
kind of things, pull requests.
Right.
You put your code up there.
Somebody will find, if they find something wrong, they'll put an issue in there.
If they can fix something or improve something, they'll do a PR.
And it's, you know, science talks so much about this research study is valid.
We know the Big Bang happened this way because this is peer reviewed, right?
Yeah.
And I mean, that's kind of what GitHub is.
Just less formally, less credentialed, but in a sense, right?
Yeah.
But what's interesting there is I spoke to, we have a floor meeting once a week.
And just before Christmas, I did talk about this comparison of what we can learn from computer
scientists.
And that was a bit what I was pointing out was that a computer scientist will write their
code and do it as best as they can and then put it up there.
And in a sense, not that they expect there to be bugs because, you know, some people will
then go to the next step, which is they'll make tests for their code.
But there's still this knowledge that there possibly and most likely is a bug of some sort
or a case that I've not considered that if you throw it at my code, okay, it'll crash.
Whereas, and that's expected.
And then when you get a pull request, you're thankful and you say, you know, great.
It's not a improving the code.
It's actually a fixing a problem with my current code.
And it's this iterative process that happens over time for improvement versus in science.
And I realize this doesn't speak to everybody out there, but a vast majority of us, if we
do code, but even if we don't, we just do our work and then we polish it up into this little,
you know, either Word or PDF document that we submit to a journal.
And this polished final version has most of the time, no data attached to it.
It's just a few figures and some tables gets assessed by two, three other of my peers.
And they have no idea that, you know, all the steps that were taken.
There is research on this that kind of shows that the number of somewhat arbitrary decisions
that are made along the way to collect your data in terms of, okay, well, I'm going to use
this versus that.
I'm going to exclude these cases versus that.
I'm going to use this test or this filter setting versus that.
There's so many permutations that in the end, it's almost, of course, you're going to find
something significant, but in itself, it's just a self-fulfilling prophecy.
You're setting yourself up to find something.
And then as the Texas sharpshooter example, it's that thing of the guy who, he's got a barn
and there's bullet holes in the barn and there's always a red circle around it.
And there's a guy who comes by and he says, wow, do you hit that every time?
And he goes, yeah, I'm so good.
And then his wife comes out and then she says, he actually just shoots.
And he draws a circle around it afterwards.
So if you want to find something, you'll find it.
And yeah, there's just, I don't want to say that I'm a skeptical about other scientists,
but we are one of the people I work with, Simon Gandivia, does a lot of work on cognitive biases.
And we have to almost protect ourselves from our own science in a sense, because the people
doing it aren't the computers, it's us.
We have to make the decisions.
And without knowing it, we have these, and a bias is that, is that you're not aware of it.
Somebody might even point it out to you and you might just not acknowledge that it's there.
You might think that doesn't apply to me, but I know other people that it applies to.
And so we just have to come up with ways.
And I think that coding, making decisions before the data comes in and making it transparent,
it's one of the ways that we can improve what we do.
And so in terms of things that we can learn from computer scientists, I think, for example,
the push towards publishing the data and the code, it's so interesting because once we publish it,
if I make that, it's a big stress on people.
Currently, it's almost like some people don't even make an effort to clean the data or the code
because they don't want anybody to use it.
Right, right.
Just leave it totally obscure and like, well, I have no idea what this does.
And the variable names are bad.
And what is this about?
And just, ah, forget it, right?
That's the hopeful outcome.
Yeah.
And somebody looked at that as well and saying that I think it's over 80% of the data sets
that are out there or code is actually not really useful.
But if you think of it from a computer science point of view, well, that's actually almost the
start of it, right?
Unless you have a very big group and there's been multiple eyes on the code, this might be the
first public appearance of this code.
And it would be nice if people had the chance to look at it, run it a few times, figure out
if there's any issues.
But the risk of that, the way the current publishing system works is that if anybody finds a genuine,
not more just, not a little error, but anything that's of significance, that means the paper
probably will need to be retracted, which is a huge deal in science.
Right.
Versus in computer science, well, sure, put a pull request and I'll fix that for you.
They're humble enough to know that I'm not perfect.
There's going to be things, I may have made a mistake in this versus in science, it's what
we publish and we just want to move on.
We want to just, you know, that thing's something on my CV.
I've ticked that box, another number and I move forward.
So that's one lesson that I don't know how to incorporate it exactly in terms of the workflow
of how we do things.
It's very tricky because the incentives are sort of opposed to the right behavior somewhat,
as you described about like, if there's a big problem, we're going to have to retract the
paper.
There are some things trying to solve that a little bit like Joss, Journal of Open Source
Software.
Are you familiar with that?
Yeah.
So, I mean, you can publish the code there and get some eyes on it, but fundamentally, right,
eventually you've got to take it and do the research.
And if the problem is found afterwards, it's bad.
But at the same time, I mean, isn't really the zen of science to get it right?
Again, the pressure, the time constraint that we all have makes it that it doesn't happen.
But another lesson from computer science, part of this was listening to Brian Okken and his
podcast and then also trying to get through his book, which is really good.
But again, it's that thing of it's good, but it doesn't really apply, or at least I couldn't jump
into it and directly apply it because it's too big of a step for what I do because most of the code,
some of it is reusable, but a lot of it is case specific.
And so to build up a whole test suite around my code seems a bit overkill, but that's definitely
a way to prevent the issues that if I could test my code, maybe simulate some data.
That'd be very useful.
And I think it's a great lesson, right?
Take some pytest and write some tests or even in MATLAB or whatever.
But I do think testing science is harder than testing a lot of things that people talk about
testing when they talk about unit testing.
For example, if I write a test for my online course site, right?
I want to test that users can sign up, but they can't sign up if they pass a bad email
address or something like that, right?
Here's a good email address.
It returns true.
Email is valid.
Here's a bad email address.
It returns false.
Email not valid.
But if I have, here are some wiggles and gravity.
Was that a black hole collision?
Like, I don't know.
We've never observed it before.
I'm not even like, you know, like, you know what I'm getting at?
It's just like, it's really hard.
And so, I don't know.
Do you have any advice?
Like, maybe take data that you know the outcome of and then try to run your code and predict
something that you know should be some way?
Or I don't know.
What do you advise people like?
Because it seems much harder from a software side to write the right test for that kind
of stuff.
Yeah, I definitely think that's the test your code where it's possible in terms of just
line to line or functions.
But then when it actually is interfacing with the data, I think simulating the data or a
data that's already been, you know, analyzed and processed.
Those are the two things that I think have to be done a little bit more.
And some fields just do it innately, whereas we don't.
And sometimes there's a limitation to how much we can test the code in this case.
But I think that being able to simulate data and having it know the outcome before you
run it through it, it gives you at least some amount of certainty.
So yeah, that's one thing that people could start doing a little bit more.
But where do they start?
I mean, for myself, that's one that I don't know how.
There's Greg Wilson, the founder of Software Carpentry, has this series of papers on, in
a sense, best computer practices, scientific computer practices, and good enough.
And in there, it's true.
We don't have enough time to be perfect.
So good enough for most of us is good.
And he mentions testing your code.
But that's where it ends, is that, you know, he might put a reference.
But I don't necessarily think that the current way to do it for, you know, big software programs
or projects translate all that well.
Obviously, some types of sciences, that's what it is, because it's all based around big programs
and big pipelines of data analysis.
But on the people that are more like myself, that do data collection themselves, they write
their code themselves, they write the papers themselves.
It's, I'm just not sure how to test my code.
Or if I do, it's going to be clunky, it's going to take me a long time.
And is it necessary to be at that level?
I would love for somebody.
But again, it's this thing, everybody's strapped for time.
And so somebody like Brian, obviously has no interest in writing a textbook or a blog series
on how can scientists test their code.
And also, it's the fact that we're so different, that the fields are so varied.
And so I still feel that while I think computer uptake in terms of programming, Python, those
types of things has definitely skyrocketed.
Some of the tools that come along with computer science haven't matured or morphed enough to
make it easily implementable.
So, you know, GitHub is something that version controls, obviously, another important thing
to talk about in terms of computer software.
And I think software carpentry teaches that on its two-day course.
And it's just logical, I mean, in terms of the way.
Yet scientists, I don't know, there's a comic strip called PhD, Piled Higher and Deeper.
And there's this one that everybody puts up as a slide often.
It's the, he has his thesis version as a doc, a Word document.
And it has a thesis version one doc, and then it has version 1.2.
And then it has final, and then final, final, and then final, final, underscore, dash, final
changes.
And I cringe because I actually looked back when I found that at my own thesis.
And that's exactly what I had.
You're like, look, this is an interesting naming convention.
It's slightly different than mine.
Exactly.
Everybody kind of laughs at it when you show it.
But really, there's no great workaround.
Because, you know, like a Word, for example, does have this inbuilt thing that you can, you
know, track changes, everybody loves it.
But once you accept that change, it's gone.
So if you want to have a history of it, you need to save a new version of it.
And there's the more collaborative online things that, you know, Google Docs and stuff like
that.
But still, the idea of having a history, and in a sense, that's what science is about, is
being able to show from the raw data, all the steps that were done.
And I think it should continue on to the manuscript as well.
So version control is another important lesson that we can apply, I think.
I just noticed that Google Docs, I know they had a version history, but you can tag different
versions, which is kind of cool.
Like, so you could have final, final, final, final changes.
Just in one doc, right?
And I guess the last thing to highlight, I think that, again, I'm a bit of a geek, so
I'd actually like to do this.
But the people I've been surrounded generally aren't people who code and especially don't
code in Python.
But this idea of a code review.
Yeah.
I was baffled to hear that people actually do that.
Like, people sit in a room and present code.
And I was just like, that would be, as a person who doesn't know how to code or just learning,
to just sit in on that would be useful.
And then also to sit there and have other people who code kind of critique it, but also improve
it or see if there's any issues and help answer some of my questions.
I'm like, wow.
And I'm sure it happens in some bigger labs.
Yeah.
But on the day-to-day, pretty much my second personality is the person I do my code review
with.
That's about all I have is I just sit there and I, does this make sense?
Talk out loud, maybe.
And it's another way that, although it seems currently that the publication, once it's out
there, you don't want any problems to be found because you may have to retract it.
So what can be done beforehand?
Well, you know.
Right.
How much can you bring that up ahead of the release?
Exactly.
Yeah, yeah, yeah.
Absolutely.
Yeah.
So that's one other thing that we could do.
But the time constraints make it that it just, unfortunately, I haven't seen it implemented
very much.
Well, I think it's probably, it sounds to me like it's, in my experience, working in
like a cognitive science research lab and some other stuff, I feel like maybe it's time,
but even the bigger challenge is expertise, right?
Usually, you know, who are you going to go to?
Because you're the person that knows the most about that.
So here we are.
I'm going to do what I can, right?
Yeah.
I think it would be a really cool service to set up some kind of, not like GitHub, but
some kind of online thing.
Maybe you can link your GitHub profile to it or something where it allows scientists to donate
a little bit of time in order to receive code reviews of their code, right?
Like if I could put up my code into this project, you know, it'll still stay hidden, not going
to come out.
But if I agree to code review somebody's stuff collaboratively with them, then they'll do
it for me or someone else will do that for mine, right?
Like I earned a half hour of code review by doing a half hour for someone else.
Or I don't know.
It seems like there's probably some way to like put this out on the internet and create it in
a way where, you know, the 20 people that are doing this kind of thing actually could
get together and have a look and help each other out maybe.
Yeah.
No, I think that'd be useful.
And, you know, you have to find the people that you would trust to do that.
But it's similar to, you know, the earning beans for giving good feedback.
I think here you can earn trust points or whatever it would be.
And, you know, the quality of your comments and keeping it to yourself.
But yeah.
And proper coding practices, simply breaking it down into small, biteable chunks means that you
can reuse it yourself.
So once maybe you've got some feedback on a section or maybe somebody will tell you,
turn that into a function.
Well, then once it's been reviewed, you can kind of trust it.
But I think a lot of us just get into it.
We just want the answer.
And we, in a sense, we probably reinvent the wheel way too many times.
Yeah.
That's something I definitely saw a lot of is like, here's a huge long script with no
function or branching or other than an if statement.
You know, it doesn't have, it doesn't have a lot of structure to it, which means it's nearly,
it cannot be reused almost, right?
Exactly.
And one of the things you touched on is one of the big differences between scientific
computation code and like computer science, formal software developer code is you hinted
at it before, but it's like you often hear that code is read way more times than it's written.
It should be written first for the software developers.
And then secondly, so it also runs things like that, right?
Whereas with science code, it's like, once you get it working and you get the graph, you're
done.
You don't need to polish it.
You don't need to touch it again.
It works.
It did the thing.
We got the outcome.
We're going to come up with something different next time or whatever.
Right.
And I think that puts a very different kinds of pressure on organizing your code, reusing
your code, documenting your code.
There's just like all these different pressures.
And I'm not saying one is better than the other necessarily.
If your job is to like, I got to quickly analyze this data and get it out.
Like, I'm not going to tell you all.
And you have to make a package while you're at it, right?
Like, that's not your problem.
But it does mean the code is treated differently.
It potentially has errors lurking in different ways and so on, right?
Yeah.
And I think that's the workflow hasn't been adapted very much to the lifecycle of the kind
of code that we would write.
And I think it's the lesson of take as much as you can and turn it into functions and things
that you can reuse.
And then, you know, build tests around those, for example, or have code reuse on those.
And then the nuances for this current study, well, that'll be, you know, something to maybe
just be a little bit more careful about and maybe have somebody look at it or check the
outputs.
But it's true that, you know, I was listening to it really rung a bell when Brian Okken said
that about, you know, in terms of testing, why not?
When once the test is built, once the code is written, you're going to make it legible,
obviously make it clear, but also make sure that it's correct because it's, you're going
to be looking at this over and over and over.
And it's going to, you know, whereas in science, I write all the time.
I read very little code.
I barely know how to read other people's code.
And that's interesting to me too, because I'm sure that with all your experience of the
various languages that you know, you can kind of look at different code and kind of pick
up quickly the general structure of things, even if the variable names are funny or versus
for me, because I've got such a personal style that I've kind of adopted based on the
various things, the resources I've used, you know, I can read my code very well.
But then the second I go just slightly differently, I'm just bleary eyed.
I'm like, what are they doing here?
And I can't.
And it's because we were very much just code for ourselves.
Not everybody, but many scientists code for themselves or maybe one other person.
Yeah.
And so it makes it a little bit more difficult.
But that idea of code reviews, I agree that if you can't, somebody else doesn't know how
to code, well, they're not going to be able to help you with the line to line things.
And while I have a bit of a love hate relationship with Jupyter notebooks, the one thing that I've
think that they're really useful for is you can sit in a room with your lab group, for example,
and you can intertwine code with outputs, with figures, and you can tell the story of
your code.
And while the, you know, if there's a, you're calling the wrong function or there's a little
bit of a mistake, those might be more difficult for others who don't code defined, but at least
the structure of your code, what it's doing, what it's exceptions that it's trying to catch.
You can do that.
I mean, I think Python's very readable as a language, but I think that the Jupyter notebook
makes it even more accessible because you can document it.
You could put little interpretations here and there, and then the figures are output.
It's kind of a way to do a bit of a code review for people who would probably run away from
that and be a bit scared of saying, let's come to this code review at 12 today.
Nobody's going to show up, but if you can, come on, I'm going to show you how I analyze
my data and I'll show you some results.
You can kind of secretly put in a bit of a code review.
You can hide it in a Jupyter notebook.
Yeah.
Disguise it.
Exactly.
That's a good idea.
Very, very cool.
Well, you know, thinking through this, looking back on what you've been saying,
it does sound like there's some interesting things to take from the computer science world
and adopt into the scientific world.
But I would say one really good thing that it seems to me is if what we're doing is moving
people from Excel into something like Python, even if there's fewer tests than maybe ideally
and whatnot.
Surely the code can be more validated in Python or Jupyter than it could be as it is in Excel,
right?
So that's got to be good for reproducibility and correctness.
Yeah.
No, I totally agree.
And simple lessons about, you know, variable naming and just how to structure the code into
functions.
The more functions you have, then the main script, if you like, just becomes very readable.
If you give it in one of your courses, it's all about you highlighted, just make, I was
surprised at how long your function names were.
But on the other hand, they were so clear.
I'm like, I know exactly what this thing does versus I had this weird, I don't know where
I learned it, but you know, you had to abbreviate everything and keep everything as short as you
can.
Right, right, right.
And then six months from now, I can't remember what it does.
But when you take the time to just make a bit of a very clear descriptive function name,
then the main script actually reads really well.
And so those are little lessons that, you know, it'll help everybody interpret it a bit better.
And if you make that public, it's so much easier for somebody else to look at that, possibly
even reuse it.
Whereas if you open up an Excel spreadsheet, I don't even know, how would you find out all
the cells that have background computations or macros?
I don't even know how you get started.
I have no idea.
You can't go through every Excel, it's in Excel, there you got it, it's crazy.
Yeah, yeah.
Well, I really appreciate that comment.
I'm like, you're allergic to Excel, I'm allergic to comments.
So anytime I'm about to write a little name function and then give it a comment to say what
it should do, I'm like, oh, maybe its name should just be what it does.
And then we won't need a comment, will we?
Yeah, no, that was a good tip.
So I use that all the time there.
Awesome.
I really do like this good enough practices in scientific computing that you referenced.
And I'll be sure to put that in for the show notes.
But it's got like really easy to adopt and reasonable stuff.
So it's clear, concise steps.
That's really great.
All right, Martin, I think it's a good place to leave it for our main topic.
But before you get out of here, let me ask you the last two questions.
If you're going to write some Python code, do some research.
What editor do you use?
It's been PyCharm for a few years now.
And just to anybody who out there is an academic or a researcher, you can get a free pro license
if you just email them your academic email.
And you can renew it every year.
So it just gives you that extra bit of...
So if it comes from a .edu or something like that?
Exactly.
And then you get the functionalities for the scientific mode.
That's the main one I would use.
Right.
And you can actually access all the JetBrains programs, IDEs.
But personally, I just use PyCharm.
But yeah, so we can get a pro license as academics.
Nice editor and nice tip.
All right.
A notable PyPI package that you've run across that people should know about?
I would say one that I emulated because at the time it was a bit above my head.
But there's something called PsychoPy.
Yeah.
Not in psychopath, but psychology.
And it's this framework to test, to collect data in presenting different types of stimuli
that you might do in psychology, like visual illusions or sounds.
And it's a nice way they actually have now implemented it.
So you can actually design and run your experiments right on the web.
But you can also implement it on your own machines.
So PsychoPy is a group in England that's been doing that.
Just recently, there's a package called DABEST.
I think it's DABEST.
I don't know how to say it.
D-A-B-E-S-T.
Pi.
DABEST.
Yeah.
It's data analysis through estimation.
And it's pretty much there's this trend towards moving away
through from just simple p-values and just saying that something is significant or not
to providing appropriate estimates of these effect sizes.
And sometimes your data is parametric, which means normally distributed.
Other times it's not.
And so there's this move towards estimating these things in the confidence intervals.
But there's some of the statistical software doesn't do it for you.
So these people, I'm pretty sure they're from Singapore.
And it's cross-platform, but they have a version for Python.
And it gives you these beautiful plots.
It computes your estimates for you, but it gives you these wonderful graphs of the effects.
And it's all done through bootstrapping.
So it has no assumptions about the distribution of your data.
So that's a really neat one.
They came out, I think, just a few years, not even a year ago, I think.
So that's quite useful.
Yeah, those are great suggestions.
Awesome.
All right.
Final call to action.
People are out there.
Maybe they're scientists or do scientific computing.
They want to bring some more of these ideas from computer science to their world.
I would say for yourself, smallest, biteable chunk.
Implement something for yourself.
And then also just try to, in the tea room, coffee room, just mention it to people.
And if you hear about issues, don't sound like the smartass who says, why didn't you code that?
Just say, hey, if you want to sit down for two seconds, I can just show you something.
And because I think that there's this dualism of people who code and those who don't.
And I think that the magic of it for some people is a bit intimidating.
And so rather than keeping the magic for ourselves and being a bit elusive, I think just demystify
the whole thing and just say, hey, look, it's really simple.
Let's just do this.
And I think the more people can do that and make it part of the culture of how we do things,
I think that helps.
And support from above.
So the senior scientists who may not have come through a time when coding was available all
that readily or was a specialty, even if they don't want to themselves, support the
junior people and realize that, you know, for their future careers and just for the betterment
of reproducible science, try to support it if you can.
Very good advice and super interesting ideas.
Thanks for sharing them with us.
All right.
No, thank you, Michael.
You bet.
Bye.
See you.
This has been another episode of Talk Python to Me.
Our guest on this episode was Martin Haru, and it's been brought to you by Clubhouse and Linode.
Clubhouse is a fast and enjoyable project management platform that breaks down silos and brings teams
together to ship value, not features.
Fall in love with project planning.
Visit talkpython.fm/clubhouse.
Start your next Python project on Linode's state-of-the-art cloud service.
Just visit talkpython.fm/Linode, L-I-N-O-D-E.
You'll automatically get a $20 credit when you create a new account.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the
different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.