Ask HN: What’s the biggest difference between professional coding and academia? • Hacker News Board

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#11

Post by santaclaus » Sat, Jul 08, 2017, 2:01 AM UTC

yakult wrote: post #9

Academic code typically just has to work once or a handful of times, for a small number of highly expert users, frequently just for the author. Ease of update is of the essence - you'll rewrite most of it many times, as your understanding the problem change. You can use all sorts of ugly hacks so long as you get what you're after. If any of it ever becomes commercially released or whatever, there'll need to be a comp…

We've had good luck with some academic code bases in production -- ETH Zurich puts out some great code [1,2].

[1] https://github.com/libigl/libigl

[2] https://github.com/pybind/pybind11

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#12

Post by pgbovine » Sat, Jul 08, 2017, 2:11 AM UTC

What does "academia" mean to you? Are you an undergraduate student, a grad student, a postdoc, a research scientist, a professor (and if so, which level)? Relationships to software creation differ at each level.

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#13

Post by austincheney » Sat, Jul 08, 2017, 2:56 AM UTC

JavaScript and the web generally are a really big deal. Unless you are working close to the metal at some point you are probably going to have to write code that somehow works in a browser. The problem with this is that it doesn't resemble C++ or Java and very few people figure out how these technologies actually work.

Academia isn't preparing developers for this reality. Many will try to fake it or hide under imposter syndrome, which is fine if everybody in the company is an imposter, otherwise it is plainly obvious you are incompetent.

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#14

Post by killjoywashere » Sat, Jul 08, 2017, 3:12 AM UTC

epmaybe wrote: post #3

ams6110 wrote: post #2

Academia only worries about getting results for publishing. Testability, maintainability, clean design, all take a back seat because once the paper is done the author will likely never touch the code again.

Currently having this problem right now. The authors also don't respond to emails either.

Because they got new email addresses at faang.com :)

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#15

Post by sonabinu » Sat, Jul 08, 2017, 3:13 AM UTC

In most cases, not enough testing

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#16

Post by santaclaus » Sat, Jul 08, 2017, 3:25 AM UTC

For what it is worth, LLVM was birthed in academia.

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#17

Post by throwaway-emc2 » Sat, Jul 08, 2017, 3:29 AM UTC

"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth.

This is the biggest difference between academic and professional programming in a single pithy statement, from a paper that Knuth wrote.

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#18

Post by cbanek » Sat, Jul 08, 2017, 3:31 AM UTC

Operations. Forward and backward compatibility concerns. In professional coding, good enough beats cute implementations that no one will see.

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#19

Post by coherentpony » Sat, Jul 08, 2017, 3:35 AM UTC

Academics aren't paid to code. Academics are paid to do research.

Professional coders are paid to code.

Re: Ask HN: What’s the biggest difference between professional coding and academia?

#20

Post by tytso » Sat, Jul 08, 2017, 3:42 AM UTC

A number of Linux kernel developers have been working with a subset of the Usenix FAST (File systems and Storage Technologies) community. We hold a Linux FAST workshop after the FAST conference for the past few years.

A few years back, some of the researchers (professors and graduate students) claimed they were interested in more testing and possibly taking some of their work (Betrfs[1], specifically), and productionalizing it. In response, I spent a lot of time with kvm-xfstests[2] and gce-xfstests[3][4] testing infrastructure, cleaning them, making them work in a turn-key fashion, and providing lots of documentation.

[1] http://betrfs.org

[2] https://github.com/tytso/xfstests-bld/blob/master/Documentat...

[3] https://github.com/tytso/xfstests-bld/blob/master/Documentat...

[4] https://thunk.org/gce-xfstests

Not a single researcher has used this code, despite the fact that I made it so easy that even a professor could use it. :-)

The problem is that trying to test and productionalize research code takes time away from the primary output of Academia, which is (a) graduating Ph.D. students, and (b) writing more papers, lest the professors perish. (Especially for those professors who have not yet received tenure.) So while academics might claim that they are interested in testing and trying to get their fruits of the research into production code, the reality is that the Darwinian nature of life in academia very much militates against this aspiration becoming a reality.

It turns out that writing a new file system really isn't that hard. It's taking the file system, testing it, finding all of the edge cases, optimizing it, making it scale to 32+ CPU's, and other such tasks to turn it into a production-ready system which takes a long time. If you take a look at how long it's taken for btrfs to become stable it's a good example of that fact. Sun worked on ZFS for seven years before they started talking about it externally, and then it was probably another 3 years before system administrators started trusting it with their production systems.