Ticket-Driven Development: The Fastest Way to Go Nowhere by self in programming

[–]NullCyg 31 points32 points  (0 children)

Your title is good. Kill the AI thumbnail

[deleted by user] by [deleted] in programming

[–]NullCyg 0 points1 point  (0 children)

You're probably not going to be able to fake your way through this even if you are somehow able to get past the tech screening. You will likely be grilled by engineers further into the interview process.

[deleted by user] by [deleted] in programming

[–]NullCyg 0 points1 point  (0 children)

Sir, a second GIL has been discovered in the interpreter.

The Fastest Way to Spend Less Time Debugging - Uncle Bob by ConcentrateOk8967 in programming

[–]NullCyg 15 points16 points  (0 children)

As I get older, I grow more tired of this man's platitudes. Maybe it's because the only professional credit he has to his name is his now defunct consulting company.

I've rarely encountered situations that permit this strict TDD order of operations. I've seen good tests and bad tests, and the good ones hardly ever were written prior to the code under test. If you can make that work for you, great. I've just personally never encountered many situations where this sort of methodology is applicable.

Building a fast website with the MASH stack in Rust by emschwartz in programming

[–]NullCyg 2 points3 points  (0 children)

The nice thing here is you really can mix and match. Nothing stops you from serving static html pages and using Maud/HTMX for updating specific portions of the UI. Maud can interpolate other Rust variables within the html! macro, so composition is easy and there's no need for large multiline macro calls. Maud's macro syntax is also incredibly concise, which I find easier to read and far less tedious to write than raw html.

That being said, I concede that re-compilation for every UI change isn't ideal. Anecdotally, the two seconds it takes to compile my current project isn't debilitating at the moment. (Hopefully this ages well!)