Hacker News Reader

Comment by mikebenfield | Hacker News Reader

> You'd think people smart enough to pursue stem phds would understand basic programming abstractions, but that is often not the case.

Another way of looking at it: People doing STEM PhDs are extremely busy. They have to master the content in their field, keep up with new research, conduct their own research, write papers, go to conferences, give talks, teach, keep up with whatever department service responsibilities they have, etc.

They're smart people so they're going to be able to slap together some code that does what they need it to do. But to expect them to learn git and how to use it well, to learn about managing dependencies, about unit tests, about build systems, about best practices for documenting code, about programming abstractions or OOP whatever else... that's a lot to ask.

(And I say this as a STEM PhD who did learn all that stuff, more or less.)

View on HN

When I was writing code as part of my PhD/research, even if I knew how to do it well, I didn't have the time to do it properly. I still remember writing a specific algorithm to compute approximate rotation numbers and slapping it in the middle of the code that had to use it, because I didn't have time to refactor it to do it properly in an easy way (would need to pass around too much data). It did what it needed to do... and luckily, I didn't need to get back to it, since it would be a steaming piece of code (in C).

If I had to do this kind of things again, I might do them properly, but I'm not 100% sure. Back then, I had more pressing things to do than writing excellent code, since I was writing code to drive the research (as in, numerical investigation), not as proper research (the end results were theoretical results)

I would say if unit tests, build systems, documentation, abstractions, modern languages, and so on are valuable for productivity, reduced bugginess or ease of access for the next developers then the incentives exist for academic researchers to learn and use these tools.

I think the real problem in academia is the same as the problem in some organizations that also don't follow best practices: the people empowered to make the decisions about whether to invest people's time into improving testing, building, technical debt, or documentation do not actually believe that an increase in productivity, increase in access or decrease in bugginess will be achieved.

> I would say if unit tests, build systems, documentation, abstractions, modern languages, and so on are valuable for productivity, reduced bugginess or ease of access for the next developers then the incentives exist for academic researchers to learn and use these tools.

The time to learn all of this is almost like a field in itself say Software engineering.

I just need to get shit done.

I had a project to do bayesian hierarchical modeling. I wrote it from scratch in R without using a MCMC framework.

Yeah it's ugly, yeah it's slow. But I got initial results to satisfy my mentor and within the time limit of the summer internship. This is on top of learning two semesters worth of Bayesian statistic in 3-4 weeks.

Time isn't expendable and I can't devote my life to every single thing while neglecting other aspect (love, health, etc..).

Yeah your theory is nice only if you don't have a deadline, a life outside of work, etc...

>Yeah your theory is nice only if you don't have a deadline, a life outside of work, etc...

Not all academic disciplines are as hectic as yours. When I was in a top grad school, most of my colleagues were not under the stress you describe. And yet their code was still crap.

Incentives are a bigger reason than workload.

> When I was in a top grad school, most of my colleagues were not under the stress you describe.

Serious questions: Where was this amazing place? When were you there? Was it a STEMish PhD? Really.

I've never heard of a grad school in STEM these days that is anywhere near like that. I'd love to know because the way STEM PhDs are going in the US these days, I can't recommend them in general, only specific PIs and labs.

>Serious questions: Where was this amazing place? When were you there? Was it a STEMish PhD? Really.

Yes. Engineering. I don't like to reveal too much about my past, so I won't say the name. Suffice it to say that it's ranked in the top 10 for pretty much all engineering + many of the sciences. EE, CE and CS are all in the top 5.

It was a decade ago, though.

Workload all depended on your advisor and funding landscape. Some were very demanding, and they had miserable lives (mostly pointless, too - most of academia seems to be converging towards a race to the bottom). But not all professors were that way. Of course, standards still have to be met, and laid back professors' students usually took longer to get a PhD because they were more relaxed.

To give you an idea, two of my fellow group mates are now faculty members. And the one whose work was most like what you describe, and who did the best work IMO, never was able to secure a tenure track position.

The lifestyle you describe is really not worth the PhD you get in the end. The ROI is just not there - financially or otherwise.

It really does seem like luck is the thing, even in something like the ivory tower. It stinks, but all that hard work is the price of the lotto ticket; it still ends up being just plain luck in the end.

I also feel like it's a race to the bottom now. It used to be 'publish or perish', now it's 'funding or famine'. The paper numbers, impact, and truthfulness have nothing to do with anything. I see so many PIs that essentially end up as one income households, their spouse's, not their own. The 'good ones' just get pushed out or leave, an evaporative effect, leaving only the liars. The academy is in real trouble these days. It isn't on life support yet, but it's not able to climb the stairs anymore.

But most academic projects get thrown away after the paper is published. These things help software maintenance. But if I never need to maintain this code, why worry?

Even in computer science a lot of this holds true, and you're lucky if you find someone who both knows the specifics of their niche of the field well and knows how to write clean code.

I once had a quite respectable lecturer working for me, and his code was awful. But that was ok - we knew that. He was hired for his conceptual skills and domain knowledge, and we paired him with a junior developer that could take his raw output and turn them into cleaner code.

If you don't have the time to do it right, how are you going to find the time to do it all over again?

In academia, you don't have to. Make the prototype, write the paper, present it at the conference, job done.

It's some engineer's job to do it properly in an actual production setting.

> Make the prototype, write the paper, present it at the conference, job done.

No. One's point is to communicate one's ideas. Code is the only specification of a system detailed enough to reproduce the desired results. You wouldn't present an unfinished paper written in the equivalent of crayon so that particular attitude is the worst kind of lazy bullshit for people actually trying to make use of your hard work.

> It's some engineer's job to do it properly in an actual production setting.

Fuck this attitude so damn hard. As an academic, one _is_ the _first_ engineer who has a duty to lead one's colleagues - to mark as clearly as possible the path for those who come after. This "fuck you, got mine" attitude is unacceptable and unsustainable.

Don't worry about it, the vast majority of the code won't see light of day, there is no engineer who has to fix it for production, there is no production.

The idea is everyone writing everything the "right way" from the get-go would be premature optimization.

> The idea is everyone writing everything the "right way" from the get-go would be premature optimization.

The right way in this case doesn't mean AdapterFactoryBeanFactoryService-land. It means taking care that your code is clear, concise and correct for others skilled in the art. The fact that academic code exists at all, as an example, means that it _is_ in production. There's no excuse for shit code that isn't written for other human beings first and computers second.

> People doing STEM PhDs are extremely busy

We're all busy. How long do you think it takes for time spent learning good software development practices to pay for itself? Surely not longer than the length of a PhD.

Academics writing sketchy code is like software engineers writing sketchy docs. We all agree it's not ideal but we can understand why it happens.

Not like a STEM PhD, you're not.

When is your first and last meeting of the work week? 6am Monday to 7pm Friday? Have you taken more than 3 weekends off in the last 12 months? Do you measure your daily coffee consumption in gallons? And yes, I'm serious.

PhD-land is crazy, perhaps this is why sooooo many drop out.

> We're all busy.

Sure, but if the core of your job, the key skill you bring to the table, is writing software, you are (hopefully) going to find the time to learn best practices for writing software.

If that's not the core of your job, if your key skill is something else and writing software is just an occasional means to an end... maybe the incentives aren't there.

> How long do you think it takes for time spent learning good software development practices to pay for itself?

If you almost never write a program longer than 1000 lines and rarely use a program six months after you've written it, it may never pay for itself.

Don't get me wrong, I personally have an interest in good software development practices. I just understand why not everyone can or will take the time to learn them.

Reply on news.ycombinator.com