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

So was the Internet, broadly speaking. Same for a lot of technology we rely upon; the question is: what changed it from a one-shot proof-of-concept into a product?

This is not a good rule of thumb, it depends on what your research is. In most cases I've dealt with (security) the academic software displays terrible performance characteristics and is very buggy. The industry application that surfaces years later does not have these problems but it doesn't present anything novel.

Previous HN discussion: "Why can't you guys comment your fucking code"

https://news.ycombinator.com/item?id=14692691

Copy&pasting my response there:

---

Why is code coming out of research labs/universities so bad?

1. DON'T SEE WHY CLEAR CODE MATTERS

Academic projects are typically one-offs, not grounded in a wider context or value chain. Even if the researcher would like to build something long-term useful and robust, they don't have the requisite domain knowledge to go that deep. The problems are more isolated, there's little feedback from other people using your output.

2. DON'T WANT TO WRITE CLEAR CODE

Different incentives between academic research (publications count, citation count...) and industry (code maintainability, modularity, robustness, handling corner cases, performance...). Sometimes direct opposites (fear of being scooped if research too clear and accessible).

3. DON'T KNOW HOW TO WRITE CLEAR CODE

Lack of programming experience. Choosing the right abstraction boundaries and expressing them clearly and succinctly in code is HARD. Code invariants, dependencies, comments, naming things properly...

But it's a skill like any other. Many professional researchers never participated in an industrial project, so they don't know the tools, how to share or collaborate (git, SSH, code dissemination...), so they haven't built that muscle.

The GOOD NEWS is, contrary to popular opinion, it doesn't cost any more time to write good code than bad code (even for a one-off code base). It's just a matter of discipline and experience, and choosing your battles.

the biggest difference, in academia you code on sunday night and actually, a very small number of people read your code. But in industry, you write a code and then it goes through a pipeline of multiple reviews, so you end up spending most of your time addressing all those comments, and also you do the same for the codes written by other people.

I've encountered academic code that implements the state of art, most efficient, algorithm for solving some problem.

The code that comes to mind had the following properties: over 20 years old; written in C and badly converted to C++ somewhere along the way (the stuff-all-the-globals-into-a-class approach); a combinatorial explosion of #define and #ifdef statements (covering all the experiments in the original paper)

In the paper, it is clear that one of the experiments wins, and why. So...

Step 1: remove all dead code.

Step 2: observe that the algorithm needs no dynamic memory allocation, remove all but 1 call to malloc, calloc, realloc, and free.

Step 3: the use of float can be replaced by correctly scaled 64-bit unsigned integers, with no loss of precision

Step 4: rewrite entirely in modern C++, this has two benefits, a) I get to use the library (judiciously, this simplifies the code enormously), and b) the code can send clearer messages to the compiler than the mid-90s liberal sprinkling of the 'register' keyword.

The net result is no asymptotic improvement whatsoever — arguably a slight improvement for very large N as heap performance starts to interfere, but nothing worth the effort.

However, the code now has tests (step 0), is clean and maintainable, is 10% of the size, and is 5-30x faster (depending on the shape of the data)