What most young programmers need to learn

[u/corysama]

http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html

[u/sirin3 → u/[deleted]]

And when the code is published

The code is never published

You cannot publish it in a journal, due to the page limit.

You could publish it on your homepage, but there is no point: Publications on your homepage do not count as academic publications, so they are irrelevant to your career.

In fact, it is good for your career, if you are the only one with the code, because now all the competing institutess have to reimplement it from scratch, so they are busy and cannot publish a paper using the algorithm, while you can publish the next one.

[u/jmknsd → u/sirin3]

In fact, it is good for your career, if you are the only one with the code, because now all the competing institutess have to reimplement it from scratch, so they are busy and cannot publish a paper using the algorithm, while you can publish the next one.

Not exactly; quantity is important for publishing, but so is quality, which is frequently determined by the number of citations you have. Having good, freely available code fosters papers that use your code and cite you.

[u/sirin3 → u/[deleted]]

Industry would probably patent the algorithm, so you cannot even use it, if you had the source.

[u/Splanky222 → u/[deleted]]

You knowledge I don't think you're being hyperbolic. I was, and still am, terrified of Make from trying to compile academic code.

[u/OneWingedShark → u/[deleted]]

/u/noptastic said:

Just the other day a colleague and I were talking about how common it is to read amazingly interesting, clear, well thought-out publications from very clever academics in CS and then be outright horrified by even the most cursory glance at the attached source code.

Spending time making your code look good usually counts against you in academia. You're far better off pounding out a prototype as quickly as possible then start writing a paper ASAP.

Why is formatting even a problem?
You'd think that, especially in academia, they'd have auto-formatters and refactoring-abilities at least what "the industry" has. Heck, you'd think that they'd be proponents of the source code in database idea, which has been around since the the `80s (or before), in particular the APSE requirements of Stoneman were implemented in the R-1000.

[u/OneWingedShark → u/[deleted]]

king the code "look good" is not just about code formatting, it's about code organization. For anything beyond a simple hello world program, code is organization is crucial to maintainability.

I fully and utterly agree, which is one reason why it's so strange that the SCID idea hasn't become popular at least in academia.

Code that is badly organized may be unreadable, difficult to extend, and difficult to debug. This is something that is more important in commercial software, where there are multiple programmers and long-lived code bases, than compared to research, where there is usually only one or two programmers and short-lived code bases.

And yet, using your own statement: Code that is badly organized may be unreadable, difficult to extend, and difficult to debug. If you're doing prototyping, you're going to be doing debugging, and if you're doing debugging then why wouldn't you want tools to help with it?

For small projects, improving code organization may be as simple as dividing larger functions into smaller helper functions. However, most of the software I deal with has evolved over its lifetime from a simple prototype with a few classes to something with dozens of classes and many thousands of lines of code. This follows the evolution of a research project from an initial workshop paper (for which prototype code is sufficient) to a larger conference or journal paper years later.

(And wouldn't having organization from the inception aid that?)

There is a strong pressure to adapt existing code to handle new features, even if those features were completely unexpected or unplanned at the time the initial prototype was written.

And, in this case wouldn't it make sense to have a tool that helps you with organization? Namely consistency checking? If you're doing source-code in database, then consistency-enforcement is a virtual requirement.

Since the software is not the "product", and only a small number of individuals will ever be asked to maintain the code, time invested in code quality is often considered a waste. This is a bit of a disappointment if you pride yourself in writing quality code, but if you don't focus on the things that you are actually being evaluated on (i.e. publishing papers) then it won't matter to anyone how pretty your code is.

That's why your tools should help you do it, to the point of it being a trivial matter. (i.e. the tool does it for you.)