engine_jim's comments

When I am designing something, I often find myself making bulleted lists when I am unsure of what to do next. I find that my more insightful sessions result in written paragraphs rather than lists. So I agree with Jeff here.

"...heterosexuals driven by abnormal appetites." Like there is any shortage of those.

This is a debate I engage in often. You can write "prototype" code to solve an "algorithmic" or "scientific" problem and it can be sloppy, but if you are planning on integrating it into a large project your team will run into problems unless the code is extremely contained.

It's true that there is a growing rebellion against best practices and design patterns, and I think in many cases some practices are dogmatic. However, the part that disturbs me is that inexperienced programmers are using it as an excuse to not apply basic principles they don't understand in the first place.

I've seen experienced software engineers that are lazy and spend more time criticizing the work of others than actually producing anything themselves, and I've seen novices that have poor fundamentals but grind for weeks to solve difficult "scientific" problems albeit with horrendous code that proves to be not maintainable in the long run. I find that in the latter case (I'll call them "grinders"), the programmer takes much longer to solve their problem because they have such limited coding experience (I've been asked many times to help debug trivial problems that result from not understanding basic concepts like how recursion works).

The author of this article does a good job at identifying the characteristics of this low quality "scientific" code, especially that it uses a lot of globals, bugs from parallelism, and has other bugs and crashes that are not understood. The author seems to insinuate that testing is the way to mitigate the bugs and crashes, this is partially true but it's better to write code you understand in the first place instead of relying on testing to fix everything so you don't continually introduce new bugs.

Grinders can benefit from understanding best practices and learning programming and computer science fundamentals. That way they can make their code more robust, code faster, and truly understand when they should and shouldn't apply a best practice. Software engineers can improve by matching the work ethic of the grinders and explaining where the grinders are making mistakes.

Your experience sounds similar to mine. I used to write games from scratch in C/C++ and I would quit the projects after I wrote most of the engine code (which would take a few months), and had something presentable.

Back then there weren't engines like Unity and Unreal that solve most of the technical problems like rendering, and physics/collision detection. Even with these tools though, I still find it difficult to finish a project quickly because I spend so much time writing infrastructure code. For that reason I never do hackathons.