> "just get it done quickly" vs "take your time and do it right" There is no such thing as "do it right". There's your flawed and biased perception of what's r

> "just get it done quickly" vs "take your time and do it right" There is no such thing as "do it right". There's your flawed and biased perception of what's right, which doesn't take unknown unknowns into account. > Oops three years later you're locking into Python and your app is slow as hell Been using Python more than a decade, never had this problem. App slow as hell is always an eng culture problem. Shitty engineers will write slow code in any language. Don't do HFT in Python, don't write web apps in C. > Producing documentation and commenting code. Don't need it now. 10 years later ... The need for documentation doesn't skyrocket from 0 to 100 overnight. Don't need it now? Don't write it. Starting to feel the need? Start writing a little bit. The problem is not the decision to not write documentation. The problem is not re-evaluating this decision in 10 years. (another problem, based on your take, is treating documentation as binary: we either don't do it, or we're going all in) > We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours Do you think every team that uses Make has this problem? Again, sounds like it's a team problem, not tool problem.