> I think we as programmers vastly understimate how useful even basic programming would be to virtually anyone today.

I used to work in second-level support. Out of a department of maybe 12, I think 2 of us knew how to program. I hate to even begin to describe some of the things I saw people trying to do by hand, and we were a software development company. I remember pleading with this one guy, "Please, before you ever try to do something like that again, come find me and ask if there is a way to automate the job."

There are so many people that would stand to benefit if only they had so much exposure to programming that they could tell when it would be crazy to not grab the guy next to them and ask if a quick script might not turn a 2-day job into 1 hour's worth of work -- coding, testing, debugging, and execution all included. Sadly, even people (nominally) in technology jobs are ignorant of this.

From my experience, I've come across many individuals in academia who I've tried to suggest particular approaches to their choice of problem and be rejected because they are too proud or too afraid to learn something new. I'm not trying to be an ass when I do, because that would undermine my attempt to share information, but something as simple as suggesting "for i in list:" instead of "for i in range(len(list))):" is so offensive to them since they didn't learn it first when they learned how to program (and god-forbid they learn it from a second year graduate student).

May be biologists or people at Stanford (or biologists at Stanford) are less proud, but my experience here has made me stop trying to relate basic programming concepts to fellow academics.

I had the same experience in grad school, and I can tell you that giving people (good!) style advice when they don't ask for it is pretty pointless. It's kind of like giving grammar advice that wasn't asked for.

People need to be in the right frame of mind to learn new things. Otherwise, if they're getting their point across, just let them keep talking (or coding).

You're probably right about it seeming rude, comparing it to grammar advice makes is a good analogy--I didn't think about it like that.

Programmers are expected to give and receive style, performance, and idiomatic advice in every code review. Is there some way this sort of peer code review could be integrated into the academic process?

Principle Investigators (i.e. professors that run labs) could establish a code review process for code that their group produces, just like any other manager can establish such a process.

Many PIs don't have the expertise to do that well, and many of them don't especially value style, performance, or idiomatic code. You have to remember that most academic code gets used by 1-5 people, and is run something like 1-50 times total. In those cases, it's actually kind of ok that that code doesn't end up being maintainable.

The important risk, of course, is erroneous results. But good researchers generally find many independent ways to check their results, so ideally, bugs that affect results should get caught in that process.

I personally love writing high quality code, and I found the academic science attitude about code to be frustrating. But there are structural reasons for these attitudes, and it's wrong to imagine that you can change them by arguing in terms of things that software engineers find valuable. You'd need to make your case in terms of things that science PIs find valuable, and in the process of trying to do that, you might actually discover that what you wanted to argue for isn't so critical after all.

> You'd need to make your case in terms of things that science PIs find valuable, and in the process of trying to do that, you might actually discover that what you wanted to argue for isn't so critical after all.

This is a great sentence - thanks for contributing.

As part of my PhD, I developed a Maple package for deriving FEM element matrices from first principles. My supervisor, despite years of work related to FEM and having done a lot of Maple programming didn't understand a lot of my code as I used some Maple techniques he had never seen. Even after co-authoring a conference paper on it he still doesn't understand the details.

Sometimes, it can be the tools we use that end up forcing one into poor practices. Maple supports doing multiple substitutions if you pass it a list, but I found that if you had enough, it would just ignore part of the list. So, I had to code a workaround that looped through the substitutions one at a time.

My supervisor was very meticulous about verifying results. So, I verified my code against various known analytical solutions and showed good convergence.

So often I saw the same thing as you that the code is written for a single project and never run again (I've written code like that), so the attitude becomes why spend too much time on it?

Of course, Maple, Matlab, and Mathematica's interactive environments don't help matters as you're often working through the problem and then turning that session into a function or a script.

"I think we as programmers vastly understimate how useful even basic programming would be to virtually anyone today."

There is also the attitude that when a non-professional programmer does assemble a few lines of code, automates a particular task, thus saving countless of hours, and creating lots of value, the programmers go: "Pffft, thats not real programming, that's only scripting"

and the coworkers possibly go "Why the hell did you so that, that's not your job. Slacker!"

Usually because we have to fix / maintain the crap after it has evolved into a hideous mess.

The opportunities to do this are widespread. On the business side, I've worked with both non-technical and technical (but non-developer) people (in multiple orgs) manually doing things like comparing data in files, joining columnar data together in word processors, and copy and pasting numbers into a spreadsheet to do calculations - and spending hours of their day on it. After getting sick of it, they would approach me and ask if there was any way I could think of to help them speed the process up. The answer was often extremely simple, and wound up completely removing them from the process except for seeing the output. They were absolutely thrilled, since they were able to focus on their actual jobs instead of messing around with a thousand line spreadsheets. Extremely gratifying to be able to do that.

Even though so much has been automated (by dint of simply using systems that have useful 'inherent' automation) over the past 15 years, there's still to much fruit out there to picked like this. It's also interesting to note how once a non-developer needs to color outside the lines of a system they are working with when dealing with data processing, they may go right to the manual process since they don't have a way to extend a system themselves. This presents opportunities to help even as our systems get more sophisticated (or just more complicated. Perhaps especially as they get more complicated, since the path of least resistance may be "forget this incredibly convoluted junk! I'll just do it by hand!", which can be a completely rational course of action for them.)

>I think we as programmers vastly understimate how useful even basic programming would be to virtually anyone today.

>It's not that they are dumb, it's that they've never been exposed to the opportunity. And conversely, it's not because I'm smart, but I literally can't remember what it was like not to break things down into computable pattern

I think that this dynamic can make for a great opportunity for those that really enjoy the research side of things and who can write software and looking for alternatives outside of pursuing degrees, especially for those who are entrepreneurial.

>…but I wonder if we could achieve the same growth in capacity of intellect by teaching more computational thinking (and implementation)

My experience with working with neuro postdocs is in line with noobermin, and toufka comments. I'm not bummed out by it, but it's kind of like seeing that there is untapped value there to be exploited by me and many others who see the opportunity being ignored by others.

This is true, but it's probably important to point out how unique the situation is for biologists.

We, quite suddenly, have the ability to generate large data sets to address very particular problems. Since each experiment is different, this process cannot be automated, but the basic workflow never changes that much. All we need is to ask some basic questions about the data; the more complicated stuff is generally not very interesting, or even harmful, as we're ultimately dealing with very blunt tools. We want to know about simple correlations, feed things into statistics libraries, and visualize the data with a few well-known tools.

The result is that anyone who takes the time to learn a little programming knows most of what they need to know. You learn a few good libraries and you're done. Bonus points if you write a script to automate your workflow a little.

I'm not saying this is uncommon, but it seems especially lucrative for biologists currently. Even if you're just putting libraries together like Lego pieces, you're getting a lot done. You don't need to proceed into programmatic thinking, thought the reward is certainly there.